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