RFC 4953
Defending TCP Against Spoofing Attacks
RFC 4953: Defending TCP Against Spoofing Attacks 🦋
Network Working Group 💖 Author: J. Touch, USC/ISI ✨ Category: Informational 🎀 Date: July 2007 🌸 Obsoletes / Updates: The title block doesn't list any RFC this one obsoletes or updates. 🧚
Part 1 of 7! 💅 Sections 1 and 2 are here, and the rest is coming.
Status of This Memo ✨
This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌈
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007). 💜
Abstract 🦋
Okay so, recent analysis of possible attacks on core Internet infrastructure shows that TCP connections are more vulnerable to spurious resets (RSTs) sent with forged IP source addresses, which is called spoofing. 😭 TCP has always been open to this kind of RST spoofing. It was only indirectly protected, by checking that the RST sequence number fell inside the current receive window, and by hiding the TCP endpoint and port numbers. 🙈
Now here's the tea. For pairs of well-known endpoints, often on predictable port pairs like BGP or links between web servers and big well-known caches, the path bandwidth-delay product has grown so much that the receive window is huge. That means off-path third parties can brute-force a working RST sequence number. ⭐ The susceptibility goes up with the square of the bandwidth, which makes it a big deal for recent high-speed networks. 💀
This document deals with that vulnerability. It talks about proposed fixes at the transport level and the challenges they bring, plus existing network-level fixes and how practical they are to deploy. 💅 It focuses on vulnerabilities from spoofed TCP segments, and it also covers related ICMP spoofing attacks on TCP connections. 🫶
Table of Contents 🧚
1. Introduction ....................................................3
2. Background ......................................................4
2.1. Review of TCP Windows ......................................5
2.2. Recent BGP Attacks Using TCP RSTs ..........................6
2.3. TCP RST Vulnerability ......................................6
2.4. What Changed - the Ever-Opening Advertised Receive Window ..7
3. Proposed Solutions and Mitigations .............................10
3.1. Transport Layer Solutions .................................10
3.1.1. TCP MD5 Authentication .............................11
3.1.2. TCP RST Window Attenuation .........................11
3.1.3. TCP Timestamp Authentication .......................12
3.1.4. Other TCP Cookies ..................................13
3.1.5. Other TCP Considerations ...........................13
3.1.6. Other Transport Protocol Solutions .................14
3.2. Network Layer (IP) Solutions ..............................14
3.2.1. Address Filtering ..................................15
3.2.2. IPsec ..............................................16
4. ICMP ...........................................................17
5. Issues .........................................................18
5.1. Transport Layer (e.g., TCP) ...............................18
5.2. Network Layer (IP) ........................................19
5.3. Application Layer .........................................21
5.4. Link Layer ................................................21
5.5. Issues Discussion .........................................21
6. Security Considerations ........................................22
7. Conclusions ....................................................23
8. Acknowledgments ................................................23
9. Informative References .........................................241. Introduction ✨
Analysis of the Internet infrastructure has just shown a new version of an old problem in BGP connections between core routers. The attack uses RST spoofing from off-path attackers [9][10][48]. 😱 The attack itself isn't new. It was written up nearly six years earlier [20]. These connections, usually over TCP, can be hit by off-path third-party reset (RST) segments with forged source addresses (spoofed), and those segments kill the TCP connection. 💔 BGP routers react to a dead TCP connection in different ways, and that can make the attack worse. They might restart the connection, or decide the other router is unreachable and flush the BGP routes [37]. This kind of attack can hit other protocols too, anything with a long-lived connection between well-known endpoints. 🌸 The impact on Internet infrastructure can be huge, especially for BGP, and it needs immediate attention. 🚨
TCP, like lots of other protocols, can be hit by these off-path third-party spoofing attacks. 🙄 They work because commodity platforms now give public access to things that used to be privileged, like system-level (i.e., root) access. Once someone has that, it's trivial for anyone to make a packet with any header they want. 🔓
Put that together with the lack of enough address filtering to drop spoofed traffic, and the chance for off-path third-party spoofing attacks goes up [9][10][48]. People have proposed fixes, like deploying existing Internet network and transport security, and changing transport protocols so they're less vulnerable to generated attacks [13][15][20][36][46]. 🛠️
One way to beat spoofing is to validate the segments of a connection, either at the transport level or the network level. TCP with MD5 extensions gives authentication at the transport level, and IPsec gives authentication at the network level [20][24][27]. Both come with deployment overhead that can be prohibitive. 😩 For example, a public service like a web server might not be able to be set up with the right certificate authorities for a huge number of peers (for IPsec using the Internet Key Exchange Protocol (IKE)), or with shared secrets (for IPsec in shared-secret mode, or TCP/MD5). That's because lots of clients might need to be configured fast, without outside help. Services on public web servers that connect to large-scale caches, or to BGP with lots of peers, can fall into this category. 🥹
The rest of this document lays out the recent attack scenario in detail and describes and compares a bunch of solutions. That includes existing solutions based on TCP/MD5 and IPsec, and newer proposals, like changes to TCP's RST processing [36], changes to TCP's timestamp processing [34], and changes to IPsec and TCP/MD5 keying [45]. This document focuses on spoofing of TCP segments, although it also discusses related spoofing of ICMP packets based on spoofed TCP contents. 🧁
Note that these attacks aren't new. Attacks using RSTs on BGP have been known since 1998, and they're the reason TCP/MD5 was developed [20]. The recent attack scenario was first documented by Convery at a NANOG (North American Network Operators' Group) meeting in 2003. But that analysis assumed the whole sequence space (2^32 packets) had to be covered for an attack to work [10]. Watson's more detailed analysis found that a single packet anywhere in the current window could succeed as an attack [48]. This document adds the observation that susceptibility to attack is directly proportional to the square of bandwidth. That's because the receive window size grows linearly, and the rate of a potential attack also grows linearly. 🧠 It also compares a variety of more recent proposals, including changes to TCP, use of IPsec, and use of TCP/MD5 to resist these attacks. 👑
2. Background 🌷
The recent analysis of potential attacks on BGP has brought TCP's vulnerability to off-path third-party spoofing attacks back into the spotlight [9][10][48]. A bunch of these attacks have been known for years. They include sending RSTs, SYNs, and even ACKs, trying to affect an existing connection or overload servers. 😤 These attacks often combine outside knowledge (for example, the IP addresses to attack, the destination port number, and sometimes the Initial Sequence Number (ISN)) with brute-force power from modern computers and network bandwidths. For instance, they might scan all source ports or an entire window space. Overall, these attacks are countered by some form of authentication at the network layer (e.g., IPsec), the transport layer (e.g., SYN cookies, TCP/MD5), or other layers. 🔐 TCP already has a weak form of this authentication in its check of segment sequence numbers against the current receiver window. But bandwidth-delay product increases on certain long connections have weakened that check so much that relying on it is a bad idea. 🙅♀️
2.1. Review of TCP Windows 🎀
Before we go on, let's review the terms and parts of TCP's windowing algorithm, bestie. 📚 TCP connections have three kinds of windows [1][35]:
- Send window (
SND.WND): the latest send window size. - Receive window (
RCV.WND): the latest advertised receive window size. - Congestion window (
CWND): the window set by congestion feedback that limits how much ofRCV.WNDcan be in flight in one round-trip time.
For TCP connections in most modern implementations, SND.WND and RCV.WND are the sizes of the matching send and receive socket buffers. You can configure them with socket buffer resizing commands. 🧚♀️
CWND decides how much data can be in transit in one round-trip time. SND.WND decides how much data the sender is willing to store on its side for possible retransmission after loss. And RCV.WND decides how well the receiver can handle that loss and reorder received packets. CWND never grows beyond RCV.WND. 💅
High bandwidth-delay product networks need CWND to be big enough to hold as much data as can be in transit in a round-trip time. Otherwise their performance suffers. 😩 So it's recommended that users and various automatic programs increase RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay product) [23][38]. ⭐
As the bandwidth-delay product of a network goes up, though, these bigger advertised receive windows can make connections more open to spoofing attacks. The rest of this document shows how. 🕵️♀️ That assumes, however, that the receive window size (for example, through a bigger receive socket buffer configuration) goes up along with the bandwidth-delay product. If it doesn't, connection performance will degrade. But susceptibility to spoofing attacks will only increase linearly (with the rate at which the attacker can send spoofed packets), not with the square of the bandwidth. 📉 Note that either increase depends on the receive window itself. It's independent of the congestion state or the amount of data transmitted. 🫶
2.2. Recent BGP Attacks Using TCP RSTs ✨
okay so BGP is a huge target for spoofing because it uses TCP connectivity to figure out routability 🗺️. That means if you lose a TCP connection with a BGP peer, the routes you learned from that peer can get flushed 😳 [37].
Until six years ago, these connections were considered pretty hard to attack, since they were described by a few comparatively obscure parameters [20]. Most TCP connections are wrapped in several layers of obfuscation, except at the endpoints of the connection 🎀:
- Both endpoint addresses are usually not well-known; although server addresses are advertised, clients are somewhat anonymous.
- Both port numbers are usually not well-known; the server's is usually advertised (representing the service), but the client's is typically sufficiently unpredictable to an off-path third-party.
- Valid sequence number space is not well-known.
- Connections are relatively short-lived and valid sequence space changes, so any attempt to guess (e.g., by external knowledge or brute force) the above information is unlikely to be useful.
BGP is an exception to the criteria above (though not the only case) 🙈. Both endpoints can be well-known, or guessed using hints from part of an AS path. The destination port is typically fixed to indicate the BGP service. The source port used by a BGP router is sometimes fixed and advertised to enable firewall configuration 🧱. Even when it isn't fixed, there are only approximately 65,000 valid source ports, which means they can be exhaustively attacked 💀. Connections are long-lived, and, as noted before, some BGP implementations interpret successive TCP connection failures as routing failures, discarding the corresponding routing information. Plus, the valid sequence number space that was once thought to provide some protection has been significantly weakened by increasing advertised receive window sizes 📈.
2.3. TCP RST Vulnerability 🥀
TCP has a known vulnerability to third-party spoofed segments. SYN flooding eats up server resources in half-open connections, which affects the server's ability to open new connections [4][11]. ACK spoofing can make connections transmit too much data too quickly, creating network congestion and segment loss, and causing connections to slow to a crawl 🐌. In the most recent attacks on BGP, RSTs cause connections to be dropped. As noted earlier, some BGP implementations interpret TCP connection termination, or a series of such failures, as a network failure [37]. This causes routers to drop the BGP routing information already exchanged, and it also inhibits their ongoing exchanges, which amplifies the impact of the attack 📣. The result can affect routing paths throughout the Internet 🌍.
The dangerous effects of RSTs on TCP have been known for many years, even when they're sent by the legitimate endpoints of a connection 😬. TCP RSTs cause the receiver to drop all connection state. Because the source isn't required to maintain a TIME_WAIT state, such a RST can cause premature reuse of address/port pairs, which could let segments from a previous connection contaminate the data of a new connection. This is known as TIME_WAIT assassination [8]. In this case, assassination happens inadvertently as the result of duplicate segments from a legitimate source, and it can be avoided by blocking RST processing while in TIME_WAIT. However, assassination can be useful to deliberately reduce the state held at servers 🧹. This requires that the source of the RSTs goes into TIME_WAIT state to avoid such hazards, and that RSTs are not blocked in the TIME_WAIT state [12].
Firewalls and load balancers, so-called 'middleboxes', sometimes emit RSTs on behalf of transited connections to optimize server performance, as noted in RFC 3360 [14]. This is effectively an on-path RST attack in which the RSTs are sent with benign or beneficial intent 🤷♀️. There are numerous hazards with this kind of RST use, which are outlined in that RFC.
2.4. What Changed - the Ever-Opening Advertised Receive Window 🪟
RSTs are a hazard to TCP, especially when they're completely unvalidated 🚨. Luckily, there are a number of obfuscation mechanisms that make it hard for off-path third parties to forge (spoof) valid RSTs, as noted earlier. We've already shown it's easy to learn both endpoint addresses and ports for some protocols, notably BGP. The final obfuscation is the segment sequence number 🔐.
TCP segments include a sequence number, which enables out-of-order receiver processing as well as duplicate detection. The sequence number space is also used to manage congestion, and it indicates the index of the next byte to be transmitted or received. For RSTs, this matters because legitimate RSTs use the next sequence number in the transmitter window, and the receiver checks that incoming RSTs have a sequence number in the expected receive window. This processing is meant to eliminate duplicate segments (somewhat moot for RSTs, though), and to drop RSTs that were part of previous connections 🧼.
TCP uses two window mechanisms: a primary mechanism for reordering and congestion control (which uses a space of 32 bits), and a secondary mechanism that scales this window [23][35]. The valid advertised receive window is a fraction, not to exceed approximately half, of this space, or ~2 billion (2 * 10^9, i.e., 2E9 or 2 U.S. billion) 🤯. Under typical configurations, the majority of TCP connections open to a very small fraction of this space, e.g., 10,000-60,000(approximately 5-100 segments). This is because the advertised receive window typically matches the receive socket buffer size. It is recommended that this buffer be tuned to match the needs of the connection, either manually or by automatic external means [38] 🛠️.
On a low-loss path, the advertised receive window should be configured to match the path bandwidth-delay product, including buffering delays (assume 1 packet/hop) [38] 📏. Many paths on the Internet have end-to-end bandwidths of under 1 Mbps, latencies under 100 ms, and are under 15 hops, which results in fairly small advertised receive windows as above (under 35,000 bytes) 🐣. Under these conditions, and further assuming the initial sequence number is suitably (pseudo-randomly) chosen, a valid guessed sequence number would have odds of 1 in 57,000 of falling within the advertised receive window. Put differently, a blind (i.e., off-path) attacker would need to send 57,000 RSTs with suitably spaced sequence number guesses within one round-trip time to successfully reset a connection. At 1 Mbps, 57,000 (40 byte) RSTs would take only 20 seconds to transmit, but this presumes that both IP addresses and both ports are known ⏱️. Without knowledge of the source port, an off-path spoofer would need to try at least the entire range of 49152-65535, or 16,384 different ports, which makes an attack that would take over 91 hours 😩. Because most TCP connections are comparatively short-lived, even this moderate variation in the source port is sufficient for such environments, although further port randomization may be recommended [29] 🎲.
Recent use of high bandwidth paths of 10 Gbps and higher results in bandwidth-delay products over 125 MB. That's approximately 1/10 of TCP's overall maximum advertised receive window size (i.e., assuming the receive socket buffers are increased as much as possible) excluding scale, assuming the receiver allocates sufficient buffering (as discussed in Section 2) 🚀. Even on networks that are ten times slower (1 Gbps), the active advertised receive window covers 1/100th of the overall window size. At these speeds, it takes only 10-100 packets, or less than 32 microseconds, to correctly guess a valid sequence number and kill a connection ⚡. A table of corresponding exposure to various amounts of RSTs is shown below, for various line rates, assuming the more conventional 100-ms latencies (though even 100 ms is large for BGP cases) 📊:
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
Figure 1: Time needed to kill a connectionThis table shows that the effect of bandwidth on the vulnerability is squared 😱. For every increase in bandwidth, there's a linear decrease in the number of sequence number guesses needed, as well as a linear decrease in the time needed to send a set of guesses. Notably, as inter-router link bandwidths approach 1 Mbps, an 'exhaustive' attack becomes practical 🚨. Checking that the RST sequence number is somewhere in the advertised receive window, out of the overall maximum receive window (2^32), is an insufficient obfuscation 🙅♀️.
Note that this table makes a number of assumptions:
- The overall bandwidth-delay product is relatively fixed.
- Traffic losses are negligible (insufficient to affect the congestion window over the duration of most of the connection).
- The advertised receive window is a large fraction of the overall maximum receive window size, e.g., because the receive socket buffers are set to match a large bandwidth-delay product.
- The attack bandwidth is similar to the end-to-end path bandwidth.
Of these assumptions, the last two are the most notable 👀. The issue of receive socket buffers was discussed in Section 2. Figure 1 summarized the time to a successful attack based on large advertised receive windows, but many current commercial routers have limits of 128 KB for large devices, 32 KB for medium, and as little as 4 KB for modest ones 📉. Figure 2 shows the time and bandwidths needed to accomplish an attack on BGP sessions in the time shown for 100-ms latencies. For even short-range network latencies (10 ms), these sessions can still be attacked over short timescales (minutes to hours) ⏳.
Receive
BW Buffer Size RSTs needed Time needed
------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour
Figure 2: Time needed to kill a connection with limited buffersThe issue of attack bandwidth is considered reasonable for the following reasons 🧠:
- RSTs are substantially easier to send than data; they can be precomputed and they are smaller than data packets (40 bytes).
- Although susceptible connections use somewhat less ubiquitous high-bandwidth paths, the attack may be distributed, at which point only the ingress link of the attack is the primary limitation.
- For the purposes of the above table, we assume that the ingress at the attack has the same bandwidth as the path, as an approximation.
The previous sections discussed the nature of the recent attacks on BGP, which come from TCP's vulnerability to RST spoofing 🎯. That vulnerability is largely due to recent increases in the fraction of the TCP advertised receive window space in use for a single, long-lived connection 💜.
3. Proposed Solutions and Mitigations ✨
okay so bestie, here's the deal 🫶 TCP already checks two things when it gets an RST: the address and port pair, and whether the sequence number sits inside the valid receive window. Last section we saw how TCP got way more vulnerable to RST spoofing as the receive window grew bigger 😭 So people have come up with a bunch of solutions, both current and proposed, and they all try to prove that a received RST is actually legit 💅
3.1. Transport Layer Solutions
The transport layer is the last spot where segments can be authenticated before they start messing with connection management 👑 TCP has a whole lineup of mechanisms, current and proposed, to make segments more authenticated, and they guard against both off-path and on-path third-party spoofing attacks 🛡️ Other transport protocols like SCTP and DCCP have some antispoofing mechanisms too, though they're more limited 🦋
3.1.1. TCP MD5 Authentication
An extension to TCP that supports MD5 authentication was developed in 1998, specifically to authenticate BGP connections (though it works for any TCP connection) [20]. 🌸 It relies on a pre-shared secret key to authenticate the whole TCP segment, which covers the data, the TCP header, and the TCP pseudo-header (some fields from the IP header). Every segment is protected, RSTs included, and a segment only gets accepted when its signature matches 🔐 This option is widely deployed in Internet routers, but it's considered undeployable for widespread use because of the need for pre-shared keys [3][30]. It's also considered computationally expensive for both hosts and routers because of the overhead of MD5 [43][44] 💀
There are also concerns about MD5 because of recent collision-based attacks [22] 😬 SHA-1 has similar concerns, and the IETF is currently evaluating how these attacks affect the recommendation to use these hashes, both in TCP/MD5 and in the IPsec suite. For this discussion, the particular algorithm used in either protocol suite isn't the focus. There's ongoing work to let TCP/MD5 evolve into a more general TCP security option [6][47] ✨
3.1.2. TCP RST Window Attenuation
A recent proposal extends TCP so that a received RST has to match the expected next sequence number [36] 🎀 This restores TCP's resistance to spurious RSTs, and it effectively limits the receive window for RSTs down to a single number. As a result, an attacker would need to send 2^32 different packets to brute-force guess the sequence number. In the worst case, the average would be half that. This makes TCP's vulnerability to attack independent of the size of the receive window (RCV.WND) 🧠 The extension also changes how the RST receiver reacts to incorrectly-numbered RSTs: it sends back a zero-length ACK 🦋 If the RST source is legitimate, then once it gets that ACK, the closed source would presumably send a RST with the sequence number matching the ACK, which correctly resets the intended recipient.
Now here's the tea ☕ This modification changes TCP's control processing, which adds complexity and could potentially affect correctness. (Adding MD5 signatures is different, since it's orthogonal to TCP control processing altogether.) For example, there may be complications between RSTs for different connections between the same pair of endpoints, because RSTs flush the TIME-WAIT state (as mentioned earlier) 😭 Also, this proposal modifies TCP so that, in some circumstances, a RST causes a reply (an ACK). That goes against generally accepted practice, if it isn't a gentle recommendation against it, although the reply can be omitted, letting timeouts do the job instead 🙈 The advantage is that it can be deployed incrementally and benefits the endpoint where it's deployed 💖 The other advantage is that window attenuation makes the vulnerability to spoofed RST packets independent of the size of the receive window 👑
A variant of this proposal uses a different value to attenuate the window of viable RSTs. It requires RSTs to carry the initial sequence number instead of the next expected sequence number, meaning the value negotiated on connection establishment [42][49] 🌈 This has the advantage of using an explicitly negotiated value, but it comes at the cost of changing how an unmodified endpoint behaves for a currently valid RST. So without some additional mechanism, it would be harder to deploy incrementally 🥲
Another variant increases TCP's window space instead of decreasing the valid range for RSTs. That means growing the sequence space from 32 bits to 64 bits 🔥 It has the equivalent effect: the ratio of valid sequence numbers for any segment to the overall sequence number space gets significantly smaller. Using the larger space depends on suitably random values for the ISN, the same as current schemes that set up weak authentication using initial sequence numbers (ISNs). That randomness adds complexity to TCP, both in the specification and in the implementation, and it only provides very weak authentication. Also, this modification isn't obviously backward compatible, so it would be difficult to deploy 🙃
The converse of increasing window space is to decrease the receive window (RCV.WND) explicitly. That would further reduce the effectiveness of spoofed RSTs that use random sequence numbers 🍓 The catch is that this alternative may reduce the throughput of the connection if the advertised receive window ends up smaller than the bandwidth-delay product of the connection 📉
3.1.3. TCP Timestamp Authentication
Another way to authenticate TCP segments is through the timestamp option, using its value as a sort of authentication [34] ⏰ This requires the receiver TCP to discard segments whose timestamp falls outside the accepted window, and that window is derived from the timestamps of other packets on the same connection. It uses an existing TCP option, but it also needs modified TCP control processing (with the same caveats as before). It may be hard to deploy incrementally without further modifications 🧩 And the timestamp value may be easier to guess, because it can be derived predictably. You could assume it represents the actual time at the host, or you could probe the host with unrelated benign traffic 🕵️♀️
3.1.4. Other TCP Cookies
All of the above techniques are variants of cookies, which are basically meaningless data whose value gets used to validate the packet 🍪 With MD5 checksums, the cookie is computed from a shared secret. Note that even a signature can be guessed, and it carries a 1 in 2^(signature length) probability of attack 😬 The main difference is that MD5 signatures are effectively one-time cookies. They aren't predictable from on-path snooping, because they depend on packet data and therefore don't repeat 🔐 Window attenuation sequence numbers can be guessed by snooping the sequence numbers of current packets on an existing connection. Timestamps can be guessed even less directly, either through separate benign connections or by assuming they roughly correlate to local time ⏳ These cookie variants are similar in spirit to TCP SYN cookies. Again, they patch a vulnerability to off-path third-party spoofing attacks, using a form of authentication that's fairly weak, except for MD5 🌸
Another form of cookie is the source port itself. It can be randomized, but it only provides 16 bits of protection (65,000 combinations), which means it can be exhaustively attacked 😭 You can combine this with destination port randomization too, but that needs a separate coordination mechanism so both parties know which ports to use. That's equivalent to exchanging a shared secret, and it's just as infeasible for large-scale deployments [39] 🙅♀️
3.1.5. Other TCP Considerations
The analysis of RST spoofing potential above assumes that the advertised receive window is opened to the maximum extent suggested by the bandwidth-delay product of the end-to-end path. It also assumes the window is opened to an appreciable fraction of the overall sequence number space. As noted earlier, for most common cases, connections are too brief, or run over bandwidths too low, for such a large window to be useful 🤏 Expanding TCP's sequence number space is a direct way to avoid this vulnerability even further, including for long connections over emerging bandwidths 🚀 If neither manual tuning nor automatic tuning of the advertised receive window (via receive buffer tuning) is provided, this stops being an issue, although connection performance will suffer [38] 🐢
The endpoint can also limit the advertised receive window by deliberately keeping it small 🧸 If the receive socket buffer is limited, say to the ubiquitous default of 64 KB, the advertised receive window won't be as vulnerable, even for very long connections over very high bandwidths. The vulnerability grows linearly with network speed, not as the square. The tradeoff is lower sustained throughput, since only one window's worth of data gets exchanged per round-trip time (RTT) 💅
Keeping the window small will keep the connection open longer. For long-lived connections with continuous sourced data, this may still present an attack opportunity, although it's a sparse and slow-moving target 🐌 In the most recent case, where BGP data is exchanged between Internet routers, the data is bursty and the aggregate traffic may be small. That means it's unlikely to cover a substantial portion of the sequence space, even if the connection is long-lived. So smaller advertised receive windows (via small receiver buffers) may, in some cases, be enough to address the immediate problem 🌟 This assumes the routing tables can still be exchanged quickly enough with the bandwidth reduced by the smaller buffers. Or it assumes the advertised receive window is only opened during a large burst exchange, for example through some other signal between the two routers, or a time-based signal. Either of those would be nonstandard though 🙈
3.1.6. Other Transport Protocol Solutions
Segment authentication has also been addressed at the transport layer in other protocols. Both SCTP and DCCP include cookies for connection establishment, and they use them to authenticate a variety of other control messages [28][41] 🍰 Putting this mechanism in the transport protocol is emerging as standard practice, but it complicates the design and implementation of new protocols [32]. As new attacks get discovered (SYN floods, RSTs, and so on), each protocol has to be modified individually to compensate. A network solution may be more appropriate and efficient 🌐
It's worth noting that RST attacks, which rely on brute force, are relatively easy for intrusion detection software to spot at the TCP layer 👀 Any connection that receives a large number of invalid (outside-window) RSTs might have its subsequent RSTs blocked, which would defeat such attacks. The catch is that this also blocks legitimate RSTs to that connection, which might then interfere with cleaning up the transport state between the endpoint peers 😬 This side-effect, combined with the increased monitoring load, might make such solutions undesirable in the general case. They might still be useful in special cases though, for example for BGP on routers 🧚
3.2. Network Layer (IP) Solutions 🌐✨
okay so there are two main flavors of network layer fixes for spoofing: address filtering and IPsec 💅. Address filtering is kind of indirect. It leans on other parties to filter packets upstream of an attack, and it doesn't necessarily need the packet source to take part. IPsec is more of a team sport 🫶. The endpoints who want to dodge an attack on their connection have to cooperate, and that currently means they need some preexisting shared knowledge, either a shared key or a shared certificate authority.
3.2.1. Address Filtering 🚧
Address filtering gets pitched a lot as the alternative to protocol mechanisms for beating IP source address spoofing [2][13]. The idea is that it restricts traffic from downstream sources across transit networks based on the IP source address. Connections already get a bit of filtering at the endpoints, since attack messages have to match the socket pair to work. But ngl, attacks like that need to know the entire socket pair, so they're unlikely except in particular cases 🙈. This section is only about filtering by address, which usually happens at the borders of an AS.
It can also restrict core-to-edge paths so traffic that should have started further toward the edge gets rejected 🧚. What it can't do is restrict traffic coming from edges that don't filter, flowing through the core to a particular edge 💀. So every border router has to do its part, because if even one border router fails to filter, the protection falls apart for everyone inside that border, and maybe for people outside too 😭. Filtering at the border can protect the folks inside from some kinds of spoofing, like connections among insiders, since only interior addresses should originate inside the border. But it can't protect connections that include endpoints outside the border (the ones that cross the AS boundary), except to restrict where the traffic is allowed to enter from. For example, traffic might be expected from one AS and not another.
So yeah, address filtering is not a local solution you can roll out to protect a pair of communicating endpoints 🙅♀️. It depends on a distributed setup of trusted gateways filtering forged traffic where it enters the network. It isn't feasible for local, incremental deployment, but it might be useful for connections among those inside the protected border in some scenarios 🌸. Filtering can also help cut down the network load caused by spoofed traffic [31].
A newer flavor of address filtering checks the IP TTL (Time to Live) field and relies on the TTL that the other end of the connection set [15] 🕰️. This has been used to filter BGP. It assumes the connection source TTL is set to 255. Packets arriving at the receiver are checked for TTL=255, and anything else gets dropped. This restricts traffic to one hop upstream of the receiver (so, a BGP router). But those hops could include other user programs on those nodes (like the BGP router's peer), or any traffic those nodes accept through tunnels 👀. The reason is that tunnels don't have to decrement TTLs, which matters a lot for "bump in the wire" (BITW) or BITW-equivalent scenarios [33] (see also Section 5.1 of [15] and [16]). TTL filtering only works where all traffic from the other end of the tunnel is trusted, meaning it doesn't originate or transit spoofed traffic 🫠. Using TTL instead of link or network security also assumes an untampered point-to-point link, where no other traffic can be spoofed onto the link.
This method works best when traffic originates one hop away, so the address filtering is based on trusting only directly-connected nodes (tunneled or otherwise) 💜. Like conventional address filtering, it cuts down spoofing traffic in general. But it's not considered a reliable security mechanism because it depends on distributed filtering, like the fact that upstream nodes don't terminate tunnels arbitrarily 😤.
3.2.2. IPsec 🔐
TCP is vulnerable to RSTs, but it's also open to other off-path and on-path spoofing attacks, including SYN attacks 😩. UDP and RTP are just as exposed. Emerging transport protocols try to defeat these attacks at the transport layer, but these attacks take advantage of network layer identity spoofing. The packet is coming from an endpoint that's pretending to be another endpoint, either upstream or somewhere else on the Internet 🎭. IPsec was built specifically to establish and enforce authentication of a packet's source and contents, so it addresses this vulnerability as directly and explicitly as possible 🔥.
The bigger problem with IPsec is key distribution and use. Honestly it's pretty cumbersome, and only recently have a lot of end-system operating systems supported it 🥲. More importantly, it relies on preshared keys, signed X.509 certificates, or a trusted third-party key infrastructure (like Kerberos) to establish and exchange keying information (like via IKE). Each of these creates challenges when you want to use IPsec to secure traffic to a well-known server, whose clients might not support IPsec or might not have registered with a previously-known certificate authority (CA) 🙃.
Good news though: these keying challenges are being worked on in the IETF in ways that will let servers set up secure associations with other parties without advance coordination [45][46] ✨. This could be especially useful for publicly-available servers, or for protecting connections to servers that, for whatever reason, have not or will not deploy conventional IPsec certificates (for example, core Internet BGP routers) 🌈.
4. ICMP 📡
Just like spoofed TCP packets can terminate a connection, spoofed ICMP packets can too 😱. ICMP can be used to launch a whole bunch of attacks on TCP, including connection resets and path-MTU attacks. It can also be used to attack the host itself with non-TCP attacks like 'ping of death' and 'smurf attacks', etc. [40]. So ICMP is a substantial threat to TCP 🚨. But it isn't the focus of this document, although a number of protections are discussed below because some are comparable to TCP anti-spoofing techniques 🦋. Also note that ICMP attacks on TCP assume the attacker knows the socket pair, which is unlikely except for a subset of services between pairs of widely-known endpoints 🤷♀️.
TCP headers can be included inside certain ICMP messages [7]. There have been recent suggestions to validate the sequence number of TCP headers when they show up inside ICMP messages [18]. This sequence checking is similar to the checks that happen for regular data packets in TCP, but it's being proposed in the spirit of the RST window attenuation described in Section 3.1.2 🌷.
Some of these checks may be reasonable, especially where they parallel the validations TCP already does, particularly where they copy the semantics of that processing 💅. For example, the TCP checksum should be validated (if the entire TCP segment is contained in the ICMP message) before any fields of the TCP header get examined, so you don't react to corrupted packets 🧼. Similarly, if the TCP MD5 option is present, its signature should probably be validated before considering the contents of the message 🔑. That validation can make sure the packet wasn't corrupted before the ICMP was generated (checksum), that the packet was actually sent by the source (IPsec or TCP/MD5 authenticated), or that the packet wasn't sitting in the network for longer than 2*MSL (valid sequence number) ⏳.
ICMP is a particular challenge because some messages can reset a connection more easily, with less validation, than even some spoofed TCP segments 😬. One other proposed alternative is to change how TCP reacts to ICMPs after a connection is established. But that may leave TCP vulnerable during connection establishment, and it also changes how TCP reacts to certain valid network events [19]. This approach does consider the context-sensitivity of ICMP messages, just like IPsec does in some tunneled configurations. But the recommendations are ambiguous about such filtering [27] 🤔.
Ultimately, requiring TCP ICMP messages to be 'in window' might not be enough protection, as this document shows for spoofed data 🙈. ICMP packets can be authenticated when they originate at known, trusted endpoints, like the endpoints of connections or routers in known domains that already have IPsec associations 🛡️. Unfortunately, they can also originate from other places in the network. Plus, some networks filter out all ICMP packets because validation may not be possible. This is especially true since they can be injected from anywhere in a network, so they can't be easily and locally address filtered [27] 💀. Because of all that, ICMP isn't addressed separately in the issues or security considerations of this document from here on 🫶.
5. Issues 🧩
There are a bunch of existing and proposed solutions for the vulnerability of transport protocols in general (and TCP in particular) to off-path third-party spoofing attacks 🌈. As shown, these operate at the transport or network layer. Transport solutions need separate modification of each transport protocol, and they handle network identity spoofing separately within the context of each transport association 🧠. Network solutions either need distributed coordination (filtering), or they can be computationally intensive and require pervasive registration of certificate authorities with every possible endpoint (authentication) 😮💨. This section explains these observations in more detail 💖.
5.1. Transport Layer (e.g., TCP) 🦋
okay so transport solutions rely on shared cookies to authenticate segments 💅. that includes the data, the transport header, and even the pseudo-header (like the fixed parts of the outer IP header in TCP). because the Internet runs on stateless network protocols, it's giving "let's use the state that some transport layers already keep, not just for the connection but for the authentication state too" ✨. three-way handshakes and heartbeats can negotiate auth state along with the connection parameters, and that state can be stored right alongside the connection state. so convenient 🎀
ngl, transport layer solutions need every transport protocol modified separately to include authentication 💀. not every transport protocol supports negotiated endpoint state (UDP, for example), and legacy protocols have been notoriously hard to safely augment 😭. also, not all authentication solutions are created equal. using a bunch of different transport solutions means end-systems have more chances of getting one specified or implemented wrong 🙈. transport auth has mostly been developed piecemeal, in response to specific attacks, like SYN cookies and RST window attenuation [4][36] ✨.
transport layer solutions are not only per-protocol but often per-connection 🍓. this has both perks and downsides. one perk is that they can protect the transport protocol when lower layers have failed, like because of bugs in implementation. TCP already has a bunch of packet validation mechanisms for these cases, like checking that RSTs are in-window. stricter checks can add more protection, like guarding against misaddressed RSTs that end up in-window (via TCPsecure), or against connection interruption due to RSTs, SYNs, or data injection from misaddressed packets (TCP/MD5) [36] 👑.
another perk is that transport protections can be limited more specifically to one particular connection. since each connection negotiates its state separately, that state can be tied to that connection more tightly. this is a perk AND a drawback 🙃. it makes it easier to tie security to an individual connection, although in practice a shared secret or certificate will generally be shared across multiple connections.
the drawback is that each transport connection has to negotiate and maintain auth state separately. some overhead isn't amortized over multiple connections (like overhead in packet exchanges), whereas other overhead isn't amortized over different transport protocols (like design and implementation complexity). both of those would also be the case in a network layer solution 😤. because authentication happens later in packet processing than it needs to, extra endpoint resources may get needlessly used up. think demultiplexing received packets, indexing connection identifiers, and continuing to buffer spoofed packets, etc., only for them to be dropped later at the transport layer 💀.
5.2. Network Layer (IP) 🌈
a network layer solution avoids the hazards of multiple transport variants 🧚. it uses a single shared endpoint authentication mechanism early in receiver packet processing, so unauthenticated packets get discarded at the network layer instead. this defeats spoofing entirely, because spoofing is masquerading as another endpoint, and network layer security validates the endpoint as the source of the packets it emits. such a network-level solution protects all transport protocols as a result, both legacy and emerging ones, and it reduces their complexity too. a shared solution also cuts protocol overhead and decouples the management (and refreshing) of auth state from individual transport connections. finally, a network layer solution protects not just the transport layer but the network layer as well, e.g., from IGMP and some kinds of ICMP (Section 4) spoofing attacks 🫶.
the IETF Proposed Standard protocol for network layer auth is IPsec [27]. IPsec specifies the overall architecture, including header authentication (AH) [25] and encapsulation (ESP) modes [26] 👑.
AH authenticates both the IP header and IP data, whereas ESP authenticates only the IP data (e.g., transport header and payload). AH is being phased out, since ESP is more efficient and the Security Parameters Index (SPI) includes enough info to verify the IP header anyway [27] 💅. these two modes describe the security applied to individual packets within the IPsec system. key exchange and management is performed either out-of-band (via pre-shared keys) or by an automated key exchange protocol, e.g., IKE [24] 🔑.
IPsec already provides auth of an IP header and its data contents, which is sufficient to defeat both on-path and off-path third-party spoofing attacks 🔥. IKE can configure auth between two endpoints on a per-endpoint, per-protocol, or per-connection basis, as desired. IKE can also do automatic periodic re-keying, which further defeats crypto-analysis based on snooping (clandestine data collection) 🕵️. the use of IPsec is already commonly strongly recommended for protected infrastructure 🍓.
existing IPsec isn't appropriate for many deployments 😬. it's computationally intensive, both in key management and in individual packet auth [43]. this overhead can be prohibitive, so it often needs extra hardware, especially in commercial routers. as importantly, IKE is not anonymous. keys can be exchanged between parties only if they trust each other's X.509 certificates, trust some other third party to help with key generation (e.g., Kerberos), or pre-share a key. these certificates provide identification (the other party knows who you are) only where the certificates themselves are signed by certificate authorities (CAs) that both parties already trust. to a large extent, the CAs themselves are the pre-shared keys that help IKE establish security association keys, which are then used in the auth algorithms 🥺.
alternative mechanisms are under development to address this limitation 🌸. they aim to let publicly-accessible servers secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so the remaining protections of IPsec can still be available [45][46]. in particular, these mechanisms can keep a client (without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path.
IPsec, although widely available in commercial routers and commodity end-systems, isn't often used except between parties that already have a preexisting relationship (employee/employer, between two ISPs, etc.). servers to anonymous clients (e.g., customer/business), or more open services (e.g., BGP, where routers may have large numbers of peers), are unmanageable due to the breadth and flux of CAs 😩. new endpoints can't establish IPsec associations with such servers unless their own certificate is signed by a CA the server already trusts. different servers, even within the same overall system (e.g., BGP), often cannot or will not trust overlapping subsets of CAs in general 💀.
5.3. Application Layer 🎀
there are a number of application layer auth mechanisms, often implicit within end-to-end encryption ✨. application layer security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) provides the ultimate protection of app data from all intermediaries, including network routers, as well as exposure at other layers in the end-systems. this is the only way to ultimately protect the app data 💖.
app auth can't protect either the network or transport protocols from spoofing attacks, though 🙅. spoofed packets interfere with network processing or reset transport connections before the app checks the data. auth needs to winnow these packets and drop them before they interfere at these lower layers 🧹.
an alternate app layer solution would involve resilience to reset connections. if the app can recover from such connection interruptions, then such attacks have less impact. unfortunately, attackers still affect the app, e.g., in the cost of restarting connections, delays until connections are restarted, or increased connection establishment messages on the network 😭. some apps (notably BGP) even interpret TCP connection reliability as an indicator of route path stability, which is why attacks on BGP have such substantial consequences 🚨.
5.4. Link Layer 🔗
link layer security operates separately on each hop of an Internet. it can be critical for protecting link resources, like bandwidth and link management protocols. protection at this layer can't suffice for network or transport layers, because it can't authenticate the endpoint source of a packet. link auth only ensures the source of the current link hop where it's examined 🥹.
5.5. Issues Discussion 💭
the issues raised in this section suggest there are challenges with all solutions to transport protection from spoofing attacks. this raises the potential need for alternate security levels. while it's already widely recognized that security needs to happen simultaneously at many protocol layers, there may also be utility in supporting a variety of strengths at a single layer. for example, IPsec already supports a variety of algorithms (MD5, SHA1, etc., for auth), but always assumes that:
- The entire body of the packet is secured.
- Security associations are established only where identity is authenticated by a known certificate authority or other pre-shared key.
- Both on-path and off-path third-party spoofing attacks must be defeated.
these assumptions are prohibitive, especially in many cases of spoofing attacks. for spoofing, the primary issue is whether packets are coming from the same party the server can reach. only the IP header is fundamentally in question, so securing the entire packet (1) is computational overkill. it's sufficient to authenticate the other party as "a party you have exchanged packets with", rather than establishing their trusted identity ("Bill" vs. "Bob") as in (2). finally, many cookie systems use clear-text (unencrypted), fixed cookie values, providing reasonable (1 in 2^{cookie-size}) protection against off-path third-party spoof attacks, but not addressing on-path attacks at all. such potential solutions are discussed in the Better Than Nothing Security (BTNS) documents [5][45][46]. note also that NULL Encryption in IPsec applies a variant of this cookie, where the SPI is the cookie, and no further encryption is applied [17] 🫶.
6. Security Considerations 🔒
okay bestie, this whole doc is about making transport protocols harder to spoof and way more resistant to spoofing attacks 💅 security shows up everywhere in here, no cap
the techniques for defeating spoofing hit different depending on what they rely on. clear-text cookies, whether explicit or implicit (like window sequence attenuation), do not protect you from on-path spoofing attacks 💀 bc valid values can be learned from earlier traffic. but true authentication algorithms are way stronger, and they protect even against on-path attacks 🔥 bc the authentication hash in a single packet acts basically like a "one-time" cookie 🎀
security is addressed at different levels of the protocol stack. spoofing is basically identity masquerading, so we think the most appropriate fixes stop it at the network layer 🧚 that's where end-to-end identity lives. some transport protocols pull endpoint identity from the network layer (TCP pseudo-headers are an example), while others set up per-connection identity using exchanged nonces (SCTP does this) ✨ it's reasonable to address security at all layers of the stack, though that's not recommended, lol
NATs and other middleboxes make all of this way more complicated 🙈 devices that modify IP and/or TCP headers in-transit basically generate traffic that looks like a spoofing attack, so they should be inhibited by antispoofing mechanisms. the details of these middlebox problems are out of scope for this doc, but they get covered in RFCs and emerging docs that talk about how these devices interact with the Internet architecture, see [21] 📚 the good news is that a lot of the most critical TCP connections, especially the ones supporting routing protocols like BGP, don't go through these middleboxes, so they're not affected by this limitation 🫶
7. Conclusions 🎀
the doc walks through the details of the recent BGP spoofing attacks that used spurious RSTs, which could be used to shut down TCP connections 😭 it also sums up and discusses a bunch of current and proposed solutions at different protocol layers. iconic 👑
8. Acknowledgments 💖
this doc was inspired by discussions in the TCPM WG <http://www.ietf.org/html.charters/tcpm-charter.html> about the recent spoofed RST attacks on BGP routers, including R. Stewart's document (whose author list has since evolved) [36][42]. the analysis of the attack issues, the alternate solutions, and the anonymous security proposed solutions came out of discussions on that list, plus chats with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang 🧚 R. Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to validate RSTs 🌸 other improvements came from various members of the IETF's TCPM WG, especially the detailed feedback from F. Gont, P. Savola, and A. Hoenes 🫶
this doc was prepared using 2-Word-v2.0.template.dot 💅
9. Informative References 📚
okay here's the whole reference list, every single entry 🦋
[1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[3] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4
Specification", RFC 4278, January 2006.
[4] Bernstein, D., "SYN cookies", 1997,
<http://cr.yp.to/syncookies.html>.
[5] Better Than Nothing Security [BTNS] WG web pages,
<http://www.postel.org/anonsec>.
[6] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O.
Wheeler, "Authentication for TCP-based Routing and Management
Protocols", Work in Progress, February 2007.
[7] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337,
May 1992.
[9] CERT alert: "Technical Cyber Security Alert TA04-111A:
Vulnerabilities in TCP", April 20, 2004,
<http://www.us-cert.gov/cas/techalerts/TA04-111A.html>.
[10] Convery, S., and M. Franz, "BGP Vulnerability Testing:
Separating Fact from FUD", 2003,
<http://www.nanog.org/mtg-0306/pdf/franz.pdf>.
[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations",
Work in Progress, May 2007.
[12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573-
1583, Mar. 1999.
[13] 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.
[14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
60, RFC 3360, August 2002.
[15] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[16] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism (GTSM)",
Work in Progress, June 2007.
[17] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[18] Gont, F., "ICMP attacks against TCP", Work in Progress, May
2007.
[19] Gont, F., "TCP's Reaction to Soft Errors", Work in Progress,
June 2007.
[20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[22] Housley, R., Post to IETF Discussion mailing list regarding his
IETF 64 Security Area presentation,
ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24,
2005, <http://www1.ietf.org/
mail-archive/ietf/Current/maillist.html>.
[23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[27] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[29] Larsen, M., and F. Gont, "Port Randomization", Work in
Progress, February 2007.
[30] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet
Denial-of-Service Activity", Proc. Usenix Security Symposium,
Aug. 2001.
[32] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991.
[33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[34] Poon, K., "Use of TCP timestamp option to defend against blind
spoofing attack", Work in Progress, October 2004.
[35] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[36] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", Work in Progress, July
2007.
[37] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer
Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume
28, number 4, Oct. 1998.
[39] Shepard, T., "Reassign Port Number option for TCP", Work in
Progress, July 2004.
[40] Shirey, R., "Internet Security Glossary, Version 2", Work in
Progress, November 2006.
[41] 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.
[42] TCPM: IETF TCPM Working Group and mailing list,
<http://www.ietf.org/html.charters/tcpm-charter.html>.
[43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
[44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995,
pp. 77-86, Mar. 1999.
[45] Touch, J., "ANONsec: Anonymous Security to Defend Against
Spoofing Attacks", Work in Progress, May 2004.
[46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability
Statement for Better Than Nothing Security (BTNS)", Work in
Progress, February 2007.
[47] Touch, J. and A. Mankin, "The TCP Simple Authentication
Option", Work in Progress, July 2007.
[48] Watson, P., "Slipping in the Window: TCP Reset attacks",
Presentation at 2004 CanSecWest,
<http://cansecwest.com/csw04archive.html>.
[49] Wood, L., Post to TCPM mailing list regarding use of ISN in
RSTs, ID=Pine.GSO.4.50.0404232249570.5889-
100000@argos.ee.surrey.ac.uk, Apr. 23, 2004,
<http://www1.ietf.org/mail-archive/web/tcpm/current/
msg00213.html>.Author's Addresses 📮
here's where to find the author, Joe Touch 🌈
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
Fax: +1 (310) 448-9300
EMail: touch@isi.edu
URI: http://www.isi.edu/touchFull Copyright Statement ⚖️
okay the legal stuff, but make it quick 💅
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 doesn't take a position on whether any IPR claims about the tech in this doc are valid or how wide they are, and it doesn't say it checked for any of them either. info on how rights work for RFCs is in BCP 78 and BCP 79.
copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of trying to get a general license for implementers or users, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
the IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that to ietf-ipr@ietf.org 🫶
Acknowledgement ✨
okay bestie, last bit 🫶 Funding for the RFC Editor function is currently provided by the Internet Society. So the people keeping these documents published are being funded by the Internet Society right now 💖🌈 ngl that's a super sweet shoutout 🎀
📦 where this page comes from
- ietf: rfc4953 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms