RFC 4987
TCP SYN Flooding Attacks and Common Mitigations
RFC 4987: TCP SYN Flooding Attacks and Common Mitigations 🎀
Okay so this is RFC 4987, and it's giving Informational 📚. It was written by W. Eddy from Verizon 💼 for the Network Working Group, and it's dated August 2007 🗓️. It doesn't obsolete or update any other RFCs, so it's totally its own main character 👑.
Status of This Memo 📣
This memo gives info to the Internet community 🫶. It does not specify an Internet standard of any kind, so don't go treating it like one 🙅♀️. Distribution of this memo is unlimited 💌.
Copyright Notice ©️
Copyright (C) The IETF Trust (2007).
Abstract 🌸
Okay this one's the tea ☕. The doc describes TCP SYN flooding attacks, which the community has known about for years 🕰️. It walks through the different countermeasures against these attacks and the trade-offs of each one 🧩. It's basically an archive of how the attack works and the common defenses, made for TCP implementers and for admins running TCP servers or networks 🖥️. It does not make any standards-level recommendations, though 🙈.
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 . . . . . . . . . . . . . . . 161. Introduction ✨
Okay so the SYN flooding attack is a denial-of-service move 😈 aimed at hosts that run TCP server processes 🖥️. It's sneaky because it abuses the state TCP keeps around for a while after it gets a SYN segment sent to a port that's been put into the LISTEN state 👀. The whole idea is to make a host hold onto enough state for bogus half-connections that it has no resources left for new legit connections 💀.
This attack has been well-known in the community for many years 🕰️, and network operators and end hosts have actually seen it in the wild 🌍. A bunch of methods have been developed and deployed to make SYN flooding less effective 🛡️. Even though the attack is super notorious and the countermeasures are widely available, the RFC series only documented the vulnerability as an example motivation for ingress filtering [RFC2827] 🧹. It never suggested any mitigation techniques for TCP implementations 😤. This document addresses both of those points 💅, but it doesn't define any standards. Formal specifications and requirements of defense mechanisms are outside the scope of this document 🚫. Plenty of defenses only affect an end host's implementation without changing interoperability 🤝. These may not need 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 those attacks target the network, and not a TCP implementation, they're out of scope for this document 🙅♀️. That's true whether or not they happen to use TCP SYN segments as part of the attack, because the nature of the packets is irrelevant next 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 🧬.
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, the article is high enough quality to be useful, and code from it was widely distributed and used 💾.
By September of 1996, SYN flooding attacks had been observed in the wild 🌍. In particular, 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 especially serious compared to other known denial-of-service attacks at the time 😬. Instead of 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 💻. Some of them significantly diverge from the TCP specification 🙈, though, and none of these techniques have yet been standardized or sanctioned by the IETF process 🫶.
2.2. Theory of Operation 🧠✨
okay so bestie, RFC 793 says a TCP implementation can let the LISTEN state be entered with all, some, or none of the IP address and port pair the application gives it 💅 For a lot of common apps like web servers, the server doesn't know anything about the remote host ahead of time, so it'll set up a connection with any client it's never heard of. This "unbound" LISTEN is exactly what SYN flooding goes after, because of how operating systems usually build it 😭
so for SYN flooding to work, it's counting on how the victim's TCP stack behaves. The attack assumes the victim allocates state for every SYN segment the moment it arrives, and that there's a cap on how much of that state can exist at once 🎀 The base TCP spec, RFC 793 [RFC0793], describes how incoming SYN segments get handled normally. It also describes a Transmission Control Block (TCB), which is the data structure holding all the state for one connection. In real life, operating systems can do this differently, but the key idea is that every TCP connection eats some memory 🦋
Per RFC 793, when a SYN shows up for a local TCP port that has a connection sitting in LISTEN, the state moves to SYN-RECEIVED and part of the TCB gets filled in from the SYN's header fields 🌸 In practice, lots of OSes don't touch the TCB that's in LISTEN. They make a copy of it and do the state change and update on the copy instead. The reason is so one local port can be shared by several different connections 💜 Copying the TCB isn't strictly required for that, but it does shape how apps that juggle lots of simultaneous connections on one port get written 🧚 The big takeaway is that instead of updating memory that's already allocated, new (or unused) memory has to be set aside for the copied TCB 🔥
Here's an example: in the Linux 2.6.10 networking code, a "sock" structure does the TCB job. Looking at it, that structure takes over 1300 bytes in memory 😳 Other systems with simpler TCP algorithms and options might have less overhead, but it usually goes over 280 bytes [SKK+97] 🍓
Hosts protect their memory from getting drained by connection requests by limiting how many TCB structures can exist at any moment, and OS kernels usually enforce that cap 🛡️ Different systems vary on whether the limit is global or per port number. They also vary on whether it counts fully established connections as well as the ones in SYN-RECEIVED 👑 Most systems have a parameter on the usual listen() system call that lets the app suggest a value for this limit, called the backlog 🌈 When the backlog limit is hit, incoming SYN segments either get ignored, or unfinished connections in the backlog get replaced 🙈 The standards docs don't describe the backlog concept at all, so what happens when it's full can differ between stacks (for example, TCP RSTs might get generated) 🤷♀️ That failure behavior decides whether the initiating hosts keep retransmitting their SYNs over time, or just give up fast ⏳ Those implementation differences are fine, since they only affect the local stack when its resources are tight, and they don't cause interoperability problems ✨
The SYN flood isn't trying to overload the network or the end host's memory 🙅♀️ It's just trying to drain the backlog of half-open connections tied to a port number. The plan is to blast a quick barrage of SYN segments from IP addresses (often spoofed) that won't reply to the SYN-ACKs they trigger 😈 If the backlog stays full of fake half-open connections, legit requests get rejected 💀 There are three big attack parameters for success: how big the barrage is, how often barrages get sent, and how the spoofed IP addresses are picked 🎯
Barrage Size
the barrage has to be big enough to fill the backlog, or it won't do anything 💅 Ideally, the barrage is no bigger than the backlog, so the attacker isn't sourcing more traffic than necessary 🍭 Typical default backlog values range from a half-dozen to several dozen, so an attacker can tailor the attack to whatever value the victim host and app use 🎀 Servers, especially ones handling a lot of traffic, often have their backlogs admin-configured to much higher values 📈
Barrage Frequency
to limit how long half-open connection state sticks around, TCP implementations usually reclaim memory from half-open connections that don't fully open after a certain amount of time 🕐 For example, a 75-second timer [SKK+97] might start when the first SYN-ACK is sent, and when it expires, the SYN-ACK retransmissions stop and the TCB gets released 💫 The TCP specs don't include giving up on connection setup after some arbitrary time limit 🙃 Some purists think the TCP implementation should keep retransmitting SYN and SYN-ACK segments with no artificial bounds (just with exponential backoff down to some conservative rate) until the app gives up 🧐 Still, common OSes today do put an artificial cap on half-open TCB lifetime anyway 🙄 For instance, backing off and stopping after a total of 511 seconds can be seen in 4.4 BSD-Lite [Ste95], and some OSes derived from that code still do it 🕰️
to stay effective, a SYN flood has to send fresh barrages of bogus requests as soon as the TCBs from the previous barrage start getting reclaimed 🔄 How often barrages go out is tuned to the victim's TCB reclamation timer 🎯 Sending more often than needed means more packets, which could draw extra attention 🚨 Sending too rarely leaves windows of time where legit connections can still get in 😬
IP Address Selection
for the attack to work well, the spoofed IP addresses have to be unresponsive to the SYN-ACK segments the victim sends back 👀 If addresses from normal connected hosts get used instead, those hosts will send the victim a TCP reset segment, which immediately frees the matching TCB and makes room in the backlog for legit connections 😤 The code in the original Phrack article used one single source address for all its spoofed SYN segments, which makes the attack segments easier to spot and filter 🙈 A strong attacker will keep a list of unresponsive and unrelated addresses to pick spoofed source addresses from 🥷
Note that this attack targets particular listening applications on a host, not the host itself or the network 🎯 It also only blocks new incoming connections to the victim port. It doesn't affect outgoing connection requests, or connections that were already established to the victim port 🫶
In practice, an attacker might skip spoofing and use a bunch of hosts to launch the SYN flood instead 🤖 For example, a collection of compromised hosts under the attacker's control (a "botnet") could do it. In that case, every host in the attack would have to suppress its operating system's native response to the SYN-ACKs coming from the target 🙅♀️ The attack TCP segments could also arrive more continuously than the word "barrage" here suggests 🌊 As long as the rate of new SYNs beats the rate at which TCBs get reaped, the attack will succeed 💖
3. Common Defenses 🛡️💜
This section talks about a bunch of defense techniques the community knows about, and a lot of them come in off-the-shelf products 🛒✨
3.1. Filtering 🚧
Here's the thing: unless an attacker has an army of controlled hosts, they need to be able to send packets with spoofed source IP addresses for this attack to work at all 😌 So blocking an attacker's ability to send spoofed IP packets is an effective fix that doesn't require changing TCP 🙌 The filtering techniques in RFCs 2827, 3013, and 3704 are the best current practices for packet filtering based on IP addresses [RFC2827][RFC3013][RFC3704] 📚 Perfectly effective, sure, but end hosts should not rely on filtering policies to stop attacks from spoofed segments, because global deployment of filters is neither guaranteed nor likely 🙃 And an attacker who can use a group of compromised hosts, or who can rapidly switch between different access providers, will make filtering totally useless 💀
3.2. Increasing Backlog 📈
the obvious first move for end hosts is to just use a bigger backlog 🤔 But Lemon showed that in FreeBSD 4.4, this tactic has some seriously bad side effects as the backlog grows [Lem02] 😬 That implementation wasn't designed to scale past a backlog of a few hundred, and the data structures and search algorithms it uses get inefficient with larger backlogs 🐢 It's reasonable to assume other TCP implementations have similar design factors that limit how they perform with large backlogs 🧱 And there doesn't seem to be a compelling reason to re-engineer stacks to support extremely large backlogs, since other solutions are available 🤷♀️ Still, to our knowledge, nobody has actually run experiments with large backlogs using efficient data structures and search algorithms yet 🔬
3.3. Reducing SYN-RECEIVED Timer ⏱️
another quick-to-implement defense is shortening the timeout between receiving a SYN and reaping the created TCB for lack of progress ⚡ But shrinking the timer that limits how long TCBs live in SYN-RECEIVED is also flawed 😩 A shorter timer does keep bogus attempts from hanging around in the backlog as long, freeing up space for legit connections sooner. But it can stop some fraction of legit connections from becoming fully established 💔 The tactic is also ineffective because it only makes the attacker increase their barrage frequency by a linearly proportional amount 🙄 This timer reduction is sometimes triggered as a response to crossing some threshold in backlog occupancy, or some rate of SYN reception 🚦
3.4. Recycling the Oldest Half-Open TCB ♻️
once the whole backlog is used up, some implementations let incoming SYNs overwrite the oldest half-open TCB entry 🫣 This works under the assumption that legit connections can be fully established in less time than it takes incoming attack SYNs to fill the backlog ⏳ But it can fail when the attacking packet rate is high and/or the backlog size is small, so it's not a robust defense 💅
3.5. SYN Cache ✨
okay so the SYN cache, which Lemon [Lem02] explained best, is all about keeping the state a SYN creates as tiny as possible 🦋. Instead of instantly making a full TCB, the host waits to allocate the full state until the connection is fully established. 💅 Hosts running a SYN cache keep some secret bits, which they pick from the incoming SYN segments. Those bits get hashed together with the IP addresses and TCP ports of the segment, and the hash value decides where in a global hash table the incomplete TCB gets stored. Each hash value has a bucket limit, and when that limit is hit, the oldest entry gets dropped 🍓
The SYN cache is so effective because the secret bits stop an attacker from aiming at specific hash values to overflow a bucket, and it caps both the CPU time and the memory needed 💜 Lemon's evaluation found that even when there's no SYN flooding attack happening, connection establishment is slightly quicker, thanks to the modified processing path 🌸 Under active attack, the SYN cache shifted the distribution of times to establish legitimate connections, roughly linearly, to about 15% longer than when nobody was attacking [Lem02]. Not bad at all, ngl ✨
If data comes along with the SYN segment, the receiver doesn't acknowledge or store that data, so it has to be retransmitted 🙈 This doesn't affect the reliability of TCP's data transfer service, but it does hurt performance a little bit. SYNs carrying data are used by the T/TCP extensions [RFC1644]. T/TCP is implemented in a bunch of popular operating systems [GN00], but it seems to be rarely used right now 😭 Measurements at one site's border router [All07] logged 2,545,785 SYN segments (not SYN-ACKs). Of those, 36 carried the T/TCP CCNEW option (or 0.001%). They 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), and every single one had exactly 24 bytes of data. So these observations suggest that issues with SYN caches and data on SYN segments may not be a big deal in deployment 🎀
3.6. SYN Cookies
SYN cookies take it one 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 would normally be kept into the sequence number sent on the SYN-ACK. If the SYN wasn't spoofed, the acknowledgement number (along with several other fields) in the ACK that completes the handshake can be used to rebuild the state that goes into the TCB 🔥 One of the best references on SYN cookies right now is on Dan Bernstein's web site [cr.yp.to]. This technique takes advantage of the long-understood low entropy in TCP header fields [RFC1144][RFC4413]. In Appendix A, we describe the SYN cookie technique, so the web page doesn't have to become unavailable 🫶
The exact mechanism for encoding state into the SYN-ACK sequence number can depend on the implementation 🌈 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 those random 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, along with secret bits. In practice, this hash has been generated using MD5 [RFC1321]. Any similar one-way hash could be used instead without hurting interoperability, since the hash value is checked by the same host that generates it 💖
The problem with SYN cookies is that the commonly implemented schemes don't work with some TCP options if the cookie generation scheme doesn't account for them 😬 For example, the Maximum Segment Size (MSS) advertised on the SYN has been handled by using 2 sequence number bits to represent 4 predefined common MSS values. Similar techniques would be needed for some other TCP options, while negotiated use of other TCP options can be detected implicitly. A timestamp on the ACK, for example, shows that Timestamp use was successfully negotiated on the SYN and SYN-ACK, and 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've first been received. For the common unidirectional data flow in many TCP connections, this can be a problem, because it limits SACK usage 🙈 For this reason, SYN cookies typically aren't used by default on systems that implement them. They're only enabled under high-stress conditions that indicate an attack, or through 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 in a similar way to how it's restored from the sequence number / acknowledgement in a basic SYN cookie. Using the Timestamp bits, it's possible to explicitly store state bits for things like send and receive window scales, SACK-allowed, and TCP-MD5-enabled, which a typical SYN cookie has no room for ✨ As far as we know, this use of Timestamps to improve on the compromises inherent in SYN cookies is unique to the FreeBSD implementation. A limitation is that the technique can only be used if the SYN itself contains a Timestamp option. But that option seems to be widely implemented today, and hosts that support window scaling and SACK typically support timestamps as well 💅
Just like SYN caches, SYN cookies don't handle application data piggybacked on the SYN segment 🦋
Another problem with SYN cookies shows up for applications where the first application data is sent by the passive host 😭 If this host is handling a large number of connections, packet loss may be likely. When a handshake-completing ACK from the initiator gets lost, the passive side's application layer never finds out the connection exists, so it never sends data, even though the initiator thinks the connection was successfully established 💀 An example of an application where the first application-layer data comes from the passive side is SMTP, if it's implemented according to RFC 2821. There, a service ready message is sent by the passive side after the TCP handshake completes 🍓
Although SYN cookie implementations exist and are deployed, the use of SYN cookies is often disabled in default configurations. So it's unclear how much operational experience actually exists with them, or whether using them opens up new vulnerabilities 🙈 Anecdotes of incidents where SYN cookies were used on typical web servers seem to suggest that the extra processing cost of computing MD5 sums for every SYN packet received isn't significant compared to losing 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, if the cache becomes full, SYN cookies can be sent instead of purging cache entries when new SYNs arrive. Hybrid approaches like this may give a strong combo of the positive aspects of each approach ⭐ Lemon has demonstrated the utility of this hybrid [Lem02] 🔥
3.8. Firewalls and Proxies
Firewall-based tactics can also be used to defend end hosts from SYN flooding attacks 🧚 The basic idea is to offload the connection establishment procedures onto a firewall. The firewall screens connection attempts until they're completed, and then proxies them back to the protected end hosts. This moves the problem away from the end hosts and turns it into the firewall's or proxy's problem, and it may introduce other problems related to altering TCP's expected end-to-end semantics 😬 A common tactic in these firewall and proxy products is to implement one of the end host based techniques discussed above, and to screen incoming SYNs from the protected network until the connection is fully established. This is done by spoofing the source addresses of several packets to the initiator and listener at various stages of the handshake [Eddy06] 👑
4. Analysis ✨
okay so the last section was all about defenses, and a bunch of them rely on stuff happening inside the network 🧱: router filtering, firewalls, and proxies. These can be super effective and often need no changes to end-host software 💅. But bestie, end hosts are mobile and their connectivity keeps changing, so it's kind of optimistic for TCP implementers to assume those protective devices will always be there 😬. TCP implementers should provide some means of defending against SYN flooding attacks in end-host implementations 🫶.
Among end-host changes, the SYN cache and SYN cookie approaches are the only viable techniques discovered to date 🔥. Increasing the backlog and reducing the SYN-RECEIVED timer are measurably problematic 🙈. The SYN cache has a higher memory footprint than SYN cookies, however SYN cookies may not be fully compatible with some TCP options, and they 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 don't 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, and it 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's known that loss of SYN-ACK packets is not uncommon [SD01], and it 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 aren't retransmitted, the chance of efficiently establishing legitimate connections goes down 📉.
In 1997, NetBSD incorporated a modified version of Borman's code 🧚. Two notable differences from the original code come from the decision to use the cache by default (for all connections). This meant the code needed to retransmit SYN-ACKs, and it needed 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 it does not use SYN cookies by default. This functionality has been in the Linux kernel for several years before 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]. Not okay, bestie 😭.
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. It defaulted to off until Windows 2003 SP1, where it's 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, the number of times SYN-ACKs are retransmitted before giving up is reduced, and the "Route Cache Entry" creation is delayed. That delay prevents some features (e.g., window scaling) from being used [win2k3-wp]. A real tradeoff, iykyk 🥲.
Several vendors of commercial firewall products sell devices that can mitigate SYN flooding's effects on end hosts by proxying connections 🛡️.
Discovering and exploiting the SYN flooding vulnerability in TCP's design gave protocol designers a valuable lesson 👑. 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. 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 it also involves a puzzle sent to the initiator that must be solved before the responder reserves any state. The general concept of designing statelessness into protocol setup to avoid denial-of-service attacks has been discussed by Aura and Nikander [AN97]. Main character energy for stateless design, no cap 🧠✨.
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 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 it might increase the robustness of the Internet to such attacks by encouraging use of the commonly available mitigations.
⚠️ bestie, this part is serious. If your stack has SYN flood mitigations available, check that they're actually turned on. Lots of them are off by default, and an attacker only needs one gap 💀.
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.
[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.
[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.Appendix A. SYN Cookies Description ✨
okay so this appendix is where the SYN cookie magic gets explained, bestie 🍓 it's taken from Bernstein's web page on SYN cookies [cr.yp.to], and it's basically a rewrite of his technical info, not a replacement. there are other slightly different ways to build SYN cookies, but the core idea is always the same: you hide data inside the SYN-ACK sequence number 🧚
A SYN cookie is an initial sequence number sent in the SYN-ACK. It's chosen based on the connection initiator's initial sequence number, MSS, a time counter, and the relevant addresses and port numbers. The actual bits are the bitwise difference (exclusive-or) between the SYN's sequence number and a 32 bit quantity, and that quantity is built like this: 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 the one in the SYN, and the bottom 24 bits are a server-selected secret function of the pair of IP addresses, the pair of port numbers, and the 32-bit counter used for the first 5 bits. this whole setup follows the rule that TCP sequence numbers increase slowly, so it's totally legit 💅
when a connection in LISTEN gets 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. that's the iconic part 🦋 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, using those counter values and the IP addresses and port numbers from the ACK segment. if there's a match, the connection can be accepted, since it's statistically very likely the other side received the SYN cookie and didn't just guess a valid cookie value. if there's no match, the connection can be rejected under the heuristic that it's probably not in response to a recently sent SYN-ACK. not me rejecting the random ACKs 💀
with SYN cookies enabled, a host stays responsive even when it's under a SYN flooding attack 🔥 the biggest price you pay is that the window scaling option gets disabled, and that kills high performance 😭
Bernstein's web page [cr.yp.to] has more on the first concept and implementation of SYN cookies, plus archives of emails documenting that history. it also lists some false negative claims people have made about SYN cookies, and it talks about reducing the vulnerability of SYN cookie implementations to blind connection forgery, where an attacker guesses valid cookies 🙈
the best description of the exact SYN cookie algorithms is in part of an email from Bernstein, which is archived on his site. fair warning, his email doesn't set the top five bits from the counter modulo 32 the way the previous description did. instead it uses 29 bits from the second MD5 operation and 3 bits for the index into the MSS table. and establishing the secret values isn't discussed either 🤓 the rest 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:
(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.govFull 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 💜
📦 where this page comes from
- ietf: rfc4987 2007-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms