idnits 2.17.00 (12 Aug 2021) /tmp/idnits2960/draft-eddy-syn-flood-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 710. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2006) is 5877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '8' on line 640 == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: draft-ietf-rohc-tcp-field-behavior has been published as RFC 4413 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft Verizon Federal Network Systems 4 Expires: October 13, 2006 April 11, 2006 6 TCP SYN Flooding Attacks and Common Mitigations 7 draft-eddy-syn-flood-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 13, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes TCP SYN flooding attacks, which have been 41 well-known to the community for several years. Various 42 countermeasures against these attacks, and the trade-offs of each, 43 are described. This document archives explanations of the attack and 44 defense techniques so that implementers and users may better evaluate 45 them. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2 Theory of Operation . . . . . . . . . . . . . . . . . . . 4 53 3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 8 54 3.1 Filtering . . . . . . . . . . . . . . . . . . . . . . . . 8 55 3.2 Increasing Backlog . . . . . . . . . . . . . . . . . . . . 8 56 3.3 Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 8 57 3.4 SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.5 SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 59 3.6 Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10 60 3.7 Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10 61 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 66 A. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . 19 69 1. Introduction 71 The SYN flooding attack is a denial of service method taking 72 advantage of the state retention TCP performs for some time after 73 receiving a SYN segment to a port with a TCB in the LISTEN state. 74 The basic idea is to exploit this behavior by causing a host to 75 retain enough state for bogus half-connections that there are no 76 resources left to establish new legitimate connections. 78 This SYN flooding attack has been well-known to the community for 79 many years, and has been observed in the wild by network operators 80 and end-hosts. A number of methods have been developed and deployed 81 to make SYN flooding less effective. Despite the notoriety of the 82 attack, and the widely available countermeasures, the RFC series has 83 not documented the vulnerability, nor suggested any mitigation 84 techniques for TCP implementations. The purpose of this document is 85 to satisfy both of these ends in an informational context. The 86 advancement (or need to advance) of mitigation techniques through the 87 standards track is left to be considered as further work. 89 This majority of this document consists of three sections. Section 2 90 explains the SYN flooding attack in greater detail. Several common 91 mitigation techniques are described in Section 3. An analysis and 92 discussion of these techniques and their use is presented in 93 Section 4. Further information on SYN cookies is contained in 94 Appendix A. 96 2. Attack Description 98 This section describes both the history and the technical basis of 99 the SYN flooding attack. 101 2.1 History 103 The TCP SYN flooding weakness was discovered as early as 1994 by Bill 104 Cheswick and Steve Bellovin. They included, and then removed, a 105 paragraph on the attack in their book "Firewalls and Internet 106 Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no 107 countermeasures were developed within the next two years. 109 The SYN flooding attack was first publicized in 1996, with the 110 release of a description and exploit tool in Phrack Magazine 111 [P48-13]. Aside from some minor inaccuracies, this article is of 112 high enough quality to be useful. This article contains code for the 113 attack and was widely distributed via the Internet. 115 By September of 1996, SYN flooding attacks had been observed in the 116 wild. Particularly, an attack against the Panix ISP's mail servers 117 caused well-publicized outages. CERT quickly released an advisory on 118 the attack [CA-96.21]. SYN flooding was particularly serious in 119 comparison to other known denial of service attacks at the time. 120 Rather than relying on the common brute-force tactic of simply 121 exhausting the network's resources, SYN flooding targets host 122 resources, which it requires fewer packets to deplete. 124 The community quickly developed many widely-differing techniques for 125 preventing or limiting the impact of SYN flooding attacks. Many of 126 these have been deployed to varying degrees on the Internet, in both 127 end hosts and intervening routers. Some of these techniques have 128 become important pieces of the TCP implementations in certain 129 operating systems, although some significantly diverge from the TCP 130 specification and have not yet been standardized or sanctioned by the 131 IETF process. 133 2.2 Theory of Operation 135 As described in RFC 793, a TCP implementation may allow the LISTEN 136 state to be entered with either all, some. or none of the pair of IP 137 addresses and port numbers given by the application. In many common 138 applications like web servers, none of the remote host's information 139 is pre-known or preconfigured, so that a connection can be 140 established with any client, and that client does not have to be 141 known to the server ahead of time. This type of "unbound" LISTEN is 142 the target of SYN flooding attacks, due to the way it is typically 143 implemented by operating systems. 145 For success, the SYN flooding attack relies on the victim host TCP 146 implementation's behavior. In particular, it assumes that the victim 147 allocates state for every TCP SYN segment when it is received, and 148 that there is a limit on the amount of such state than can be kept at 149 any time. The current TCP specification, RFC 793 [RFC0793], 150 describes the standard processing of incoming SYN segments. RFC 793 151 describes the concept of a Transmission Control Block (TCB) data 152 structure to store all the state information for an individual 153 connection. In practice, operating systems may implement this 154 concept rather differently, but the key is that each TCP connection 155 requires some memory space. 157 Per RFC 793, when a SYN is received for a local TCP port where a 158 connection is in the LISTEN state, then the state transitions to SYN- 159 RECEIVED and some of the TCB is initialized with information from the 160 header fields of the received SYN segment. In practice, this is not 161 really how things work. Many operating systems do not alter the TCB 162 in LISTEN, but instead make a copy of the TCB and perform the state 163 transition and update on the copy. This is done so that the local 164 TCP port may be shared amongst several distinct connections. This 165 TCB-copying behavior is not actually essential for this purpose, but 166 influences the way in which applications that wish to handle multiple 167 simultaneous connections through a single TCP port are written. The 168 crucial result of this behavior is that instead of updating already- 169 allocated memory, new (or unused) memory must be devoted to the 170 copied TCB. 172 As an example, in the Linux 2.6.10 networking code, a "sock" 173 structure is used to implement the TCB concept. By examination, this 174 structure takes over 1300 bytes to store in memory. In other systems 175 that implement less complex TCP algorithms and options, the overhead 176 may be less, although typically exceeds 280 bytes [SKK+97]. While 177 the exact size of the TCP connection data structures may vary between 178 implementations, it is always true that a received segment elicits 179 some allocation of resources. 181 To protect the host's memory from being exhausted by connection 182 requests, the number of TCB structures that can be resident at any 183 time is usually limited by operating system kernels. Systems vary on 184 whether limits are globally applied or local to a particular port 185 number. There is also variation on whether the limits apply to 186 fully-established connections as well as those in SYN-RECEIVED. 187 Commonly, systems implement a parameter to the typical listen() 188 system call that allows the application to suggest a value for this 189 limit, called the backlog. When the backlog limit is reached, then 190 either incoming SYN segments are ignored, or uncompleted connections 191 in the backlog are replaced. The concept of using a backlog is not 192 described in the standards documents, so the failure behavior when 193 the backlog is reached may vary (for instance, TCP RSTs might be 194 generated). The exact failure behavior will determine whether 195 initiating hosts continue to retransmit SYN segments over time, or 196 quickly cease. 198 The SYN flooding attack neither attempts to overload the network's 199 resources, nor the end host's memory, but merely to exhaust an 200 application's backlog of half-open connections. The goal is to send 201 a quick barrage of SYN segments from spoofed IP addresses that will 202 not generate replies to the SYN-ACKs that are produced. By keeping 203 the backlog full of bogus half-opened connections, legitimate 204 requests will be rejected. Three important attack parameters for 205 success are the size of the barrage, the frequency with which 206 barrages are generated, and the means of selecting IP addresses to 207 spoof. 209 Barrage Size 211 To be effective, the size of the barrage must be made large enough 212 to reach the backlog. Ideally, the barrage size is no larger than 213 the backlog, minimizing the volume of traffic the attacker must 214 source. Typical default backlog values vary from a half-dozen to 215 several dozen, so the attack might be tailored to the particular 216 value determined by the victim host and application. 218 Barrage Frequency 220 To limit the lifetime of half-opened connection state, TCP 221 implementations commonly reclaim memory from half-opened 222 connections if they do not become fully-opened after some time 223 period. For instance, a timer of 75 seconds [SKK+97] might be set 224 when the first SYN-ACK is sent, and on expiration cause SYN-ACK 225 retransmissions to cease and the TCB to be released. The TCP 226 specifications do not include this behavior of giving up on 227 connection establishment after an arbitrary time. Some purists 228 have expressed that the TCP implementation should continue 229 retransmitting SYN and SYN-ACK segments without artificial bounds 230 (but with exponential backoff to some conservative rate) until the 231 application gives up. Despite this, common operating systems 232 today do implement some artificial limit on half-open TCB 233 lifetime. For instance, backing off and stopping after a total of 234 511 seconds can be observed in 4.4 BSD-Lite [Ste95]. 236 To remain effective, a SYN flooding attack needs to send new 237 barrages of bogus connection requests as soon as the TCBs from the 238 previous barrage begin to be reclaimed. The frequency of barrages 239 are tailored to the victim TCP implementation's TCB reclamation 240 timer. Frequencies higher than needed source more packets, 241 potentially drawing more attention, and frequencies that are too 242 low will allow windows of time where legitimate connections can be 243 established. 245 IP Address Selection 247 For an effective attack, it is important that the spoofed IP 248 addresses be unresponsive to the SYN-ACK segments that the victim 249 will generate. If addresses of normal connected hosts are used, 250 then those hosts will send the victim a TCP reset segment that 251 will immediately free the corresponding TCB and allow room in the 252 backlog for legitimate connections to be made. The code 253 distributed in the original Phrack article used a single source 254 address for all spoofed SYN segments. This makes the attack 255 segments somewhat easier to identify and filter. A strong 256 attacker will have a list of unresponsive and unrelated addresses 257 that it chooses spoofed source addresses from. 259 It is important to note that this attack is directed at particular 260 listening applications on a host, and not the host itself or the 261 network. The attack also prevents only the establishment of new 262 incoming connections to the victim port, and does not impact outgoing 263 connection requests, nor previously established connections to the 264 victim port. 266 3. Common Defenses 268 3.1 Filtering 270 Since the ability to send packets with spoofed source IP addresses is 271 required for this attack to work, removing an attacker's ability to 272 send spoofed IP packets is an effective solution that requires no 273 modifications to TCP. The filtering techniques described in RFCs 274 2827, 3013, and 3704 represent the best current practices for packet 275 filtering based on IP addresses [RFC2827][RFC3013][RFC3704]. While 276 perfectly effective, end hosts should not rely on filtering policies 277 to prevent attacks from spoofed segments, as global deployment of 278 filters is neither guaranteed nor likely. An attacker with the 279 ability to use a group of compromised hosts or to move around in the 280 network will also make filtering an impotent solution. 282 3.2 Increasing Backlog 284 An obvious attempt at defense is for end hosts to use a larger 285 backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some 286 serious negative aspects as the size of the backlog grows [Lem02]. 287 The implementation has not been designed to scale past backlogs of a 288 few hundred, and the data structures and search algorithms that it 289 uses are inefficient with larger backlogs. It is reasonable to 290 assume that other TCP implementations have similar design factors 291 that limit their performance with large backlogs, and there seems to 292 be no compelling reason why stacks should be re-engineered to support 293 extremely large backlogs, since other solutions are available. 294 However, experiments with large backlogs using efficient data 295 structures and search algorithms have not been conducted, to our 296 knowledge. 298 3.3 Reducing SYN-RECEIVED Timer 300 Decreasing the timer that limits the lifetime of TCBs in SYN-RECEIVED 301 is also flawed. While a shorter timer will keep bogus connection 302 attempts from persisting for as long in the backlog, and thus free up 303 space for legitimate connections sooner, it can prevent some fraction 304 of legitimate connections from becoming fully established. This 305 tactic is also ineffective because it only requires the attacker to 306 increase the barrage frequency by a linearly proportional amount. 308 3.4 SYN Cache 310 The SYN cache, best described by Lemon [Lem02], is based on 311 minimizing the amount of state that a SYN allocates, i.e. not 312 immediately allocating a full TCB. The full state allocation is 313 delayed until the connection has been fully established. Hosts 314 implementing a SYN cache have some secret bits that they select from 315 the incoming SYN segments. The secret bits are hashed along with the 316 IP addresses and TCP ports of a segment, and the hash value 317 determines the location in a global hash table where the incomplete 318 TCB is stored. There is a bucket limit for each hash value, and when 319 this limit is reached, the oldest entry is dropped. 321 The SYN cache technique is effective because the secret bits prevent 322 an attacker from being able to target specific hash values for 323 overflowing the bucket limit, and it bounds both the CPU time and 324 memory requirements. Lemon's evaluation of the SYN cache shows that 325 even under conditions where a SYN flooding attack is not being 326 performed, due to the modified processing path, connection 327 establishment is slightly more expedient. Under active attack, SYN 328 cache performance was observed to approximately linearly shift the 329 distribution of times to establish legitimate connections to about 330 15% longer than when not under attack. 332 If data accompanies the SYN segment, then this data is not 333 acknowledged or stored by the receiver, and will require 334 retransmission. This does not affect the reliability of TCP's data 335 transfer service, but it does affect its performance to some small 336 extent. 338 3.5 SYN Cookies 340 SYN cookies go a step further and allocate no state at all for 341 connections in SYN-RECEIVED. Instead, they encode most of the state 342 (and all of the strictly required) state that they would normally 343 keep into the sequence number transmitted on the SYN-ACK. If the SYN 344 was not spoofed, then the acknowledgement number (along with several 345 other fields) in the ACK that completes the handshake can be used to 346 reconstruct the state to be put into the TCB. To date, one of the 347 best references on SYN cookies can be found on Dan Bernstein's web 348 site [cr.yp.to]. This technique exploits the long-understood low 349 entropy in TCP header fields [RFC1144][WM04]. In Appendix A, we 350 describe the SYN cookie technique, to avoid the possibility that the 351 web page will become unavailable. 353 The exact mechanism for encoding state into the SYN-ACK sequence 354 number can be implementation dependent. A common consideration is 355 that to prevent replay, some time-dependent random bits must be 356 embedded in the sequence number. One technique used 7 bits for these 357 bits and 25 bits for the other data [Lem02]. One way to encode these 358 bits has been to XOR the initial sequence number received with a 359 truncated cryptographic hash of the IP address and TCP port number 360 pairs, and secret bits. In practice, this hash has been generated 361 using MD5. 363 The problem with SYN cookies is that current schemes are incompatible 364 with some TCP options, if the cookie generation scheme does not 365 consider them. For example, an encoding of the MSS advertised on the 366 SYN has been accommodated by using 2 sequence number bits to 367 represent 4 predefined common MSS values. Similar techniques would 368 be required for some other TCP options, while negotiated use of other 369 TCP options can be detected implicitly. A timestamp on the ACK, as 370 an example, indicates that Timestamp use was successfully negotiated 371 on the SYN and SYN-ACK, while the reception of a SACK option at some 372 point during the connection implies that SACK was negotiated. Note 373 that SACK blocks should normally not be sent by a host using TCP 374 cookies unless they are first received. For the common 375 unidirectional data flow in many TCP connections, this can be a 376 problem, as it limits SACK usage. For this reason, SYN cookies 377 typically default to off on systems that implement them, and are only 378 enabled either under high-stress conditions indicative of an attack, 379 or via adminstrative action. 381 Similarly to SYN caches, SYN cookies do not handle application data 382 piggybacked on the SYN segment. 384 3.6 Hybrid Approaches 386 The SYN cache and SYN cookie techniques can be combined. For 387 example, in the event that the cache becomes full, then SYN cookies 388 can be sent instead of purging cache entries upon the arrival of new 389 SYNs. Such hybrid approaches may provide a strong combination of the 390 positive aspects of each approach. Lemon has demonstrated the 391 utility of this hybrid. 393 3.7 Firewalls and Proxies 395 Firewall-baed tactics may also be used to defend end-hosts from SYN 396 flooding attacks. The basic concept is to offload the connection 397 establishment proceedures onto a firewall that screens connection 398 attempts until they are completed and then proxies them back to 399 protected end hosts. This moves the problem away from end-hosts to 400 become the firewall's or proxy's problem, and may introduce other 401 problems related to altering TCP's expected end-to-end semantics. 403 4. Analysis 405 Several of the defenses discussed in the previous section rely on 406 changes to behavior inside the network; via router filtering, 407 firewalls, and proxies. These may be highly effective, and often 408 require no modification or configuration of end host software. Given 409 the mobile nature and dynamic connectivity of many end hosts, it is 410 optimistic for TCP implementers to assume the presence of such 411 protective devices. TCP implementers should provide some means of 412 defense to SYN flooding attacks in end host implementations. 414 Among end host modifications, the SYN cache and SYN cookie approaches 415 seem to be the only viable techniques discoverd. Increasing the 416 backlog and reducing the SYN-RECEIVED timer are measurably 417 problematic. The SYN cache implies a higher memory footprint than 418 SYN cookies, however, SYN cookies may not be fully compatible with 419 some TCP options, and may hamper development of future TCP extensions 420 that require state. For these reasons, SYN cookies should not be 421 enabled by default on systems that provide them. SYN caches do not 422 have the same negative implications and may be enabled as a default 423 mode of processing. 425 In October of 1996, Dave Borman implemented a SYN cache at BSDi for 426 BSD/OS, which was given to the community with no restrictions. This 427 code seems to be the basis for the SYN cache implementations adopted 428 later in other BSD variants. The cache was used when the backlog 429 became full, rather than by default, as we have described. A note to 430 the tcp-impl mailing list explains that this code does not retransmit 431 SYN-ACKs, which is a practice we would not encourage. 433 In 1997, NetBSD incorporated a modified version of Borman's code. 434 Two notable differences from the original code stem from the decision 435 to use of the cache by default (for all connections). This implied 436 the need to perform retransmissions for SYN-ACKs, and to use larger 437 structures to keep more complete data. The original structure was 32 438 bytes long for IPv4 connections and 56 bytes with IPv6 support, while 439 the current FreeBSD structure is 196 bytes long. As previously 440 cited, Lemon implemented the SYN cache and cookie techniques in 441 FreeBSD 4.4. Lemon notes that a SYN cache structure took up 160 442 bytes compared to 736 for the full TCB (now 196 bytes for the cache 443 structure). We have examined the OpenBSD 3.6 code and determined 444 that it includes a similar SYN cache. 446 Linux 2.6.5 code, also by examination, contains a SYN cookie 447 implementation that encodes 8 MSS values, and does not use SYN 448 cookies by default. This functionality has been present in the Linux 449 kernel for several years previous to 2.6.5. 451 Beginning with Windows 2000, Microsoft's Windows operating systems 452 have had a "TCP SYN attack protection" feature which can be toggled 453 on or off in the registry. This defaulted to off, until Windows 2003 454 SP1, in which it is on by default. With this feature enabled, when 455 the number of half-open connections and half-open connections with 456 retransmitted SYN-ACKs exceeds configurable thresholds, then the 457 number of times which SYN-ACKs are retransmitted before giving up is 458 reduced, and the "Route Cache Entry" creation is delayed, which 459 prevents some features (e.g. window scaling) from being used . 461 Several vendors of commercial firewall products sell devices that can 462 mitigate SYN flooding's effects on end hosts by proxying connections. 464 Discovery and exploitation of the SYN flooding vulnerability in TCP's 465 design provided a valuable lesson for protocol designers. The Stream 466 Control Transmission Protocol [RFC2960], which was designed more 467 recently, incorporated a 4-way handshake with a stateless cookie- 468 based component for the listening end. In this way, the passive- 469 opening side has better evidence that the initiator really exists at 470 the given address before it allocates any state. The Host Identity 471 Protocol base exchange [MNJH04] is similarly designed as a 4-way 472 handshake, but also involves a puzzle sent to the initiator which 473 must be solved before any state is reserved by the responder. The 474 general concept of designing statelessness into protocol setup to 475 avoid denial of service attacks has been discussed by Aura and 476 Nikander [AN97]. 478 5. Security Considerations 480 The SYN flooding attack on TCP has been described in numerous other 481 publications, and the details and code needed to perform the attack 482 have been easily available for years. Describing the attack in this 483 document does not pose any danger of further publicizing this 484 weakness in unmodified TCP stacks. Several widely-deployed operating 485 systems implement the mitigation techniques that this document 486 discusses for defeating SYN flooding attacks. In at least some 487 cases, these operating systems do not enable these countermeasures by 488 default, however, the mechanisms for defeating SYN flooding are well 489 deployed, and easily enabled by end-users. The publication of this 490 document should not influence the number of SYN flooding attacks 491 observed, and might increase the robustness of the Internet to such 492 attacks by encouraging use of the commonly available mitigations. 494 6. Acknowledgements 496 A conversation with Ted Faber was the impetus for writing this 497 document. Comments and suggestions from Joe Touch, Dave Borman, 498 Fernando Gont, and Jean-Baptiste Marchand were useful in 499 strengthening this document. 501 Work on this document was performed at NASA's Glenn Research Center. 502 Funding was partially provided by a combination of NASA's Advanced 503 Communications, Navigation, and Surveillance Architectures and System 504 Technologies (ACAST) project, and the Sensis Corporation. 506 7. Informative References 508 [AN97] Aura, T. and P. Nikander, "Stateless Connections", 509 Proceedings of the First International Conference on 510 Information and Communication Security 1997. 512 [CA-96.21] 513 CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP 514 Spoofing Attacks", September 1996. 516 [CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 517 Security", ISBN: 0201633574, January 1994. 519 [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN 520 Cache", BSDCON 2002, February 2002. 522 [MNJH04] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 523 "Host Identity Protocol", (draft-ietf-hip-base-03), 524 June 2005. 526 [P48-13] daemon9, "Project Neptune", Phrack Magazine, Volume 7, 527 Issue 48, File 13 of 18, July 1996. 529 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 530 RFC 793, September 1981. 532 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 533 serial links", RFC 1144, February 1990. 535 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 536 Defeating Denial of Service Attacks which employ IP Source 537 Address Spoofing", BCP 38, RFC 2827, May 2000. 539 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 540 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 541 Zhang, L., and V. Paxson, "Stream Control Transmission 542 Protocol", RFC 2960, October 2000. 544 [RFC3013] Killalea, T., "Recommended Internet Service Provider 545 Security Services and Procedures", BCP 46, RFC 3013, 546 November 2000. 548 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 549 Networks", BCP 84, RFC 3704, March 2004. 551 [SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, 552 A., and D. Zamboni, "Analysis of a Denial of Service 553 Attack on TCP", Proceedings of the 1997 IEEE Symposium on 554 Security and Privacy 1997. 556 [Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: 557 The Implementation", January 1995. 559 [WM04] West, M. and S. McCann, "TCP/IP Field Behavior", 560 (draft-ietf-rohc-tcp-field-behavior), October 2004. 562 [cr.yp.to] 563 Bernstein, D., "URL: http://cr.yp.to/syncookies.html", 564 visited in December 2005. 566 [win2k3-wp] 567 Microsoft Corporation, "Microsoft Windows Server 2003 568 TCP/IP Implementation Details", White Paper, July 2005. 570 Author's Address 572 Wesley M. Eddy 573 Verizon Federal Network Systems 574 21000 Brookpark Rd, MS 54-5 575 Cleveland, OH 44135 577 Phone: 216-433-6682 578 Email: weddy@grc.nasa.gov 580 Appendix A. SYN Cookies 582 This information is taken from Bernstein's web page on SYN cookies . 583 This is a rewriting of the technical information on that web page and 584 not a full replacement. There are other slightly different ways of 585 implementing the SYN cookie concept than the exact means described 586 here, although the basic idea of encoding data into the SYN-ACK 587 sequence number is constant. 589 A SYN cookie is an initial sequence number sent in the SYN-ACK, that 590 is chosen based on the connection initiator's initial sequence 591 number, MSS, a time counter, and the relevent addresses and port 592 numbers. The actual bits comprising the SYN cookie are chosen to be 593 the bitwise difference (exclusive-or) between the SYN's sequence 594 number and a 32 bit quantity computed so that the top five bits come 595 from a 32-bit counter value modulo 32, where the counter increases 596 every 64 seconds, the next 3 bits encode a usable MSS near to the one 597 in the SYN, and the bottom 24 bits are a server-selected secret 598 function of pair of IP addresses, the pair of port numbers, and the 599 32-bit counter used for the first 5 bits. This means of selecting an 600 initial sequence number for use in the SYN-ACK complies with the rule 601 that TCP sequence numbers increase slowly. 603 When a connection in LISTEN receives a SYN segment, it can generate a 604 SYN cookie and send it in the sequence number of a SYN-ACK, without 605 allocating any other state. If an ACK comes back, the difference 606 between the acknowledged sequence number and the sequence number of 607 the ACK segment can be checked against recent values of the counter 608 and the secret function's output given those counter values and the 609 IP addresses and port numbers in the ACK segment. If there is a 610 match, the connection can be accepted, since it is statistically very 611 likely that the other side received the SYN cookie and did not simply 612 guess a valid cookie value. If there is not a match, the connection 613 can be rejected under the heuristic that it is probably not in 614 response to a recently sent SYN-ACK. 616 With SYN cookies enabled, a host will be able to maintain responsive 617 even when under a SYN flooding attack. The largest price to be paid 618 for using SYN cookies is in the disabling of the window scaling 619 option, which disables high performance. 621 Bernstein's web page contains more information about the initial 622 conceptualization and implementation of SYN cookies, and archives of 623 emails documenting this history. It also lists some false negative 624 claims that have been made about SYN cookies, and discusses reducing 625 the vulnerability of SYN cookie implementations to blind connection 626 forgery by an attacker guessing valid cookies. 628 The best description of the exact SYN cookie algorithms is in part of 629 an email from Bernstein, that is archived on the web site (notice it 630 does not set the top five bits from the counter modulo 32, as the 631 previous description did, but instead uses 29 bits from the second 632 MD5 operation and 3 bits for the index into the MSS table; 633 establishing the secret values is also not discussed): 635 Here's what an implementation would involve: 637 Maintain two (constant) secret keys, sec1 and sec2. 639 Maintain a (constant) sorted table of 8 common MSS values, 640 msstab[8]. 642 Keep track of a ``last overflow time.'' 644 Maintain a counter that increases slowly over time and never 645 repeats, such as ``number of seconds since 1970, shifted right 646 6 bits.'' 648 When a SYN comes in from (saddr,sport) to (daddr,dport) with 649 ISN x, find the largest i for which msstab[i] <= the incoming 650 MSS. Compute 652 z = MD5(sec1,saddr,sport,daddr,dport,sec1) 654 + x 656 + (counter << 24) 658 + (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 << 659 24)) 661 and then 663 y = (i << 29) + (z % (1 << 29)) 665 Create a TCB as usual, with y as our ISN. Send back a SYNACK. 667 Exception: _If_ we're out of memory for TCBs, set the ``last 668 overflow time'' to the current time. Send the SYNACK anyway, 669 with all fancy options turned off. 671 When an ACK comes back, follow this procedure to find a TCB: 673 (1) Look for a (saddr,sport,daddr,dport) TCB. If it's 674 there, done. 676 (2) If the ``last overflow time'' is earlier than a few 677 minutes ago, give up. 679 (3) Figure out whether our alleged ISN makes sense. This 680 means recomputing y as above, for each of the counters that 681 could have been used in the last few minutes (say, the last 682 four counters), and seeing whether any of the y's match the 683 ISN in the bottom 29 bits. If none of them do, give up. 685 (4) Create a new TCB. The top three bits of our ISN give a 686 usable MSS. Turn off all fancy options. 688 Intellectual Property Statement 690 The IETF takes no position regarding the validity or scope of any 691 Intellectual Property Rights or other rights that might be claimed to 692 pertain to the implementation or use of the technology described in 693 this document or the extent to which any license under such rights 694 might or might not be available; nor does it represent that it has 695 made any independent effort to identify any such rights. Information 696 on the procedures with respect to rights in RFC documents can be 697 found in BCP 78 and BCP 79. 699 Copies of IPR disclosures made to the IETF Secretariat and any 700 assurances of licenses to be made available, or the result of an 701 attempt made to obtain a general license or permission for the use of 702 such proprietary rights by implementers or users of this 703 specification can be obtained from the IETF on-line IPR repository at 704 http://www.ietf.org/ipr. 706 The IETF invites any interested party to bring to its attention any 707 copyrights, patents or patent applications, or other proprietary 708 rights that may cover technology that may be required to implement 709 this standard. Please address the information to the IETF at 710 ietf-ipr@ietf.org. 712 Disclaimer of Validity 714 This document and the information contained herein are provided on an 715 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 716 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 717 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 718 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 719 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 720 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 722 Copyright Statement 724 Copyright (C) The Internet Society (2006). This document is subject 725 to the rights, licenses and restrictions contained in BCP 78, and 726 except as set forth therein, the authors retain all their rights. 728 Acknowledgment 730 Funding for the RFC Editor function is currently provided by the 731 Internet Society.