draft-ietf-tcpm-tcpsecure-05.txt   draft-ietf-tcpm-tcpsecure-06.txt 
Network Working Group R. Stewart TCP Maintenance and Minor A. Ramaiah
Extensions Working Group R. Stewart
Internet-Draft M. Dalal Internet-Draft M. Dalal
Expires: December 17, 2006 Editor Intended status: Standards Track Editor
June 15, 2006 Expires: May 11, 2007 November 7, 2006
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-05.txt draft-ietf-tcpm-tcpsecure-06.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 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2006. This Internet-Draft will expire on May 11, 2007.
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 [I-D.touch-tcp-antispoof] provide charts which Note: Both [SITW] and [I-D.ietf-tcpm-tcp-antispoof] provide charts
can give the reader an idea as to the time it takes to penetrate an which can give the reader an idea as to the time it takes to
unprotected system. penetrate an unprotected system.
Many of these long term TCP applications tend to have predictable IP Many of these long term TCP applications tend to have predictable IP
addresses and ports which makes it far easier for the 4-tuple to be addresses and ports which makes it far easier for the 4-tuple to be
guessed. Having guessed the 4-tuple correctly, an attacker can guessed. Having guessed the 4-tuple correctly, an attacker can
inject a RST, SYN or DATA segment into a TCP connection by carefully inject a RST, SYN or DATA segment into a TCP connection by carefully
crafting the sequence number of the spoofed segment to be in the crafting the sequence number of the spoofed segment to be in the
current receive window. This can cause the connection to either current receive window. This can cause the connection to either
abort or possibly cause data corruption. This document requires abort or possibly cause data corruption. This document 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.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 23 13.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
TCP [RFC0793] is widely deployed and the most common reliable end to TCP [RFC0793] is widely deployed and the most common reliable end to
end transport protocol used for data communication in todays end transport protocol used for data communication in 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.
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) so and destination ports (commonly referred to as a 4-tuple value). The
that a target TCP endpoint can associate such a packet with an targeted TCP endpoint will then associate such a packet with an
existing TCP connection. Note that in and of itself guessing this existing TCP connection. Note that in and of itself guessing this
4-tuple value is not always easy for an attacker. But there are some 4-tuple value is not always easy for an attacker. But there are some
applications (e.g. BGP [RFC1771]) that may have a tendency to use applications (e.g. BGP [RFC1771]) that may have a tendency to use
the same set(s) of ports on either endpoint making the odds of the same set(s) of ports on either endpoint making the odds of
guessing correctly the 4-tuple value much easier. When an attacker guessing correctly the 4-tuple value much easier. When an attacker
is successful in guessing the 4-tuple value, one of three types of is successful in guessing the 4-tuple value, one of three types of
injection attacks may be waged against a long-lived connection. injection attacks may be waged against a long-lived connection.
RST - Where an attacker injects a reset segment hoping to cause the RST - Where an attacker injects a RST segment hoping to cause the
connection to be torn down. connection to be torn down.
SYN - Where an attacker injects a 'SYN' hoping to cause the receiver SYN - Where an attacker injects a 'SYN' hoping to cause the receiver
to believe the peer has restarted and so tear down the connection to believe the peer has restarted and so tear down the connection
state. state.
DATA - Where an attacker tries to inject a "DATA" segment to corrupt DATA - Where an attacker tries to inject a "DATA" segment to corrupt
the contents of the transmission. the contents of the transmission.
1.1. The RESET attack 1.1. 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
addresses the issue. For this attack the goal is to cause one of the addresses the issue. For this attack the goal is to cause one of the
two endpoints of the connection to incorrectly tear down the two endpoints of the connection to incorrectly tear down the
connection state, effectively closing the connection. To do this the connection state, effectively closing the connection. To do this 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
number will be a starting point for a series of guesses to attempt number will be a starting point for a series of guesses to attempt
skipping to change at page 7, line 5 skipping to change at page 7, line 5
connection that lasts only a few brief packets, as often is the case connection that lasts only a few brief packets, as often is the case
for web traffic, would not be subject to such an attack since the for web traffic, would not be subject to such an attack since the
connection may not be established long enough for an attacker to connection may not be established long enough for an attacker to
generate enough traffic. However there is a set of applications such generate enough traffic. However there is a set of applications such
as BGP [RFC1771] which is judged to be potentially most affected by as BGP [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 also needs to be emphasized that for applications like BGP which
use the TCP MD5 option [RFC2385], can make the attacks described in
this specification much harder to accomplish.
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 [I-D.touch-tcp-antispoof] refer to draft [I-D.ietf-tcpm-tcp-antispoof]
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. TCP document are to be interpreted as described in [RFC2119]. TCP
terminology should be interpreted as described in [RFC0793]. terminology should be interpreted as described in [RFC0793].
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 particularly by guessing "in-window" sequence numbers. In particular [RFC0793],
[RFC0793], p37, states the following: 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
[RFC0793] currently requires handling of a segment with the RST bit [RFC0793] currently requires handling of a segment with the RST bit
skipping to change at page 10, line 39 skipping to change at page 10, line 39
window but NOT the exact expected sequence number) when the window but NOT the exact expected sequence number) when the
challenge ACK is sent back, it will no longer have the challenge ACK is sent back, it will no longer have the
transmission control block (TCB) related to this connection and transmission control block (TCB) related to this connection and
hence as per [RFC0793], the remote peer will send a second RST hence as per [RFC0793], the remote peer will send a second RST
back. The sequence number of the second RST is derived from the back. The sequence number of the second RST is derived from the
acknowledgment number of the incoming ACK. This second RST if it acknowledgment number of the incoming ACK. This second RST if it
reaches the sender will cause the connection to be aborted since reaches the sender will cause the connection to be aborted since
the sequence number would now be an exact match. the sequence number would now be an exact match.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is detailed in exchange. This concern is discussed in Section 9
4. Blind reset attack using the SYN bit 4. Blind reset attack using the SYN bit
4.1. Description of the attack 4.1. Description of the attack
Analysis of the reset attack using the RST bit, highlights another Analysis of the reset attack using the RST bit, highlights another
possible avenue for a blind attacker using a similar set of sequence possible avenue for a blind attacker using a similar set of sequence
number guessing. Instead of using the RST bit an attacker can use number guessing. Instead of using the RST bit an attacker can use
the SYN bit with the exact same semantics to tear down a connection. the SYN bit with the exact same semantics to tear down a connection.
skipping to change at page 11, line 52 skipping to change at page 11, line 52
send a RST segment back with the sequence number derived from the ACK send a RST segment back with the sequence number derived from the ACK
field that caused the RST. field that caused the RST.
This RST will confirm that the remote TCP endpoint has indeed closed This RST will confirm that the remote TCP endpoint has indeed closed
the previous connection. Upon receipt of a valid RST, the local TCP the previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to re- should then rely on SYN retransmission from the remote end to re-
establish the connection. establish the connection.
A spoofed SYN, on the other hand, will then have generated an A spoofed SYN, on the other hand, will then have generated an
additional ACK which the peer will discarded as a duplicate ACK and additional ACK which the peer will discard as a duplicate ACK and
will not affect the established connection. will not affect the established connection.
Note that this mitigation does leave one corner case un-handled which Note that this mitigation does leave one corner case un-handled which
will prevent the reset of a connection when it should be reset (i.e. will prevent the reset of a connection when it should be reset (i.e.
it is a non spoofed SYN wherein a peer really did restart). This it is a non spoofed SYN wherein a peer really did restart). This
problem occurs when the restarting host chooses the exact same IP problem occurs when the restarting host chooses the exact same IP
address and port number that it was using prior to its restart. By address and port number that it was using prior to its restart. By
chance the restarted host must also choose an initial sequence number chance the restarted host must also choose an initial sequence number
of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in of exactly (RCV.NXT - 1) of the remote TCP endpoint that is still in
the established state. Such a case would cause the receiver to the established state. Such a case would cause the receiver to
skipping to change at page 12, line 25 skipping to change at page 12, line 25
would be within the outgoing connections window the inbound ACK would would be within the outgoing connections window the inbound ACK would
be acceptable, and the sender of the SYN will do nothing with the be acceptable, and the sender of the SYN will do nothing with the
response ACK. This sequence will continue as the SYN sender response ACK. This sequence will continue as the SYN sender
continually times out and retransmits the SYN until such time as the continually times out and retransmits the SYN until such time as the
connection attempt fails. connection attempt fails.
This corner case is a result of the [RFC0793] specification and is This corner case is a result of the [RFC0793] specification and is
not introduced by these new requirments. not introduced by these new requirments.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is detailed in Section 9 exchange. This concern is discussed in Section 9
5. Blind data injection attack 5. Blind data injection attack
5.1. Description of the attack 5.1. Description of the attack
A third type of attack is also highlighted by both the RST and SYN A third type of attack is also highlighted by both the RST and SYN
attacks. It is also possible to inject data into a TCP connection by attacks. It is also possible to inject data into a TCP connection by
simply guessing the a sequence number within the current receive simply guessing 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
next segment to send. In other words an ACK value is acceptable if next segment to send. In other words an ACK value is acceptable if
it is (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). This means that an it is (SND.UNA-(2^31-1)) <= SEG.ACK <= SND.NXT). 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 successfully injecting data into a number so that the chances successfully injecting data into a
connection are 1 in ((2^32 / RCV.WND) * 2). connection are 1 in ((2^32 / RCV.WND) * 2).
When an attacker successfully injects data into a connection the data When an attacker successfully injects data into a connection the data
will sit in the receiver's re-assembly queue until the peer sends will sit in the receiver's re-assembly queue until the peer sends
enough data to bridge the gap between the RCV.NXT value and the enough data to bridge the gap between the RCV.NXT value and the
injected data. At that point one of two things will occur either: injected data. At that point one of two things will occur :
a) An packet war will ensue with the receiver indicating that it has a) A packet war will ensue with the receiver indicating that it has
received data up until RCV.NXT (which includes the attackers data) received data up until RCV.NXT (which includes the attackers data)
and the sender sending an ACK with an acknowledgment number less and the sender sending an ACK with an acknowledgment number less
than RCV.NXT. than RCV.NXT.
b) The sender will send enough data to the peer which will move b) 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
skipping to change at page 14, line 13 skipping to change at page 14, line 13
has ever received from its peer. This window may be a scaled value has ever received from its peer. This window may be a scaled value
i.e. the value may be larger than 65,535 bytes ([RFC1323]). This i.e. the value may be 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 must he/she guess the sequence valid sequence number since not only must he/she guess the sequence
number in window, but must also guess a proper ACK value within a number in window, but must also guess a proper ACK value within a
scoped range. This mitigation reduces but does not eliminate the scoped range. This mitigation reduces but does not eliminate the
ability to generate false segments. It does however reduce the ability to generate false segments. It does however 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 discussed in Section 9
6. ACK throttling 6. ACK throttling
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, an ACK throttling mechanism SHOULD be implemented as challenge ACKs, an ACK throttling mechanism is suggested as follows :
follows:
1) In any 5 second window, no more than 10 challenge ACK's should be 1) The system administrator can configure the number of challenge
ACK's that can be sent out in a given interval. For example, in
any 5 second window, no more than 10 challenge ACK's should be
sent. sent.
2) The values for both the time and number of ACK's MUST be tunable 2) The values for both the time and number of ACK's SHOULD be tunable
by the system administrator to accommodate different perceived by the system administrator to accommodate different perceived
threats. levels of threat and/or system resources.
It should be noted that These numbers are empirical in nature and It should be noted that these numbers are empirical in nature and
have been obtained from the RST throttling mechanism implemented in have been obtained from the RST throttling mechanism implemented in
some OS's. Also note that no timer is needed to implement the above some OS's. Also note that no timer is needed to implement the above
mechanism, instead a timestamp and a counter can be used. mechanism, instead a timestamp and a counter can be used.
An implementation SHOULD include a ACK throttling mechanism to be An implementation SHOULD include 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 occurring and such a if ever invoked, something incorrect is occurring and such a
mechanism will act as a failsafe that protects both the sender and mechanism will act as a failsafe that protects both the sender and
the network. the network.
skipping to change at page 17, line 12 skipping to change at page 17, line 12
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 required here, it may clear the connection M-B does not have the fix recommended in this document, it may clear
and forward the RST to E-A saving an incorrect sequence number. If the connection and forward the RST to E-A saving an incorrect
E-A does not have the fix it will clear the connection and everything sequence number. If E-A does not have the fix the connection would
will be fine. However if E-A does have the required fix above, it get cleared as required. However if E-A does have the required fix,
will send a challenge ACK to E-C. M-B, being a middlebox, may it will send a challenge ACK to E-C. M-B, being a middlebox, may
intercept this ACK and resend the RST on behalf of E-C with the old intercept this ACK and resend the RST on behalf of E-C with the old
sequence number. This RST, will again, not acceptable and may sequence number. This RST, will again, not 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 The above situation may result in a RST/ACK war. However we believe
such a case exists in the Internet the middle box design itself is that if such a case exists in the Internet the middle box design does
flawed. Consider a similar scenario where the RST from M-B to E-A not comply to [RFC0793]. [RFC0793] dictates that the sequence number
gets lost, E-A will continue to hold the connection and E-A might of a RST has to be derived from the acknowledgment number of the
send an ACK an arbitrary time later after the connection state was incoming ACK segment. It is outside the scope of this document to
destroyed at M-B. For this case, M-B will have to cache the RST for suggest mitigations to the ill-behaved middleboxes.
an arbitrary amount of time till until it is confirmed that the
connection has been cleared at E-A. Further, this is not compliant Consider a similar scenario where the RST from M-B to E-A gets lost,
to [RFC0793] which dictates that the sequence number of a RST has to E-A will continue to hold the connection and E-A might send an ACK an
be derived from the acknowledgment number of the incoming ACK arbitrary time later after the connection state was destroyed at M-B.
segment. 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
cleared at E-A.
8.2. Middleboxes that advance sequence numbers 8.2. Middleboxes that advance sequence numbers
Some middleboxes may compute RST sequence numbers at the higher end Some middleboxes may compute RST sequence numbers at the higher end
of the acceptable window. The scenario is the same as the earlier of the acceptable window. The scenario is the same as the earlier
case, but in this case instead of sending the cached RST, the case, but in this case instead of sending the cached RST, the
middlebox (M-B) sends a RST that computes its sequence number as a middlebox (M-B) sends a RST that computes its sequence number as 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 19, line 8 skipping to change at page 19, line 8
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. Security Considerations 9. Security Considerations
These changes to the TCP state machine do NOT protect an These changes to the TCP state machine do NOT protect an
implementation from on-path attacks. Situations where an on-path implementation from on-path attacks. It also needs to be emphasized
attack is a threat should be mitigated by the use of IPSEC-AH that while mitigations within this document make it harder for off-
[RFC4302] and IPSEC-ESP [RFC4303]. It should also be emphasised that path attackers to inject segments, it does NOT make it impossible.
while mitigations within this document make it harder for off-path The only way to fully protect a TCP connection from both on and off
attackers to inject segments, it does NOT make it impossible. The path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP
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]. [RFC4303].
implementers also should be aware that the attacks detailed in this
specification are not the only attacks available to an off-path
attacker and that the counter measures described herein are not a
comprehensive defense against such attacks.
In particular, administrators should be aware that forged ICMP
messages provide off-path attackers the opportunity to disrupt
connections or degrade service. Such attacks may be subject to even
less scrutiny than the TCP attacks addressed here, especially in
stacks not tuned for hostile environments. It is important to note
that some ICMP messages, validated or not, are key to the proper
function of TCP. Those ICMP messages used to properly set the path
maximum transmission unit are the most obvious example. There are a
variety of ways to choose which, if any, ICMP messages to trust in
the presence of off-path attackers and choosing between them depends
on the assumptions and guarantees developers and administrators can
make about their network. This specification does not attempt to do
more than note this and related issues.
In any case, this RFC details only part of a complete strategy to
prevent off-path attackers from disrupting services that use TCP.
Administrators and implementers should consider the other attack
vectors and determine appropriate mitigations in securing their
systems.
Another consideration that should be noted is a reflector attack is Another consideration that should be noted is a reflector attack is
possible with the required RST/SYN mitigation techniques. In this possible with the required RST/SYN mitigation techniques. In this
attack an off-path attacker can cause a victim to send an ACK segment attack an off-path attacker can cause a victim to send an ACK segment
for each spoofed RST/SYN segment that lies within the current receive for each spoofed RST/SYN segment that lies within the current receive
window of the victim. It should be noted, however, that this does window of the victim. It should be noted, however, that this does
not cause any amplification since the attacker must generate a not cause any amplification since the attacker must generate a
segment for each one that the victim will generate. segment for each one that the victim will generate.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 23, line 23 skipping to change at page 23, line 23
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
13.2. Informative References 13.2. Informative References
[I-D.touch-tcp-antispoof] [I-D.ietf-tcpm-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks", Touch, J., "Defending TCP Against Spoofing Attacks",
draft-touch-tcp-antispoof-00 (work in progress), draft-ietf-tcpm-tcp-antispoof-05 (work in progress),
July 2004. October 2006.
[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".
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995. (BGP-4)", RFC 1771, March 1995.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
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.
[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
Editor
170 Tasman Drive
San Jose, CA 95134
USA
Phone: +1 (408) 525-6486
Email: ananth@cisco.com
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
Phone: Phone: +1 (803) 345-0369
Email: rrs@cisco.com Email: rrs@cisco.com
Mitesh Dalal Mitesh Dalal
Editor Editor
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1-408-853-5257 Phone: +1 (408) 853-5257
Email: mdalal@cisco.com Email: mdalal@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 25, line 29 skipping to change at page 26, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 36 change blocks. 
75 lines changed or deleted 117 lines changed or added

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