draft-ietf-tcpm-tcpsecure-04.txt   draft-ietf-tcpm-tcpsecure-05.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Dalal Internet-Draft M. Dalal
Expires: August 17, 2006 Editor Expires: December 17, 2006 Editor
February 13, 2006 June 15, 2006
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-04.txt draft-ietf-tcpm-tcpsecure-05.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 34 skipping to change at page 1, line 34
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 August 17, 2006. This Internet-Draft will expire on December 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
A recent study indicates that some types of TCP connections have an A recent study indicates that some types of TCP connections have an
increased vulnerability to spoofed packet injection attacks than increased vulnerability to spoofed packet injection attacks than
previously believed [SITW]. TCP has historically been considered previously believed [SITW]. TCP has historically been considered
protected against spoofed packet injection attacks by relying on the protected against spoofed packet injection attacks by relying on the
fact that it is difficult to guess the 4-tuple (the source and fact that it is difficult to guess the 4-tuple (the source and
destination IP addresses and the source and destination ports) in destination IP addresses and the source and destination ports) in
combination with the 32 bit sequence number(s). A combination of combination with the 32 bit sequence number(s). A combination of
increasing window sizes and applications using a longer term increasing window sizes and applications using a longer term
connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have connections (e.g. H-323 or Border Gateway Protocol [RFC1771]) have
left modern TCP implementation more vulnerable to these types of left modern TCP implementation more vulnerable to these types of
spoofed packet injection attacks. spoofed packet injection attacks.
Note: Both [SITW] and [DTASA] provide charts which can give the Note: Both [SITW] and [I-D.touch-tcp-antispoof] provide charts which
reader an idea as to the time it takes to penetrate an unprotected can give the reader an idea as to the time it takes to penetrate an
system. 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 carefly 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 proposes abort or possibly cause data corruption. This document requires
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 probability of such an attack.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. The RESET attack . . . . . . . . . . . . . . . . . . . . . 4 1.1. The RESET attack . . . . . . . . . . . . . . . . . . . . . 4
1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 5 1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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
6. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 15 6. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Backward Compatibility and Other considerations . . . . . . . 16 7. Backward Compatibility and Other considerations . . . . . . . 16
8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 17 8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 17 8.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 17
8.2. Middleboxes that advance sequence numbers . . . . . . . . 17 8.2. Middleboxes that advance sequence numbers . . . . . . . . 17
9. Interoperability Testing . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 25
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 todays end transport protocol used for data communication in todays
Internet. Yet when it was defined over 20 years ago the Internet, as Internet. Yet when it was defined over 20 years ago the Internet, as
we know it, was a different place lacking many of the threats that we know it, was a different place lacking many of the threats that
are now common. TCP spoofing attacks are one such attack that are are now common. TCP spoofing attacks are one such attack that are
seen on the Internet today. seen on the Internet today.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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. The RESET attack
Focusing upon the RESET attack, let's examine this attack in more Focusing upon the RESET attack, let's examine this attack in more
detail to get an overview as to how it works and how this document detail to get an overview as to how it works and how this document
proposes addressing the issue. For this attack the goal is to cause addresses the issue. For this attack the goal is to cause one of the
one of the two endpoints of the connection to incorrectly tear down two endpoints of the connection to incorrectly tear down the
the connection state, effectively closing the connection. To do this connection state, effectively closing the connection. To do this the
the attacker needs to have or guess several pieces of information attacker needs to have or guess several pieces of information
(namely): (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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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. Without mitigation
[SITW] has shown that such an attack is much easier to accomplish [SITW] has shown that such an attack is much easier to accomplish
then previously assumed. This is because RFC793 [RFC0793] specifies then previously assumed. This is because [RFC0793] specifies that
that any RST within the current window is acceptable. any RST within the current window is acceptable.
A slight modification to the TCP state machine can be made which A slight modification to the TCP state machine can be made which
makes such an attack much more difficult to accomplish. If the makes such an attack much more difficult to accomplish. If the
receiver examines the incoming RST segment and validates that the receiver examines the incoming RST segment and validates that the
sequence number exactly matches the sequence number that is next sequence number exactly matches the sequence number that is next
expected, then such an attack becomes much more difficult then expected, then such an attack becomes much more difficult then
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 state machine
to mitigate all three types of attacks (RST, SYN and DATA). to mitigate all three types of attacks (RST, SYN and DATA).
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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 [RFC1771] 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 should be noted that there are existing alternative protection It should be noted that there are existing alternative protection
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 [DTASA] refer to draft [I-D.touch-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 [RFC2119]. document are to be interpreted as described in [RFC2119]. TCP
TCP terminology should be interpreted as described in RFC793 terminology should be interpreted as described in [RFC0793].
[RFC0793].
3. Blind reset attack using the RST bit 3. Blind reset attack using the RST bit
3.1. Description of the attack 3.1. Description of the attack
As described in the introduction, it is possible for an attacker to As described in the introduction, it is possible for an attacker to
generate a "RST" segment that would be acceptable to a TCP receiver generate a "RST" segment that would be acceptable to a TCP receiver
by guessing a "in-window" sequence numbers. In particulary RFC 793, by guessing a "in-window" sequence numbers. In particularly
p37, states the following: [RFC0793], p37, states the following:
"In all states except SYN-SENT, all reset (RST) segments are "In all states except SYN-SENT, all reset (RST) segments are
validated by checking their SEQ-fields [sequence numbers]. A reset validated by checking their SEQ-fields [sequence numbers]. A reset
is valid if its sequence number is in the window. In the SYN-SENT is valid if its sequence number is in the window. In the SYN-SENT
state (a RST received in response to an initial SYN), the RST is state (a RST received in response to an initial SYN), the RST is
acceptable if the ACK field acknowledges the SYN." acceptable if the ACK field acknowledges the SYN."
3.2. Mitigation 3.2. Mitigation
RFC793 [RFC0793] currently requires handling of a segment with the [RFC0793] currently requires handling of a segment with the RST bit
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 proposes the following changes should be made Instead, this document requires that implementations MUST perform the
to provide protection against such an attack. following steps in place of those specified in [RFC0793](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 9, line 48 skipping to change at page 10, line 4
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
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. segment and stop processing the incoming packet further.
The previous text,quoted from RFC793 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 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.
skipping to change at page 10, line 30 skipping to change at page 10, line 32
With the above slight change to the TCP state machine, it becomes With the above slight change to the TCP state machine, it becomes
much harder for an attacker to generate an acceptable reset 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 RFC793 [RFC0793], the remote peer will send a second hence as per [RFC0793], the remote peer will send a second RST
RST back. The sequence number of the second RST is derived from back. The sequence number of the second RST is derived from the
the acknowledgment number of the incoming ACK. This second RST if acknowledgment number of the incoming ACK. This second RST if it
it reaches the sender will cause the connection to be aborted reaches the sender will cause the connection to be aborted since
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 detailed in exchange. This concern is detailed in
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 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 symantics to tear down a connection. the SYN bit with the exact same semantics to tear down a connection.
4.2. Mitigation 4.2. Mitigation
RFC793 [RFC0793] currently requires handling of a segment with the [RFC0793] currently requires handling of a segment with the SYN bit
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, changing the handling of the SYN in the synchronized state Instead, the handling of the SYN in the synchronized state MUST be
to the following will mitigate this attack: 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 21 skipping to change at page 12, line 21
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 RFC793 [RFC0793] specification This corner case is a result of the [RFC0793] specification and is
and is not introduced by the proposed mitigations. 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 detailed in Section 10 exchange. This concern is detailed 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 the a sequence number within the current receive
window of the victim. The ACK value of any data segment is window of the victim. The ACK value of any data segment is
considered valid as long as it does not acknowledge data ahead of the considered valid as long as it does not acknowledge data ahead of the
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 should be added to any incoming segment. An additional input check MUST be added to any incoming segment. The
The ACK value MUST be acceptable only if it is in the range of ACK value MUST be acceptable only if it is in the range of ((SND.UNA
((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is - MAX.SND.WND) <= SEG.ACK <= SND.NXT).A new state variable
defined as the largest window that the local receiver has ever MAX.SND.WND is defined as the largest window that the local sender
advertised to its peer. This window may be a scaled value i.e. the has ever received from its peer. This window may be a scaled value
value may be larger than 65,535 bytes (RFC1323 [RFC1323]). This i.e. the value may be larger than 65,535 bytes ([RFC1323]). This
small check will greatly reduce the vulnerability to an attacker small check will reduce the vulnerability to an attacker guessing a
guessing a valid sequence number since not only must he/she guess the valid sequence number since not only must he/she guess the sequence
sequence number in window, but must also guess a proper ACK value number in window, but must also guess a proper ACK value within a
within a scoped range. This mitigation reduces but does not scoped range. This mitigation reduces but does not eliminate the
eliminate the ability to generate false segments. It does however ability to generate false segments. It does however reduce the
reduce the probability that invalid data will be injected. 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 detailed in exchange. This concern is detailed in
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 SHOULD be implemented. challenge ACKs, an ACK throttling mechanism SHOULD be implemented as
Suggested values are to send no more than 10 challenge ACKs in a 5 follows:
second window. These numbers are empirical in nature and have been
obtained from the RST throttling mechanism implemented in some OS's.
These value MUST be tunable by a system administrator to accommodate
different preceived threats.
An alternative mechanism may also be used that does not involve an 1) In any 5 second window, no more than 10 challenge ACK's should be
additional timer. In such an implementation a sender would only send sent.
X acks between any window advancment. Note that such a limitation
will not require a timer but must be implemented with care to avoid a 2) The values for both the time and number of ACK's MUST be tunable
deadlock in the face of ack loss. by the system administrator to accommodate different perceived
threats.
It should be noted that These numbers are empirical in nature and
have been obtained from the RST throttling mechanism implemented in
some OS's. Also note that no timer is needed to implement the above
mechanism, instead a timestamp and a counter can be used.
An implementation SHOULD include a ACK throttling mechanism to be An implementation SHOULD include a 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 occuring and such a mechanisn if ever invoked, something incorrect is occurring and such a
will act as a failsafe that protects both the sender and the network. mechanism will act as a failsafe that protects both the sender and
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 thottling 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 proposed mitigation techniques in this document are 1) All of the new required mitigation techniques in this document are
totally compatible with existing (RFC793 [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 proposed mitigations which 2) There is a corner scenario in the above mitigations which will
will require more than one round trip time to successfully abort require more than one round trip time to successfully abort the
the connection as per the figure below. This scenario is similar connection as per the figure below. This scenario is similar to
to the one in which the original RST was lost in the network. the 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 3) 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 mitagations connection need to have the fix. Although, having the mitigations
at one end might prevent that end from being exposed to the at one end might prevent that end from being exposed to the
attack, the connection is still vulnerable at the other end. attack, the 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 connection between two TCP endhosts
E-A and E-C. If E-C sends a RST with a sequence number that is E-A and E-C. If E-C sends a RST with a sequence number that is
within the window but not an exact match to reset the connection and within the window but not an exact match to reset the connection and
M-B does not have the fix proposed here, it may clear the connection M-B does not have the fix required here, it may clear the connection
and forward the RST to E-A saving an incorrect sequence number. If and forward the RST to E-A saving an incorrect sequence number. If
E-A does not have the fix it will clear the connection and everything E-A does not have the fix it will clear the connection and everything
will be fine. However if E-A does have the proposed fix above, it will be fine. However if E-A does have the required fix above, it
will send a challenge ACK to E-C. M-B, being a middlebox, may 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 acceptable and may
trigger a challenge ACK. trigger a challenge ACK.
This may cause a RST/ACK war to occur. However we believe that if This may cause a RST/ACK war to occur. However we believe that if
such a case exists in the Internet the middle box design itself is such a case exists in the Internet the middle box design itself is
flawed. Consider a similar scenario where the RST from M-B to E-A flawed. 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 gets lost, E-A will continue to hold the connection and E-A might
send an ACK an arbitrary time later after the connection state was send an ACK an arbitrary time later after the connection state was
destroyed at M-B. For this case, M-B will have to cache the RST for destroyed at M-B. For this case, M-B will have to cache the RST for
an arbitrary amount of time till until it is confirmed that the an arbitrary amount of time till until it is confirmed that the
connection has been cleared at E-A. Further, this is not compliant connection has been cleared at E-A. Further, this is not compliant
to RFC793 which dictates that the sequence number of a RST has to be to [RFC0793] which dictates that the sequence number of a RST has to
derived from the acknowledgment number of the incoming ACK segment. be derived from the acknowledgment number of the incoming ACK
segment.
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 a
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
skipping to change at page 18, line 4 skipping to change at page 18, line 14
TCP A Middlebox TCP A Middlebox
1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED 1. ESTABLISHED <-- <SEQ=500><ACK=100><CTL=RST> <-- CLOSED
2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 2. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
Although the authors are not aware of an implementation that does the Although the authors are not aware of an implementation that does the
above, it could be mitigated by implementing the ACK throttling above, it could be mitigated by implementing the ACK throttling
mechanism described earlier. mechanism described earlier.
9. Interoperability Testing 9. Security Considerations
Interoperability testing was performed among the operating systems
from Juniper Networks, WindRiver Systems, QNX Software and Cisco
Systems. The following topology was used:
+---------+ +---------+
|TCP A |----+------|Victim B |
+---------+ | +---------+
|
+---------+ |
|Attacker |----+
+---------+
In the above topology B is the unit under test. TCP A is a remote
peer and the attacker workstation is used to generate malicious
spoofed packets.
First, an unmodifed stack had the following tests performed upon it.
A TCP connection was brought up between TCP endpoint A and B. The
4-tuple of the connection was manually populated in the brute force
attack script running on the attacker workstation. The script
crafted TCP packets by using the 4-tuple and by generating sequence
numbers that incremented from 0 to the max permissible sequence
number (2^32 -1) in varying increments of window size of 8K to 64K
(the window size agreed by A and B was larger than 8K, but was
ignored to make the test conservative). The time it took to cause
the connection to reset/corrupt was then recorded.
The test was repeated by then generating sequence numbers that were
window (the one agreed between endpoints A and B) size apart. It was
observed that increasing the window size caused the connection to be
reset faster than with a smaller window. Further, it was also
observed that the initial sequence number (ISN) selection also played
a role in how fast a connection was aborted, with ISN selection in
the lower half of the sequence space aborting sooner than an ISN in
the upper half. Results were also found to be influenced by any
active data transfer on the connection.
Active data transfer sometimes caused the connection to be reset
faster and some other times to slow the attack. The window size
selection at the attacker workstation and how it compares to the
actual window size between A and B was also found to be a factor.
The tests were repeated with a stack that did have the fix and as
expected it became difficult as compared to the previous results to
cause the connection to abort.
[Editors Note: Add time test data gathered at inter-op here!!]
10. Security Considerations These changes to the TCP state machine do NOT protect an
implementation from on-path attacks. Situations where an on-path
attack is a threat should be mitigated by the use of IPSEC-AH
[RFC4302] and IPSEC-ESP [RFC4303]. It should also be emphasised that
while mitigations within this document make it harder for off-path
attackers to inject segments, it does NOT make it impossible. The
only way to fully protect a TCP connection from both on and off path
attacks is the use of both IPSEC-AH [RFC4302] and IPSEC-ESP
[RFC4303].
A reflector attack is possible with the proposed RST/SYN mitigation Another consideration that should be noted is a reflector attack is
techniques. Here an off-path attacker can cause a victim to send an possible with the required RST/SYN mitigation techniques. In this
ACK segment for each spoofed RST/SYN segment that lies within the attack an off-path attacker can cause a victim to send an ACK segment
current receive window of the victim. This, however, does not cause for each spoofed RST/SYN segment that lies within the current receive
any sort of amplification since the attacker must generate a segment window of the victim. It should be noted, however, that this does
for each one that the victim will generate. not cause any amplification since the attacker must generate a
segment for each one that the victim will generate.
11. IANA Considerations 10. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
12. 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
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.
13. Acknowledgments Ack throttling was introduced to this document by combining the
suggestions from the tcpm working group.
12. Acknowledgments
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong and Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
the tcpm WG members for suggestions and comments. Some of the text Joe Touch, and other members of the tcpm WG members for suggestions
in this document has been derived from and comments.
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[DTASA] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
13.2. Informative References
[I-D.touch-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks",
draft-touch-tcp-antispoof-00 (work in progress), draft-touch-tcp-antispoof-00 (work in progress),
July 2004. July 2004.
[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)".
skipping to change at page 25, line 43 skipping to change at page 23, line 50
[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 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
[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.
[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks". [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks,
Presentation at 2004 CanSecWest
http://www.cansecwest.com/archives.html".
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Editor Editor
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
 End of changes. 46 change blocks. 
153 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/