Network Working Group W. Eddy Internet-Draft Verizon FNS / NASA GRC Expires: November 26, 2005 May 25, 2005 TCP SYN Flooding Attacks and Common Mitigations draft-eddy-syn-flood-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 defense techniques so that implementers may better evaluate them. Eddy Expires November 26, 2005 [Page 1] Internet-Draft TCP SYN Flooding May 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Attack Description . . . . . . . . . . . . . . . . . . . . . . 4 2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Theory of Operation . . . . . . . . . . . . . . . . . . . 4 3. Common Defenses . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Filtering . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Increasing Backlog . . . . . . . . . . . . . . . . . . . . 8 3.3 Reducing SYN-RECEIVED Timer . . . . . . . . . . . . . . . 8 3.4 SYN Cache . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5 SYN Cookies . . . . . . . . . . . . . . . . . . . . . . . 9 3.6 Hybrid Approaches . . . . . . . . . . . . . . . . . . . . 10 3.7 Firewalls and Proxies . . . . . . . . . . . . . . . . . . 10 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Eddy Expires November 26, 2005 [Page 2] Internet-Draft TCP SYN Flooding May 2005 1. Introduction The SYN flooding attack is a denial of service method taking advantage of the state retention TCP performs for some time after receiving a SYN segment to a port with a TCB in 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 has not documented the vulnerability, nor suggested any mitigation techniques for TCP implementations. The purpose of this document is to satisfy both of these ends in an informational context. The advancement (or need to advance) of mitigation techniques through the standards track is left to be considered as further work. This 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. Eddy Expires November 26, 2005 [Page 3] Internet-Draft TCP SYN Flooding May 2005 2. Attack Description 2.1 History The TCP SYN flooding weakness was discovered as early as 1994 by Bill Cheswick and Steve Bellovin. 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. This article contains code for the attack and was widely distributed via the Internet. By September of 1996, SYN flooding attacks had been observed in the wild. Particularly, an attack against the Panix 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, because rather than relying on brute-force exhaustion of network resources, the attack targets host resources, which it requires 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 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 have not yet been standardized or sanctioned by the IETF process. 2.2 Theory of Operation For sucess, 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 received, and that there is a limit on the amount of such state than can be kept at any time. The current 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 Eddy Expires November 26, 2005 [Page 4] Internet-Draft TCP SYN Flooding May 2005 connection is in the LISTEN state, then the state transitions to SYN- RECEIVED and some of the TCB is filled in with information from the header fields of the received SYN segment. In practice, this is not really how things work. 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 typically exceeds 280 bytes [SKK+97]. While the exact size of the TCP connection data structures may vary between implementations, it is always true that a received segment elicits some allocation of resources. To protect the host's 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 may vary (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. The SYN flooding attack neither attempts to overload the network's resources, nor the end host's memory, but merely to exhaust an application's backlog of half-open connections. The goal is to send a quick barrage of SYN segments from spoofed IP addresses 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 Eddy Expires November 26, 2005 [Page 5] Internet-Draft TCP SYN Flooding May 2005 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 should be tailored to the particular value determined by the victim host and application. 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]. 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 should be 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 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 Eddy Expires November 26, 2005 [Page 6] Internet-Draft TCP SYN Flooding May 2005 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 prevents 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. Eddy Expires November 26, 2005 [Page 7] Internet-Draft TCP SYN Flooding May 2005 3. Common Defenses 3.1 Filtering Since 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 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. 3.2 Increasing Backlog An obvious attempt at 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. 3.3 Reducing SYN-RECEIVED Timer 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. 3.4 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 are hashed along with the IP addresses and TCP ports of a segment. The hash value determines the location in a global hash table where the incomplete TCB is stored. Their is a bucket limit for each hash value, and when this limit is reached, the oldest entry is dropped. Eddy Expires November 26, 2005 [Page 8] Internet-Draft TCP SYN Flooding May 2005 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. 3.5 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 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][WM04]. 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. The problem with SYN cookies is that current schemes are incompatible with some TCP options, if the cookie generation scheme does not consider them. For example, an encoding of the 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 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 default to off on systems that implement them, and are only Eddy Expires November 26, 2005 [Page 9] Internet-Draft TCP SYN Flooding May 2005 enabled either under high-stress conditions indicative of an attack, or via adminstrative action. 3.6 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. 3.7 Firewalls and Proxies Firewall-baed tactics may also be used to defend end-hosts from SYN flooding attacks. The basic concept is to offload the connection establishment proceedures onto a firewall that screens connection attempts until they are completed and then proxies them back to protected end hosts. Eddy Expires November 26, 2005 [Page 10] Internet-Draft TCP SYN Flooding May 2005 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 are 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 discoverd. 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. Dave Borman's implemented a SYN cache in BSDI, in October of 1996. 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, which is a practice we would not encourage. Borman's code grew to use the cache by default and to perform retransmissions as it was included into NetBSD in 1997. As previously cited, Lemon implemented the SYN cache and cookie techniques in FreeBSD 4.4. Lemon notes that a SYN cache structure took up 160 bytes compared to 736 for the full TCB. 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. THE INFORMATION HERE ON WHAT COMMON IMPLMENTATIONS CONTAIN IS HIGHLY INCOMPLETE. PLEASE SEND ANY FURTHER INFORMATION ABOUT THESE AND OTHER TCP IMPLEMENTATIONS AND THEIR APPROACH TO SYN FLOODING MITIGATION TO THE AUTHORS FOR INCLUSION IN A FUTURE VERSION OF THIS DOCUMENT. WE ARE ESPECIALLY CURIOUS AS TO WHAT WINDOWS XP AND RECENT SOLARIS RELEASES IMPLEMENT. Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections. Eddy Expires November 26, 2005 [Page 11] Internet-Draft TCP SYN Flooding May 2005 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. The Host Identity Protocol [MN04] is similarly designed. Eddy Expires November 26, 2005 [Page 12] Internet-Draft TCP SYN Flooding May 2005 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 turn these countermeasures on 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. Eddy Expires November 26, 2005 [Page 13] Internet-Draft TCP SYN Flooding May 2005 6. Acknowledgements A conversation with Ted Faber was the impetus for writing this document. 7. Informative References [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. [Lem02] Lemon, J., "Resisting SYN Flood DoS Attacks with a SYN Cache", BSDCON 2002, February 2002. [MN04] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", (draft-ietf-hip-arch), January 2004. [P48-13] daemon9, "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. [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. [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 Eddy Expires November 26, 2005 [Page 14] Internet-Draft TCP SYN Flooding May 2005 Security and Privacy 1997. [Ste95] Stevens, W. and G. Wright, "TCP/IP Illustrated, Volume 2: The Implementation", January 1995. [WM04] West, M. and S. McCann, "TCP/IP Field Behavior", (draft-ietf-rohc-tcp-field-behavior), October 2004. [cr.yp.to] Bernstein, D., "URL: http://cr.yp.to", visited in May 2004. Author's Address Wesley M. Eddy Verizon FNS / NASA GRC 21000 Brookpark Rd, MS 54-5 Cleveland, OH 44135 Phone: 216-433-6682 Email: weddy@grc.nasa.gov Eddy Expires November 26, 2005 [Page 15] Internet-Draft TCP SYN Flooding May 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Eddy Expires November 26, 2005 [Page 16]