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