diff options
Diffstat (limited to 'doc/rfc/rfc4987.txt')
| -rw-r--r-- | doc/rfc/rfc4987.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4987.txt b/doc/rfc/rfc4987.txt new file mode 100644 index 0000000..636c337 --- /dev/null +++ b/doc/rfc/rfc4987.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group W. Eddy +Request for Comments: 4987 Verizon +Category: Informational August 2007 + + + TCP SYN Flooding Attacks and Common Mitigations + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document describes TCP SYN flooding attacks, which have been + well-known to the community for several years. Various + countermeasures against these attacks, and the trade-offs of each, + are described. This document archives explanations of the attack and + common defense techniques for the benefit of TCP implementers and + administrators of TCP servers or networks, but does not make any + standards-level recommendations. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 2 + 2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 3 + 3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. Increasing Backlog . . . . . . . . . . . . . . . . . . . . 7 + 3.3. Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 7 + 3.4. Recycling the Oldest Half-Open TCB . . . . . . . . . . . . 7 + 3.5. SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.7. Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10 + 3.8. Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10 + 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 13 + Appendix A. SYN Cookies Description . . . . . . . . . . . . . . . 16 + + + + +Eddy Informational [Page 1] + +RFC 4987 TCP SYN Flooding August 2007 + + +1. Introduction + + The SYN flooding attack is a denial-of-service method affecting hosts + that run TCP server processes. The attack takes advantage of the + state retention TCP performs for some time after receiving a SYN + segment to a port that has been put into the LISTEN state. The basic + idea is to exploit this behavior by causing a host to retain enough + state for bogus half-connections that there are no resources left to + establish new legitimate connections. + + This SYN flooding attack has been well-known to the community for + many years, and has been observed in the wild by network operators + and end hosts. A number of methods have been developed and deployed + to make SYN flooding less effective. Despite the notoriety of the + attack, and the widely available countermeasures, the RFC series only + documented the vulnerability as an example motivation for ingress + filtering [RFC2827], and has not suggested any mitigation techniques + for TCP implementations. This document addresses both points, but + does not define any standards. Formal specifications and + requirements of defense mechanisms are outside the scope of this + document. Many defenses only impact an end host's implementation + without changing interoperability. These may not require + standardization, but their side-effects should at least be well + understood. + + This document intentionally focuses on SYN flooding attacks from an + individual end host or application's perspective, as a means to deny + service to that specific entity. High packet-rate attacks that + target the network's packet-processing capability and capacity have + been observed operationally. Since such attacks target the network, + and not a TCP implementation, they are out of scope for this + document, whether or not they happen to use TCP SYN segments as part + of the attack, as the nature of the packets used is irrelevant in + comparison to the packet-rate in such attacks. + + The majority of this document consists of three sections. Section 2 + explains the SYN flooding attack in greater detail. Several common + mitigation techniques are described in Section 3. An analysis and + discussion of these techniques and their use is presented in + Section 4. Further information on SYN cookies is contained in + Appendix A. + +2. Attack Description + + This section describes both the history and the technical basis of + the SYN flooding attack. + + + + + +Eddy Informational [Page 2] + +RFC 4987 TCP SYN Flooding August 2007 + + +2.1. History + + The TCP SYN flooding weakness was discovered as early as 1994 by Bill + Cheswick and Steve Bellovin [B96]. They included, and then removed, + a paragraph on the attack in their book "Firewalls and Internet + Security: Repelling the Wily Hacker" [CB94]. Unfortunately, no + countermeasures were developed within the next two years. + + The SYN flooding attack was first publicized in 1996, with the + release of a description and exploit tool in Phrack Magazine + [P48-13]. Aside from some minor inaccuracies, this article is of + high enough quality to be useful, and code from the article was + widely distributed and used. + + By September of 1996, SYN flooding attacks had been observed in the + wild. Particularly, an attack against one ISP's mail servers caused + well-publicized outages. CERT quickly released an advisory on the + attack [CA-96.21]. SYN flooding was particularly serious in + comparison to other known denial-of-service attacks at the time. + Rather than relying on the common brute-force tactic of simply + exhausting the network's resources, SYN flooding targets end-host + resources, which require fewer packets to deplete. + + The community quickly developed many widely differing techniques for + preventing or limiting the impact of SYN flooding attacks. Many of + these have been deployed to varying degrees on the Internet, in both + end hosts and intervening routers. Some of these techniques have + become important pieces of the TCP implementations in certain + operating systems, although some significantly diverge from the TCP + specification and none of these techniques have yet been standardized + or sanctioned by the IETF process. + +2.2. Theory of Operation + + As described in RFC 793, a TCP implementation may allow the LISTEN + state to be entered with either all, some, or none of the pair of IP + addresses and port numbers specified by the application. In many + common applications like web servers, none of the remote host's + information is pre-known or preconfigured, so that a connection can + be established with any client whose details are unknown to the + server ahead of time. This type of "unbound" LISTEN is the target of + SYN flooding attacks due to the way it is typically implemented by + operating systems. + + For success, the SYN flooding attack relies on the victim host TCP + implementation's behavior. In particular, it assumes that the victim + allocates state for every TCP SYN segment when it is received, and + that there is a limit on the amount of such state than can be kept at + + + +Eddy Informational [Page 3] + +RFC 4987 TCP SYN Flooding August 2007 + + + any time. The current base TCP specification, RFC 793 [RFC0793], + describes the standard processing of incoming SYN segments. RFC 793 + describes the concept of a Transmission Control Block (TCB) data + structure to store all the state information for an individual + connection. In practice, operating systems may implement this + concept rather differently, but the key is that each TCP connection + requires some memory space. + + Per RFC 793, when a SYN is received for a local TCP port where a + connection is in the LISTEN state, then the state transitions to SYN- + RECEIVED, and some of the TCB is initialized with information from + the header fields of the received SYN segment. In practice, many + operating systems do not alter the TCB in LISTEN, but instead make a + copy of the TCB and perform the state transition and update on the + copy. This is done so that the local TCP port may be shared amongst + several distinct connections. This TCB-copying behavior is not + actually essential for this purpose, but influences the way in which + applications that wish to handle multiple simultaneous connections + through a single TCP port are written. The crucial result of this + behavior is that, instead of updating already-allocated memory, new + (or unused) memory must be devoted to the copied TCB. + + As an example, in the Linux 2.6.10 networking code, a "sock" + structure is used to implement the TCB concept. By examination, this + structure takes over 1300 bytes to store in memory. In other systems + that implement less-complex TCP algorithms and options, the overhead + may be less, although it typically exceeds 280 bytes [SKK+97]. + + To protect host memory from being exhausted by connection requests, + the number of TCB structures that can be resident at any time is + usually limited by operating system kernels. Systems vary on whether + limits are globally applied or local to a particular port number. + There is also variation on whether the limits apply to fully + established connections as well as those in SYN-RECEIVED. Commonly, + systems implement a parameter to the typical listen() system call + that allows the application to suggest a value for this limit, called + the backlog. When the backlog limit is reached, then either incoming + SYN segments are ignored, or uncompleted connections in the backlog + are replaced. The concept of using a backlog is not described in the + standards documents, so the failure behavior when the backlog is + reached might differ between stacks (for instance, TCP RSTs might be + generated). The exact failure behavior will determine whether + initiating hosts continue to retransmit SYN segments over time, or + quickly cease. These differences in implementation are acceptable + since they only affect the behavior of the local stack when its + resources are constrained, and do not cause interoperability + problems. + + + + +Eddy Informational [Page 4] + +RFC 4987 TCP SYN Flooding August 2007 + + + The SYN flooding attack does not attempt to overload the network's + resources or the end host's memory, but merely attempts to exhaust + the backlog of half-open connections associated with a port number. + The goal is to send a quick barrage of SYN segments from IP addresses + (often spoofed) that will not generate replies to the SYN-ACKs that + are produced. By keeping the backlog full of bogus half-opened + connections, legitimate requests will be rejected. Three important + attack parameters for success are the size of the barrage, the + frequency with which barrages are generated, and the means of + selecting IP addresses to spoof. + + Barrage Size + + To be effective, the size of the barrage must be made large enough + to reach the backlog. Ideally, the barrage size is no larger than + the backlog, minimizing the volume of traffic the attacker must + source. Typical default backlog values vary from a half-dozen to + several dozen, so the attack might be tailored to the particular + value determined by the victim host and application. On machines + intended to be servers, especially for a high volume of traffic, + the backlogs are often administratively configured to higher + values. + + Barrage Frequency + + To limit the lifetime of half-opened connection state, TCP + implementations commonly reclaim memory from half-opened + connections if they do not become fully opened after some time + period. For instance, a timer of 75 seconds [SKK+97] might be set + when the first SYN-ACK is sent, and on expiration cause SYN-ACK + retransmissions to cease and the TCB to be released. The TCP + specifications do not include this behavior of giving up on + connection establishment after an arbitrary time. Some purists + have expressed that the TCP implementation should continue + retransmitting SYN and SYN-ACK segments without artificial bounds + (but with exponential backoff to some conservative rate) until the + application gives up. Despite this, common operating systems + today do implement some artificial limit on half-open TCB + lifetime. For instance, backing off and stopping after a total of + 511 seconds can be observed in 4.4 BSD-Lite [Ste95], and is still + practiced in some operating systems derived from this code. + + To remain effective, a SYN flooding attack needs to send new + barrages of bogus connection requests as soon as the TCBs from the + previous barrage begin to be reclaimed. The frequency of barrages + are tailored to the victim TCP implementation's TCB reclamation + timer. Frequencies higher than needed source more packets, + potentially drawing more attention, and frequencies that are too + + + +Eddy Informational [Page 5] + +RFC 4987 TCP SYN Flooding August 2007 + + + low will allow windows of time where legitimate connections can be + established. + + IP Address Selection + + For an effective attack, it is important that the spoofed IP + addresses be unresponsive to the SYN-ACK segments that the victim + will generate. If addresses of normal connected hosts are used, + then those hosts will send the victim a TCP reset segment that + will immediately free the corresponding TCB and allow room in the + backlog for legitimate connections to be made. The code + distributed in the original Phrack article used a single source + address for all spoofed SYN segments. This makes the attack + segments somewhat easier to identify and filter. A strong + attacker will have a list of unresponsive and unrelated addresses + that it chooses spoofed source addresses from. + + It is important to note that this attack is directed at particular + listening applications on a host, and not the host itself or the + network. The attack also attempts to prevent only the establishment + of new incoming connections to the victim port, and does not impact + outgoing connection requests, nor previously established connections + to the victim port. + + In practice, an attacker might choose not to use spoofed IP + addresses, but instead to use a multitude of hosts to initiate a SYN + flooding attack. For instance, a collection of compromised hosts + under the attacker's control (i.e., a "botnet") could be used. In + this case, each host utilized in the attack would have to suppress + its operating system's native response to the SYN-ACKs coming from + the target. It is also possible for the attack TCP segments to + arrive in a more continuous fashion than the "barrage" terminology + used here suggests; as long as the rate of new SYNs exceeds the rate + at which TCBs are reaped, the attack will be successful. + +3. Common Defenses + + This section discusses a number of defense techniques that are known + to the community, many of which are available in off-the-shelf + products. + +3.1. Filtering + + Since in the absence of an army of controlled hosts, the ability to + send packets with spoofed source IP addresses is required for this + attack to work, removing an attacker's ability to send spoofed IP + packets is an effective solution that requires no modifications to + TCP. The filtering techniques described in RFCs 2827, 3013, and 3704 + + + +Eddy Informational [Page 6] + +RFC 4987 TCP SYN Flooding August 2007 + + + represent the best current practices for packet filtering based on IP + addresses [RFC2827][RFC3013][RFC3704]. While perfectly effective, + end hosts should not rely on filtering policies to prevent attacks + from spoofed segments, as global deployment of filters is neither + guaranteed nor likely. An attacker with the ability to use a group + of compromised hosts or to rapidly change between different access + providers will also make filtering an impotent solution. + +3.2. Increasing Backlog + + An obvious attempt at a defense is for end hosts to use a larger + backlog. Lemon has shown that in FreeBSD 4.4, this tactic has some + serious negative aspects as the size of the backlog grows [Lem02]. + The implementation has not been designed to scale past backlogs of a + few hundred, and the data structures and search algorithms that it + uses are inefficient with larger backlogs. It is reasonable to + assume that other TCP implementations have similar design factors + that limit their performance with large backlogs, and there seems to + be no compelling reason why stacks should be re-engineered to support + extremely large backlogs, since other solutions are available. + However, experiments with large backlogs using efficient data + structures and search algorithms have not been conducted, to our + knowledge. + +3.3. Reducing SYN-RECEIVED Timer + + Another quickly implementable defense is shortening the timeout + period between receiving a SYN and reaping the created TCB for lack + of progress. Decreasing the timer that limits the lifetime of TCBs + in SYN-RECEIVED is also flawed. While a shorter timer will keep + bogus connection attempts from persisting for as long in the backlog, + and thus free up space for legitimate connections sooner, it can + prevent some fraction of legitimate connections from becoming fully + established. This tactic is also ineffective because it only + requires the attacker to increase the barrage frequency by a linearly + proportional amount. This timer reduction is sometimes implemented + as a response to crossing some threshold in the backlog occupancy, or + some rate of SYN reception. + +3.4. Recycling the Oldest Half-Open TCB + + Once the entire backlog is exhausted, some implementations allow + incoming SYNs to overwrite the oldest half-open TCB entry. This + works under the assumption that legitimate connections can be fully + established in less time than the backlog can be filled by incoming + attack SYNs. This can fail when the attacking packet rate is high + and/or the backlog size is small, and is not a robust defense. + + + + +Eddy Informational [Page 7] + +RFC 4987 TCP SYN Flooding August 2007 + + +3.5. SYN Cache + + The SYN cache, best described by Lemon [Lem02], is based on + minimizing the amount of state that a SYN allocates, i.e., not + immediately allocating a full TCB. The full state allocation is + delayed until the connection has been fully established. Hosts + implementing a SYN cache have some secret bits that they select from + the incoming SYN segments. The secret bits are hashed along with the + IP addresses and TCP ports of a segment, and the hash value + determines the location in a global hash table where the incomplete + TCB is stored. There is a bucket limit for each hash value, and when + this limit is reached, the oldest entry is dropped. + + The SYN cache technique is effective because the secret bits prevent + an attacker from being able to target specific hash values for + overflowing the bucket limit, and it bounds both the CPU time and + memory requirements. Lemon's evaluation of the SYN cache shows that + even under conditions where a SYN flooding attack is not being + performed, due to the modified processing path, connection + establishment is slightly more expedient. Under active attack, SYN + cache performance was observed to approximately linearly shift the + distribution of times to establish legitimate connections to about + 15% longer than when not under attack [Lem02]. + + If data accompanies the SYN segment, then this data is not + acknowledged or stored by the receiver, and will require + retransmission. This does not affect the reliability of TCP's data + transfer service, but it does affect its performance to some small + extent. SYNs carrying data are used by the T/TCP extensions + [RFC1644]. While T/TCP is implemented in a number of popular + operating systems [GN00], it currently seems to be rarely used. + Measurements at one site's border router [All07] logged 2,545,785 SYN + segments (not SYN-ACKs), of which 36 carried the T/TCP CCNEW option + (or 0.001%). These came from 26 unique hosts, and no other T/TCP + options were seen. 2,287 SYN segments with data were seen (or 0.09% + of all SYN segments), all of which had exactly 24 bytes of data. + These observations indicate that issues with SYN caches and data on + SYN segments may not be significant in deployment. + +3.6. SYN Cookies + + SYN cookies go a step further and allocate no state at all for + connections in SYN-RECEIVED. Instead, they encode most of the state + (and all of the strictly required) state that they would normally + keep into the sequence number transmitted on the SYN-ACK. If the SYN + was not spoofed, then the acknowledgement number (along with several + other fields) in the ACK that completes the handshake can be used to + reconstruct the state to be put into the TCB. To date, one of the + + + +Eddy Informational [Page 8] + +RFC 4987 TCP SYN Flooding August 2007 + + + best references on SYN cookies can be found on Dan Bernstein's web + site [cr.yp.to]. This technique exploits the long-understood low + entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we + describe the SYN cookie technique, to avoid the possibility that the + web page will become unavailable. + + The exact mechanism for encoding state into the SYN-ACK sequence + number can be implementation dependent. A common consideration is + that to prevent replay, some time-dependent random bits must be + embedded in the sequence number. One technique used 7 bits for these + bits and 25 bits for the other data [Lem02]. One way to encode these + bits has been to XOR the initial sequence number received with a + truncated cryptographic hash of the IP address and TCP port number + pairs, and secret bits. In practice, this hash has been generated + using MD5 [RFC1321]. Any similar one-way hash could be used instead + without impacting interoperability since the hash value is checked by + the same host who generates it. + + The problem with SYN cookies is that commonly implemented schemes are + incompatible with some TCP options, if the cookie generation scheme + does not consider them. For example, an encoding of the Maximum + Segment Size (MSS) advertised on the SYN has been accommodated by + using 2 sequence number bits to represent 4 predefined common MSS + values. Similar techniques would be required for some other TCP + options, while negotiated use of other TCP options can be detected + implicitly. A timestamp on the ACK, as an example, indicates that + Timestamp use was successfully negotiated on the SYN and SYN-ACK, + while the reception of a Selective Acknowledgement (SACK) option at + some point during the connection implies that SACK was negotiated. + Note that SACK blocks should normally not be sent by a host using TCP + cookies unless they are first received. For the common + unidirectional data flow in many TCP connections, this can be a + problem, as it limits SACK usage. For this reason, SYN cookies + typically are not used by default on systems that implement them, and + are only enabled either under high-stress conditions indicative of an + attack, or via administrative action. + + Recently, a new SYN cookie technique developed for release in FreeBSD + 7.0 leverages the bits of the Timestamp option in addition to the + sequence number bits for encoding state. Since the Timestamp value + is echoed back in the Timestamp Echo field of the ACK packet, any + state stored in the Timestamp option can be restored similarly to the + way that it is from the sequence number / acknowledgement in a basic + SYN cookie. Using the Timestamp bits, it is possible to explicitly + store state bits for things like send and receive window scales, + SACK-allowed, and TCP-MD5-enabled, for which there is no room in a + typical SYN cookie. This use of Timestamps to improve the + compromises inherent in SYN cookies is unique to the FreeBSD + + + +Eddy Informational [Page 9] + +RFC 4987 TCP SYN Flooding August 2007 + + + implementation, to our knowledge. A limitation is that the technique + can only be used if the SYN itself contains a Timestamp option, but + this option seems to be widely implemented today, and hosts that + support window scaling and SACK typically support timestamps as well. + + Similarly to SYN caches, SYN cookies do not handle application data + piggybacked on the SYN segment. + + Another problem with SYN cookies is for applications where the first + application data is sent by the passive host. If this host is + handling a large number of connections, then packet loss may be + likely. When a handshake-completing ACK from the initiator is lost, + the passive side's application layer never is notified of the + connection's existence and never sends data, even though the + initiator thinks that the connection has been successfully + established. An example application where the first application- + layer data is sent by the passive side is SMTP, if implemented + according to RFC 2821, where a "service ready" message is sent by the + passive side after the TCP handshake is completed. + + Although SYN cookie implementations exist and are deployed, the use + of SYN cookies is often disabled in default configurations, so it is + unclear how much operational experience actually exists with them or + if using them opens up new vulnerabilities. Anecdotes of incidents + where SYN cookies have been used on typical web servers seem to + indicate that the added processing burden of computing MD5 sums for + every SYN packet received is not significant in comparison to the + loss of application availability when undefended. For some + computationally constrained mobile or embedded devices, this + situation might be different. + +3.7. Hybrid Approaches + + The SYN cache and SYN cookie techniques can be combined. For + example, in the event that the cache becomes full, then SYN cookies + can be sent instead of purging cache entries upon the arrival of new + SYNs. Such hybrid approaches may provide a strong combination of the + positive aspects of each approach. Lemon has demonstrated the + utility of this hybrid [Lem02]. + +3.8. Firewalls and Proxies + + Firewall-based tactics may also be used to defend end hosts from SYN + flooding attacks. The basic concept is to offload the connection + establishment procedures onto a firewall that screens connection + attempts until they are completed and then proxies them back to + protected end hosts. This moves the problem away from end hosts to + become the firewall's or proxy's problem, and may introduce other + + + +Eddy Informational [Page 10] + +RFC 4987 TCP SYN Flooding August 2007 + + + problems related to altering TCP's expected end-to-end semantics. A + common tactic used in these firewall and proxy products is to + implement one of the end host based techniques discussed above, and + screen incoming SYNs from the protected network until the connection + is fully established. This is accomplished by spoofing the source + addresses of several packets to the initiator and listener at various + stages of the handshake [Eddy06]. + +4. Analysis + + Several of the defenses discussed in the previous section rely on + changes to behavior inside the network; via router filtering, + firewalls, and proxies. These may be highly effective, and often + require no modification or configuration of end-host software. Given + the mobile nature and dynamic connectivity of many end hosts, it is + optimistic for TCP implementers to assume the presence of such + protective devices. TCP implementers should provide some means of + defense to SYN flooding attacks in end-host implementations. + + Among end-host modifications, the SYN cache and SYN cookie approaches + seem to be the only viable techniques discovered to date. Increasing + the backlog and reducing the SYN-RECEIVED timer are measurably + problematic. The SYN cache implies a higher memory footprint than + SYN cookies; however, SYN cookies may not be fully compatible with + some TCP options, and may hamper development of future TCP extensions + that require state. For these reasons, SYN cookies should not be + enabled by default on systems that provide them. SYN caches do not + have the same negative implications and may be enabled as a default + mode of processing. + + In October of 1996, Dave Borman implemented a SYN cache at BSDi for + BSD/OS, which was given to the community with no restrictions. This + code seems to be the basis for the SYN cache implementations adopted + later in other BSD variants. The cache was used when the backlog + became full, rather than by default, as we have described. A note to + the tcp-impl mailing list explains that this code does not retransmit + SYN-ACKs [B97]. More recent implementations have chosen to reverse + this decision and retransmit SYN-ACKs. It is known that loss of SYN- + ACK packets is not uncommon [SD01] and can severely slow the + performance of connections when initial retransmission timers for + SYNs are overly conservative (as in some operating systems) or + retransmitted SYNs are lost. Furthermore, if a SYN flooding attacker + has a high sending rate, loss of retransmitted SYNs is likely, so if + SYN-ACKs are not retransmitted, the chance of efficiently + establishing legitimate connections is reduced. + + + + + + +Eddy Informational [Page 11] + +RFC 4987 TCP SYN Flooding August 2007 + + + In 1997, NetBSD incorporated a modified version of Borman's code. + Two notable differences from the original code stem from the decision + to use the cache by default (for all connections). This implied the + need to perform retransmissions for SYN-ACKs, and to use larger + structures to keep more complete data. The original structure was 32 + bytes long for IPv4 connections and 56 bytes with IPv6 support, while + the current FreeBSD structure is 196 bytes long. As previously + cited, Lemon implemented the SYN cache and cookie techniques in + FreeBSD 4.4 [Lem02]. Lemon notes that a SYN cache structure took up + 160 bytes compared to 736 for the full TCB (now 196 bytes for the + cache structure). We have examined the OpenBSD 3.6 code and + determined that it includes a similar SYN cache. + + Linux 2.6.5 code, also by examination, contains a SYN cookie + implementation that encodes 8 MSS values, and does not use SYN + cookies by default. This functionality has been present in the Linux + kernel for several years previous to 2.6.5. + + When a SYN cache and/or SYN cookies are implemented with IPv6, the + IPv6 flow label value used on the SYN-ACK should be consistent with + the flow label used for the rest of the packets within that flow. + There have been implementation bugs that caused random flow labels to + be used in SYN-ACKs generated by SYN cache and SYN cookie code + [MM05]. + + Beginning with Windows 2000, Microsoft's Windows operating systems + have had a "TCP SYN attack protection" feature, which can be toggled + on or off in the registry. This defaulted to off, until Windows 2003 + SP1, in which it is on by default. With this feature enabled, when + the number of half-open connections and half-open connections with + retransmitted SYN-ACKs exceeds configurable thresholds, then the + number of times that SYN-ACKs are retransmitted before giving up is + reduced, and the "Route Cache Entry" creation is delayed, which + prevents some features (e.g., window scaling) from being used + [win2k3-wp]. + + Several vendors of commercial firewall products sell devices that can + mitigate SYN flooding's effects on end hosts by proxying connections. + + Discovery and exploitation of the SYN flooding vulnerability in TCP's + design provided a valuable lesson for protocol designers. The Stream + Control Transmission Protocol [RFC2960], which was designed more + recently, incorporated a 4-way handshake with a stateless cookie- + based component for the listening end. In this way, the passive- + opening side has better evidence that the initiator really exists at + the given address before it allocates any state. The Host Identity + Protocol base exchange [MNJH07] is similarly designed as a 4-way + handshake, but also involves a puzzle sent to the initiator that must + + + +Eddy Informational [Page 12] + +RFC 4987 TCP SYN Flooding August 2007 + + + be solved before any state is reserved by the responder. The general + concept of designing statelessness into protocol setup to avoid + denial-of-service attacks has been discussed by Aura and Nikander + [AN97]. + +5. Security Considerations + + The SYN flooding attack on TCP has been described in numerous other + publications, and the details and code needed to perform the attack + have been easily available for years. Describing the attack in this + document does not pose any danger of further publicizing this + weakness in unmodified TCP stacks. Several widely deployed operating + systems implement the mitigation techniques that this document + discusses for defeating SYN flooding attacks. In at least some + cases, these operating systems do not enable these countermeasures by + default; however, the mechanisms for defeating SYN flooding are well + deployed, and easily enabled by end-users. The publication of this + document should not influence the number of SYN flooding attacks + observed, and might increase the robustness of the Internet to such + attacks by encouraging use of the commonly available mitigations. + +6. Acknowledgements + + A conversation with Ted Faber was the impetus for writing this + document. Comments and suggestions from Joe Touch, Dave Borman, + Fernando Gont, Jean-Baptiste Marchand, Christian Huitema, Caitlin + Bestler, Pekka Savola, Andre Oppermann, Alfred Hoenes, Mark Allman, + Lars Eggert, Pasi Eronen, Warren Kumari, David Malone, Ron Bonica, + and Lisa Dusseault were useful in strengthening this document. The + original work on TCP SYN cookies presented in Appendix A is due to + D.J. Bernstein. + + Work on this document was performed at NASA's Glenn Research Center. + Funding was partially provided by a combination of NASA's Advanced + Communications, Navigation, and Surveillance Architectures and System + Technologies (ACAST) project, the Sensis Corporation, NASA's Space + Communications Architecture Working Group, and NASA's Earth Science + Technology Office. + +7. Informative References + + [AN97] Aura, T. and P. Nikander, "Stateless Connections", + Proceedings of the First International Conference on + Information and Communication Security, 1997. + + [All07] Allman, M., "personal communication", February 2007. + + + + + +Eddy Informational [Page 13] + +RFC 4987 TCP SYN Flooding August 2007 + + + [B96] Bennahum, D., "PANIX ATTACK", MEME 2.12, October 1996, + <http://memex.org/meme2-12.html>. + + [B97] Borman, D., "Re: SYN/RST cookies (was Re: a quick + clarification...)", IETF tcp-impl mailing list, + June 1997. + + [CA-96.21] CERT, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP + Spoofing Attacks", September 1996. + + [CB94] Cheswick, W. and S. Bellovin, "Firewalls and Internet + Security", ISBN: 0201633574, January 1994. + + [Eddy06] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", + Cisco Internet Protocol Journal Volume 8, Number 4, + December 2006. + + [GN00] Griffin, M. and J. Nelson, "T/TCP: TCP for + Transactions", Linux Journal, February 2000. + + [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN + Cache", BSDCON 2002, February 2002. + + [MM05] McGann, O. and D. Malone, "Flow Label Filtering + Feasibility", European Conference on Computer Network + Defense 2005, December 2005. + + [MNJH07] Moskowitz, R., Nikander, P., Jokela, P., and T. + Henderson, "Host Identity Protocol", Work in Progress, + June 2007. + + [P48-13] daemon9, route, and infinity, "Project Neptune", Phrack + Magazine, Volume 7, Issue 48, File 13 of 18, July 1996. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed + serial links", RFC 1144, February 1990. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", + RFC 1321, April 1992. + + [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions + Functional Specification", RFC 1644, July 1994. + + + + + + +Eddy Informational [Page 14] + +RFC 4987 TCP SYN Flooding August 2007 + + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP + Source Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., + Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., + Zhang, L., and V. Paxson, "Stream Control Transmission + Protocol", RFC 2960, October 2000. + + [RFC3013] Killalea, T., "Recommended Internet Service Provider + Security Services and Procedures", BCP 46, RFC 3013, + November 2000. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for + Multihomed Networks", BCP 84, RFC 3704, March 2004. + + [RFC4413] West, M. and S. McCann, "TCP/IP Field Behavior", + RFC 4413, March 2006. + + [SD01] Seddigh, N. and M. Devetsikiotis, "Studies of TCP's + Retransmission Timeout Mechanism", Proceedings of the + 2001 IEEE International Conference on Communications + (ICC 2001), volume 6, pages 1834-1840, June 2001. + + [SKK+97] Schuba, C., Krsul, I., Kuhn, M., Spafford, E., Sundaram, + A., and D. Zamboni, "Analysis of a Denial of Service + Attack on TCP", Proceedings of the 1997 IEEE Symposium + on Security and Privacy 1997. + + [Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume + 2: The Implementation", January 1995. + + [cr.yp.to] Bernstein, D., "SYN cookies", visited in December 2005, + <http://cr.yp.to/syncookies.html>. + + [win2k3-wp] Microsoft Corporation, "Microsoft Windows Server 2003 + TCP/IP Implementation Details", White Paper, July 2005. + + + + + + + + + + + + + + +Eddy Informational [Page 15] + +RFC 4987 TCP SYN Flooding August 2007 + + +Appendix A. SYN Cookies Description + + This information is taken from Bernstein's web page on SYN cookies + [cr.yp.to]. This is a rewriting of the technical information on that + web page and not a full replacement. There are other slightly + different ways of implementing the SYN cookie concept than the exact + means described here, although the basic idea of encoding data into + the SYN-ACK sequence number is constant. + + A SYN cookie is an initial sequence number sent in the SYN-ACK, that + is chosen based on the connection initiator's initial sequence + number, MSS, a time counter, and the relevant addresses and port + numbers. The actual bits comprising the SYN cookie are chosen to be + the bitwise difference (exclusive-or) between the SYN's sequence + number and a 32 bit quantity computed so that the top five bits come + from a 32-bit counter value modulo 32, where the counter increases + every 64 seconds, the next 3 bits encode a usable MSS near to the one + in the SYN, and the bottom 24 bits are a server-selected secret + function of pair of IP addresses, the pair of port numbers, and the + 32-bit counter used for the first 5 bits. This means of selecting an + initial sequence number for use in the SYN-ACK complies with the rule + that TCP sequence numbers increase slowly. + + When a connection in LISTEN receives a SYN segment, it can generate a + SYN cookie and send it in the sequence number of a SYN-ACK, without + allocating any other state. If an ACK comes back, the difference + between the acknowledged sequence number and the sequence number of + the ACK segment can be checked against recent values of the counter + and the secret function's output given those counter values and the + IP addresses and port numbers in the ACK segment. If there is a + match, the connection can be accepted, since it is statistically very + likely that the other side received the SYN cookie and did not simply + guess a valid cookie value. If there is not a match, the connection + can be rejected under the heuristic that it is probably not in + response to a recently sent SYN-ACK. + + With SYN cookies enabled, a host will be able to remain responsive + even when under a SYN flooding attack. The largest price to be paid + for using SYN cookies is in the disabling of the window scaling + option, which disables high performance. + + Bernstein's web page [cr.yp.to] contains more information about the + initial conceptualization and implementation of SYN cookies, and + archives of emails documenting this history. It also lists some + false negative claims that have been made about SYN cookies, and + discusses reducing the vulnerability of SYN cookie implementations to + blind connection forgery by an attacker guessing valid cookies. + + + + +Eddy Informational [Page 16] + +RFC 4987 TCP SYN Flooding August 2007 + + + The best description of the exact SYN cookie algorithms is in a part + of an email from Bernstein, that is archived on the web site (notice + it does not set the top five bits from the counter modulo 32, as the + previous description did, but instead uses 29 bits from the second + MD5 operation and 3 bits for the index into the MSS table; + establishing the secret values is also not discussed). The remainder + of this section is excerpted from Bernstein's email [cr.yp.to]: + + Here's what an implementation would involve: + + Maintain two (constant) secret keys, sec1 and sec2. + + Maintain a (constant) sorted table of 8 common MSS values, + msstab[8]. + + Keep track of a "last overflow time". + + Maintain a counter that increases slowly over time and never + repeats, such as "number of seconds since 1970, shifted right 6 + bits". + + When a SYN comes in from (saddr,sport) to (daddr,dport) with + ISN x, find the largest i for which msstab[i] <= the incoming + MSS. Compute + + z = MD5(sec1,saddr,sport,daddr,dport,sec1) + + + x + + + (counter << 24) + + + (MD5(sec2,counter,saddr,sport,daddr,dport,sec2) % (1 << + 24)) + + and then + + y = (i << 29) + (z % (1 << 29)) + + Create a TCB as usual, with y as our ISN. Send back a SYNACK. + + Exception: _If_ we're out of memory for TCBs, set the "last + overflow time" to the current time. Send the SYNACK anyway, + with all fancy options turned off. + + When an ACK comes back, follow this procedure to find a TCB: + + + + + + +Eddy Informational [Page 17] + +RFC 4987 TCP SYN Flooding August 2007 + + + (1) Look for a (saddr,sport,daddr,dport) TCB. If it's there, + done. + + (2) If the "last overflow time" is earlier than a few minutes + ago, give up. + + (3) Figure out whether our alleged ISN makes sense. This + means recomputing y as above, for each of the counters + that could have been used in the last few minutes (say, + the last four counters), and seeing whether any of the y's + match the ISN in the bottom 29 bits. If none of them do, + give up. + + (4) Create a new TCB. The top three bits of our ISN give a + usable MSS. Turn off all fancy options. + +Author's Address + + Wesley M. Eddy + Verizon Federal Network Systems + NASA Glenn Research Center + 21000 Brookpark Rd, MS 54-5 + Cleveland, OH 44135 + + Phone: 216-433-6682 + EMail: weddy@grc.nasa.gov + + + + + + + + + + + + + + + + + + + + + + + + + +Eddy Informational [Page 18] + +RFC 4987 TCP SYN Flooding August 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Eddy Informational [Page 19] + |