idnits 2.17.1 draft-ietf-tcpm-syn-flood-05.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 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. 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 (May 30, 2007) is 6138 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '8' on line 795 == 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 May 30, 2007 5 Expires: December 1, 2007 7 TCP SYN Flooding Attacks and Common Mitigations 8 draft-ietf-tcpm-syn-flood-05 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 December 1, 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. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 9 60 3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 11 63 3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 12 64 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 68 8. Informative References . . . . . . . . . . . . . . . . . . . . 18 69 Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 20 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 71 Intellectual Property and Copyright Statements . . . . . . . . . . 24 73 1. Introduction 75 The SYN flooding attack is a denial of service method affecting hosts 76 that run TCP server processes. The attack takes advantage of the 77 state retention TCP performs for some time after receiving a SYN 78 segment to a port that has been put into the LISTEN state. The basic 79 idea is to exploit this behavior by causing a host to retain enough 80 state for bogus half-connections that there are no resources left to 81 establish new legitimate connections. 83 This SYN flooding attack has been well-known to the community for 84 many years, and has been observed in the wild by network operators 85 and end-hosts. A number of methods have been developed and deployed 86 to make SYN flooding less effective. Despite the notoriety of the 87 attack, and the widely available countermeasures, the RFC series only 88 documented the vulnerability as an example motivation for ingress 89 filtering [RFC2827], and has not suggested any mitigation techniques 90 for TCP implementations. This document addresses both points, but 91 does not define any standards. Formal specifications and 92 requirements of defense mechanisms are outside the scope of this 93 document. Many defenses only impact an end-host's implementation 94 without changing interoperability. These may not require 95 standardization, but their side-effects should at least be well 96 understood. 98 This document intentionally focuses on SYN flooding attacks from an 99 individual end-host or application's perspective, as a means to deny 100 service to that specific entity. High packet-rate attacks that 101 target the network's packet processing capability and capacity have 102 been observed operationally. Since such attacks target the network, 103 and not a TCP implementation, they are out of scope for this 104 document, whether or not they happen to use TCP SYN segments as part 105 of the attack, as the nature of the packets used is irrelevant in 106 comparison to the packet-rate in such attacks. 108 The majority of this document consists of three sections. Section 2 109 explains the SYN flooding attack in greater detail. Several common 110 mitigation techniques are described in Section 3. An analysis and 111 discussion of these techniques and their use is presented in 112 Section 4. Further information on SYN cookies is contained in 113 Appendix A. 115 2. Attack Description 117 This section describes both the history and the technical basis of 118 the SYN flooding attack. 120 2.1. History 122 The TCP SYN flooding weakness was discovered as early as 1994 by Bill 123 Cheswick and Steve Bellovin [B96]. They included, and then removed, 124 a paragraph on the attack in their book "Firewalls and Internet 125 Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no 126 countermeasures were developed within the next two years. 128 The SYN flooding attack was first publicized in 1996, with the 129 release of a description and exploit tool in Phrack Magazine 130 [P48-13]. Aside from some minor inaccuracies, this article is of 131 high enough quality to be useful, and code from the article was 132 widely distributed and used. 134 By September of 1996, SYN flooding attacks had been observed in the 135 wild. Particularly, an attack against one ISP's mail servers caused 136 well-publicized outages. CERT quickly released an advisory on the 137 attack [CA-96.21]. SYN flooding was particularly serious in 138 comparison to other known denial of service attacks at the time. 139 Rather than relying on the common brute-force tactic of simply 140 exhausting the network's resources, SYN flooding targets end-host 141 resources, which it requires fewer packets to deplete. 143 The community quickly developed many widely-differing techniques for 144 preventing or limiting the impact of SYN flooding attacks. Many of 145 these have been deployed to varying degrees on the Internet, in both 146 end hosts and intervening routers. Some of these techniques have 147 become important pieces of the TCP implementations in certain 148 operating systems, although some significantly diverge from the TCP 149 specification and none of these techniques have yet been standardized 150 or sanctioned by the IETF process. 152 2.2. Theory of Operation 154 As described in RFC 793, a TCP implementation may allow the LISTEN 155 state to be entered with either all, some, or none of the pair of IP 156 addresses and port numbers specified by the application. In many 157 common applications like web servers, none of the remote host's 158 information is pre-known or preconfigured, so that a connection can 159 be established with any client whose details are unknown to the 160 server ahead of time. This type of "unbound" LISTEN is the target of 161 SYN flooding attacks due to the way it is typically implemented by 162 operating systems. 164 For success, the SYN flooding attack relies on the victim host TCP 165 implementation's behavior. In particular, it assumes that the victim 166 allocates state for every TCP SYN segment when it is received, and 167 that there is a limit on the amount of such state than can be kept at 168 any time. The current base TCP specification, RFC 793 [RFC0793], 169 describes the standard processing of incoming SYN segments. RFC 793 170 describes the concept of a Transmission Control Block (TCB) data 171 structure to store all the state information for an individual 172 connection. In practice, operating systems may implement this 173 concept rather differently, but the key is that each TCP connection 174 requires some memory space. 176 Per RFC 793, when a SYN is received for a local TCP port where a 177 connection is in the LISTEN state, then the state transitions to SYN- 178 RECEIVED and some of the TCB is initialized with information from the 179 header fields of the received SYN segment. In practice, many 180 operating systems do not alter the TCB in LISTEN, but instead make a 181 copy of the TCB and perform the state transition and update on the 182 copy. This is done so that the local TCP port may be shared amongst 183 several distinct connections. This TCB-copying behavior is not 184 actually essential for this purpose, but influences the way in which 185 applications that wish to handle multiple simultaneous connections 186 through a single TCP port are written. The crucial result of this 187 behavior is that instead of updating already-allocated memory, new 188 (or unused) memory must be devoted to the 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 the 218 backlog of half-open connections associated with a port number. The 219 goal is to send a quick barrage of SYN segments from IP addresses 220 (often spoofed) that will not generate replies to the SYN-ACKs that 221 are produced. By keeping the backlog full of bogus half-opened 222 connections, legitimate requests will be rejected. Three important 223 attack parameters for success are the size of the barrage, the 224 frequency with which barrages are generated, and the means of 225 selecting IP addresses to 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 collection of compromised hosts 291 under the attacker's control (i.e. a "botnet") could be used. In 292 this case, each host utilized in the attack would have to suppress 293 its operating system's native response to the SYN-ACKs coming from 294 the target. It is also possible for the attack TCP segments to 295 arrive in a more continuous fashion than the "barrage" terminology 296 used here suggests; as long as the rate of new SYNs exceeds the rate 297 at which TCBs are reaped, the attack will be successful. 299 3. Common Defenses 301 This section discusses a number of defense techniques which are known 302 to the community, many of which are available in off-the-shelf 303 products. 305 3.1. Filtering 307 Since in the absence of an army of controlled hosts, the ability to 308 send packets with spoofed source IP addresses is required for this 309 attack to work, removing an attacker's ability to send spoofed IP 310 packets is an effective solution that requires no modifications to 311 TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 312 represent the best current practices for packet filtering based on IP 313 addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, 314 end hosts should not rely on filtering policies to prevent attacks 315 from spoofed segments, as global deployment of filters is neither 316 guaranteed nor likely. An attacker with the ability to use a group 317 of compromised hosts or to rapidly change between different access 318 providers will also make filtering an impotent solution. 320 3.2. Increasing Backlog 322 An obvious attempt at a defense is for end hosts to use a larger 323 backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some 324 serious negative aspects as the size of the backlog grows [Lem02]. 325 The implementation has not been designed to scale past backlogs of a 326 few hundred, and the data structures and search algorithms that it 327 uses are inefficient with larger backlogs. It is reasonable to 328 assume that other TCP implementations have similar design factors 329 that limit their performance with large backlogs, and there seems to 330 be no compelling reason why stacks should be re-engineered to support 331 extremely large backlogs, since other solutions are available. 332 However, experiments with large backlogs using efficient data 333 structures and search algorithms have not been conducted, to our 334 knowledge. 336 3.3. Reducing SYN-RECEIVED Timer 338 Another quickly implementable defense is shortening the timeout 339 period between receiving a SYN and reaping the created TCB for lack 340 of progress. Decreasing the timer that limits the lifetime of TCBs 341 in SYN-RECEIVED is also flawed. While a shorter timer will keep 342 bogus connection attempts from persisting for as long in the backlog, 343 and thus free up space for legitimate connections sooner, it can 344 prevent some fraction of legitimate connections from becoming fully 345 established. This tactic is also ineffective because it only 346 requires the attacker to increase the barrage frequency by a linearly 347 proportional amount. This timer reduction is sometimes implemented 348 as a response to crossing some threshold in the backlog occupancy, or 349 some rate of SYN reception. 351 3.4. Recycling the Oldest Half-Open TCB 353 Once the entire backlog is exhausted, some implementations allow 354 incoming SYNs to overwrite the oldest half-open TCB entry. This 355 works under the assumption that legitimate connections can be fully 356 established in less time than the backlog can be filled by incoming 357 attack SYNs. This can fail when the attacking packet rate is high 358 and/or the backlog size is small, and is not a robust defense. 360 3.5. SYN Cache 362 The SYN cache, best described by Lemon [Lem02], is based on 363 minimizing the amount of state that a SYN allocates, i.e. not 364 immediately allocating a full TCB. The full state allocation is 365 delayed until the connection has been fully established. Hosts 366 implementing a SYN cache have some secret bits that they select from 367 the incoming SYN segments. The secret bits are hashed along with the 368 IP addresses and TCP ports of a segment, and the hash value 369 determines the location in a global hash table where the incomplete 370 TCB is stored. There is a bucket limit for each hash value, and when 371 this limit is reached, the oldest entry is dropped. 373 The SYN cache technique is effective because the secret bits prevent 374 an attacker from being able to target specific hash values for 375 overflowing the bucket limit, and it bounds both the CPU time and 376 memory requirements. Lemon's evaluation of the SYN cache shows that 377 even under conditions where a SYN flooding attack is not being 378 performed, due to the modified processing path, connection 379 establishment is slightly more expedient. Under active attack, SYN 380 cache performance was observed to approximately linearly shift the 381 distribution of times to establish legitimate connections to about 382 15% longer than when not under attack [Lem02]. 384 If data accompanies the SYN segment, then this data is not 385 acknowledged or stored by the receiver, and will require 386 retransmission. This does not affect the reliability of TCP's data 387 transfer service, but it does affect its performance to some small 388 extent. SYNs carrying data are used by the T/TCP extensions 389 [RFC1644]. While T/TCP is implemented in a number of popular 390 operating systems [GN00], it currently seems to be rarely used. 391 Measurements at one site's border router [All07] logged 2,545,785 SYN 392 segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option 393 (or 0.001%). These came from 26 unique hosts, and no other T/TCP 394 options were seen. 2,287 SYN segments with data were seen (or 0.09% 395 of all SYN segments), all of which had exactly 24 bytes of data. 396 These observations indicate that issues with SYN caches and data on 397 SYN segments may not be significant in deployment. 399 3.6. SYN Cookies 401 SYN cookies go a step further and allocate no state at all for 402 connections in SYN-RECEIVED. Instead, they encode most of the state 403 (and all of the strictly required) state that they would normally 404 keep into the sequence number transmitted on the SYN-ACK. If the SYN 405 was not spoofed, then the acknowledgement number (along with several 406 other fields) in the ACK that completes the handshake can be used to 407 reconstruct the state to be put into the TCB. To date, one of the 408 best references on SYN cookies can be found on Dan Bernstein's web 409 site [cr.yp.to]. This technique exploits the long-understood low 410 entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we 411 describe the SYN cookie technique, to avoid the possibility that the 412 web page will become unavailable. 414 The exact mechanism for encoding state into the SYN-ACK sequence 415 number can be implementation dependent. A common consideration is 416 that to prevent replay, some time-dependent random bits must be 417 embedded in the sequence number. One technique used 7 bits for these 418 bits and 25 bits for the other data [Lem02]. One way to encode these 419 bits has been to XOR the initial sequence number received with a 420 truncated cryptographic hash of the IP address and TCP port number 421 pairs, and secret bits. In practice, this hash has been generated 422 using MD5 [RFC1321]. Any similar one-way hash could be used instead 423 without impacting interoperability since the hash value is checked by 424 the same host who generates it. 426 The problem with SYN cookies is that commonly implemented schemes are 427 incompatible with some TCP options, if the cookie generation scheme 428 does not consider them. For example, an encoding of the MSS 429 advertised on the SYN has been accommodated by using 2 sequence 430 number bits to represent 4 predefined common MSS values. Similar 431 techniques would be required for some other TCP options, while 432 negotiated use of other TCP options can be detected implicitly. A 433 timestamp on the ACK, as an example, indicates that Timestamp use was 434 successfully negotiated on the SYN and SYN-ACK, while the reception 435 of a SACK option at some point during the connection implies that 436 SACK was negotiated. Note that SACK blocks should normally not be 437 sent by a host using TCP cookies unless they are first received. For 438 the common unidirectional data flow in many TCP connections, this can 439 be a problem, as it limits SACK usage. For this reason, SYN cookies 440 typically are not used by default on systems that implement them, and 441 are only enabled either under high-stress conditions indicative of an 442 attack, or via administrative action. 444 Recently, a new SYN cookie technique developed for release in FreeBSD 445 7.0 leverages the bits of the Timestamp option in addition to the 446 sequence number bits for encoding state. Since the Timestamp value 447 is echoed back in the Timestamp Echo field of the ACK packet, any 448 state stored in the Timestamp option can be restored similarly to the 449 way that it is from the sequence number / acknowledgement in a basic 450 SYN cookie. Using the Timestamp bits, it is possible to explicitly 451 store state bits for things like send and receive window scales, 452 SACK-allowed, and TCP-MD5-enabled, that there is no room for in a 453 typical SYN cookie. This use of Timestamps to improve the 454 compromises inherent in SYN cookies is unique to the FreeBSD 455 implementation, to our knowledge. A limitation is that the technique 456 can only be used if the SYN itself contains a Timestamp option, but 457 this option seems to be widely implemented today, and hosts that 458 support window scaling and SACK typically support timestamps as well. 460 Similarly to SYN caches, SYN cookies do not handle application data 461 piggybacked on the SYN segment. 463 Another problem with SYN cookies is for applications where the first 464 application data is sent by the passive host. If this host is 465 handling a large number of connections, then packet loss may be 466 likely. When a handshake-completing ACK from the initiator is lost, 467 the passive side's application-layer never is notified of the 468 connection's existence and never sends data, even though the 469 initiator thinks that the connection has been successfully 470 established. An example application where the first application- 471 layer data is sent by the passive side is SMTP, if implemented 472 according to RFC 2821, where a "service ready" message is sent by the 473 passive side after the TCP handshake is completed. 475 Although SYN cookie implementations exist and are deployed, the use 476 of SYN cookies is often disabled in default configurations, so it is 477 unclear how much operational experience actually exists with them, or 478 if using them opens up new vulnerabilities. Anecdotes of incidents 479 where SYN cookies have been used on typical web servers seem to 480 indicate that the added processing burden of computing MD5 sums for 481 every SYN packet received is not significant in comparison to the 482 loss of application availability when undefended. For some 483 computationally-constrained mobile or embedded devices, this 484 situation might be different. 486 3.7. Hybrid Approaches 488 The SYN cache and SYN cookie techniques can be combined. For 489 example, in the event that the cache becomes full, then SYN cookies 490 can be sent instead of purging cache entries upon the arrival of new 491 SYNs. Such hybrid approaches may provide a strong combination of the 492 positive aspects of each approach. Lemon has demonstrated the 493 utility of this hybrid [Lem02]. 495 3.8. Firewalls and Proxies 497 Firewall-based tactics may also be used to defend end-hosts from SYN 498 flooding attacks. The basic concept is to offload the connection 499 establishment procedures onto a firewall that screens connection 500 attempts until they are completed and then proxies them back to 501 protected end hosts. This moves the problem away from end-hosts to 502 become the firewall's or proxy's problem, and may introduce other 503 problems related to altering TCP's expected end-to-end semantics. A 504 common tactic used in these firewall and proxy products is to 505 implement one of the end-host based techniques discussed above, and 506 screen incoming SYNs from the protected network until the connection 507 is fully established. This is accomplished by spoofing the source 508 addresses of several packets to the initiator and listener at various 509 stages of the handshake [Eddy06]. 511 4. Analysis 513 Several of the defenses discussed in the previous section rely on 514 changes to behavior inside the network; via router filtering, 515 firewalls, and proxies. These may be highly effective, and often 516 require no modification or configuration of end host software. Given 517 the mobile nature and dynamic connectivity of many end hosts, it is 518 optimistic for TCP implementers to assume the presence of such 519 protective devices. TCP implementers should provide some means of 520 defense to SYN flooding attacks in end host implementations. 522 Among end host modifications, the SYN cache and SYN cookie approaches 523 seem to be the only viable techniques discovered to date. Increasing 524 the backlog and reducing the SYN-RECEIVED timer are measurably 525 problematic. The SYN cache implies a higher memory footprint than 526 SYN cookies, however, SYN cookies may not be fully compatible with 527 some TCP options, and may hamper development of future TCP extensions 528 that require state. For these reasons, SYN cookies should not be 529 enabled by default on systems that provide them. SYN caches do not 530 have the same negative implications and may be enabled as a default 531 mode of processing. 533 In October of 1996, Dave Borman implemented a SYN cache at BSDi for 534 BSD/OS, which was given to the community with no restrictions. This 535 code seems to be the basis for the SYN cache implementations adopted 536 later in other BSD variants. The cache was used when the backlog 537 became full, rather than by default, as we have described. A note to 538 the tcp-impl mailing list explains that this code does not retransmit 539 SYN-ACKs [B97]. More recent implementations have chosen to reverse 540 this decision and retransmit SYN-ACKs. It is known that loss of SYN- 541 ACK packets is not uncommon [SD01] and can severely slow the 542 performance of connections when initial retransmission timers for 543 SYNs are overly conservative (as in some operating systems) or 544 retransmitted SYNs are lost. Furthermore, if a SYN flooding attacker 545 has a high sending rate, loss of retransmitted SYNs is likely, so if 546 SYN-ACKs are not retransmitted, the chance of efficiently 547 establishing legitimate connections is reduced. 549 In 1997, NetBSD incorporated a modified version of Borman's code. 550 Two notable differences from the original code stem from the decision 551 to use the cache by default (for all connections). This implied the 552 need to perform retransmissions for SYN-ACKs, and to use larger 553 structures to keep more complete data. The original structure was 32 554 bytes long for IPv4 connections and 56 bytes with IPv6 support, while 555 the current FreeBSD structure is 196 bytes long. As previously 556 cited, Lemon implemented the SYN cache and cookie techniques in 557 FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up 558 160 bytes compared to 736 for the full TCB (now 196 bytes for the 559 cache structure). We have examined the OpenBSD 3.6 code and 560 determined that it includes a similar SYN cache. 562 Linux 2.6.5 code, also by examination, contains a SYN cookie 563 implementation that encodes 8 MSS values, and does not use SYN 564 cookies by default. This functionality has been present in the Linux 565 kernel for several years previous to 2.6.5. 567 When a SYN cache and/or SYN cookies are implemented with IPv6, the 568 IPv6 flow label value used on the SYN-ACK should be consistent with 569 the flow label used for the rest of the packets within that flow. 570 There have been implementation bugs that caused random flow labels to 571 be used in SYN-ACKs generated by SYN cache and SYN cookie code 572 [MM05]. 574 Beginning with Windows 2000, Microsoft's Windows operating systems 575 have had a "TCP SYN attack protection" feature which can be toggled 576 on or off in the registry. This defaulted to off, until Windows 2003 577 SP1, in which it is on by default. With this feature enabled, when 578 the number of half-open connections and half-open connections with 579 retransmitted SYN-ACKs exceeds configurable thresholds, then the 580 number of times which SYN-ACKs are retransmitted before giving up is 581 reduced, and the "Route Cache Entry" creation is delayed, which 582 prevents some features (e.g. window scaling) from being used 583 [win2k3-wp]. 585 Several vendors of commercial firewall products sell devices that can 586 mitigate SYN flooding's effects on end hosts by proxying connections. 588 Discovery and exploitation of the SYN flooding vulnerability in TCP's 589 design provided a valuable lesson for protocol designers. The Stream 590 Control Transmission Protocol [RFC2960], which was designed more 591 recently, incorporated a 4-way handshake with a stateless cookie- 592 based component for the listening end. In this way, the passive- 593 opening side has better evidence that the initiator really exists at 594 the given address before it allocates any state. The Host Identity 595 Protocol base exchange [MNJH07] is similarly designed as a 4-way 596 handshake, but also involves a puzzle sent to the initiator which 597 must be solved before any state is reserved by the responder. The 598 general concept of designing statelessness into protocol setup to 599 avoid denial of service attacks has been discussed by Aura and 600 Nikander [AN97]. 602 5. Security Considerations 604 The SYN flooding attack on TCP has been described in numerous other 605 publications, and the details and code needed to perform the attack 606 have been easily available for years. Describing the attack in this 607 document does not pose any danger of further publicizing this 608 weakness in unmodified TCP stacks. Several widely-deployed operating 609 systems implement the mitigation techniques that this document 610 discusses for defeating SYN flooding attacks. In at least some 611 cases, these operating systems do not enable these countermeasures by 612 default, however, the mechanisms for defeating SYN flooding are well 613 deployed, and easily enabled by end-users. The publication of this 614 document should not influence the number of SYN flooding attacks 615 observed, and might increase the robustness of the Internet to such 616 attacks by encouraging use of the commonly available mitigations. 618 6. IANA Considerations 620 This document does not update or create any IANA registries. 622 7. Acknowledgements 624 A conversation with Ted Faber was the impetus for writing this 625 document. Comments and suggestions from Joe Touch, Dave Borman, 626 Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin 627 Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman, 628 Lars Eggert, Pasi Eronen, Warren Kumari, David Malone, Ron Bonica, 629 and Lisa Dusseault were useful in strengthening this document. The 630 original work on TCP SYN cookies presented in Appendix A is due to 631 D.J. Bernstein. 633 Work on this document was performed at NASA's Glenn Research Center. 634 Funding was partially provided by a combination of NASA's Advanced 635 Communications, Navigation, and Surveillance Architectures and System 636 Technologies (ACAST) project, the Sensis Corporation, NASA's Space 637 Communications Architecture Working Group, and NASA's Earth Science 638 Technology Office. 640 8. Informative References 642 [AN97] Aura, T. and P. Nikander, "Stateless Connections", 643 Proceedings of the First International Conference on 644 Information and Communication Security , 1997. 646 [All07] Allman, M., "personal communication", February 2007. 648 [B96] Bennahum, D., "PANIX ATTACK", MEME 2.12 649 (http://memex.org/meme2-12.html), October 1996. 651 [B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick 652 clarification...)", IETF tcp-impl mailing list, June 1997. 654 [CA-96.21] 655 CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP 656 Spoofing Attacks", September 1996. 658 [CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet 659 Security", ISBN: 0201633574, January 1994. 661 [Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", 662 Cisco Internet Protocol Journal Volume 8, Number 4, 663 December 2006. 665 [GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for Transactions", 666 Linux Journal, February 2000. 668 [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN 669 Cache", BSDCON 2002, February 2002. 671 [MM05] McGann, O. and D. Malone, "Flow Label Filtering 672 Feasibility", European Conference on Computer Network 673 Defense 2005, December 2005. 675 [MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 676 "Host Identity Protocol", (draft-ietf-hip-base-07), 677 February 2007. 679 [P48-13] daemon9, route, and infinity, "Project Neptune", Phrack 680 Magazine, Volume 7, Issue 48, File 13 of 18, July 1996. 682 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 683 RFC 793, September 1981. 685 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 686 serial links", RFC 1144, February 1990. 688 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 689 April 1992. 691 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 692 Functional Specification", RFC 1644, July 1994. 694 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 695 Defeating Denial of Service Attacks which employ IP Source 696 Address Spoofing", BCP 38, RFC 2827, May 2000. 698 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 699 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 700 Zhang, L., and V. Paxson, "Stream Control Transmission 701 Protocol", RFC 2960, October 2000. 703 [RFC3013] Killalea, T., "Recommended Internet Service Provider 704 Security Services and Procedures", BCP 46, RFC 3013, 705 November 2000. 707 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 708 Networks", BCP 84, RFC 3704, March 2004. 710 [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413, 711 March 2006. 713 [SD01] Seddigh, N. and M. Devetsikiotis, "Studies of TCP's 714 Retransmission Timeout Mechanism", Proceedings of the 2001 715 IEEE International Conference on Communications (ICC 716 2001), volume 6, pages 1834-1840, June 2001. 718 [SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, 719 A., and D. Zamboni, "Analysis of a Denial of Service 720 Attack on TCP", Proceedings of the 1997 IEEE Symposium on 721 Security and Privacy 1997. 723 [Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: 724 The Implementation", January 1995. 726 [cr.yp.to] 727 Bernstein, D., "URL: http://cr.yp.to/syncookies.html", 728 visited in December 2005. 730 [win2k3-wp] 731 Microsoft Corporation, "Microsoft Windows Server 2003 732 TCP/IP Implementation Details", White Paper, July 2005. 734 Appendix A. SYN Cookies Description 736 This information is taken from Bernstein's web page on SYN cookies 737 [cr.yp.to]. This is a rewriting of the technical information on that 738 web page and not a full replacement. There are other slightly 739 different ways of implementing the SYN cookie concept than the exact 740 means described here, although the basic idea of encoding data into 741 the SYN-ACK sequence number is constant. 743 A SYN cookie is an initial sequence number sent in the SYN-ACK, that 744 is chosen based on the connection initiator's initial sequence 745 number, MSS, a time counter, and the relevant addresses and port 746 numbers. The actual bits comprising the SYN cookie are chosen to be 747 the bitwise difference (exclusive-or) between the SYN's sequence 748 number and a 32 bit quantity computed so that the top five bits come 749 from a 32-bit counter value modulo 32, where the counter increases 750 every 64 seconds, the next 3 bits encode a usable MSS near to the one 751 in the SYN, and the bottom 24 bits are a server-selected secret 752 function of pair of IP addresses, the pair of port numbers, and the 753 32-bit counter used for the first 5 bits. This means of selecting an 754 initial sequence number for use in the SYN-ACK complies with the rule 755 that TCP sequence numbers increase slowly. 757 When a connection in LISTEN receives a SYN segment, it can generate a 758 SYN cookie and send it in the sequence number of a SYN-ACK, without 759 allocating any other state. If an ACK comes back, the difference 760 between the acknowledged sequence number and the sequence number of 761 the ACK segment can be checked against recent values of the counter 762 and the secret function's output given those counter values and the 763 IP addresses and port numbers in the ACK segment. If there is a 764 match, the connection can be accepted, since it is statistically very 765 likely that the other side received the SYN cookie and did not simply 766 guess a valid cookie value. If there is not a match, the connection 767 can be rejected under the heuristic that it is probably not in 768 response to a recently sent SYN-ACK. 770 With SYN cookies enabled, a host will be able to remain responsive 771 even when under a SYN flooding attack. The largest price to be paid 772 for using SYN cookies is in the disabling of the window scaling 773 option, which disables high performance. 775 Bernstein's web page [cr.yp.to] contains more information about the 776 initial conceptualization and implementation of SYN cookies, and 777 archives of emails documenting this history. It also lists some 778 false negative claims that have been made about SYN cookies, and 779 discusses reducing the vulnerability of SYN cookie implementations to 780 blind connection forgery by an attacker guessing valid cookies. 782 The best description of the exact SYN cookie algorithms is in a part 783 of an email from Bernstein, that is archived on the web site (notice 784 it does not set the top five bits from the counter modulo 32, as the 785 previous description did, but instead uses 29 bits from the second 786 MD5 operation and 3 bits for the index into the MSS table; 787 establishing the secret values is also not discussed). The remainder 788 of this section is excerpted from Bernstein's email [cr.yp.to]: 790 Here's what an implementation would involve: 792 Maintain two (constant) secret keys, sec1 and sec2. 794 Maintain a (constant) sorted table of 8 common MSS values, 795 msstab[8]. 797 Keep track of a ``last overflow time.'' 799 Maintain a counter that increases slowly over time and never 800 repeats, such as ``number of seconds since 1970, shifted right 801 6 bits.'' 803 When a SYN comes in from (saddr,sport) to (daddr,dport) with 804 ISN x, find the largest i for which msstab[i] <= the incoming 805 MSS. Compute 807 z = MD5(sec1,saddr,sport,daddr,dport,sec1) 809 + x 811 + (counter << 24) 813 + (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 << 814 24)) 816 and then 818 y = (i << 29) + (z % (1 << 29)) 820 Create a TCB as usual, with y as our ISN. Send back a SYNACK. 822 Exception: _If_ we're out of memory for TCBs, set the ``last 823 overflow time'' to the current time. Send the SYNACK anyway, 824 with all fancy options turned off. 826 When an ACK comes back, follow this procedure to find a TCB: 828 (1) Look for a (saddr,sport,daddr,dport) TCB. If it's 829 there, done. 831 (2) If the ``last overflow time'' is earlier than a few 832 minutes ago, give up. 834 (3) Figure out whether our alleged ISN makes sense. This 835 means recomputing y as above, for each of the counters that 836 could have been used in the last few minutes (say, the last 837 four counters), and seeing whether any of the y's match the 838 ISN in the bottom 29 bits. If none of them do, give up. 840 (4) Create a new TCB. The top three bits of our ISN give a 841 usable MSS. Turn off all fancy options. 843 Author's Address 845 Wesley M. Eddy 846 Verizon Federal Network Systems 847 NASA Glenn Research Center 848 21000 Brookpark Rd, MS 54-5 849 Cleveland, OH 44135 851 Phone: 216-433-6682 852 Email: weddy@grc.nasa.gov 854 Full Copyright Statement 856 Copyright (C) The IETF Trust (2007). 858 This document is subject to the rights, licenses and restrictions 859 contained in BCP 78, and except as set forth therein, the authors 860 retain all their rights. 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 865 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 866 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Intellectual Property 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed to 874 pertain to the implementation or use of the technology described in 875 this document or the extent to which any license under such rights 876 might or might not be available; nor does it represent that it has 877 made any independent effort to identify any such rights. Information 878 on the procedures with respect to rights in RFC documents can be 879 found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the use of 884 such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR repository at 886 http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights that may cover technology that may be required to implement 891 this standard. Please address the information to the IETF at 892 ietf-ipr@ietf.org. 894 Acknowledgment 896 Funding for the RFC Editor function is provided by the IETF 897 Administrative Support Activity (IASA).