draft-ietf-tcpm-tcpsecure-13.txt   rfc5961.txt 
TCP Maintenance and Minor A. Ramaiah Internet Engineering Task Force (IETF) A. Ramaiah
Extensions Working Group Cisco Systems Request for Comments: 5961 Cisco
Internet-Draft R. Stewart Category: Standards Track R. Stewart
Intended status: Standards Track Huawei ISSN: 2070-1721 Huawei
Expires: November 4, 2010 M. Dalal M. Dalal
Cisco Systems Cisco
May 3, 2010 August 2010
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-13.txt
Abstract Abstract
TCP has historically been considered protected against spoofed off- TCP has historically been considered to be protected against spoofed
path packet injection attacks by relying on the fact that it is off-path packet injection attacks by relying on the fact that it is
difficult to guess the 4-tuple (the source and destination IP difficult to guess the 4-tuple (the source and destination IP
addresses and the source and destination ports) in combination with addresses and the source and destination ports) in combination with
the 32 bit sequence number(s). A combination of increasing window the 32-bit sequence number(s). A combination of increasing window
sizes and applications using longer term connections (e.g. H-323 or sizes and applications using longer-term connections (e.g., H-323 or
Border Gateway Protocol [RFC4271]) have left modern TCP Border Gateway Protocol (BGP) [RFC4271]) have left modern TCP
implementations more vulnerable to these types of spoofed packet implementations more vulnerable to these types of spoofed packet
injection attacks. injection attacks.
Many of these long term TCP applications tend to have predictable IP Many of these long-term TCP applications tend to have predictable IP
addresses and ports which makes it far easier for the 4-tuple addresses and ports that makes it far easier for the 4-tuple (4-tuple
(4-tuple is the same as the socket pair mentioned in [RFC0793]) to be is the same as the socket pair mentioned in RFC 793) to be guessed.
guessed. Having guessed the 4-tuple correctly, an attacker can Having guessed the 4-tuple correctly, an attacker can inject a TCP
inject a TCP segment with the RST bit set, the SYN bit set or data segment with the RST bit set, the SYN bit set or data into a TCP
into a TCP connection by systematically guessing the sequence number connection by systematically guessing the sequence number of the
of the spoofed segment to be in the current receive window. This can spoofed segment to be in the current receive window. This can cause
cause the connection to abort or cause data corruption. This the connection to abort or cause data corruption. This document
document specifies small modifications to the way TCP handles inbound specifies small modifications to the way TCP handles inbound segments
segments that can reduce the chances of a successful attack. that can reduce the chances of a successful attack.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 4, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5961.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement ....................................3
1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 5 1.2. Basic Attack Methodology ...................................4
1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 1.3. Attack probabilities .......................................5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology .....................................................7
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind Reset Attack Using the RST Bit ............................7
3.1. Description of the attack . . . . . . . . . . . . . . . . 9 3.1. Description of the Attack ..................................7
3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mitigation .................................................7
4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 4. Blind Reset Attack Using the SYN Bit ............................9
4.1. Description of the attack . . . . . . . . . . . . . . . . 11 4.1. Description of the Attack ..................................9
4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mitigation .................................................9
5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5. Blind Data Injection Attack ....................................10
5.1. Description of the attack . . . . . . . . . . . . . . . . 13 5.1. Description of the Attack .................................10
5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Mitigation ................................................11
6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15 6. Suggested Mitigation Strengths .................................12
7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16 7. ACK Throttling .................................................12
8. Backward Compatibility and Other considerations . . . . . . . 17 8. Backward Compatibility and Other Considerations ................13
9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18 9. Middlebox Considerations .......................................14
9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18 9.1. Middlebox That Resend RSTs ................................14
9.2. Middleboxes that advance sequence numbers . . . . . . . . 18 9.2. Middleboxes That Advance Sequence Numbers .................15
9.3. Middleboxes that drop the challenge ACK . . . . . . . . . 19 9.3. Middleboxes That Drop the Challenge ACK ...................15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations .......................................16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. Contributors ..................................................17
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments ...............................................17
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. References ....................................................17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References .....................................17
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 13.2. Informative References ...................................17
14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
TCP [RFC0793] is widely deployed and the most common reliable end to TCP [RFC0793] is widely deployed and the most common reliable end-to-
end transport protocol used for data communication in today's end transport protocol used for data communication in today's
Internet. Yet when it was standardized over 20 years ago, the Internet. Yet, when it was standardized over 20 years ago, the
Internet, was a different place, lacking many of the threats that are Internet was a different place, lacking many of the threats that are
now common. The off-path TCP spoofing attacks, which are seen in the now common. The off-path TCP spoofing attacks, which are seen in the
Internet today, fall into this category. Internet today, fall into this category.
In a TCP spoofing attack, an off-path attacker crafts TCP packets by In a TCP spoofing attack, an off-path attacker crafts TCP packets by
forging the IP source and destination addresses as well as the source forging the IP source and destination addresses as well as the source
and destination ports (referred to as a 4-tuple value in this and destination ports (referred to as a 4-tuple value in this
document). The targeted TCP endpoint will then associate such a document). The targeted TCP endpoint will then associate such a
packet with an existing TCP connection. It needs to be noted that, packet with an existing TCP connection. It needs to be noted that,
guessing this 4-tuple value is not always easy for an attacker. But guessing this 4-tuple value is not always easy for an attacker. But
there are some applications (e.g. BGP [RFC4271]) that have a there are some applications (e.g., BGP [RFC4271]) that have a
tendency to use the same set(s) of ports on either endpoint making tendency to use the same set(s) of ports on either endpoint, making
the odds of correctly guessing the 4-tuple value much easier. When the odds of correctly guessing the 4-tuple value much easier. When
an attacker is successful in guessing the 4-tuple value, one of three an attacker is successful in guessing the 4-tuple value, one of three
types of injection attacks may be waged against a long-lived types of injection attacks may be waged against a long-lived
connection. connection.
RST - Where an attacker injects a RST segment hoping to cause the RST - Where an attacker injects a RST segment hoping to cause the
connection to be torn down. RST segment here refers to a TCP connection to be torn down. "RST segment" here refers to a TCP
segment with RST bit set. segment with the RST bit set.
SYN - Where an attacker injects a SYN hoping to cause the receiver SYN - Where an attacker injects a SYN hoping to cause the receiver
to believe the peer has restarted and so tear down the connection to believe the peer has restarted and therefore tear down the
state. SYN segment here refers to a TCP segment with SYN bit set. connection state. "SYN segment" here refers to a TCP segment with
SYN bit set.
DATA - Where an attacker tries to inject a DATA segment to corrupt DATA - Where an attacker tries to inject a DATA segment to corrupt
the contents of the transmission. DATA segment here refers to any the contents of the transmission. "DATA segment" here refers to
TCP segment containing data. any TCP segment containing data.
1.1. Applicability Statement 1.1. Applicability Statement
This document talks about some known in-window attacks and suitable This document talks about some known in-window attacks and suitable
defenses against these. The mitigations suggested in this draft defenses against these. The mitigations suggested in this document
SHOULD be implemented in devices that regularly need to maintain TCP SHOULD be implemented in devices that regularly need to maintain TCP
connections of the kind most vulnerable to the attacks described in connections of the kind most vulnerable to the attacks described in
this document. Examples of such TCP connections are the ones that this document. Examples of such TCP connections are the ones that
tend to be long-lived and where the connection end points can be tend to be long-lived and where the connection endpoints can be
determined, in cases where no auxiliary anti-spoofing protection determined, in cases where no auxiliary anti-spoofing protection
mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations
MAY be implemented in other cases. MAY be implemented in other cases.
1.2. Basic Attack Methodology 1.2. Basic Attack Methodology
Focusing upon the RST attack, we examine this attack in more detail Focusing upon the RST attack, we examine this attack in more detail
to get an overview as to how it works and how this document addresses to get an overview as to how it works and how this document addresses
the issue. For this attack the goal is for the attacker to cause one the issue. For this attack, the goal is for the attacker to cause
of the two endpoints of the connection to incorrectly tear down the one of the two endpoints of the connection to incorrectly tear down
connection state, effectively aborting the connection. One of the the connection state, effectively aborting the connection. One of
important things to note is that for the attack to succeed the RST the important things to note is that for the attack to succeed the
needs to be in the valid receive window. It also needs to be RST needs to be in the valid receive window. It also needs to be
emphasized that the receive window is independent of the current emphasized that the receive window is independent of the current
congestion window of the TCP connection. The attacker would try to congestion window of the TCP connection. The attacker would try to
forge many RST segments to try to cover the space of possible windows forge many RST segments to try to cover the space of possible windows
by putting out a packet in each potential window. To do this the by putting out a packet in each potential window. To do this, the
attacker needs to have or guess several pieces of information namely: attacker needs to have or guess several pieces of information namely:
1) The 4-tuple value containing the IP address and TCP port number of 1) The 4-tuple value containing the IP address and TCP port number of
both ends of the connection. For one side (usually the server) both ends of the connection. For one side (usually the server),
guessing the port number is a trivial exercise. The client side guessing the port number is a trivial exercise. The client side
may or may not be easy for an attacker to guess depending on a may or may not be easy for an attacker to guess depending on a
number of factors, most notably the operating system and number of factors, most notably the operating system and
application involved. application involved.
2) A sequence number that will be used in the RST. This sequence 2) A sequence number that will be used in the RST. This sequence
number will be a starting point for a series of guesses to attempt number will be a starting point for a series of guesses to attempt
to present a RST segment to a connection endpoint that would be to present a RST segment to a connection endpoint that would be
acceptable to it. Any random value may be used to guess the acceptable to it. Any random value may be used to guess the
starting sequence number. starting sequence number.
3) The window size that the two endpoints are using. This value does 3) The window size that the two endpoints are using. This value does
NOT have to be the exact window size since a smaller value used in NOT have to be the exact window size since a smaller value used in
lieu of the correct one will just cause the attacker to generate lieu of the correct one will just cause the attacker to generate
more segments before succeeding in his mischief. Most modern more segments before succeeding in his mischief. Most modern
operating systems have a default window size which usually is operating systems have a default window size that usually is
applied to most connections. Some applications however may change applied to most connections. Some applications however may change
the window size to better suit the needs of the application. So the window size to better suit the needs of the application. So
often times the attacker, with a fair degree of certainty (knowing often times the attacker, with a fair degree of certainty (knowing
the application that is under attack), can come up with a very the application that is under attack), can come up with a very
close approximation as to the actual window size in use on the close approximation as to the actual window size in use on the
connection. connection.
After assembling the above set of information the attacker begins After assembling the above set of information, the attacker begins
sending spoofed TCP segments with the RST bit set and a guessed TCP sending spoofed TCP segments with the RST bit set and a guessed TCP
sequence number. Each time a new RST segment is sent, the sequence sequence number. Each time a new RST segment is sent, the sequence
number guess is incremented by the window size. The feasibility of number guess is incremented by the window size. The feasibility of
this methodology (without mitigations) was first shown in [SITW]. this methodology (without mitigations) was first shown in [SITW].
This is because [RFC0793] specifies that any RST within the current This is because [RFC0793] specifies that any RST within the current
window is acceptable. Also [RFC4953] talks about the probability of window is acceptable. Also, [RFC4953] talks about the probability of
a successful attack with varying window sizes and bandwidth. a successful attack with varying window sizes and bandwidth.
A slight enhancement to TCP's segment processing rules can be made A slight enhancement to TCP's segment processing rules can be made,
which makes such an attack much more difficult to accomplish. If the which makes such an attack much more difficult to accomplish. If the
receiver examines the incoming RST segment and validates that the receiver examines the incoming RST segment and validates that the
sequence number exactly matches the sequence number that is next sequence number exactly matches the sequence number that is next
expected, then such an attack becomes much more difficult than expected, then such an attack becomes much more difficult than
outlined in [SITW] (i.e. the attacker would have to generate 1/2 the outlined in [SITW] (i.e., the attacker would have to generate 1/2 the
entire sequence space, on average). This document will discuss the entire sequence space, on average). This document will discuss the
exact details of what needs to be changed within TCP's segment exact details of what needs to be changed within TCP's segment
processing rules to mitigate all three types of attacks (RST, SYN and processing rules to mitigate all three types of attacks (RST, SYN,
DATA). and DATA).
1.3. Attack probabilities 1.3. Attack probabilities
Every application has control of a number of factors that drastically Every application has control of a number of factors that drastically
affect the probability of a successful spoofing attack. These affect the probability of a successful spoofing attack. These
factors include such things as: factors include such things as:
Window Size - Normally settable by the application but often times Window Size - Normally settable by the application but often times
defaulting to 32,768 or 65,535 depending upon the operating system defaulting to 32,768 or 65,535 depending upon the operating system
([Medina05]). (see Figure 6 of [Medina05]).
Server Port number - This value is normally a fixed value so that a Server Port number - This value is normally a fixed value so that a
client will know where to connect to the peer at. Thus this value client will know where to connect to the peer. Thus, this value
normally provides no additional protection. normally provides no additional protection.
Client Port number - This value may be a random ephemeral value, if Client Port number - This value may be a random ephemeral value, if
so, this makes a spoofing attack more difficult. There are some so, this makes a spoofing attack more difficult. There are some
clients, however, that for whatever reason either pick a fixed clients, however, that for whatever reason either pick a fixed
client port or have a very guessable one (due to the range of client port or have a very guessable one (due to the range of
ephemeral ports available with their operating system or other ephemeral ports available with their operating system or other
application considerations) for such applications a spoofing application considerations) for such applications a spoofing
attack becomes less difficult. attack becomes less difficult.
For the purposes of the rest of this discussion we will assume that For the purposes of the rest of this discussion we will assume that
the attacker knows the 4-tuple values. This assumption will help us the attacker knows the 4-tuple values. This assumption will help us
focus on the effects of the window size versus the number of TCP focus on the effects of the window size versus the number of TCP
packets an attacker must generate. This assumption will rarely be packets an attacker must generate. This assumption will rarely be
true in the real Internet since at least the client port number will true in the real Internet since at least the client port number will
provide us with some amount of randomness (depending on the operating provide us with some amount of randomness (depending on the operating
system). system).
To successfully inject a spoofed packet (RST, SYN or DATA), in the To successfully inject a spoofed packet (RST, SYN, or DATA), in the
past, the entire sequence space (i.e. 2^32) was often considered past, the entire sequence space (i.e., 2^32) was often considered
available to make such an attack unlikely. [SITW] demonstrated that available to make such an attack unlikely. [SITW] demonstrated that
this assumption was incorrect and that instead of (1/2 * 2^32) this assumption was incorrect and that instead of (1/2 * 2^32)
packets (assuming a random distribution), (1/2 * (2^32/window)) packets (assuming a random distribution), (1/2 * (2^32/window))
packets is required. In other words, the mean number of tries needed packets are required. In other words, the mean number of tries
to inject a RST segment is (2^31/window) rather than the 2^31 assumed needed to inject a RST segment is (2^31/window) rather than the 2^31
before. assumed before.
Substituting numbers into this formula we see that for a window size Substituting numbers into this formula, we see that for a window size
of 32,768, an average of 65,536 packets would need to be transmitted of 32,768, an average of 65,536 packets would need to be transmitted
in order to "spoof" a TCP segment that would be acceptable to a TCP in order to "spoof" a TCP segment that would be acceptable to a TCP
receiver. A window size of 65,535 reduces this even further to receiver. A window size of 65,535 reduces this even further to
32,768 packets. At today's access bandwidths an attack of that size 32,768 packets. At today's access bandwidths, an attack of that size
is feasible. is feasible.
With rises in bandwidth to both the home and office, it can only be With rises in bandwidth to both the home and office, it can only be
expected that the values for default window sizes will continue to expected that the values for default window sizes will continue to
rise in order to better take advantage of the newly available rise in order to better take advantage of the newly available
bandwidth. It also needs to be noted that this attack can be bandwidth. It also needs to be noted that this attack can be
performed in a distributed fashion in order potentially gain access performed in a distributed fashion in order potentially gain access
to more bandwidth. to more bandwidth.
As we can see from the above discussion this weakness lowers the bar As we can see from the above discussion this weakness lowers the bar
quite considerably for likely attacks. But there is one additional quite considerably for likely attacks. But there is one additional
dependency which is the duration of the TCP connection. A TCP dependency that is the duration of the TCP connection. A TCP
connection that lasts only a few brief packets, as often is the case connection that lasts only a few brief packets, as often is the case
for web traffic, would not be subject to such an attack since the for web traffic, would not be subject to such an attack since the
connection may not be established long enough for an attacker to connection may not be established long enough for an attacker to
generate enough traffic. However there is a set of applications such generate enough traffic. However, there is a set of applications,
as BGP [RFC4271] which is judged to be potentially most affected by such as BGP [RFC4271], that is judged to be potentially most affected
this vulnerability. BGP relies on a persistent TCP session between by this vulnerability. BGP relies on a persistent TCP session
BGP peers. Resetting the connection can result in medium term between BGP peers. Resetting the connection can result in term-
unavailability due to the need to rebuild routing tables and route medium unavailability due to the need to rebuild routing tables and
flapping; see [NISCC] for further details. route flapping; see [NISCC] for further details.
For applications that can use the TCP MD5 option [RFC2385], such as For applications that can use the TCP MD5 option [RFC2385], such as
BGP, that option makes the attacks described in this specification BGP, that option makes the attacks described in this specification
effectively impossible. However, some applications or effectively impossible. However, some applications or
implementations may find that option expensive to implement. implementations may find that option expensive to implement.
There are alternative protections against the threats that this There are alternative protections against the threats that this
document addresses. For further details regarding the attacks and document addresses. For further details regarding the attacks and
the existing techniques, please refer to [RFC4953]. It also needs to the existing techniques, please refer to [RFC4953]. It also needs to
be emphasized that, as suggested in be emphasized that, as suggested in [TSVWG-PORT] and [RFC1948], port
[I-D.ietf-tsvwg-port-randomization] and [RFC1948], port randomization randomization and initial sequence number (ISN) randomization would
and ISN randomization would help improve the robustness of the TCP help improve the robustness of the TCP connection against off-path
connection against off-path attacks. attacks.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. TCP document are to be interpreted as described in [RFC2119]. TCP
terminology should be interpreted as described in [RFC0793]. terminology should be interpreted as described in [RFC0793].
3. Blind reset attack using the RST bit 3. Blind Reset Attack Using the RST Bit
3.1. Description of the attack 3.1. Description of the Attack
As described in the introduction, it is possible for an attacker to As described in the introduction, it is possible for an attacker to
generate a "RST" segment that would be acceptable to a TCP receiver generate a RST segment that would be acceptable to a TCP receiver by
by guessing "in-window" sequence numbers. In particular [RFC0793], guessing in-window sequence numbers. In particular [RFC0793], page
p37, states the following: 37, states the following:
"In all states except SYN-SENT, all reset (RST) segments are In all states except SYN-SENT, all reset (RST) segments are
validated by checking their SEQ-fields [sequence numbers]. A reset validated by checking their SEQ-fields [sequence numbers]. A
is valid if its sequence number is in the window. In the SYN-SENT reset is valid if its sequence number is in the window. In the
state (a RST received in response to an initial SYN), the RST is SYN-SENT state (a RST received in response to an initial SYN), the
acceptable if the ACK field acknowledges the SYN." RST is acceptable if the ACK field acknowledges the SYN.
3.2. Mitigation 3.2. Mitigation
[RFC0793] currently requires handling of a segment with the RST bit [RFC0793] currently requires handling of a segment with the RST bit
when in a synchronized state to be processed as follows: when in a synchronized state to be processed as follows:
1) If the RST bit is set and the sequence number is outside the 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+ current receive window (SEG.SEQ <= RCV.NXT || SEG.SEQ > RCV.NXT+
RCV.WND) , silently drop the segment. RCV.WND), silently drop the segment.
2) If the RST bit is set and the sequence number is acceptable i.e.: 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. (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then reset the connection.
Instead, this document requires that implementations SHOULD implement Instead, implementations SHOULD implement the following steps in
the following steps in place of those specified in [RFC0793] (as place of those specified in [RFC0793] (as listed above).
listed above).
1) If the RST bit is set and the sequence number is outside the 1) If the RST bit is set and the sequence number is outside the
current receive window, silently drop the segment. current receive window, silently drop the segment.
2) If the RST bit is set and the sequence number exactly matches the 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 next expected sequence number (RCV.NXT), then TCP MUST reset the
connection. connection.
3) If the RST bit is set and the sequence number does not exactly 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 match the next expected sequence value, yet is within the current
skipping to change at page 10, line 4 skipping to change at page 8, line 11
2) If the RST bit is set and the sequence number exactly matches the 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 next expected sequence number (RCV.NXT), then TCP MUST reset the
connection. connection.
3) If the RST bit is set and the sequence number does not exactly 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 match the next expected sequence value, yet is within the current
receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST
send an acknowledgment (challenge ACK): send an acknowledgment (challenge ACK):
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the challenge ACK, TCP MUST drop the unacceptable After sending the challenge ACK, TCP MUST drop the unacceptable
segment and stop processing the incoming packet further. Further segment and stop processing the incoming packet further. Further
segments destined to this connection will be processed as normal. segments destined to this connection will be processed as normal.
The modified RST segment processing would thus become : The modified RST segment processing would thus become:
In all states except SYN-SENT, all reset (RST) segments are validated In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields [sequence numbers]. A reset is valid if by checking their SEQ-fields [sequence numbers]. A reset is valid if
its sequence number exactly matches the next expected sequence its sequence number exactly matches the next expected sequence
number. If the RST arrives and its sequence number field does NOT number. If the RST arrives and its sequence number field does NOT
match the next expected sequence number but is within the window, match the next expected sequence number but is within the window,
then the receiver should generate an ACK. In all other cases where 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 the SEQ-field does not match and is outside the window, the receiver
MUST silently discard the segment. MUST silently discard the segment.
In the SYN-SENT state (a RST received in response to an initial SYN), 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 the RST is acceptable if the ACK field acknowledges the SYN. In all
other cases the receiver MUST silently discard the segment. other cases the receiver MUST silently discard the segment.
With the above slight change to the TCP state machine, it becomes With the above slight change to the TCP state machine, it becomes
much harder for an attacker to generate an acceptable reset segment. much harder for an attacker to generate an acceptable reset segment.
In cases where the remote peer did generate a RST but it fails to In cases where the remote peer did generate a RST, but it fails to
meet the above criteria (the RST sequence number was within the meet the above criteria (the RST sequence number was within the
window but NOT the exact expected sequence number) when the challenge window but NOT the exact expected sequence number), when the
ACK is sent back, it will no longer have the transmission control challenge ACK is sent back, it will no longer have the transmission
block (TCB) related to this connection and hence as per [RFC0793], control block (TCB) related to this connection and hence as per
the remote peer will send a second RST back. The sequence number of [RFC0793], the remote peer will send a second RST back. The sequence
the second RST is derived from the acknowledgment number of the number of the second RST is derived from the acknowledgment number of
incoming ACK. This second RST, if it reaches the sender, will cause the incoming ACK. This second RST, if it reaches the sender, will
the connection to be aborted since the sequence number would now be cause the connection to be aborted since the sequence number would
an exact match. now be an exact match.
A valid RST received out-of-order would still generate a challenge A valid RST received out of order would still generate a challenge
ACK in response. If this RST happens to be a genuine one, the other ACK in response. If this RST happens to be a genuine one, the other
end would send an RST with an exact sequence number match which would end would send an RST with an exact sequence number match that would
cause the connection to be dropped. cause the connection to be dropped.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 10. exchange. This concern is discussed in Section 10.
4. Blind reset attack using the SYN bit 4. Blind Reset Attack Using the SYN Bit
4.1. Description of the attack 4.1. Description of the Attack
The analysis of the reset attack using the RST bit highlights another The analysis of the reset attack using the RST bit highlights another
possible avenue for a blind attacker using a similar set of sequence possible avenue for a blind attacker using a similar set of sequence
number guessing. Instead of using the RST bit an attacker can use number guessing. Instead of using the RST bit, an attacker can use
the SYN bit with the exact same semantics to tear down a connection. the SYN bit with the exact same semantics to tear down a connection.
4.2. Mitigation 4.2. Mitigation
[RFC0793] currently requires handling of a segment with the SYN bit [RFC0793] currently requires handling of a segment with the SYN bit
set in the synchronized state to be as follows: set in the synchronized state to be as follows:
1) If the SYN bit is set and the sequence number is outside the 1) If the SYN bit is set and the sequence number is outside the
expected window, send an ACK back to the sender. expected window, send an ACK back to the sender.
2) If the SYN bit is set and the sequence number is acceptable i.e.: 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 (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND), then send a RST segment to
the sender. the sender.
Instead, the handling of the SYN in the synchronized state SHOULD be Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows: performed as follows:
1) If the SYN bit is set, irrespective of the sequence number, TCP 1) If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote MUST send an ACK (also referred to as challenge ACK) to the remote
peer: peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further. segment and stop processing further.
By sending an ACK, the remote peer is challenged to confirm the loss By sending an ACK, the remote peer is challenged to confirm the loss
of the previous connection and the request to start a new connection. of the previous connection and the request to start a new connection.
A legitimate peer, after restart, would not have a TCB in the A legitimate peer, after restart, would not have a TCB in the
synchronized state. Thus when the ACK arrives the peer should send a synchronized state. Thus, when the ACK arrives, the peer should send
RST segment back with the sequence number derived from the ACK field a RST segment back with the sequence number derived from the ACK
that caused the RST. field that caused the RST.
This RST will confirm that the remote peer has indeed closed the This RST will confirm that the remote peer has indeed closed the
previous connection. Upon receipt of a valid RST, the local TCP previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to re- should then rely on SYN retransmission from the remote end to
establish the connection. re-establish the connection.
A spoofed SYN, on the other hand, will then have generated an A spoofed SYN, on the other hand, will then have generated an
additional ACK which the peer will discard as a duplicate ACK and additional ACK that the peer will discard as a duplicate ACK and will
will not affect the established connection. not affect the established connection.
Note that this mitigation does leave one corner case un-handled which Note that this mitigation does leave one corner case un-handled,
will prevent the reset of a connection when it should be reset (i.e. which will prevent the reset of a connection when it should be reset
it is a non-spoofed SYN wherein a peer really did restart). This (i.e., it is a non-spoofed SYN wherein a peer really did restart).
problem occurs when the restarting host chooses the exact same IP This problem occurs when the restarting host chooses the exact same
address and port number that it was using prior to its restart. By IP address and port number that it was using prior to its restart.
chance the restarted host must also choose an initial sequence number By chance, the restarted host must also choose an initial sequence
of exactly (RCV.NXT - 1) of the remote peer that is still in the number of exactly (RCV.NXT - 1) of the remote peer that is still in
established state. Such a case would cause the receiver to generate the established state. Such a case would cause the receiver to
a "challenge" ACK as described above. But since the ACK would be generate a "challenge" ACK as described above. But since the ACK
within the outgoing connections window the inbound ACK would be would be within the outgoing connections window, the inbound ACK
acceptable, and the sender of the SYN will do nothing with the would be acceptable, and the sender of the SYN will do nothing with
response ACK. This sequence will continue as the SYN sender the response ACK. This sequence will continue as the SYN sender
continually times out and retransmits the SYN until such time as the continually times out and retransmits the SYN until such time as the
connection attempt fails. connection attempt fails.
This corner case is a result of the [RFC0793] specification and is This corner case is a result of the [RFC0793] specification and is
not introduced by these new requirements. not introduced by these new requirements.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 10. exchange. This concern is discussed in Section 10.
5. Blind data injection attack 5. Blind Data Injection Attack
5.1. Description of the attack 5.1. Description of the Attack
A third type of attack is also highlighted by both the RST and SYN A third type of attack is also highlighted by both the RST and SYN
attacks. It is also possible to inject data into a TCP connection by attacks. It is also possible to inject data into a TCP connection by
simply guessing a sequence number within the current receive window simply guessing a sequence number within the current receive window
of the victim. The ACK value of any data segment is considered valid of the victim. The ACK value of any data segment is considered valid
as long as it does not acknowledge data ahead of the next segment to as long as it does not acknowledge data ahead of the next segment to
send. In other words an ACK value is acceptable if it is ((SND.UNA- send. In other words, an ACK value is acceptable if it is
(2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above ((SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the
inequality takes into account the fact that comparisons on TCP above inequality takes into account the fact that comparisons on TCP
sequence and acknowledgement numbers is done using the modulo 32 bit sequence and acknowledgment numbers is done using the modulo 32-bit
arithmetic to accommodate the number wraparound. This means that an arithmetic to accommodate the number wraparound. This means that an
attacker has to guess two ACK values with every guessed sequence attacker has to guess two ACK values with every guessed sequence
number so that the chances of successfully injecting data into a number so that the chances of successfully injecting data into a
connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2). Thus the mean connection are 1 in ( 1/2 (2^32 / RCV.WND) * 2). Thus, the mean
number of tries needed to inject data successfully is 1/2 (2*2^32/ number of tries needed to inject data successfully is
RWND) = 2^32/RCV.WND. 1/2 (2*2^32/RWND) = 2^32/RCV.WND.
When an attacker successfully injects data into a connection the data When an attacker successfully injects data into a connection, the
will sit in the receiver's re-assembly queue until the peer sends data will sit in the receiver's re-assembly queue until the peer
enough data to bridge the gap between the RCV.NXT value and the sends enough data to bridge the gap between the RCV.NXT value and the
injected data. At that point one of two things will occur : injected data. At that point, one of two things will occur:
1) A packet war will ensue with the receiver indicating that it has 1) A packet war will ensue with the receiver indicating that it has
received data up until RCV.NXT (which includes the attacker's received data up until RCV.NXT (which includes the attacker's
data) and the sender sending an ACK with an acknowledgment number data) and the sender sending an ACK with an acknowledgment number
less than RCV.NXT. less than RCV.NXT.
2) The sender will send enough data to the peer which will move 2) The sender will send enough data to the peer that will move
RCV.NXT even further along past the injected data. RCV.NXT even further along past the injected data.
Depending upon the TCP implementation in question and the TCP traffic Depending upon the TCP implementation in question and the TCP traffic
characteristics at that time, data corruption may result. In case characteristics at that time, data corruption may result. In case
(a) the connection will eventually be reset by one of the sides (a), the connection will eventually be reset by one of the sides
unless the sender produces more data that will transform the ACK war unless the sender produces more data that will transform the ACK war
into case (b). The reset will usually occur via User Time Out (UTO) into case (b). The reset will usually occur via User Time Out (UTO)
(see section 4.2.3.5 of [RFC1122]). (see section 4.2.3.5 of [RFC1122]).
Note that the protections illustrated in this section neither cause Note that the protections illustrated in this section neither cause
an ACK war nor prevent one from occurring if data is actually an ACK war nor prevent one from occurring if data is actually
injected into a connection. The ACK war is a product of the attack injected into a connection. The ACK war is a product of the attack
itself and cannot be prevented (other than by preventing the data itself and cannot be prevented (other than by preventing the data
from being injected). from being injected).
5.2. Mitigation 5.2. Mitigation
All TCP stacks MAY implement the following mitigation. TCP stacks All TCP stacks MAY implement the following mitigation. TCP stacks
which implement this mitigation MUST add an additional input check to that implement this mitigation MUST add an additional input check to
any incoming segment. The ACK value is considered acceptable only if any incoming segment. The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded and an ACK sent back. It needs to above condition MUST be discarded and an ACK sent back. It needs to
be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a be noted 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 duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
ACK, drop the segment, and return." The "ignored" above implies that ACK, drop the segment, and return". The "ignored" above implies that
the processing of the incoming data segment continues, which means the processing of the incoming data segment continues, which means
the ACK value is treated as acceptable. This mitigation makes the the ACK value is treated as acceptable. This mitigation makes the
ACK check more stringent since any ACK < SND.UNA wouldn't be ACK check more stringent since any ACK < SND.UNA wouldn't be
accepted, instead only ACKs which are in the range ((SND.UNA - accepted, instead only ACKs that are in the range ((SND.UNA -
MAX.SND.WND) <= SEG.ACK <= SND.NXT) gets through. MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.
A new state variable MAX.SND.WND is defined as the largest window 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 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 may be scaled to a value larger than 65,535 bytes ([RFC1323]). This
small check will reduce the vulnerability to an attacker guessing a small check will reduce the vulnerability to an attacker guessing a
valid sequence number, since, not only one must guess the in-window valid sequence number, since, not only one must guess the in-window
sequence number, but also guess a proper ACK value within a scoped sequence number, but also guess a proper ACK value within a scoped
range. This mitigation reduces, but does not eliminate, the ability range. This mitigation reduces, but does not eliminate, the ability
to generate false segments. It does however reduce the probability to generate false segments. It does however reduce the probability
that invalid data will be injected. that invalid data will be injected.
Implementations can also chose to hard code the MAX.SND.WND value to Implementations can also chose to hard code the MAX.SND.WND value to
the maximum permissible window size i.e., 65535 in the absence of the maximum permissible window size, i.e., 65535 in the absence of
window scaling. In presence of the window scaling option the value window scaling. In the presence of the window scaling option, the
becomes (MAX.SND.WND << Snd.Wind.Scale). value becomes (MAX.SND.WND << Snd.Wind.Scale).
This mitigation also helps in improving robustness on accepting This mitigation also helps in improving robustness on accepting
spoofed FIN segments (FIN attacks). Among other things, this spoofed FIN segments (FIN attacks). Among other things, this
mitigation requires that the attacker also needs to get the mitigation requires that the attacker also needs to get the
acknowledgment number to fall in the range mentioned above in order acknowledgment number to fall in the range mentioned above in order
to successfully spoof a FIN segment leading to the closure of the to successfully spoof a FIN segment leading to the closure of the
connection. Thus, this mitigation greatly improves the robustness to connection. Thus, this mitigation greatly improves the robustness to
spoofed FIN segments. spoofed FIN segments.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 10. exchange. This concern is discussed in Section 10.
6. Suggested Mitigation strengths 6. Suggested Mitigation Strengths
As described in the above sections, recommendation levels for RST, As described in the above sections, recommendation levels for RST,
SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The SYN, and DATA are tagged as SHOULD, SHOULD, and MAY, respectively.
reason that DATA mitigation is tagged as MAY, even though it The reason that DATA mitigation is tagged as MAY, even though it
increased the TCP robustness in general is because, the DATA increased the TCP robustness in general is because, the DATA
injection is perceived to be more difficult (twice as unlikely) when injection is perceived to be more difficult (twice as unlikely) when
compared to RST and SYN counterparts. However, it needs to be noted compared to RST and SYN counterparts. However, it needs to be noted
that all the suggested mitigations improve TCP's robustness in that all the suggested mitigations improve TCP's robustness in
general and hence the choice of implementing some or all mitigations general and hence the choice of implementing some or all mitigations
recommended in the document is purely left to the implementer. recommended in the document is purely left to the implementer.
7. ACK throttling 7. ACK Throttling
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, an ACK throttling mechanism is suggested as follows : challenge ACKs, an ACK throttling mechanism is suggested as follows:
1) The system administrator can configure the number of challenge 1) The system administrator can configure the number of challenge
ACKs that can be sent out in a given interval. For example, in 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 any 5 second window, no more than 10 challenge ACKs should be
sent. sent.
2) The values for both the time and number of ACKs SHOULD be tunable 2) The values for both the time and number of ACKs SHOULD be tunable
by the system administrator to accommodate different perceived by the system administrator to accommodate different perceived
levels of threat and/or system resources. levels of threat and/or system resources.
It should be noted that these numbers are empirical in nature and It should be noted that these numbers are empirical in nature and
have been obtained from the RST throttling mechanisms existing in have been obtained from the RST throttling mechanisms existing in
some implementations. Also note that no timer is needed to implement some implementations. Also, note that no timer is needed to
the above mechanism, instead a timestamp and a counter can be used. implement the above mechanism, instead a timestamp and a counter can
be used.
An implementation SHOULD include an ACK throttling mechanism to be An implementation SHOULD include an ACK throttling mechanism to be
conservative. While we have not encountered a case where the lack of conservative. While we have not encountered a case where the lack of
ACK throttling can be exploited, as a fail-safe mechanism we ACK throttling can be exploited, as a fail-safe mechanism we
recommend its use. An implementation may take an excessive number of recommend its use. An implementation may take an excessive number of
invocations of the throttling mechanism as an indication that network invocations of the throttling mechanism as an indication that network
conditions are unusual or hostile. conditions are unusual or hostile.
An administrator who is more concerned about protecting his bandwidth An administrator who is more concerned about protecting his bandwidth
and CPU utilization may set smaller ACK throttling values whereas an and CPU utilization may set smaller ACK throttling values whereas an
administrator who is more interested in faster cleanup of stale administrator who is more interested in faster cleanup of stale
connections (i.e. concerned about excess TCP state) may decide to set connections (i.e., concerned about excess TCP state) may decide to
a higher value thus allowing more RST's to be processed in any given set a higher value thus allowing more RST's to be processed in any
time period. given time period.
The time limit SHOULD be tunable to help timeout brute force attacks The time limit SHOULD be tunable to help timeout brute force attacks
faster than a potential legitimate flood of RSTs. faster than a potential legitimate flood of RSTs.
8. Backward Compatibility and Other considerations 8. Backward Compatibility and Other Considerations
All of the new required mitigation techniques in this document are All of the new required mitigation techniques in this document are
totally compatible with existing ([RFC0793]) compliant TCP totally compatible with existing ([RFC0793]) compliant TCP
implementations as this document introduces no new assumptions or implementations as this document introduces no new assumptions or
conditions. conditions.
There is a corner scenario in the above mitigations which will There is a corner scenario in the above mitigations that will require
require more than one round trip time to successfully abort the more than one round-trip time to successfully abort the connection as
connection as per the figure below. This scenario is similar to the per the figure below. This scenario is similar to the one in which
one in which the original RST was lost in the network. the original RST was lost in the network.
TCP A TCP B TCP A TCP B
1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB 1.a. ESTAB <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTAB
b. (delayed) ... <SEQ=400><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 c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED
2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED 2. ESTAB --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(ACK for 1.a) (ACK for 1.a)
... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED ... <SEQ=400><ACK=0><CTL=RST> <-- CLOSED
3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED 3. CHALLENGE --> <SEQ=101><ACK=400><CTL=ACK> --> CLOSED
(for 1.c) (for 1.c)
skipping to change at page 18, line 5 skipping to change at page 14, line 28
5. RESPONSE arrives at A, but dropped since its outside of window. 5. RESPONSE arrives at A, but dropped since its outside of window.
6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSED 7. CLOSED CLOSED
For the mitigation to be maximally effective against the For the mitigation to be maximally effective against the
vulnerabilities discussed in this document, both ends of the TCP vulnerabilities discussed in this document, both ends of the TCP
connection need to have the fix. Although, having the mitigations at connection need to have the fix. Although, having the mitigations at
one end might prevent that end from being exposed to the attack, the one end might prevent that end from being exposed to the attack, the
connection is still vulnerable at the other end. connection is still vulnerable at the other end.
9. Middlebox considerations 9. Middlebox Considerations
9.1. Middlebox that resend RST's 9.1. Middlebox That Resend RSTs
Consider a middlebox M-B tracking connections between two TCP end Consider a middlebox M-B tracking connections between two TCP end
hosts E-A and E-C. If E-C sends a RST with a sequence number that is hosts E-A and E-C. If E-C sends a RST with a sequence number that is
within the window but not an exact match to reset the connection and within the window but not an exact match to reset the connection and
M-B does not have the fix recommended in this document, it may clear M-B does not have the fix recommended in this document, it may clear
the connection and forward the RST to E-A saving an incorrect the connection and forward the RST to E-A saving an incorrect
sequence number. If E-A does not have the fix the connection would sequence number. If E-A does not have the fix, the connection would
get cleared as required. However if E-A does have the required fix, get cleared as required. However, if E-A does have the required fix,
it will send a challenge ACK to E-C. M-B, being a middlebox, may 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 intercept this ACK and resend the RST on behalf of E-C with the old
sequence number. This RST will, again, not be acceptable and may sequence number. This RST will, again, not be acceptable and may
trigger a challenge ACK. trigger a challenge ACK.
The above situation may result in a RST/ACK war. However, we believe The above situation may result in a RST/ACK war. However, we believe
that if such a case exists in the Internet, the middle box is that if such a case exists in the Internet, the middlebox is
generating packets a conformant TCP endpoint would not generate. generating packets a conformant TCP endpoint would not generate.
[RFC0793] dictates that the sequence number of a RST has to be [RFC0793] dictates that the sequence number of a RST has to be
derived from the acknowledgment number of the incoming ACK segment. derived from the acknowledgment number of the incoming ACK segment.
It is outside the scope of this document to suggest mitigations to It is outside the scope of this document to suggest mitigations to
the ill-behaved middleboxes. the ill-behaved middleboxes.
Consider a similar scenario where the RST from M-B to E-A gets lost, Consider a similar scenario where the RST from M-B to E-A gets lost,
E-A will continue to hold the connection and E-A might send an ACK an E-A will continue to hold the connection and E-A might send an ACK an
arbitrary time later after the connection state was destroyed at M-B. arbitrary time later after the connection state was destroyed at M-B.
For this case, M-B will have to cache the RST for an arbitrary amount For this case, M-B will have to cache the RST for an arbitrary amount
of time till until it is confirmed that the connection has been of time until it is confirmed that the connection has been cleared at
cleared at E-A. E-A.
9.2. Middleboxes that advance sequence numbers 9.2. Middleboxes That Advance Sequence Numbers
Some middleboxes may compute RST sequence numbers at the higher end Some middleboxes may compute RST sequence numbers at the higher end
of the acceptable window. The scenario is the same as the earlier of the acceptable window. The scenario is the same as the earlier
case, but in this case instead of sending the cached RST, the case, but in this case instead of sending the cached RST, the
middlebox (M-B) sends a RST that computes its sequence number as the middlebox (M-B) sends a RST that computes its sequence number as the
sum of the acknowledgement field in the ACK and the window advertised sum of the acknowledgment field in the ACK and the window advertised
by the ACK that was sent by E-A to challenge the RST as depicted by the ACK that was sent by E-A to challenge the RST as depicted
below. The difference in the sequence numbers between step 1 and 2 below. The difference in the sequence numbers between step 1 and 2
below is due to data lost in the network. below is due to data lost in the network.
TCP A Middlebox TCP A Middlebox
1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED 1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
Although the authors are not aware of an implementation that does the Although the authors are not aware of an implementation that does the
above, it could be mitigated by implementing the ACK throttling above, it could be mitigated by implementing the ACK throttling
mechanism described earlier. mechanism described earlier.
9.3. Middleboxes that drop the challenge ACK 9.3. Middleboxes That Drop the Challenge ACK
It also needs to be noted that, some middleboxes (Firewalls/NATs) It also needs to be noted that, some middleboxes (Firewalls/NATs)
which doesn't have the fix recommended in the document, may drop the that don't have the fix recommended in the document, may drop the
challenge ACK. This can happen because, the original RST segment challenge ACK. This can happen because, the original RST segment
which was in window had already cleared the flow state pertaining to that was in window had already cleared the flow state pertaining to
the TCP connection in the middlebox. In such cases, the end hosts the TCP connection in the middlebox. In such cases, the end hosts
which have implemented the RST mitigation described in this document, that have implemented the RST mitigation described in this document,
will have the TCP connection left open. This is a corner case and will have the TCP connection left open. This is a corner case and
can go away if the middlebox is conformant with the changes proposed can go away if the middlebox is conformant with the changes proposed
in this document. in this document.
10. Security Considerations 10. Security Considerations
These changes to the TCP state machine do NOT protect an These changes to the TCP state machine do NOT protect an
implementation from on-path attacks. It also needs to be emphasized implementation from on-path attacks. It also needs to be emphasized
that while mitigations within this document make it harder for off- that while mitigations within this document make it harder for off-
path attackers to inject segments, it does NOT make it impossible. 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 The only way to fully protect a TCP connection from both on- and off-
path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP path attacks is by using either IPsec Authentication Header (AH)
[RFC4303]. [RFC4302] or IPsec Encapsulating Security Payload (ESP) [RFC4303].
Implementers also should be aware that the attacks detailed in this Implementers also should be aware that the attacks detailed in this
specification are not the only attacks available to an off-path specification are not the only attacks available to an off-path
attacker and that the counter measures described herein are not a attacker and that the counter measures described herein are not a
comprehensive defense against such attacks. comprehensive defense against such attacks.
In particular, administrators should be aware that forged ICMP In particular, administrators should be aware that forged ICMP
messages provide off-path attackers the opportunity to disrupt messages provide off-path attackers the opportunity to disrupt
connections or degrade service. Such attacks may be subject to even connections or degrade service. Such attacks may be subject to even
less scrutiny than the TCP attacks addressed here, especially in less scrutiny than the TCP attacks addressed here, especially in
stacks not tuned for hostile environments. It is important to note stacks not tuned for hostile environments. It is important to note
that some ICMP messages, validated or not, are key to the proper that some ICMP messages, validated or not, are key to the proper
function of TCP. Those ICMP messages used to properly set the path function of TCP. Those ICMP messages used to properly set the path
maximum transmission unit are the most obvious example. There are a maximum transmission unit are the most obvious example. There are a
variety of ways to choose which, if any, ICMP messages to trust in variety of ways to choose which, if any, ICMP messages to trust in
the presence of off-path attackers and choosing between them depends the presence of off-path attackers and choosing between them depends
on the assumptions and guarantees developers and administrators can on the assumptions and guarantees developers and administrators can
make about their network. This specification does not attempt to do make about their network. This specification does not attempt to do
more than note this and related issues. Unless implementers address more than note this and related issues. Unless implementers address
spoofed ICMP messages [I-D.ietf-tcpm-icmp-attacks], the mitigations spoofed ICMP messages [RFC5927], the mitigations specified in this
specified in this document may not provide the desired protection document may not provide the desired protection level.
level.
In any case, this RFC details only part of a complete strategy to In any case, this RFC details only part of a complete strategy to
prevent off-path attackers from disrupting services that use TCP. prevent off-path attackers from disrupting services that use TCP.
Administrators and implementers should consider the other attack Administrators and implementers should consider the other attack
vectors and determine appropriate mitigations in securing their vectors and determine appropriate mitigations in securing their
systems. systems.
Another notable consideration is that a reflector attack is possible Another notable consideration is that a reflector attack is possible
with the required RST/SYN mitigation techniques. In this attack, an 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 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 spoofed RST/SYN segment that lies within the current receive window
of the victim. It should be noted, however, that this does not cause of the victim. It should be noted, however, that this does not cause
any amplification since the attacker must generate a segment for each any amplification since the attacker must generate a segment for each
one that the victim will generate. one that the victim will generate.
11. IANA Considerations 11. Contributors
This document contains no IANA considerations.
12. Contributors
Mitesh Dalal and Amol Khare of Cisco Systems came up with the Mitesh Dalal and Amol Khare of Cisco Systems came up with the
solution for the RST/SYN attacks. Anantha Ramaiah and Randall solution for the RST/SYN attacks. Anantha Ramaiah and Randall
Stewart of Cisco Systems discovered the data injection vulnerability Stewart of Cisco Systems discovered the data injection vulnerability
and together with Patrick Mahan and Peter Lei of Cisco Systems found and together with Patrick Mahan and Peter Lei of Cisco Systems found
solutions for the same. Paul Goyette, Mark Baushke, Frank solutions for the same. Paul Goyette, Mark Baushke, Frank
Kastenholz, Art Stine and David Wang of Juniper Networks provided the Kastenholz, Art Stine, and David Wang of Juniper Networks provided
insight that apart from RSTs, SYNs could also result in formidable the insight that apart from RSTs, SYNs could also result in
attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of formidable attacks. Shrirang Bage of Cisco Systems, Qing Li and
Wind River Systems and Xiaodan Tang of QNX Software along with the Preety Puri of Wind River Systems, and Xiaodan Tang of QNX Software
folks above helped in ratifying and testing the interoperability of along with the folks above helped in ratifying and testing the
the suggested solutions. interoperability of the suggested solutions.
13. Acknowledgments 12. Acknowledgments
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra
Murphy, Brian Carpenter, Cullen Jennings and other members of the Murphy, Brian Carpenter, Cullen Jennings, and other members of the
tcpm WG for suggestions and comments. ACK throttling was introduced tcpm WG for suggestions and comments. ACK throttling was introduced
to this document by combining the suggestions from the tcpm working to this document by combining the suggestions from the tcpm working
group. group.
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 13.2. Informative References
[I-D.ietf-tcpm-icmp-attacks] [Medina05] Medina, A., Allman, M., and S. Floyd, "Measuring the
Gont, F., "ICMP attacks against TCP", Evolution of Transport Protocols in the Internet", ACM
draft-ietf-tcpm-icmp-attacks-12 (work in progress), Computer Communication Review, 35(2), April 2005,
March 2010. <http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps>.
[I-D.ietf-tsvwg-port-randomization] [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Larsen, M. and F. Gont, "Transport Protocol Port Vulnerability Issues in TCP".
Randomization Recommendations",
draft-ietf-tsvwg-port-randomization-07 (work in progress),
April 2010.
[Medina05] [RFC1122] Braden, R., "Requirements for Internet Hosts -
Medina, A., Allman, M., and S. Floyd, "Measuring the Communication Layers", STD 3, RFC 1122, October 1989.
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
(figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
Vulnerability Issues in TCP". Extensions for High Performance", RFC 1323, May 1992.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1948] Bellovin, S., "Defending Against Sequence Number
Communication Layers", STD 3, RFC 1122, October 1989. Attacks", RFC 1948, May 1996.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
for High Performance", RFC 1323, May 1992. MD5 Signature Option", RFC 2385, August 1998.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
RFC 1948, May 1996. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
Signature Option", RFC 2385, August 1998. December 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
Protocol 4 (BGP-4)", RFC 4271, January 2006. RFC 4303, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
December 2005. RFC 4953, July 2007.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
RFC 4303, December 2005. July 2010.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [SITW] Watson, P., "Slipping in the Window: TCP Reset
RFC 4953, July 2007. attacks", Presentation at 2004 CanSecWest,
<http://cansecwest.com/csw04archive.html>.
[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks, [TSVWG-PORT] Larsen, M. and F. Gont, "Transport Protocol Port
Presentation at 2004 CanSecWest Randomization Recommendations", Work in Progress,
http://www.cansecwest.com/archives.html". August 2010.
Authors' Addresses Authors' Addresses
Anantha Ramaiah Anantha Ramaiah
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 525-6486 Phone: +1 (408) 525-6486
Email: ananth@cisco.com EMail: ananth@cisco.com
Randall R. Stewart Randall R. Stewart
Huawei Huawei
148 Crystal Cove Ct 148 Crystal Cove Ct
Chapin, SC 29036 Chapin, SC 29036
USA USA
Phone: +1 (803) 345-0369 Phone: +1 (803) 345-0369
Email: rstewart@huawei.com EMail: rstewart@huawei.com
Mitesh Dalal Mitesh Dalal
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 853-5257 Phone: +1 (408) 853-5257
Email: mdalal@cisco.com EMail: mdalal@cisco.com
 End of changes. 116 change blocks. 
282 lines changed or deleted 264 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/