draft-ietf-tcpm-tcpsecure-10.txt   draft-ietf-tcpm-tcpsecure-11.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 Cisco Systems Updates: 793 (if approved) Cisco Systems
Expires: January 10, 2009 July 9, 2008 Intended status: Standards Track November 3, 2008
Expires: May 7, 2009
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-10.txt draft-ietf-tcpm-tcpsecure-11.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 36
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 January 10, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
TCP has historically been considered protected against spoofed off- TCP has historically been considered protected against spoofed off-
path packet injection attacks by relying on the fact that it is 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 [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 to be addresses and ports which makes it far easier for the 4-tuple
(4-tuple is the same as the socket pair mentioned in [RFC0793]) 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 inject a TCP segment with the RST bit set, the SYN bit set or data
systematically guessing the sequence number of the spoofed segment to into a TCP connection by systematically guessing the sequence number
be in the current receive window. This can cause the connection to of the spoofed segment to be in the current receive window. This can
either abort or possibly cause data corruption. This document cause the connection to abort or cause data corruption. This
specifies small modifications to the way TCP handles inbound segments document specifies small modifications to the way TCP handles inbound
that can reduce the chances of a successful attack. segments that can reduce the chances of a successful attack.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 4 1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 5
1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 1.3. 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 . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15 6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15
7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16 7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Backward Compatibility and Other considerations . . . . . . . 17 8. Backward Compatibility and Other considerations . . . . . . . 17
9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18 9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18 9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18
9.2. Middleboxes that advance sequence numbers . . . . . . . . 18 9.2. Middleboxes that advance sequence numbers . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 4, line 11 skipping to change at page 4, line 11
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 27
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 TCP spoofing attacks, which are seen in the Internet now common. The off-path TCP spoofing attacks, which are seen in the
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 (commonly referred to as a 4-tuple value). The and destination ports (referred to as a 4-tuple value in this
targeted TCP endpoint will then associate such a packet with an document). The targeted TCP endpoint will then associate such a
existing TCP connection. It needs to be noted that, guessing this packet with an existing TCP connection. It needs to be noted that,
4-tuple value is not always easy for an attacker. But there are some guessing this 4-tuple value is not always easy for an attacker. But
applications (e.g. BGP [RFC4271]) that have a tendency to use the there are some applications (e.g. BGP [RFC4271]) that have a
same set(s) of ports on either endpoint making the odds of guessing tendency to use the same set(s) of ports on either endpoint making
correctly the 4-tuple value much easier. When an attacker is the odds of correctly guessing the 4-tuple value much easier. When
successful in guessing the 4-tuple value, one of three types of an attacker is successful in guessing the 4-tuple value, one of three
injection attacks may be waged against a long-lived connection. types of 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. RST segment here refers to a TCP
segment with 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 so tear down the connection
state. 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. the contents of the transmission. DATA segment here refers to 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 draft
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 end points 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 one
of the 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 aborting the connection. One of the connection state, effectively aborting the connection. One of the
important things to note is that, for the attack to succeed the RST 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 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
skipping to change at page 5, line 48 skipping to change at page 6, line 5
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 the TCP's segment processing rules can be A slight enhancement to TCP's segment processing rules can be made
made which makes such an attack much more difficult to accomplish. which makes such an attack much more difficult to accomplish. If the
If the receiver examines the incoming RST segment and validates that receiver examines the incoming RST segment and validates that the
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 and
DATA). DATA).
1.3. Attack probabilities 1.3. Attack probabilities
Every application has control of a number of factors that effect Every application has control of a number of factors that drastically
drastically 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]). ([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 at. Thus this value
normally provides no additional protection. normally provides no additional protection.
skipping to change at page 6, line 44 skipping to change at page 6, line 49
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. packets is required. In other words, the mean number of tries needed
to inject a RST segment is (2^31/window) rather than the 2^31 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
skipping to change at page 7, line 34 skipping to change at page 7, line 40
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.
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 draft [RFC4953] the existing techniques, please refer to [RFC4953]
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
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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, this document requires that implementations SHOULD implement
the following steps in place of those specified in [RFC0793] (as the following steps in place of those specified in [RFC0793] (as
listed above). listed above).
A) 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.
B) 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.
C) 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 previous text, quoted from [RFC0793] pg 37 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.
skipping to change at page 11, line 29 skipping to change at page 11, line 29
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:
A) 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 end sender is challenged to confirm the By sending an ACK, the remote end sender is challenged to confirm the
loss of the previous connection and the request to start a new loss of the previous connection and the request to start a new
skipping to change at page 13, line 21 skipping to change at page 13, line 21
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 ((SND.UNA-
(2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above (2^31-1)) <= SEG.ACK <= SND.NXT). The (2^31 - 1) in the above
inequality takes into account the fact that comparisons on TCP inequality takes into account the fact that comparisons on TCP
sequence and acknowledgement numbers is done using the modulo 32 bit sequence and acknowledgement 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 ((2^32 / RCV.WND) * 2). 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/
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 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 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.
b) The sender will send enough data to the peer which will move 2) The sender will send enough data to the peer which 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
skipping to change at page 14, line 8 skipping to change at page 14, line 13
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 which 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 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" This mitigation makes the ACK ACK, drop the segment, and return." This mitigation makes the ACK
check more stringent since any ACK < SND.UNA wouldn't be accepted, check more stringent since any ACK < SND.UNA wouldn't be accepted,
instead only ACK's which are in the range ((SND.UNA - MAX.SND.WND) <= instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <=
SEG.ACK <= SND.NXT) gets through. SEG.ACK <= SND.NXT) gets 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
skipping to change at page 15, line 8 skipping to change at page 15, line 8
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. SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The
There was no strong technical reasoning for choosing the Data reason that DATA mitigation is tagged as MAY, even though it
mitigation as MAY. It was perceived from some quarters that data increased the TCP robustness in general is because, the DATA
mitigation, even though increased the TCP robustness in general, is injection is perceived to be more difficult (twice less unlikely)
not as elegant as the solutions offered for RST and SYN counterparts. when compared to RST and SYN counterparts. However, it needs to be
However, it needs to be noted that all the suggested mitigations noted that all the suggested mitigations improve TCP's robustness in
improve TCP's robustness in general and hence the choice of general and hence the choice of implementing some or all mitigations
implementing some or all mitigations recommended in the document is recommended in the document is purely left to the implementer.
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.
skipping to change at page 16, line 25 skipping to change at page 16, line 25
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 implement
the above mechanism, instead a timestamp and a counter can be used. 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. Currently there is no known bad behavior that can be conservative. While we have not encountered a case where the lack of
attributed to the lack of ACK throttling, but as a general principle, ACK throttling can be exploited, as a fail-safe mechanism we
if ever invoked, something incorrect is occurring and such a recommend it's use. An implementation may take an excessive number
mechanism will act as a failsafe that protects both the sender and of invocations of the throttling mechanism as an indication that
the network. network 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 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.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
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 design that if such a case exists in the Internet, the middle box is
does not comply to [RFC0793]. [RFC0793] dictates that the sequence generating packets a conformant TCP endpoint would not generate.
number of a RST has to be derived from the acknowledgment number of [RFC0793] dictates that the sequence number of a RST has to be
the incoming ACK segment. It is outside the scope of this document derived from the acknowledgment number of the incoming ACK segment.
to suggest mitigations to the ill-behaved middleboxes. It is outside the scope of this document 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.
9.2. Middleboxes that advance sequence numbers 9.2. Middleboxes that advance sequence numbers
skipping to change at page 22, line 19 skipping to change at page 23, line 5
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 the
insight that apart from RSTs, SYNs could also result in formidable insight that apart from RSTs, SYNs could also result in formidable
attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of
Wind River Systems and Xiaodan Tang of QNX Software along with the Wind River Systems and Xiaodan Tang of QNX Software along with the
folks above helped in ratifying and testing the interoperability of folks above helped in ratifying and testing the interoperability of
the suggested solutions. the suggested solutions.
ACK throttling was introduced to this document by combining the
suggestions from the tcpm working group.
13. Acknowledgments 13. 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 and other members of the Joe Touch, Alfred Hoenes, Andre Oppermann and other members of the
tcpm WG for suggestions and comments. tcpm WG for suggestions and comments. ACK throttling was introduced
to this document by combining the suggestions from the tcpm working
group.
14. References 14. References
14.1. Normative References 14.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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
14.2. Informative References 14.2. Informative References
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-03 (work in progress), draft-ietf-tcpm-icmp-attacks-04 (work in progress),
March 2008. October 2008.
[Medina05] [Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet. ACM Evolution of Transport Protocols in the Internet. ACM
Computer Communication Review, 35(2), April 2005. Computer Communication Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
(figure 6)". (figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP". Vulnerability Issues in TCP".
skipping to change at page 25, line 5 skipping to change at page 24, line 47
[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 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[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
 End of changes. 36 change blocks. 
80 lines changed or deleted 88 lines changed or added

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