idnits 2.17.1 draft-ietf-tcpm-syn-flood-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 828. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 18, 2007) is 6211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '8' on line 731 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 11 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 Intended status: Informational April 18, 2007 5 Expires: October 20, 2007 7 TCP SYN Flooding Attacks and Common Mitigations 8 draft-ietf-tcpm-syn-flood-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 20, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes TCP SYN flooding attacks, which have been 42 well-known to the community for several years. Various 43 countermeasures against these attacks, and the trade-offs of each, 44 are described. This document archives explanations of the attack and 45 common defense techniques for the benefit of TCP implementers and 46 administrators of TCP servers or networks, but does not make any 47 standards-level recommendations. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 4 55 3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 8 57 3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 8 58 3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 8 59 3.4. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.5. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.6. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11 62 3.7. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 11 63 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 67 8. Informative References . . . . . . . . . . . . . . . . . . . . 17 68 Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 19 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 70 Intellectual Property and Copyright Statements . . . . . . . . . . 23 72 1. Introduction 74 The SYN flooding attack is a denial of service method affecting hosts 75 that run TCP server processes. The attack takes advantage of the 76 state retention TCP performs for some time after receiving a SYN 77 segment to a port that has been put into the LISTEN state. The basic 78 idea is to exploit this behavior by causing a host to retain enough 79 state for bogus half-connections that there are no resources left to 80 establish new legitimate connections. 82 This SYN flooding attack has been well-known to the community for 83 many years, and has been observed in the wild by network operators 84 and end-hosts. A number of methods have been developed and deployed 85 to make SYN flooding less effective. Despite the notoriety of the 86 attack, and the widely available countermeasures, the RFC series only 87 documented the vulnerability as an example motivation for ingress 88 filtering [RFC2827], and has not suggested any mitigation techniques 89 for TCP implementations. This document addresses both points, but 90 does not define any standards. Formal specifications and 91 requirements of defense mechanisms are outside the scope of this 92 document. Many defenses only impact an end-host's implementation 93 without changing interoperability. These may not require 94 standardization, but their side-effects should at least be well 95 understood. 97 This document intentionally focuses on SYN flooding attacks from an 98 individual end-host or application's perspective, as a means to deny 99 service to that specific entity. Often, high packet-rate attacks 100 that target the network's packet processing capability and capacity 101 have been observed operationally. Since such attacks target the 102 network, and not a TCP implementation, they are out of scope for this 103 document, whether or not they happen to use TCP SYN segments as part 104 of the attack, as the nature of the packets used is irrelevant in 105 comparison to the packet-rate in such attacks. 107 The majority of this document consists of three sections. Section 2 108 explains the SYN flooding attack in greater detail. Several common 109 mitigation techniques are described in Section 3. An analysis and 110 discussion of these techniques and their use is presented in 111 Section 4. Further information on SYN cookies is contained in 112 Appendix A. 114 2. Attack Description 116 This section describes both the history and the technical basis of 117 the SYN flooding attack. 119 2.1. History 121 The TCP SYN flooding weakness was discovered as early as 1994 by Bill 122 Cheswick and Steve Bellovin [B96]. They included, and then removed, 123 a paragraph on the attack in their book "Firewalls and Internet 124 Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no 125 countermeasures were developed within the next two years. 127 The SYN flooding attack was first publicized in 1996, with the 128 release of a description and exploit tool in Phrack Magazine 129 [P48-13]. Aside from some minor inaccuracies, this article is of 130 high enough quality to be useful, and code from the article was 131 widely distributed and used. 133 By September of 1996, SYN flooding attacks had been observed in the 134 wild. Particularly, an attack against the Panix ISP's mail servers 135 caused well-publicized outages. CERT quickly released an advisory on 136 the attack [CA-96.21]. SYN flooding was particularly serious in 137 comparison to other known denial of service attacks at the time. 138 Rather than relying on the common brute-force tactic of simply 139 exhausting the network's resources, SYN flooding targets end-host 140 resources, which it requires fewer packets to deplete. 142 The community quickly developed many widely-differing techniques for 143 preventing or limiting the impact of SYN flooding attacks. Many of 144 these have been deployed to varying degrees on the Internet, in both 145 end hosts and intervening routers. Some of these techniques have 146 become important pieces of the TCP implementations in certain 147 operating systems, although some significantly diverge from the TCP 148 specification and none of these techniques have yet been standardized 149 or sanctioned by the IETF process. 151 2.2. Theory of Operation 153 As described in RFC 793, a TCP implementation may allow the LISTEN 154 state to be entered with either all, some, or none of the pair of IP 155 addresses and port numbers specified by the application. In many 156 common applications like web servers, none of the remote host's 157 information is pre-known or preconfigured, so that a connection can 158 be established with any client whose details are unknown to the 159 server ahead of time. This type of "unbound" LISTEN is the target of 160 SYN flooding attacks due to the way it is typically implemented by 161 operating systems. 163 For success, the SYN flooding attack relies on the victim host TCP 164 implementation's behavior. In particular, it assumes that the victim 165 allocates state for every TCP SYN segment when it is received, and 166 that there is a limit on the amount of such state than can be kept at 167 any time. The current base TCP specification, RFC 793 [RFC0793], 168 describes the standard processing of incoming SYN segments. RFC 793 169 describes the concept of a Transmission Control Block (TCB) data 170 structure to store all the state information for an individual 171 connection. In practice, operating systems may implement this 172 concept rather differently, but the key is that each TCP connection 173 requires some memory space. 175 Per RFC 793, when a SYN is received for a local TCP port where a 176 connection is in the LISTEN state, then the state transitions to SYN- 177 RECEIVED and some of the TCB is initialized with information from the 178 header fields of the received SYN segment. In practice, this is not 179 really how things work. Many operating systems do not alter the TCB 180 in LISTEN, but instead make a copy of the TCB and perform the state 181 transition and update on the copy. This is done so that the local 182 TCP port may be shared amongst several distinct connections. This 183 TCB-copying behavior is not actually essential for this purpose, but 184 influences the way in which applications that wish to handle multiple 185 simultaneous connections through a single TCP port are written. The 186 crucial result of this behavior is that instead of updating already- 187 allocated memory, new (or unused) memory must be devoted to the 188 copied TCB. 190 As an example, in the Linux 2.6.10 networking code, a "sock" 191 structure is used to implement the TCB concept. By examination, this 192 structure takes over 1300 bytes to store in memory. In other systems 193 that implement less complex TCP algorithms and options, the overhead 194 may be less, although it typically exceeds 280 bytes [SKK+97]. 196 To protect host memory from being exhausted by connection requests, 197 the number of TCB structures that can be resident at any time is 198 usually limited by operating system kernels. Systems vary on whether 199 limits are globally applied or local to a particular port number. 200 There is also variation on whether the limits apply to fully- 201 established connections as well as those in SYN-RECEIVED. Commonly, 202 systems implement a parameter to the typical listen() system call 203 that allows the application to suggest a value for this limit, called 204 the backlog. When the backlog limit is reached, then either incoming 205 SYN segments are ignored, or uncompleted connections in the backlog 206 are replaced. The concept of using a backlog is not described in the 207 standards documents, so the failure behavior when the backlog is 208 reached might differ between stacks (for instance, TCP RSTs might be 209 generated). The exact failure behavior will determine whether 210 initiating hosts continue to retransmit SYN segments over time, or 211 quickly cease. These differences in implementation are acceptable 212 since they only affect the behavior of the local stack when its 213 resources are constrained, and do not cause interoperability 214 problems. 216 The SYN flooding attack neither attempts to overload the network's 217 resources, nor the end host's memory, but merely to exhaust an 218 application's backlog of half-open connections. The goal is to send 219 a quick barrage of SYN segments from IP addresses (often spoofed) 220 that will not generate replies to the SYN-ACKs that are produced. By 221 keeping the backlog full of bogus half-opened connections, legitimate 222 requests will be rejected. Three important attack parameters for 223 success are the size of the barrage, the frequency with which 224 barrages are generated, and the means of selecting IP addresses to 225 spoof. 227 Barrage Size 229 To be effective, the size of the barrage must be made large enough 230 to reach the backlog. Ideally, the barrage size is no larger than 231 the backlog, minimizing the volume of traffic the attacker must 232 source. Typical default backlog values vary from a half-dozen to 233 several dozen, so the attack might be tailored to the particular 234 value determined by the victim host and application. On machines 235 intended to be servers, especially for a high volume of traffic, 236 the backlogs are often administratively configured to higher 237 values. 239 Barrage Frequency 241 To limit the lifetime of half-opened connection state, TCP 242 implementations commonly reclaim memory from half-opened 243 connections if they do not become fully-opened after some time 244 period. For instance, a timer of 75 seconds [SKK+97] might be set 245 when the first SYN-ACK is sent, and on expiration cause SYN-ACK 246 retransmissions to cease and the TCB to be released. The TCP 247 specifications do not include this behavior of giving up on 248 connection establishment after an arbitrary time. Some purists 249 have expressed that the TCP implementation should continue 250 retransmitting SYN and SYN-ACK segments without artificial bounds 251 (but with exponential backoff to some conservative rate) until the 252 application gives up. Despite this, common operating systems 253 today do implement some artificial limit on half-open TCB 254 lifetime. For instance, backing off and stopping after a total of 255 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still 256 practiced in some operating systems derived from this code. 258 To remain effective, a SYN flooding attack needs to send new 259 barrages of bogus connection requests as soon as the TCBs from the 260 previous barrage begin to be reclaimed. The frequency of barrages 261 are tailored to the victim TCP implementation's TCB reclamation 262 timer. Frequencies higher than needed source more packets, 263 potentially drawing more attention, and frequencies that are too 264 low will allow windows of time where legitimate connections can be 265 established. 267 IP Address Selection 269 For an effective attack, it is important that the spoofed IP 270 addresses be unresponsive to the SYN-ACK segments that the victim 271 will generate. If addresses of normal connected hosts are used, 272 then those hosts will send the victim a TCP reset segment that 273 will immediately free the corresponding TCB and allow room in the 274 backlog for legitimate connections to be made. The code 275 distributed in the original Phrack article used a single source 276 address for all spoofed SYN segments. This makes the attack 277 segments somewhat easier to identify and filter. A strong 278 attacker will have a list of unresponsive and unrelated addresses 279 that it chooses spoofed source addresses from. 281 It is important to note that this attack is directed at particular 282 listening applications on a host, and not the host itself or the 283 network. The attack also attempts to prevent only the establishment 284 of new incoming connections to the victim port, and does not impact 285 outgoing connection requests, nor previously established connections 286 to the victim port. 288 In practice, an attacker might choose not to use spoofed IP 289 addresses, but instead to use a multitude of hosts to initiate a SYN 290 flooding attack. For instance, a "botnet" could be used. In this 291 case, each host utilized in the attack would have to suppress its 292 operating system's native response to the SYN-ACKs coming from the 293 target. It is also possible for the attack TCP segments to arrive in 294 a more continuous fashion than the "barrage" terminology used here 295 suggests; as long as the rate of new SYNs exceeds the rate at which 296 TCBs are reaped, the attack will be successful. 298 3. Common Defenses 300 This section discusses a number of defense techniques which are known 301 to the community, many of which are available in off-the-shelf 302 products. 304 3.1. Filtering 306 Since in the absence of an army of controlled hosts, the ability to 307 send packets with spoofed source IP addresses is required for this 308 attack to work, removing an attacker's ability to send spoofed IP 309 packets is an effective solution that requires no modifications to 310 TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 311 represent the best current practices for packet filtering based on IP 312 addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, 313 end hosts should not rely on filtering policies to prevent attacks 314 from spoofed segments, as global deployment of filters is neither 315 guaranteed nor likely. An attacker with the ability to use a group 316 of compromised hosts or to rapidly change between different access 317 providers will also make filtering an impotent solution. 319 3.2. Increasing Backlog 321 An obvious attempt at a defense is for end hosts to use a larger 322 backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some 323 serious negative aspects as the size of the backlog grows [Lem02]. 324 The implementation has not been designed to scale past backlogs of a 325 few hundred, and the data structures and search algorithms that it 326 uses are inefficient with larger backlogs. It is reasonable to 327 assume that other TCP implementations have similar design factors 328 that limit their performance with large backlogs, and there seems to 329 be no compelling reason why stacks should be re-engineered to support 330 extremely large backlogs, since other solutions are available. 331 However, experiments with large backlogs using efficient data 332 structures and search algorithms have not been conducted, to our 333 knowledge. 335 3.3. Reducing SYN-RECEIVED Timer 337 Another quickly implementable defense is shortening the timeout 338 period between receiving a SYN and reaping the created TCB for lack 339 of progress. Decreasing the timer that limits the lifetime of TCBs 340 in SYN-RECEIVED is also flawed. While a shorter timer will keep 341 bogus connection attempts from persisting for as long in the backlog, 342 and thus free up space for legitimate connections sooner, it can 343 prevent some fraction of legitimate connections from becoming fully 344 established. This tactic is also ineffective because it only 345 requires the attacker to increase the barrage frequency by a linearly 346 proportional amount. 348 3.4. SYN Cache 350 The SYN cache, best described by Lemon [Lem02], is based on 351 minimizing the amount of state that a SYN allocates, i.e. not 352 immediately allocating a full TCB. The full state allocation is 353 delayed until the connection has been fully established. Hosts 354 implementing a SYN cache have some secret bits that they select from 355 the incoming SYN segments. The secret bits are hashed along with the 356 IP addresses and TCP ports of a segment, and the hash value 357 determines the location in a global hash table where the incomplete 358 TCB is stored. There is a bucket limit for each hash value, and when 359 this limit is reached, the oldest entry is dropped. 361 The SYN cache technique is effective because the secret bits prevent 362 an attacker from being able to target specific hash values for 363 overflowing the bucket limit, and it bounds both the CPU time and 364 memory requirements. Lemon's evaluation of the SYN cache shows that 365 even under conditions where a SYN flooding attack is not being 366 performed, due to the modified processing path, connection 367 establishment is slightly more expedient. Under active attack, SYN 368 cache performance was observed to approximately linearly shift the 369 distribution of times to establish legitimate connections to about 370 15% longer than when not under attack [Lem02]. 372 If data accompanies the SYN segment, then this data is not 373 acknowledged or stored by the receiver, and will require 374 retransmission. This does not affect the reliability of TCP's data 375 transfer service, but it does affect its performance to some small 376 extent. SYNs carrying data are used by the T/TCP extensions 377 [RFC1644]. While T/TCP is implemented in a number of popular 378 operating systems [GN00], it currently seems to be rarely used. 379 Measurements at one site's border router [All07] logged 2,545,785 SYN 380 segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option 381 (or 0.001%). These came from 26 unique hosts, and no other T/TCP 382 options were seen. 2,287 SYN segments with data were seen (or 0.09% 383 of all SYN segments), all of which had exactly 24 bytes of data. 384 These observations indicate that issues with SYN caches and data on 385 SYN segments may not be significant in deployment. 387 3.5. SYN Cookies 389 SYN cookies go a step further and allocate no state at all for 390 connections in SYN-RECEIVED. Instead, they encode most of the state 391 (and all of the strictly required) state that they would normally 392 keep into the sequence number transmitted on the SYN-ACK. If the SYN 393 was not spoofed, then the acknowledgement number (along with several 394 other fields) in the ACK that completes the handshake can be used to 395 reconstruct the state to be put into the TCB. To date, one of the 396 best references on SYN cookies can be found on Dan Bernstein's web 397 site [cr.yp.to]. This technique exploits the long-understood low 398 entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we 399 describe the SYN cookie technique, to avoid the possibility that the 400 web page will become unavailable. 402 The exact mechanism for encoding state into the SYN-ACK sequence 403 number can be implementation dependent. A common consideration is 404 that to prevent replay, some time-dependent random bits must be 405 embedded in the sequence number. One technique used 7 bits for these 406 bits and 25 bits for the other data [Lem02]. One way to encode these 407 bits has been to XOR the initial sequence number received with a 408 truncated cryptographic hash of the IP address and TCP port number 409 pairs, and secret bits. In practice, this hash has been generated 410 using MD5. 412 The problem with SYN cookies is that commonly implemented schemes are 413 incompatible with some TCP options, if the cookie generation scheme 414 does not consider them. For example, an encoding of the MSS 415 advertised on the SYN has been accommodated by using 2 sequence 416 number bits to represent 4 predefined common MSS values. Similar 417 techniques would be required for some other TCP options, while 418 negotiated use of other TCP options can be detected implicitly. A 419 timestamp on the ACK, as an example, indicates that Timestamp use was 420 successfully negotiated on the SYN and SYN-ACK, while the reception 421 of a SACK option at some point during the connection implies that 422 SACK was negotiated. Note that SACK blocks should normally not be 423 sent by a host using TCP cookies unless they are first received. For 424 the common unidirectional data flow in many TCP connections, this can 425 be a problem, as it limits SACK usage. For this reason, SYN cookies 426 typically are not used by default on systems that implement them, and 427 are only enabled either under high-stress conditions indicative of an 428 attack, or via administrative action. 430 Recently, a new SYN cookie technique developed for release in FreeBSD 431 7.0 leverages the bits of the Timestamp option in addition to the 432 sequence number bits for encoding state. Since the Timestamp value 433 is echoed back in the Timestamp Echo field of the ACK packet, any 434 state stored in the Timestamp option can be restored similarly to the 435 way that it is from the sequence number / acknowledgement in a basic 436 SYN cookie. Using the Timestamp bits, it is possible to explicitly 437 store state bits for things like send and receive window scales, 438 SACK-allowed, and TCP-MD5-enabled, that there is no room for in a 439 typical SYN cookie. This use of Timestamps to improve the 440 compromises inherent in SYN cookies is unique to the FreeBSD 441 implementation, to our knowledge. A limitation is that the technique 442 can only be used if the SYN itself contains a Timestamp option, but 443 this option seems to be widely implemented today, and hosts that 444 support window scaling and SACK typically support timestamps as well. 446 Similarly to SYN caches, SYN cookies do not handle application data 447 piggybacked on the SYN segment. 449 Another problem with SYN cookies is for applications where the first 450 application data is sent by the passive host. If this host is 451 handling a large number of connections, then packet loss may be 452 likely. When a handshake-completing ACK from the initiator is lost, 453 the passive side's application-layer never is notified of the 454 connection's existence and never sends data, even though the 455 initiator thinks that the connection has been successfully 456 established. An example application where the first application- 457 layer data is sent by the passive side is SMTP, if implemented 458 according to RFC 2821, where a "service ready" message is sent by the 459 passive side after the TCP handshake is completed. 461 3.6. Hybrid Approaches 463 The SYN cache and SYN cookie techniques can be combined. For 464 example, in the event that the cache becomes full, then SYN cookies 465 can be sent instead of purging cache entries upon the arrival of new 466 SYNs. Such hybrid approaches may provide a strong combination of the 467 positive aspects of each approach. Lemon has demonstrated the 468 utility of this hybrid [Lem02]. 470 3.7. Firewalls and Proxies 472 Firewall-based tactics may also be used to defend end-hosts from SYN 473 flooding attacks. The basic concept is to offload the connection 474 establishment procedures onto a firewall that screens connection 475 attempts until they are completed and then proxies them back to 476 protected end hosts. This moves the problem away from end-hosts to 477 become the firewall's or proxy's problem, and may introduce other 478 problems related to altering TCP's expected end-to-end semantics. 480 4. Analysis 482 Several of the defenses discussed in the previous section rely on 483 changes to behavior inside the network; via router filtering, 484 firewalls, and proxies. These may be highly effective, and often 485 require no modification or configuration of end host software. Given 486 the mobile nature and dynamic connectivity of many end hosts, it is 487 optimistic for TCP implementers to assume the presence of such 488 protective devices. TCP implementers should provide some means of 489 defense to SYN flooding attacks in end host implementations. 491 Among end host modifications, the SYN cache and SYN cookie approaches 492 seem to be the only viable techniques discovered to date. Increasing 493 the backlog and reducing the SYN-RECEIVED timer are measurably 494 problematic. The SYN cache implies a higher memory footprint than 495 SYN cookies, however, SYN cookies may not be fully compatible with 496 some TCP options, and may hamper development of future TCP extensions 497 that require state. For these reasons, SYN cookies should not be 498 enabled by default on systems that provide them. SYN caches do not 499 have the same negative implications and may be enabled as a default 500 mode of processing. 502 In October of 1996, Dave Borman implemented a SYN cache at BSDi for 503 BSD/OS, which was given to the community with no restrictions. This 504 code seems to be the basis for the SYN cache implementations adopted 505 later in other BSD variants. The cache was used when the backlog 506 became full, rather than by default, as we have described. A note to 507 the tcp-impl mailing list explains that this code does not retransmit 508 SYN-ACKs, which is a practice we discourage [B97]. 510 In 1997, NetBSD incorporated a modified version of Borman's code. 511 Two notable differences from the original code stem from the decision 512 to use the cache by default (for all connections). This implied the 513 need to perform retransmissions for SYN-ACKs, and to use larger 514 structures to keep more complete data. The original structure was 32 515 bytes long for IPv4 connections and 56 bytes with IPv6 support, while 516 the current FreeBSD structure is 196 bytes long. As previously 517 cited, Lemon implemented the SYN cache and cookie techniques in 518 FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up 519 160 bytes compared to 736 for the full TCB (now 196 bytes for the 520 cache structure). We have examined the OpenBSD 3.6 code and 521 determined that it includes a similar SYN cache. 523 Linux 2.6.5 code, also by examination, contains a SYN cookie 524 implementation that encodes 8 MSS values, and does not use SYN 525 cookies by default. This functionality has been present in the Linux 526 kernel for several years previous to 2.6.5. 528 Beginning with Windows 2000, Microsoft's Windows operating systems 529 have had a "TCP SYN attack protection" feature which can be toggled 530 on or off in the registry. This defaulted to off, until Windows 2003 531 SP1, in which it is on by default. With this feature enabled, when 532 the number of half-open connections and half-open connections with 533 retransmitted SYN-ACKs exceeds configurable thresholds, then the 534 number of times which SYN-ACKs are retransmitted before giving up is 535 reduced, and the "Route Cache Entry" creation is delayed, which 536 prevents some features (e.g. window scaling) from being used 537 [win2k3-wp]. 539 Several vendors of commercial firewall products sell devices that can 540 mitigate SYN flooding's effects on end hosts by proxying connections. 542 Discovery and exploitation of the SYN flooding vulnerability in TCP's 543 design provided a valuable lesson for protocol designers. The Stream 544 Control Transmission Protocol [RFC2960], which was designed more 545 recently, incorporated a 4-way handshake with a stateless cookie- 546 based component for the listening end. In this way, the passive- 547 opening side has better evidence that the initiator really exists at 548 the given address before it allocates any state. The Host Identity 549 Protocol base exchange [MNJH07] is similarly designed as a 4-way 550 handshake, but also involves a puzzle sent to the initiator which 551 must be solved before any state is reserved by the responder. The 552 general concept of designing statelessness into protocol setup to 553 avoid denial of service attacks has been discussed by Aura and 554 Nikander [AN97]. 556 5. Security Considerations 558 The SYN flooding attack on TCP has been described in numerous other 559 publications, and the details and code needed to perform the attack 560 have been easily available for years. Describing the attack in this 561 document does not pose any danger of further publicizing this 562 weakness in unmodified TCP stacks. Several widely-deployed operating 563 systems implement the mitigation techniques that this document 564 discusses for defeating SYN flooding attacks. In at least some 565 cases, these operating systems do not enable these countermeasures by 566 default, however, the mechanisms for defeating SYN flooding are well 567 deployed, and easily enabled by end-users. The publication of this 568 document should not influence the number of SYN flooding attacks 569 observed, and might increase the robustness of the Internet to such 570 attacks by encouraging use of the commonly available mitigations. 572 6. IANA Considerations 574 This document does not update or create any IANA registries. 576 7. Acknowledgements 578 A conversation with Ted Faber was the impetus for writing this 579 document. Comments and suggestions from Joe Touch, Dave Borman, 580 Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin 581 Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, and Mark 582 Allman were useful in strengthening this document. The original work 583 on TCP SYN cookies presented in Appendix A is due to D.J. Bernstein. 585 Work on this document was performed at NASA's Glenn Research Center. 586 Funding was partially provided by a combination of NASA's Advanced 587 Communications, Navigation, and Surveillance Architectures and System 588 Technologies (ACAST) project, the Sensis Corporation, NASA's Space 589 Communications Architecture Working Group, and NASA's Earth Science 590 Technology Office. 592 8. Informative References 594 [AN97] Aura, T. and P. Nikander, "Stateless Connections", 595 Proceedings of the First International Conference on 596 Information and Communication Security , 1997. 598 [All07] Allman, M., "", personal communication , February 2007. 600 [B96] Bennahum, D., "PANIX ATTACK", MEME 2.12 601 (http://memex.org/meme2-12.html), October 1996. 603 [B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick 604 clarification...)", IETF tcp-impl mailing list, June 1997. 606 [CA-96.21] 607 CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP 608 Spoofing Attacks", September 1996. 610 [CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 611 Security", ISBN: 0201633574, January 1994. 613 [GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", 614 Linux Journal, February 2000. 616 [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN 617 Cache", BSDCON 2002, February 2002. 619 [MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 620 "Host Identity Protocol", (draft-ietf-hip-base-07), 621 February 2007. 623 [P48-13] daemon9, route, and infinity, "Project Neptune", Phrack 624 Magazine, Volume 7, Issue 48, File 13 of 18, July 1996. 626 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 627 RFC 793, September 1981. 629 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 630 serial links", RFC 1144, February 1990. 632 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 633 Functional Specification", RFC 1644, July 1994. 635 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 636 Defeating Denial of Service Attacks which employ IP Source 637 Address Spoofing", BCP 38, RFC 2827, May 2000. 639 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 640 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 641 Zhang, L., and V. Paxson, "Stream Control Transmission 642 Protocol", RFC 2960, October 2000. 644 [RFC3013] Killalea, T., "Recommended Internet Service Provider 645 Security Services and Procedures", BCP 46, RFC 3013, 646 November 2000. 648 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 649 Networks", BCP 84, RFC 3704, March 2004. 651 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 652 March 2006. 654 [SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, 655 A., and D. Zamboni, "Analysis of a Denial of Service 656 Attack on TCP", Proceedings of the 1997 IEEE Symposium on 657 Security and Privacy 1997. 659 [Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: 660 The Implementation", January 1995. 662 [cr.yp.to] 663 Bernstein, D., "URL: http://cr.yp.to/syncookies.html", 664 visited in December 2005. 666 [win2k3-wp] 667 Microsoft Corporation, "Microsoft Windows Server 2003 668 TCP/IP Implementation Details", White Paper, July 2005. 670 Appendix A. SYN Cookies Description 672 This information is taken from Bernstein's web page on SYN cookies 673 [cr.yp.to]. This is a rewriting of the technical information on that 674 web page and not a full replacement. There are other slightly 675 different ways of implementing the SYN cookie concept than the exact 676 means described here, although the basic idea of encoding data into 677 the SYN-ACK sequence number is constant. 679 A SYN cookie is an initial sequence number sent in the SYN-ACK, that 680 is chosen based on the connection initiator's initial sequence 681 number, MSS, a time counter, and the relevant addresses and port 682 numbers. The actual bits comprising the SYN cookie are chosen to be 683 the bitwise difference (exclusive-or) between the SYN's sequence 684 number and a 32 bit quantity computed so that the top five bits come 685 from a 32-bit counter value modulo 32, where the counter increases 686 every 64 seconds, the next 3 bits encode a usable MSS near to the one 687 in the SYN, and the bottom 24 bits are a server-selected secret 688 function of pair of IP addresses, the pair of port numbers, and the 689 32-bit counter used for the first 5 bits. This means of selecting an 690 initial sequence number for use in the SYN-ACK complies with the rule 691 that TCP sequence numbers increase slowly. 693 When a connection in LISTEN receives a SYN segment, it can generate a 694 SYN cookie and send it in the sequence number of a SYN-ACK, without 695 allocating any other state. If an ACK comes back, the difference 696 between the acknowledged sequence number and the sequence number of 697 the ACK segment can be checked against recent values of the counter 698 and the secret function's output given those counter values and the 699 IP addresses and port numbers in the ACK segment. If there is a 700 match, the connection can be accepted, since it is statistically very 701 likely that the other side received the SYN cookie and did not simply 702 guess a valid cookie value. If there is not a match, the connection 703 can be rejected under the heuristic that it is probably not in 704 response to a recently sent SYN-ACK. 706 With SYN cookies enabled, a host will be able to remain responsive 707 even when under a SYN flooding attack. The largest price to be paid 708 for using SYN cookies is in the disabling of the window scaling 709 option, which disables high performance. 711 Bernstein's web page [cr.yp.to] contains more information about the 712 initial conceptualization and implementation of SYN cookies, and 713 archives of emails documenting this history. It also lists some 714 false negative claims that have been made about SYN cookies, and 715 discusses reducing the vulnerability of SYN cookie implementations to 716 blind connection forgery by an attacker guessing valid cookies. 718 The best description of the exact SYN cookie algorithms is in a part 719 of an email from Bernstein, that is archived on the web site (notice 720 it does not set the top five bits from the counter modulo 32, as the 721 previous description did, but instead uses 29 bits from the second 722 MD5 operation and 3 bits for the index into the MSS table; 723 establishing the secret values is also not discussed). The remainder 724 of this section is excerpted from Bernstein's email [cr.yp.to]: 726 Here's what an implementation would involve: 728 Maintain two (constant) secret keys, sec1 and sec2. 730 Maintain a (constant) sorted table of 8 common MSS values, 731 msstab[8]. 733 Keep track of a ``last overflow time.'' 735 Maintain a counter that increases slowly over time and never 736 repeats, such as ``number of seconds since 1970, shifted right 737 6 bits.'' 739 When a SYN comes in from (saddr,sport) to (daddr,dport) with 740 ISN x, find the largest i for which msstab[i] <= the incoming 741 MSS. Compute 743 z = MD5(sec1,saddr,sport,daddr,dport,sec1) 745 + x 747 + (counter << 24) 749 + (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 << 750 24)) 752 and then 754 y = (i << 29) + (z % (1 << 29)) 756 Create a TCB as usual, with y as our ISN. Send back a SYNACK. 758 Exception: _If_ we're out of memory for TCBs, set the ``last 759 overflow time'' to the current time. Send the SYNACK anyway, 760 with all fancy options turned off. 762 When an ACK comes back, follow this procedure to find a TCB: 764 (1) Look for a (saddr,sport,daddr,dport) TCB. If it's 765 there, done. 767 (2) If the ``last overflow time'' is earlier than a few 768 minutes ago, give up. 770 (3) Figure out whether our alleged ISN makes sense. This 771 means recomputing y as above, for each of the counters that 772 could have been used in the last few minutes (say, the last 773 four counters), and seeing whether any of the y's match the 774 ISN in the bottom 29 bits. If none of them do, give up. 776 (4) Create a new TCB. The top three bits of our ISN give a 777 usable MSS. Turn off all fancy options. 779 Author's Address 781 Wesley M. Eddy 782 Verizon Federal Network Systems 783 NASA Glenn Research Center 784 21000 Brookpark Rd, MS 54-5 785 Cleveland, OH 44135 787 Phone: 216-433-6682 788 Email: weddy@grc.nasa.gov 790 Full Copyright Statement 792 Copyright (C) The IETF Trust (2007). 794 This document is subject to the rights, licenses and restrictions 795 contained in BCP 78, and except as set forth therein, the authors 796 retain all their rights. 798 This document and the information contained herein are provided on an 799 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 800 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 801 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 802 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 803 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 804 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 Intellectual Property 808 The IETF takes no position regarding the validity or scope of any 809 Intellectual Property Rights or other rights that might be claimed to 810 pertain to the implementation or use of the technology described in 811 this document or the extent to which any license under such rights 812 might or might not be available; nor does it represent that it has 813 made any independent effort to identify any such rights. Information 814 on the procedures with respect to rights in RFC documents can be 815 found in BCP 78 and BCP 79. 817 Copies of IPR disclosures made to the IETF Secretariat and any 818 assurances of licenses to be made available, or the result of an 819 attempt made to obtain a general license or permission for the use of 820 such proprietary rights by implementers or users of this 821 specification can be obtained from the IETF on-line IPR repository at 822 http://www.ietf.org/ipr. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights that may cover technology that may be required to implement 827 this standard. Please address the information to the IETF at 828 ietf-ipr@ietf.org. 830 Acknowledgment 832 Funding for the RFC Editor function is provided by the IETF 833 Administrative Support Activity (IASA).