RFC 5961

Improving TCP's Robustness to Blind In-Window Attacks

📅 published August 2010, from ietf

RFC 5961: Improving TCP's Robustness to Blind In-Window Attacks 💖

  • Series: Internet Engineering Task Force (IETF), Request for Comments: 5961
  • Authors: A. Ramaiah (Cisco), R. Stewart (Huawei), M. Dalal (Cisco)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: August 2010

Okay bestie, this one is a whole glow-up for TCP 🦋 It's a Standards Track doc from the IETF, so people actually have to build it. Let's get into it 💅

Abstract ✨

Okay so TCP has always kind of been treated as safe from spoofed off-path packet injection, because the attacker has to guess the 4-tuple (the source and destination IP addresses plus the source and destination ports) and the 32-bit sequence number(s). Lowkey that was a solid defense, but then two things changed. Window sizes got bigger, and apps started using long-lived connections (think H-323 or Border Gateway Protocol (BGP) [RFC4271]). Now modern TCP is way more vulnerable to these attacks 🥺

Many of these long-term apps have predictable IP addresses and ports, which makes the 4-tuple way easier to guess. (The 4-tuple is the same thing as the socket pair mentioned in RFC 793 🎀) Once an attacker guesses it right, they can inject a TCP segment with the RST bit set, the SYN bit set, or data into a connection. They do this by systematically guessing a sequence number that lands in the current receive window. That can make the connection abort or corrupt data, which is not it 💀 This document lays out small changes to how TCP handles inbound segments, and those changes can lower the chances of a successful attack. Iconic behaviour 👑

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🌸

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc5961.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. No cap, read the fine print 🙈

Table of Contents 🧚

   1. Introduction ....................................................3
      1.1. Applicability Statement ....................................3
      1.2. Basic Attack Methodology ...................................4
      1.3. Attack probabilities .......................................5
   2. Terminology .....................................................7
   3. Blind Reset Attack Using the RST Bit ............................7
      3.1. Description of the Attack ..................................7
      3.2. Mitigation .................................................7
   4. Blind Reset Attack Using the SYN Bit ............................9
      4.1. Description of the Attack ..................................9
      4.2. Mitigation .................................................9
   5. Blind Data Injection Attack ....................................10
      5.1. Description of the Attack .................................10
      5.2. Mitigation ................................................11
   6. Suggested Mitigation Strengths .................................12
   7. ACK Throttling .................................................12
   8. Backward Compatibility and Other Considerations ................13
   9. Middlebox Considerations .......................................14
      9.1. Middlebox That Resend RSTs ................................14
      9.2. Middleboxes That Advance Sequence Numbers .................15
      9.3. Middleboxes That Drop the Challenge ACK ...................15
   10. Security Considerations .......................................16
   11. Contributors ..................................................17
   12. Acknowledgments ...............................................17
   13. References ....................................................17
      13.1. Normative References .....................................17
      13.2. Informative References ...................................17

1. Introduction 🌈

TCP [RFC0793] is everywhere. It's the most common reliable end-to-end transport protocol for data communication on today's Internet, and it's basically the main character 👑 But it was standardized over 20 years ago, when the Internet was a totally different place without a lot of the threats we deal with now. Off-path TCP spoofing attacks are one of those newer threats, and they're showing up on the Internet today 😭

In a TCP spoofing attack, an off-path attacker crafts TCP packets by forging the IP source and destination addresses, plus the source and destination ports (this document calls that a 4-tuple value). The targeted TCP endpoint then links that packet to an existing TCP connection. Guessing the 4-tuple isn't always easy for an attacker, ngl. But some applications (BGP [RFC4271] is one example) tend to use the same set(s) of ports on either endpoint, so guessing the 4-tuple correctly gets way easier 🥹 When an attacker manages to guess the 4-tuple, they can launch one of three types of injection attacks against a long-lived connection:

  • RST - An attacker injects a RST segment, hoping to tear the connection down. "RST segment" here means a TCP segment with the RST bit set. 🚫
  • SYN - An attacker injects a SYN, hoping to make the receiver think the peer has restarted, so it tears down the connection state. "SYN segment" here means a TCP segment with the SYN bit set. 🙃
  • DATA - An attacker tries to inject a DATA segment to corrupt the contents of the transmission. "DATA segment" here means any TCP segment that contains data. 🍓

1.1. Applicability Statement

Okay so this document talks about some known in-window attacks and the defenses against them. The mitigations suggested here SHOULD be implemented in devices that regularly need to keep up TCP connections of the kind most vulnerable to the attacks described in this document. These are usually connections that are long-lived, where the connection endpoints can be identified, and where no auxiliary anti-spoofing protection like TCP MD5 [RFC2385] can be deployed. These mitigations MAY be implemented in other cases 💖

1.2. Basic Attack Methodology 🕵️‍♀️

Let's zoom in on the RST attack so we can see how it works and how this document fixes it 🦋 For this attack, the goal is to make one of the two endpoints of the connection tear down the connection state by mistake, which basically aborts the connection. The key thing to know is that the RST needs to land in the valid receive window for the attack to work. It's also worth emphasizing that the receive window is independent of the TCP connection's current congestion window. The attacker tries to forge lots of RST segments to cover the space of possible windows, putting out a packet in each potential window. To pull this off, the attacker needs to have or guess several pieces of info:

  1. The 4-tuple value, which contains the IP address and TCP port number of both ends of the connection. For one side (usually the server), guessing the port number is a trivial exercise 😌 Whether the client side is easy to guess depends on a bunch of factors, most notably the operating system and application involved.
  2. A sequence number to use in the RST. This sequence number is the starting point for a series of guesses, trying to present an RST segment to a connection endpoint that it would accept. Any random value can be used to guess the starting sequence number 🎲
  3. The window size the two endpoints are using. This value does NOT have to be the exact window size, because a smaller value used in its place just means the attacker has to generate more segments before succeeding in their mischief. Most modern operating systems have a default window size that usually applies to most connections. Some applications, though, may change the window size to better suit their needs. So often the attacker can come up with a very close approximation of the actual window size on the connection, with a fair degree of certainty, if they know which application is under attack 🎯

After gathering that info, the attacker starts sending spoofed TCP segments with the RST bit set and a guessed TCP sequence number. Every time a new RST segment is sent, the sequence number guess goes up by the window size. The feasibility of this methodology (without mitigations) was first shown in [SITW]. That's because [RFC0793] says any RST within the current window is acceptable. Also, [RFC4953] talks about the probability of a successful attack with varying window sizes and bandwidth 📊

A small enhancement to TCP's segment processing rules can make this attack way harder to pull off ✨ If the receiver checks the incoming RST segment and confirms that its sequence number exactly matches the sequence number that's next expected, then the attack becomes much harder than what [SITW] outlined. The attacker would have to generate 1/2 the entire sequence space, on average, which is giving major "nope" energy 🙅‍♀️ This document goes into the exact details of what needs to change in TCP's segment processing rules to mitigate all three types of attacks (RST, SYN, and DATA). Stay tuned bestie, part 2 is coming 🫶

1.3. Attack probabilities ✨

okay so every application gets a say in how likely a spoofing attack is to work 👀 Here are the big factors:

  • Window Size: normally the app sets this, but it often defaults to 32,768 or 65,535 depending on the OS (see Figure 6 of [Medina05]) 💅
  • Server Port number: this one's usually fixed so clients know where to connect, which means it normally gives no extra protection 🙈
  • Client Port number: this might be a random ephemeral value, and if it is, spoofing gets way harder 🦋 But some clients pick a fixed port or have a super guessable one (because of their OS's ephemeral range or other app stuff), and then spoofing gets less difficult 😭

For the rest of this chat, we're going to assume the attacker already knows the 4-tuple values 🧚 That lets us focus on window size vs. how many TCP packets an attacker has to send. Real talk though, this assumption will rarely be true on the real Internet, since at least the client port number adds some randomness (depending on the OS) 🎀

Back in the day, people thought the whole sequence space (aka 2^32) was available, which made a spoofed packet (RST, SYN, or DATA) seem super unlikely to work 🤡 [SITW] proved that wasn't right. Instead of (1/2 * 2^32) packets (assuming a random distribution), you need (1/2 * (2^32/window)) packets. In other words, the mean number of tries needed to inject a RST segment is (2^31/window) instead of the 2^31 people assumed before 🔥

Plugging in numbers: for a window size of 32,768, an average of 65,536 packets would need to be sent to "spoof" a TCP segment that a TCP receiver accepts. A window size of 65,535 drops that even further, to 32,768 packets. At today's access bandwidths, an attack that size is totally feasible 😳

As home and office bandwidth keeps going up, default window sizes will probably keep going up too, so they can take better advantage of the new bandwidth ⭐ Also, this attack can be run in a distributed fashion to potentially get access to even more bandwidth 🌈

So yeah, this weakness lowers the bar quite a lot for likely attacks. There's one more thing that matters, though: how long the TCP connection lasts ⏳ A connection that only lasts a few brief packets, which is often the case for web traffic, wouldn't be affected much, since the attacker might not get enough time to send enough traffic. But some applications, like BGP [RFC4271], are judged to be the most affected by this vulnerability 🍓 BGP relies on a persistent TCP session between BGP peers, and resetting that connection can cause term-medium unavailability because routing tables have to be rebuilt and routes flap. See [NISCC] for the full details 💀

For apps that can use the TCP MD5 option [RFC2385], like BGP, that option makes the attacks in this specification effectively impossible 🔐 Some applications or implementations might find it expensive to implement, though.

There are other protections against the threats this document covers. For more on the attacks and existing techniques, check out [RFC4953] 📚 And as suggested in [TSVWG-PORT] and [RFC1948], port randomization and initial sequence number (ISN) randomization would help make TCP connections more robust against off-path attacks 💜

2. Terminology ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119]. TCP terminology should be read as described in [RFC0793] 🤓

3. Blind Reset Attack Using the RST Bit ✨

3.1. Description of the Attack

As we covered in the intro, an attacker can generate a RST segment that a TCP receiver accepts just by guessing in-window sequence numbers 😈 Specifically, [RFC0793], page 37, says the following:

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN.

3.2. Mitigation

[RFC0793] currently requires that a segment with the RST bit, received in a synchronized state, be handled like this:

  1. If the RST bit is set and the sequence number is outside the current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+ RCV.WND), silently drop the segment.
  2. If the RST bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then reset the connection.

Instead, implementations SHOULD follow these steps in place of the ones in [RFC0793] (listed above) 💖

  1. If the RST bit is set and the sequence number is outside the current receive window, silently drop the segment.
  2. If the RST bit is set and the sequence number exactly matches the next expected sequence number (RCV.NXT), then TCP MUST reset the connection.
  3. If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

After sending the challenge ACK, TCP MUST drop the unacceptable segment and stop processing the incoming packet any further. Further segments destined for this connection will be processed as normal ✨

So the modified RST segment processing goes like this:

In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number exactly matches the next expected sequence number. If the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. In all other cases, where the SEQ-field does not match and is outside the window, the receiver MUST silently discard the segment.

In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. In all other cases the receiver MUST silently discard the segment 🫶

With that small change to the TCP state machine, it becomes way harder for an attacker to make an acceptable reset segment 🛡️

Now, if the remote peer did send a RST, but it doesn't meet the criteria above (the RST sequence number was within the window but NOT the exact expected one), the challenge ACK comes back and the peer no longer has the transmission control block (TCB) for this connection. So, per [RFC0793], the remote peer sends back a second RST 🔁 The sequence number of that second RST comes from the acknowledgment number of the incoming ACK. If this second RST reaches the sender, it aborts the connection, because the sequence number is now an exact match 🎯

A valid RST that shows up out of order will still get a challenge ACK in response. If that RST is a genuine one, the other end sends back a RST with an exact sequence number match, and the connection gets dropped 👑

Heads up: the mitigation above may cause a non-amplification ACK exchange. This concern is discussed in Section 10 ⚠️

4. Blind Reset Attack Using the SYN Bit ✨

4.1. Description of the Attack

Analyzing the RST-bit reset attack shows another possible route for a blind attacker doing similar sequence number guessing 👀 Instead of the RST bit, an attacker can use the SYN bit, with the exact same semantics, to tear down a connection 💀

4.2. Mitigation

[RFC0793] currently requires that a segment with the SYN bit set, received in the synchronized state, be handled as follows:

  1. If the SYN bit is set and the sequence number is outside the expected window, send an ACK back to the sender.
  2. If the SYN bit is set and the sequence number is acceptable, i.e., (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then send a RST segment to the sender.

Instead, handling of the SYN in the synchronized state SHOULD be done as follows 🌸

  1. If the SYN bit is set, regardless of the sequence number, TCP MUST send an ACK (also called a challenge ACK) to the remote peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

After sending the acknowledgment, TCP MUST drop the unacceptable segment and stop further processing.

By sending an ACK, the remote peer gets challenged to confirm that the previous connection was lost and that it really wants to start a new one 🧚 A legit peer that restarted won't have a TCB in the synchronized state. So when the ACK arrives, the peer should send back a RST segment with a sequence number derived from the ACK field that caused the RST 🔄

That RST confirms the remote peer really closed the previous connection. Once a valid RST is received, the local TCP endpoint MUST terminate its connection. After that, the local TCP endpoint should rely on SYN retransmission from the remote end to re-establish the connection 🦋

Meanwhile, a spoofed SYN will have generated an extra ACK that the peer throws away as a duplicate ACK, so it won't affect the established connection 🙅‍♀️

Now, this mitigation does leave one corner case unhandled 😬 It stops a connection from being reset when it should be (that is, a non-spoofed SYN where a peer really did restart). This happens when the restarting host picks the exact same IP address and port number it was using before its restart. On top of that, the restarted host also has to pick an initial sequence number of exactly (RCV.NXT - 1) of the remote peer, which is still in the established state. That would make the receiver send a "challenge" ACK like described above. But since the ACK would be inside the outgoing connection's window, the inbound ACK would be acceptable, and the SYN sender won't do anything with the response ACK. This keeps going as the SYN sender keeps timing out and retransmitting the SYN until the connection attempt fails 💔

This corner case comes from the [RFC0793] specification itself and isn't caused by these new requirements 🙃

Heads up again: the mitigation above may cause a non-amplification ACK exchange. This concern is discussed in Section 10 ⚠️

5. Blind Data Injection Attack ✨

5.1. Description of the Attack ✨

okay bestie, there's a THIRD attack, and both the RST and SYN attacks are basically its hype men 🫶😭 You can also shove data into a TCP connection just by guessing a sequence number that sits inside the victim's current receive window 🎀

Here's the vibe check on ACK values. Any data segment's ACK value counts as valid as long as it doesn't acknowledge data that's ahead of the next segment to send 💅 Put more precisely, an ACK value is acceptable if ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). That (2^31 - 1) bit is there because TCP sequence and acknowledgment numbers are compared using modulo 32-bit arithmetic, so the numbers can wrap around 🌈 Because of that, the attacker has to guess two ACK values for every sequence number they guess. The chance of a successful injection is 1 in ( 1/2 (2^32 / RCV.WND) * 2), which means the mean number of tries is 1/2 (2*2^32/RWND) = 2^32/RCV.WND 🦋

Once an attacker successfully injects data, that data just sits in the receiver's re-assembly queue until the peer sends enough data to bridge the gap between RCV.NXT and the injected data. Then one of two things happens:

  1. A packet war kicks off, with the receiver saying it has received data up until RCV.NXT (which includes the attacker's data) and the sender sending an ACK with an acknowledgment number less than RCV.NXT. Chaos, honestly 💀
  2. The sender sends enough data to move RCV.NXT even further along past the injected data. Iconic, peace restored ✨

Depending on the TCP implementation and the traffic at that moment, data corruption may happen. In case (a), the connection will eventually get reset by one of the sides, unless the sender produces more data that turns the ACK war into case (b). The reset will usually happen via User Time Out (UTO) (see section 4.2.3.5 of [RFC1122]) ⏳

Also, the protections in this section neither cause an ACK war nor stop one from happening if data really does get injected into a connection. The ACK war is a product of the attack itself and can't be prevented, other than by preventing the data from being injected in the first place 🙈

5.2. Mitigation 🛡️

All TCP stacks MAY implement the following mitigation. TCP stacks that implement this mitigation MUST add an additional input check to any incoming segment. The ACK value is only considered acceptable if it falls in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). Every incoming segment whose ACK value doesn't meet that condition MUST be discarded, and an ACK gets sent back 🎀

Now, be aware that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The word "ignored" there implies that processing of the incoming data segment continues, which means the ACK value gets treated as acceptable. This mitigation makes the ACK check way stricter, since any ACK below SND.UNA won't be accepted anymore. Only ACKs in the range ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through 🔥

A new state variable, MAX.SND.WND, is defined as the largest window that the local sender has ever received from its peer. This window may be scaled to a value larger than 65,535 bytes ([RFC1323]). This small check reduces the vulnerability to an attacker who guesses a valid sequence number, because they now also have to guess a proper ACK value inside a scoped range. This mitigation reduces, but does not eliminate, the ability to generate false segments. It does, however, reduce the probability that invalid data gets injected 📉

Implementations can also choose to hard code the MAX.SND.WND value to the maximum permissible window size, i.e., 65535 in the absence of window scaling. With the window scaling option present, the value becomes (MAX.SND.WND << Snd.Wind.Scale) 💜

This mitigation also helps improve robustness against spoofed FIN segments (FIN attacks). Among other things, the attacker now also needs the acknowledgment number to fall in the range mentioned above in order to successfully spoof a FIN segment and close the connection. So yeah, this mitigation greatly improves robustness against spoofed FIN segments 👑

Note that the above mitigation may cause a non-amplification ACK exchange. This concern is discussed in Section 10 🧚

6. Suggested Mitigation Strengths

As described in the sections above, the recommendation levels for RST, SYN, and DATA are tagged as SHOULD, SHOULD, and MAY, respectively. The reason DATA mitigation is tagged as MAY, even though it increased TCP robustness in general, is that DATA injection is perceived to be more difficult (twice as unlikely) compared to its RST and SYN counterparts 🍓 Still, all the suggested mitigations improve TCP's robustness in general, so choosing to implement some or all of the mitigations recommended in this document is purely left to the implementer 🌸

7. ACK Throttling 🚦

To keep multiple RSTs/SYNs from triggering multiple challenge ACKs, an ACK throttling mechanism is suggested, like so:

  1. The system administrator can configure the number of challenge ACKs that can be sent out in a given interval. For example, in any 5 second window, no more than 10 challenge ACKs should be sent.
  2. The values for both the time and the number of ACKs SHOULD be tunable by the system administrator, so they can match different perceived levels of threat and/or system resources 🎚️

It should be noted that these numbers are empirical in nature and were obtained from the RST throttling mechanisms that exist in some implementations. Also, no timer is needed for this mechanism. Instead, a timestamp and a counter can be used ⏱️

An implementation SHOULD include an ACK throttling mechanism to be conservative. We haven't come across a case where the lack of ACK throttling can be exploited, but as a fail-safe, we recommend using it. An implementation may treat an excessive number of invocations of the throttling mechanism as a sign that network conditions are unusual or hostile 🚨

An administrator who is more concerned about protecting bandwidth and CPU utilization may set smaller ACK throttling values. An administrator who cares more about faster cleanup of stale connections (i.e., is concerned about excess TCP state) may decide to set a higher value, which allows more RSTs to be processed in any given time period 🧹

The time limit SHOULD be tunable so it can time out brute force attacks faster than a potential legitimate flood of RSTs ⏰

8. Backward Compatibility and Other Considerations 🤝

All of the new required mitigation techniques in this document are totally compatible with existing ([RFC0793]) compliant TCP implementations, since this document introduces no new assumptions or conditions 🫶

There's a corner scenario in the mitigations above that needs more than one round-trip time to successfully abort the connection, shown in the figure below. It's similar to the case where the original RST gets lost in the network 🌀

          TCP A                                                 TCP B
   1.a. ESTAB        <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <--  ESTAB
     b. (delayed)    ... <SEQ=400><ACK=101><CTL=ACK><DATA> <--  ESTAB
     c. (in flight)  ... <SEQ=500><ACK=101><CTL=RST>       <--  CLOSED
   2.   ESTAB        --> <SEQ=101><ACK=400><CTL=ACK>       -->  CLOSED
       (ACK for 1.a)
                     ... <SEQ=400><ACK=0><CTL=RST>         <--  CLOSED
   3.   CHALLENGE    --> <SEQ=101><ACK=400><CTL=ACK>       -->  CLOSED
        (for 1.c)
                     ... <SEQ=400><ACK=0><CTL=RST>         <--  RESPONSE
   4.a. ESTAB        <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
     b. ESTAB        --> <SEQ=101><ACK=500><CTL=ACK>
     c. (in flight)  ... <SEQ=500><ACK=0><CTL=RST>         <--  CLOSED
   5.   RESPONSE arrives at A, but dropped since its outside of window.
   6.   ESTAB        <-- <SEQ=500><ACK=0><CTL=RST>         4.c reaches A
   7.   CLOSED                                                   CLOSED

For the mitigation to be maximally effective against the vulnerabilities discussed in this document, both ends of the TCP connection need the fix. Having the mitigations at one end might keep that end from being exposed to the attack, but the connection is still vulnerable at the other end 🥺

9. Middlebox Considerations 🕵️

9.1. Middlebox That Resend RSTs

Picture a middlebox M-B tracking a connection between two TCP end hosts, E-A and E-C. If E-C sends a RST with a sequence number that's within the window but not an exact match to reset the connection, and M-B doesn't have the fix recommended in this document, M-B may clear the connection and forward the RST to E-A, saving an incorrect sequence number. If E-A doesn't have the fix, the connection gets cleared as required. But if E-A does have the required fix, it will send a challenge ACK to E-C. M-B, being a middlebox, may intercept this ACK and resend the RST on behalf of E-C with the old sequence number. This RST won't be acceptable either, and it may trigger another challenge ACK 😤

The situation above may result in a RST/ACK war. However, we believe that if such a case exists on the Internet, the middlebox is generating packets that a conformant TCP endpoint would never generate. [RFC0793] dictates that the sequence number of a RST has to be derived from the acknowledgment number of the incoming ACK segment. It's outside the scope of this document to suggest mitigations for ill-behaved middleboxes 🙅‍♀️

Now consider a similar scenario where the RST from M-B to E-A gets lost. E-A will keep holding the connection and might send an ACK an arbitrary time later, after the connection state was destroyed at M-B. In this case, M-B would have to cache the RST for an arbitrary amount of time until it's confirmed that the connection has been cleared at E-A 🧊

9.2. Middleboxes That Advance Sequence Numbers

Some middleboxes may compute RST sequence numbers at the higher end of the acceptable window. The scenario is the same as the earlier case, but this time, instead of sending the cached RST, the middlebox (M-B) sends a RST that computes its sequence number as the sum of the acknowledgment field in the ACK and the window advertised by the ACK that E-A sent to challenge the RST, as depicted below. The difference in the sequence numbers between step 1 and step 2 below is due to data lost in the network 🌪️

   TCP A                                                   Middlebox

1. ESTABLISHED  <-- <SEQ=500><ACK=100><CTL=RST>          <--  CLOSED

2. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED

3. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

4. ESTABLISHED  --> <SEQ=100><ACK=300><WND=500><CTL=ACK> -->  CLOSED

5. ESTABLISHED  <-- <SEQ=800><ACK=100><CTL=RST>          <--  CLOSED

Although the authors aren't aware of an implementation that does the above, it could be mitigated by implementing the ACK throttling mechanism described earlier 🦋

9.3. Middleboxes That Drop the Challenge ACK 🛡️

Okay, bestie, one more middlebox drama 💀. Some middleboxes (Firewalls/NATs) that don't have the fix recommended in this document may drop the challenge ACK 🙈. This can happen because the original RST segment that was in window had already cleared the flow state for the TCP connection in the middlebox. So the end hosts that have implemented the RST mitigation described here end up with the TCP connection left open 😭. It's a corner case, and it can go away if the middlebox is conformant with the changes proposed in this document ✨.

10. Security Considerations 🔐

Real talk, these changes to the TCP state machine do NOT protect an implementation from on-path attacks 🚫. It also needs to be emphasized that while the mitigations in this document make it harder for off-path attackers to inject segments, it does NOT make it impossible 💀. The only way to fully protect a TCP connection from both on- and off-path attacks is by using either IPsec Authentication Header (AH) [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303] 🔥.

Implementers also should be aware that the attacks detailed in this specification are not the only attacks available to an off-path attacker, and that the counter measures described herein are not a comprehensive defense against such attacks 👀.

Administrators, in particular, should be aware that forged ICMP messages give off-path attackers the chance to disrupt connections or degrade service 😬. Such attacks may be subject to even less scrutiny than the TCP attacks addressed here, especially in stacks not tuned for hostile environments 🙃. It is important to note that some ICMP messages, validated or not, are key to the proper function of TCP 🧚. The ICMP messages used to properly set the path maximum transmission unit are the most obvious example 🎀. There are a variety of ways to choose which, if any, ICMP messages to trust in the presence of off-path attackers, and choosing between them depends on the assumptions and guarantees that developers and administrators can make about their network 💅. This specification does not attempt to do more than note this and related issues 🌸. Unless implementers address spoofed ICMP messages [RFC5927], the mitigations specified in this document may not provide the desired protection level ⚠️.

In any case, this RFC details only part of a complete strategy to prevent off-path attackers from disrupting services that use TCP 🦋. Administrators and implementers should consider the other attack vectors and determine appropriate mitigations for securing their systems ✨.

Another notable consideration is that a reflector attack is possible with the required RST/SYN mitigation techniques 😭. In this attack, an off-path attacker can cause a victim to send an ACK segment for each spoofed RST/SYN segment that lies within the current receive window of the victim 🪞. It should be noted, however, that this does not cause any amplification, since the attacker must generate a segment for each one that the victim will generate 🫶.

11. Contributors 🌈

Mitesh Dalal and Amol Khare of Cisco Systems came up with the solution for the RST/SYN attacks 👑. Anantha Ramaiah and Randall Stewart of Cisco Systems discovered the data injection vulnerability, and together with Patrick Mahan and Peter Lei of Cisco Systems, they found solutions for the same 🔥. Paul Goyette, Mark Baushke, Frank Kastenholz, Art Stine, and David Wang of Juniper Networks provided the insight that, apart from RSTs, SYNs could also result in formidable attacks 💜. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of Wind River Systems, and Xiaodan Tang of QNX Software, along with the folks above, helped in ratifying and testing the interoperability of the suggested solutions 🎀.

12. Acknowledgments 🫶

Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra Murphy, Brian Carpenter, Cullen Jennings, and other members of the tcpm WG for suggestions and comments 💖. ACK throttling was introduced to this document by combining the suggestions from the tcpm working group 🍓.

13. References 📚

13.1. Normative References

[RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2. Informative References

[Medina05]    Medina, A., Allman, M., and S. Floyd, "Measuring the
              Evolution of Transport Protocols in the Internet", ACM
              Computer Communication Review, 35(2), April 2005,
              <http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps>.

[NISCC]       NISCC, "NISCC Vulnerability Advisory 236929 -
              Vulnerability Issues in TCP".

[RFC1122]     Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1323]     Jacobson, V., Braden, B., and D. Borman, "TCP
              Extensions for High Performance", RFC 1323, May 1992.

[RFC1948]     Bellovin, S., "Defending Against Sequence Number
              Attacks", RFC 1948, May 1996.

[RFC2385]     Heffernan, A., "Protection of BGP Sessions via the TCP
              MD5 Signature Option", RFC 2385, August 1998.

[RFC4271]     Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

[RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

[RFC4953]     Touch, J., "Defending TCP Against Spoofing Attacks",
              RFC 4953, July 2007.

[RFC5927]     Gont, F., "ICMP Attacks against TCP", RFC 5927,
              July 2010.

[SITW]        Watson, P., "Slipping in the Window: TCP Reset
              attacks", Presentation at 2004 CanSecWest,
              <http://cansecwest.com/csw04archive.html>.

[TSVWG-PORT]  Larsen, M. and F. Gont, "Transport Protocol Port
              Randomization Recommendations", Work in Progress,
              August 2010.

Authors' Addresses 🎀

Anantha Ramaiah
Cisco Systems
170 Tasman Drive
San Jose, CA  95134
USA

Phone: +1 (408) 525-6486
EMail: ananth@cisco.com


Randall R. Stewart
Huawei
148 Crystal Cove Ct
Chapin, SC  29036
USA

Phone: +1 (803) 345-0369
EMail: rstewart@huawei.com


Mitesh Dalal
Cisco Systems
170 Tasman Drive
San Jose, CA  95134
USA

Phone: +1 (408) 853-5257
EMail: mdalal@cisco.com
📦 where this page comes from