draft-ietf-tcpm-tcpsecure-06.txt   draft-ietf-tcpm-tcpsecure-07.txt 
TCP Maintenance and Minor A. Ramaiah TCP Maintenance and Minor A. Ramaiah
Extensions Working Group R. Stewart Extensions Working Group R. Stewart
Internet-Draft M. Dalal Internet-Draft M. Dalal
Intended status: Standards Track Editor Intended status: Standards Track Editor
Expires: May 11, 2007 November 7, 2006 Expires: August 26, 2007 February 22, 2007
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-06.txt draft-ietf-tcpm-tcpsecure-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 11, 2007. This Internet-Draft will expire on August 26, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A recent study indicates that some types of TCP connections have an TCP has historically been considered protected against spoofed packet
increased vulnerability to spoofed packet injection attacks than injection attacks by relying on the fact that it is difficult to
previously believed [SITW]. TCP has historically been considered guess the 4-tuple (the source and destination IP addresses and the
protected against spoofed packet injection attacks by relying on the source and destination ports) in combination with the 32 bit sequence
fact that it is difficult to guess the 4-tuple (the source and number(s). A combination of increasing window sizes and applications
destination IP addresses and the source and destination ports) in using a longer term connections (e.g. H-323 or Border Gateway
combination with the 32 bit sequence number(s). A combination of Protocol [RFC4271]) have left modern TCP implementation more
increasing window sizes and applications using a longer term vulnerable to these types of spoofed packet injection attacks.
connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have
left modern TCP implementation more vulnerable to these types of
spoofed packet injection attacks.
Note: Both [SITW] and [I-D.ietf-tcpm-tcp-antispoof] provide charts
which can give the reader an idea as to the time it takes to
penetrate an unprotected system.
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 to be addresses and ports which makes it far easier for the 4-tuple to be
guessed. Having guessed the 4-tuple correctly, an attacker can guessed. Having guessed the 4-tuple correctly, an attacker can
inject a RST, SYN or DATA segment into a TCP connection by carefully inject a RST, SYN or DATA segment into a TCP connection by carefully
crafting the sequence number of the spoofed segment to be in the crafting the sequence number of the spoofed segment to be in the
current receive window. This can cause the connection to either current receive window. This can cause the connection to either
abort or possibly cause data corruption. This document requires abort or possibly cause data corruption. This document specifies
small modifications to the way TCP handles inbound segments that can small modifications to the way TCP handles inbound segments that can
reduce the probability of such an attack. reduce the chances of a successful attack.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The RESET attack . . . . . . . . . . . . . . . . . . . . . 4 1.1. Basic Attack Methodology . . . . . . . . . . . . . . . . . 4
1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 5 1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
3.1. Description of the attack . . . . . . . . . . . . . . . . 9 3.1. Description of the attack . . . . . . . . . . . . . . . . 9
3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11
4.1. Description of the attack . . . . . . . . . . . . . . . . 11 4.1. Description of the attack . . . . . . . . . . . . . . . . 11
4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13
5.1. Description of the attack . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 13
5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 8 skipping to change at page 4, line 8
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 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 todays end transport protocol used for data communication in today's
Internet. Yet when it was defined over 20 years ago the Internet, as Internet. Yet when it was standardized over 20 years ago, the
we know it, was a different place lacking many of the threats that Internet, as we know it, was a different place, lacking many of the
are now common. TCP spoofing attacks are one such attack that are threats that are now common. TCP spoofing attacks are one such
seen on the Internet today. attack that are seen on the Internet today.
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 (commonly referred to as a 4-tuple value). The and destination ports (commonly referred to as a 4-tuple value). The
targeted TCP endpoint will then associate such a packet with an targeted TCP endpoint will then associate such a packet with an
existing TCP connection. Note that in and of itself guessing this existing TCP connection. Note that in and of itself guessing this
4-tuple value is not always easy for an attacker. But there are some 4-tuple value is not always easy for an attacker. But there are some
applications (e.g. BGP [RFC1771]) that may have a tendency to use applications (e.g. BGP [RFC4271]) that may have a tendency to use
the same set(s) of ports on either endpoint making the odds of the same set(s) of ports on either endpoint making the odds of
guessing correctly the 4-tuple value much easier. When an attacker guessing correctly the 4-tuple value much easier. When an attacker
is successful in guessing the 4-tuple value, one of three types of is successful in guessing the 4-tuple value, one of three types of
injection attacks may be waged against a long-lived connection. injection attacks may be waged against a long-lived 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. connection to be torn down.
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 so tear down the connection
state. state.
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. the contents of the transmission.
1.1. The RESET attack 1.1. Basic Attack Methodology
Focusing upon the RESET attack, let's examine this attack in more Focusing upon the RESET attack, we examine this attack in more detail
detail to get an overview as to how it works and how this document to get an overview as to how it works and how this document addresses
addresses the issue. For this attack the goal is to cause one of the the issue. For this attack the goal is for the attacker to cause one
two endpoints of the connection to incorrectly tear down the of the two endpoints of the connection to incorrectly tear down the
connection state, effectively closing the connection. To do this the connection state, effectively aborting the connection. One of the
important things to note is that, for the attack to succeed the RST
needs to be in the valid receive window. It also needs to be
emphasised that the receive window is independent of the current
congestion window of the TCP connection. The attacker would try to
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
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
initial sequence number. initial 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
skipping to change at page 5, line 26 skipping to change at page 5, line 33
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. Without mitigation number guess is incremented by the window size. The feasibility of
[SITW] has shown that such an attack is much easier to accomplish this methodology (without mitigations) was first shown in [SITW].
then previously assumed. This is because [RFC0793] specifies that This is because [RFC0793] specifies that any RST within the current
any RST within the current window is acceptable. window is acceptable. Also [I-D.ietf-tcpm-tcp-antispoof] talks about
the probability of a successful attack with varying window sizes and
bandwidth.
A slight modification to the TCP state machine can be made which A slight enhancement to the TCP's segment processing rules can be
makes such an attack much more difficult to accomplish. If the made which makes such an attack much more difficult to accomplish.
receiver examines the incoming RST segment and validates that the If the receiver examines the incoming RST segment and validates that
sequence number exactly matches the sequence number that is next the sequence number exactly matches the sequence number that is next
expected, then such an attack becomes much more difficult then 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 state machine exact details of what needs to be changed within TCP's segment
to mitigate all three types of attacks (RST, SYN and DATA). processing rules to mitigate all three types of attacks (RST, SYN and
DATA).
1.2. Attack probabilities 1.2. Attack probabilities
Every application has control of a number of factors that effect Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack. These drastically 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 [Medina05]). (Medina05 [Medina05]).
skipping to change at page 6, line 19 skipping to change at page 6, line 29
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 verses 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 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 X 2^32] this assumption was incorrect and that instead of [1/2 * 2^32]
packets (assuming a random distribution) [1/2 X (2^32/window)] packets (assuming a random distribution) [1/2 * (2^32/window)]
packets is required. packets is required.
Placing real numbers on this formula we see that for a window size of Placing real numbers on this formula we see that for a window size of
32,768, an average of 65,536 packets would need to be transmitted in 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 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. With rises in bandwidth to both the home and office, 32,768 packets. With rises in bandwidth to both the home and office,
it can only be expected that the values for default window sizes will it can only be expected that the values for default window sizes will
continue to rise in order to better take advantage of the newly continue to rise in order to better take advantage of the newly
available bandwidth. available bandwidth. It also needs to be noted that this attack can
be performed in a distributed fashion in order potentially gain
access 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 which 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 such
as BGP [RFC1771] which is judged to be potentially most affected by as BGP [RFC4271] which is judged to be potentially most affected by
this vulnerability. BGP relies on a persistent TCP session between this vulnerability. BGP relies on a persistent TCP session between
BGP peers. Resetting the connection can result in medium term BGP peers. Resetting the connection can result in medium term
unavailability due to the need to rebuild routing tables and route unavailability due to the need to rebuild routing tables and route
flapping see [NISCC] for further details. flapping; see [NISCC] for further details.
It also needs to be emphasized that for applications like BGP which It also needs to be emphasized that, for applications like BGP, use
use the TCP MD5 option [RFC2385], can make the attacks described in of the TCP MD5 option [RFC2385], can make the attacks described in
this specification much harder to accomplish. this specification effectively impossible.
It should be noted that there are existing alternative protection It should be noted that there are existing alternative protections
against the threats that this document addresses. For further against the threats that this document addresses. For further
details regarding the attacks and the existing techniques, please details regarding the attacks and the existing techniques, please
refer to draft [I-D.ietf-tcpm-tcp-antispoof] refer to draft [I-D.ietf-tcpm-tcp-antispoof]
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].
skipping to change at page 9, line 32 skipping to change at page 9, line 32
[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 MUST perform the Instead, this document requires that implementations SHOULD implement
following steps in place of those specified in [RFC0793](listed the following steps in place of those specified in [RFC0793](as
above). listed above).
A) If the RST bit is set and the sequence number is outside the A) 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.
B) If the RST bit is set and the sequence number exactly matches the B) 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.
C) If the RST bit is set and the sequence number does not exactly C) 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 12 skipping to change at page 10, line 12
<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. segment and stop processing the incoming packet further.
The previous text,quoted from [RFC0793] pg 37 would thus become: The previous text,quoted from [RFC0793] pg 37 would thus become:
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 validated by checking their SEQ-fields [sequence numbers]. A
reset is valid if its sequence number exactly matches the next reset is valid if its sequence number exactly matches the next
expected sequence number. If the the RST arrives and its sequence expected sequence number. If the RST arrives and its sequence
number field does NOT match the next expected sequence number but number field does NOT match the next expected sequence number but
is within the window, then the receiver should generate an ACK. is within the window, then the receiver should generate an ACK.
In all other cases where the SEQ-field does not match and is In all other cases where the SEQ-field does not match and is
outside the window, the receiver MUST silently discard the outside the window, the receiver MUST silently discard the
segment. segment.
In the SYN-SENT state (a RST received in response to an initial 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. SYN), the RST is acceptable if the ACK field acknowledges the SYN.
In all other cases the receiver MUST silently discard the segment. In all other cases the receiver MUST silently discard the segment.
skipping to change at page 10, line 34 skipping to change at page 10, line 34
much harder for an attacker to generate an acceptable reset much harder for an attacker to generate an acceptable reset
segment. 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 window but NOT the exact expected sequence number) when the
challenge ACK is sent back, it will no longer have the challenge ACK is sent back, it will no longer have the
transmission control block (TCB) related to this connection and transmission control block (TCB) related to this connection and
hence as per [RFC0793], the remote peer will send a second RST hence as per [RFC0793], the remote peer will send a second RST
back. The sequence number of the second RST is derived from the back. The sequence number of the second RST is derived from the
acknowledgment number of the incoming ACK. This second RST if it acknowledgment number of the incoming ACK. This second RST, if it
reaches the sender will cause the connection to be aborted since reaches the sender, will cause the connection to be aborted since
the sequence number would now be an exact match. the sequence number would now be an exact match.
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 9 exchange. This concern is discussed in Section 9.
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
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 MUST be Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows: performed as follows:
A) If the SYN bit is set, irrespective of the sequence number, TCP A) 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.
skipping to change at page 12, line 8 skipping to change at page 12, line 8
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 re-
establish the connection. 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 which the peer will discard as a duplicate ACK and
will not affect the established connection. will 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 which
will prevent the reset of a connection when it should be reset (i.e. will prevent the reset of a connection when it should be reset (i.e.
it is a non spoofed SYN wherein a peer really did restart). This it is a non-spoofed SYN wherein a peer really did restart). This
problem occurs when the restarting host chooses the exact same IP problem occurs when the restarting host chooses the exact same IP
address and port number that it was using prior to its restart. By address and port number that it was using prior to its restart. By
chance the restarted host must also choose an initial sequence number chance the restarted host must also choose an initial sequence number
of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in
the established state. Such a case would cause the receiver to the established state. Such a case would cause the receiver to
generate a "challenge" ack as described above. But since the ACK generate a "challenge" ack as described above. But since the ACK
would be within the outgoing connections window the inbound ACK would would be within the outgoing connections window the inbound ACK would
be acceptable, and the sender of the SYN will do nothing with the be acceptable, and the sender of the SYN will do nothing with the
response ACK. This sequence will continue as the SYN sender 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 requirments. not introduced by these new requirments.
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 9 exchange. This concern is discussed in Section 9.
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 the a sequence number within the current receive simply guessing a sequence number within the current receive window
window of the victim. The ACK value of any data segment is of the victim. The ACK value of any data segment is considered valid
considered valid as long as it does not acknowledge data ahead of the as long as it does not acknowledge data ahead of the next segment to
next segment to send. In other words an ACK value is acceptable if send. In other words an ACK value is acceptable if it is ((SND.UNA-
it is (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). This means that an (2^31-1)) <= SEG.ACK <= SND.NXT). This means that an attacker has to
attacker has to guess two ACK values with every guessed sequence guess two ACK values with every guessed sequence number so that the
number so that the chances successfully injecting data into a chances of successfully injecting data into a connection are 1 in
connection are 1 in ((2^32 / RCV.WND) * 2). ((2^32 / RCV.WND) * 2).
When an attacker successfully injects data into a connection the data When an attacker successfully injects data into a connection the data
will sit in the receiver's re-assembly queue until the peer sends will sit in the receiver's re-assembly queue until the peer sends
enough data to bridge the gap between the RCV.NXT value and the 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 :
a) A packet war will ensue with the receiver indicating that it has a) A packet war will ensue with the receiver indicating that it has
received data up until RCV.NXT (which includes the attackers data) received data up until RCV.NXT (which includes the attackers data)
and the sender sending an ACK with an acknowledgment number less and the sender sending an ACK with an acknowledgment number less
than RCV.NXT. than RCV.NXT.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
(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
An additional input check MUST be added to any incoming segment. The All TCP stacks SHOULD implement the following mitigation. TCP stacks
ACK value MUST be acceptable only if it is in the range of ((SND.UNA which implement the mitigation requires that an additional input
- MAX.SND.WND) <= SEG.ACK <= SND.NXT).A new state variable check MUST be added to any incoming segment. The ACK value MUST be
MAX.SND.WND is defined as the largest window that the local sender acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <=
has ever received from its peer. This window may be a scaled value SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't
i.e. the value may be larger than 65,535 bytes ([RFC1323]). This satisfy the above condition MUST be discarded silently. A new state
small check will reduce the vulnerability to an attacker guessing a variable MAX.SND.WND is defined as the largest window that the local
valid sequence number since not only must he/she guess the sequence sender has ever received from its peer. This window may be scaled to
number in window, but must also guess a proper ACK value within a a value larger than 65,535 bytes ([RFC1323]). This small check will
scoped range. This mitigation reduces but does not eliminate the reduce the vulnerability to an attacker guessing a valid sequence
ability to generate false segments. It does however reduce the number, since he/she not only must guess the in-window sequence
probability that invalid data will be injected. number, but also guess a proper ACK value within 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 will be injected.
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 9 exchange. This concern is discussed in Section 9.
6. ACK throttling 6. 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
ACK's that can be sent out in a given interval. For example, in ACK's that can be sent out in a given interval. For example, in
any 5 second window, no more than 10 challenge ACK's should be any 5 second window, no more than 10 challenge ACK's should be
sent. sent.
2) The values for both the time and number of ACK's SHOULD be tunable 2) The values for both the time and number of ACK's 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 mechanism implemented in have been obtained from the RST throttling mechanism implemented in
some OS's. Also note that no timer is needed to implement the above some OS's. Also note that no timer is needed to implement the above
mechanism, instead a timestamp and a counter can be used. mechanism, instead a timestamp and a counter can be used.
An implementation SHOULD include a ACK throttling mechanism to be An implementation SHOULD include an ACK throttling mechanism to be
conservative. Currently there is no known bad behavior that can be conservative. Currently there is no known bad behavior that can be
attributed to the lack of ACK throttling, but as a general principle, attributed to the lack of ACK throttling, but as a general principle,
if ever invoked, something incorrect is occurring and such a if ever invoked, something incorrect is occurring and such a
mechanism will act as a failsafe that protects both the sender and mechanism will act as a failsafe that protects both the sender and
the network. the network.
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 set
a higher value thus allowing more RST's to be processed in any given a higher value thus allowing more RST's to be processed in any given
time period. 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.
7. Backward Compatibility and Other considerations 7. Backward Compatibility and Other considerations
1) 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.
2) There is a corner scenario in the above mitigations which will There is a corner scenario in the above mitigations which will
require more than one round trip time to successfully abort the require more than one round trip time to successfully abort the
connection as per the figure below. This scenario is similar to connection as per the figure below. This scenario is similar to the
the one in which the original RST was lost in the network. one in which 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)
... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE ... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE
4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A 4.a. ESTAB <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK> b. ESTAB --> <SEQ=101><ACK=500><CTL=ACK>
c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED
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
3) 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 connection need to have the fix. Although, having the mitigations at
at one end might prevent that end from being exposed to the one end might prevent that end from being exposed to the attack, the
attack, the connection is still vulnerable at the other end. connection is still vulnerable at the other end.
8. Middlebox considerations 8. Middlebox considerations
8.1. Middlebox that resend RST's 8.1. Middlebox that resend RST's
Consider a middlebox M-B tracking connection between two TCP endhosts Consider a middlebox M-B tracking connections between two TCP
E-A and E-C. If E-C sends a RST with a sequence number that is endhosts E-A and E-C. If E-C sends a RST with a sequence number that
within the window but not an exact match to reset the connection and is within the window but not an exact match to reset the connection
M-B does not have the fix recommended in this document, it may clear and M-B does not have the fix recommended in this document, it may
the connection and forward the RST to E-A saving an incorrect clear 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 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 design does that if such a case exists in the Internet, the middle box design
not comply to [RFC0793]. [RFC0793] dictates that the sequence number does not comply to [RFC0793]. [RFC0793] dictates that the sequence
of a RST has to be derived from the acknowledgment number of the number of a RST has to be derived from the acknowledgment number of
incoming ACK segment. It is outside the scope of this document to the incoming ACK segment. It is outside the scope of this document
suggest mitigations to the ill-behaved middleboxes. to suggest mitigations to 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 till until it is confirmed that the connection has been
cleared at E-A. cleared at E-A.
8.2. Middleboxes that advance sequence numbers 8.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 a middlebox (M-B) sends a RST that computes its sequence number as the
sum of the ack field in the ACK and the window advertised by the ACK sum of the ack field in the ACK and the window advertised by the ACK
that was sent by E-A to challenge the RST as depicted below. The 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 is due difference in the sequence numbers between step 1 and 2 below is due
to data lost in the network. 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
skipping to change at page 19, line 40 skipping to change at page 19, line 40
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. more than note this and related issues.
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 consideration that should be noted is a reflector attack is Another consideration that should be noted is, a reflector attack is
possible with the required RST/SYN mitigation techniques. In this possible with the required RST/SYN mitigation techniques. In this
attack an off-path attacker can cause a victim to send an ACK segment attack, an off-path attacker can cause a victim to send an ACK
for each spoofed RST/SYN segment that lies within the current receive segment for each spoofed RST/SYN segment that lies within the current
window of the victim. It should be noted, however, that this does receive window of the victim. It should be noted, however, that this
not cause any amplification since the attacker must generate a does not cause any amplification since the attacker must generate a
segment for each one that the victim will generate. segment for each one that the victim will generate.
10. IANA Considerations 10. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
11. Contributors 11. 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
skipping to change at page 23, line 44 skipping to change at page 23, line 44
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP". Vulnerability Issues in TCP".
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks, [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks,
Presentation at 2004 CanSecWest Presentation at 2004 CanSecWest
http://www.cansecwest.com/archives.html". http://www.cansecwest.com/archives.html".
Authors' Addresses Authors' Addresses
Anantha Ramaiah Anantha Ramaiah
Editor Editor
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 26, line 7 skipping to change at page 26, line 7
Editor Editor
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 53 change blocks. 
127 lines changed or deleted 134 lines changed or added

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