draft-ietf-tcpm-tcpsecure-09.txt   draft-ietf-tcpm-tcpsecure-10.txt 
TCP Maintenance and Minor A. Ramaiah TCP Maintenance and Minor A. Ramaiah
Extensions Working Group R. Stewart Extensions Working Group R. Stewart
Internet-Draft M. Dalal Internet-Draft M. Dalal
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 10, 2008 January 7, 2008 Expires: January 10, 2009 July 9, 2008
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-09.txt draft-ietf-tcpm-tcpsecure-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 10, 2008. This Internet-Draft will expire on January 10, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
TCP has historically been considered protected against spoofed off- TCP has historically been considered protected against spoofed off-
path packet injection attacks by relying on the fact that it is path packet injection attacks by relying on the fact that it is
difficult to guess the 4-tuple (the source and destination IP difficult to guess the 4-tuple (the source and destination IP
addresses and the source and destination ports) in combination with addresses and the source and destination ports) in combination with
the 32 bit sequence number(s). A combination of increasing window the 32 bit sequence number(s). A combination of increasing window
sizes and applications using longer term connections (e.g. H-323 or sizes and applications using longer term connections (e.g. H-323 or
Border Gateway Protocol [RFC4271]) have left modern TCP Border Gateway Protocol [RFC4271]) have left modern TCP
skipping to change at page 3, line 21 skipping to change at page 3, line 21
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
3.1. Description of the attack . . . . . . . . . . . . . . . . 9 3.1. Description of the attack . . . . . . . . . . . . . . . . 9
3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11
4.1. Description of the attack . . . . . . . . . . . . . . . . 11 4.1. Description of the attack . . . . . . . . . . . . . . . . 11
4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13
5.1. Description of the attack . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 13
5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13
6. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15
7. Backward Compatibility and Other considerations . . . . . . . 16 7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Middlebox considerations . . . . . . . . . . . . . . . . . . . 17 8. Backward Compatibility and Other considerations . . . . . . . 17
8.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 17 9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18
8.2. Middleboxes that advance sequence numbers . . . . . . . . 17 9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.2. Middleboxes that advance sequence numbers . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
TCP [RFC0793] is widely deployed and the most common reliable end to TCP [RFC0793] is widely deployed and the most common reliable end to
end transport protocol used for data communication in today's end transport protocol used for data communication in today's
Internet. Yet when it was standardized over 20 years ago, the Internet. Yet when it was standardized over 20 years ago, the
Internet, was a different place, lacking many of the threats that are Internet, was a different place, lacking many of the threats that are
now common. The TCP spoofing attacks, which are seen in the Internet now common. The TCP spoofing attacks, which are seen in the Internet
today, fall into this category. today, fall into this category.
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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. Applicability Statement 1.1. Applicability Statement
The mitigations presented in this document talks about some known in- This document talks about some known in-window attacks and suitable
window attacks and the solutions to the same. The mitigations defenses against these. The mitigations suggested in this draft
suggested in this draft SHOULD be implemented in devices where the SHOULD be implemented in devices that regularly need to maintain TCP
TCP connections are most vulnerable to the attacks described in this connections of the kind most vulnerable to the attacks described in
document. Some examples of such TCP connections are the ones that this document. Examples of such TCP connections are the ones that
tend to be long-lived where the connection end points can be tend to be long-lived and where the connection end points can be
determined, in cases where no auxiliary anti-spoofing protection determined, in cases where no auxiliary anti-spoofing protection
mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations
MAY be implemented in other cases. MAY be implemented in other cases.
1.2. Basic Attack Methodology 1.2. Basic Attack Methodology
Focusing upon the RST attack, we examine this attack in more detail Focusing upon the RST attack, we examine this attack in more detail
to get an overview as to how it works and how this document addresses to get an overview as to how it works and how this document addresses
the issue. For this attack the goal is for the attacker to cause one the issue. For this attack the goal is for the attacker to cause one
of the two endpoints of the connection to incorrectly tear down the of the two endpoints of the connection to incorrectly tear down the
skipping to change at page 5, line 45 skipping to change at page 5, line 45
the application that is under attack), can come up with a very the application that is under attack), can come up with a very
close approximation as to the actual window size in use on the close approximation as to the actual window size in use on the
connection. connection.
After assembling the above set of information the attacker begins After assembling the above set of information the attacker begins
sending spoofed TCP segments with the RST bit set and a guessed TCP sending spoofed TCP segments with the RST bit set and a guessed TCP
sequence number. Each time a new RST segment is sent, the sequence sequence number. Each time a new RST segment is sent, the sequence
number guess is incremented by the window size. The feasibility of number guess is incremented by the window size. The feasibility of
this methodology (without mitigations) was first shown in [SITW]. this methodology (without mitigations) was first shown in [SITW].
This is because [RFC0793] specifies that any RST within the current This is because [RFC0793] specifies that any RST within the current
window is acceptable. Also [I-D.ietf-tcpm-tcp-antispoof] talks about window is acceptable. Also [RFC4953] talks about the probability of
the probability of a successful attack with varying window sizes and a successful attack with varying window sizes and bandwidth.
bandwidth.
A slight enhancement to the TCP's segment processing rules can be A slight enhancement to the TCP's segment processing rules can be
made which makes such an attack much more difficult to accomplish. made which makes such an attack much more difficult to accomplish.
If the receiver examines the incoming RST segment and validates that If the receiver examines the incoming RST segment and validates that
the sequence number exactly matches the sequence number that is next the sequence number exactly matches the sequence number that is next
expected, then such an attack becomes much more difficult than expected, then such an attack becomes much more difficult than
outlined in [SITW] (i.e. the attacker would have to generate 1/2 the outlined in [SITW] (i.e. the attacker would have to generate 1/2 the
entire sequence space, on average). This document will discuss the entire sequence space, on average). This document will discuss the
exact details of what needs to be changed within TCP's segment exact details of what needs to be changed within TCP's segment
processing rules to mitigate all three types of attacks (RST, SYN and processing rules to mitigate all three types of attacks (RST, SYN and
skipping to change at page 7, line 35 skipping to change at page 7, line 34
unavailability due to the need to rebuild routing tables and route unavailability due to the need to rebuild routing tables and route
flapping; see [NISCC] for further details. flapping; see [NISCC] for further details.
For applications that can use the TCP MD5 option [RFC2385], such as For applications that can use the TCP MD5 option [RFC2385], such as
BGP, that option makes the attacks described in this specification BGP, that option makes the attacks described in this specification
effectively impossible. However, some applications or effectively impossible. However, some applications or
implementations may find that option expensive to implement. implementations may find that option expensive to implement.
There are alternative protections against the threats that this There are alternative protections against the threats that this
document addresses. For further details regarding the attacks and document addresses. For further details regarding the attacks and
the existing techniques, please refer to draft the existing techniques, please refer to draft [RFC4953]
[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
skipping to change at page 10, line 43 skipping to change at page 10, line 43
incoming ACK. This second RST, if it reaches the sender, will cause incoming ACK. This second RST, if it reaches the sender, will cause
the connection to be aborted since the sequence number would now be the connection to be aborted since the sequence number would now be
an exact match. an exact match.
A valid RST received out-of-order would still generate a challenge A valid RST received out-of-order would still generate a challenge
ACK in response. If this RST happens to be a genuine one, the other ACK in response. If this RST happens to be a genuine one, the other
end would send an RST with an exact sequence number match which would end would send an RST with an exact sequence number match which would
cause the connection to be dropped. cause the connection to be dropped.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 9. exchange. This concern is discussed in Section 10.
4. Blind reset attack using the SYN bit 4. Blind reset attack using the SYN bit
4.1. Description of the attack 4.1. Description of the attack
The analysis of the reset attack using the RST bit highlights another The analysis of the reset attack using the RST bit highlights another
possible avenue for a blind attacker using a similar set of sequence possible avenue for a blind attacker using a similar set of sequence
number guessing. Instead of using the RST bit an attacker can use number guessing. Instead of using the RST bit an attacker can use
the SYN bit with the exact same semantics to tear down a connection. the SYN bit with the exact same semantics to tear down a connection.
4.2. Mitigation 4.2. Mitigation
[RFC0793] currently requires handling of a segment with the SYN bit [RFC0793] currently requires handling of a segment with the SYN bit
set in the synchronized state to be as follows: set in the synchronized state to be as follows:
1) If the SYN bit is set and the sequence number is outside the 1) If the SYN bit is set and the sequence number is outside the
expected window, send an ACK back to the sender. expected window, send an ACK back to the sender.
2) If the SYN bit is set and the sequence number is acceptable i.e.: 2) If the SYN bit is set and the sequence number is acceptable i.e.:
(RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then send a RST segment to (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then send a RST segment to
the sender. the sender.
Instead, the handling of the SYN in the synchronized state SHOULD be Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows: performed as follows:
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>
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 requirements. not introduced by these new requirements.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 9. exchange. This concern is discussed in Section 10.
5. Blind data injection attack 5. Blind data injection attack
5.1. Description of the attack 5.1. Description of the attack
A third type of attack is also highlighted by both the RST and SYN A third type of attack is also highlighted by both the RST and SYN
attacks. It is also possible to inject data into a TCP connection by attacks. It is also possible to inject data into a TCP connection by
simply guessing a sequence number within the current receive window simply guessing a sequence number within the current receive window
of the victim. The ACK value of any data segment is considered valid of the victim. The ACK value of any data segment is considered valid
as long as it does not acknowledge data ahead of the next segment to as long as it does not acknowledge data ahead of the next segment to
skipping to change at page 13, line 29 skipping to change at page 13, line 29
attacker has to guess two ACK values with every guessed sequence attacker has to guess two ACK values with every guessed sequence
number so that the chances of successfully injecting data into a number so that the chances of successfully injecting data into a
connection are 1 in ((2^32 / RCV.WND) * 2). connection are 1 in ((2^32 / RCV.WND) * 2).
When an attacker successfully injects data into a connection the data When an attacker successfully injects data into a connection the data
will sit in the receiver's re-assembly queue until the peer sends will sit in the receiver's re-assembly queue until the peer sends
enough data to bridge the gap between the RCV.NXT value and the enough data to bridge the gap between the RCV.NXT value and the
injected data. At that point one of two things will occur : injected data. At that point one of two things will occur :
a) A packet war will ensue with the receiver indicating that it has a) A packet war will ensue with the receiver indicating that it has
received data up until RCV.NXT (which includes the attackers data) received data up until RCV.NXT (which includes the attacker's
and the sender sending an ACK with an acknowledgment number less data) and the sender sending an ACK with an acknowledgment number
than RCV.NXT. less 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
unless the sender produces more data that will transform the ACK war unless the sender produces more data that will transform the ACK war
into case (b). The reset will usually occur via User Time Out (UTO) into case (b). The reset will usually occur via User Time Out (UTO)
(see section 4.2.3.5 of [RFC1122]). (see section 4.2.3.5 of [RFC1122]).
Note that the protections illustrated in this section neither cause Note that the protections illustrated in this section neither cause
an ACK war nor prevent one from occurring if data is actually an ACK war nor prevent one from occurring if data is actually
injected into a connection. The ACK war is a product of the attack injected into a connection. The ACK war is a product of the attack
itself and cannot be prevented (other than by preventing the data itself and cannot be prevented (other than by preventing the data
from being injected). from being injected).
5.2. Mitigation 5.2. Mitigation
All TCP stacks SHOULD implement the following mitigation. TCP stacks All TCP stacks MAY implement the following mitigation. TCP stacks
which implement this mitigation MUST add an additional input check to which implement this mitigation MUST add an additional input check to
any incoming segment. The ACK value is considered acceptable only if any incoming segment. The ACK value is considered acceptable only if
it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
SND.NXT). All incoming segments whose ACK value doesn't satisfy the SND.NXT). All incoming segments whose ACK value doesn't satisfy the
above condition MUST be discarded silently. A new state variable above condition MUST be discarded and an ACK sent back. It needs to
MAX.SND.WND is defined as the largest window that the local sender be noted that RFC 793 page 72 (fifth check) says : "If the ACK is a
has ever received from its peer. This window may be scaled to a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK
value larger than 65,535 bytes ([RFC1323]). This small check will acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
reduce the vulnerability to an attacker guessing a valid sequence ACK, drop the segment, and return" This mitigation makes the ACK
number, since he/she not only must guess the in-window sequence check more stringent since any ACK < SND.UNA wouldn't be accepted,
number, but also guess a proper ACK value within a scoped range. instead only ACK's which are in the range ((SND.UNA - MAX.SND.WND) <=
This mitigation reduces, but does not eliminate, the ability to SEG.ACK <= SND.NXT) gets through.
generate false segments. It does however reduce the probability that
invalid data will be injected. A new state variable MAX.SND.WND is defined as the largest window
that the local sender has ever received from its peer. This window
may be scaled to a value larger than 65,535 bytes ([RFC1323]). This
small check will reduce the vulnerability to an attacker guessing a
valid sequence number, since, not only one must guess the in-window
sequence number, but also guess a proper ACK value within a scoped
range. This mitigation reduces, but does not eliminate, the ability
to generate false segments. It does however reduce the probability
that invalid data will be injected.
Implementations can also chose to hard code the MAX.SND.WND value to Implementations can also chose to hard code the MAX.SND.WND value to
the maximum permissible window size i.e., 65535 in the absence of the maximum permissible window size i.e., 65535 in the absence of
window scaling. In presence of the window scaling option the value window scaling. In presence of the window scaling option the value
becomes (MAX.SND.WND << Snd.Wind.Scale). becomes (MAX.SND.WND << Snd.Wind.Scale).
This mitigation also helps in improving robustness on accepting This mitigation also helps in improving robustness on accepting
spoofed FIN segments (FIN attacks). Among other things, this spoofed FIN segments (FIN attacks). Among other things, this
mitigation requires that the attacker also needs to get the mitigation requires that the attacker also needs to get the
acknowledgment number to fall in the range mentioned above in order acknowledgment number to fall in the range mentioned above in order
to successfully spoof a FIN segment leading to the closure of the to successfully spoof a FIN segment leading to the closure of the
connection. Thus, this mitigation greatly improves the robustness to connection. Thus, this mitigation greatly improves the robustness to
spoofed FIN segments. spoofed FIN segments.
Note that the above mitigation may cause a non-amplification ACK Note that the above mitigation may cause a non-amplification ACK
exchange. This concern is discussed in Section 9. exchange. This concern is discussed in Section 10.
6. ACK throttling 6. Suggested Mitigation strengths
As described in the above sections, recommendation levels for RST,
SYN and Data are tagged as SHOULD, SHOULD and MAY respectively.
There was no strong technical reasoning for choosing the Data
mitigation as MAY. It was perceived from some quarters that data
mitigation, even though increased the TCP robustness in general, is
not as elegant as the solutions offered for RST and SYN counterparts.
However, it needs to be noted that all the suggested mitigations
improve TCP's robustness in general and hence the choice of
implementing some or all mitigations recommended in the document is
purely left to the implementer.
7. ACK throttling
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, an ACK throttling mechanism is suggested as follows : challenge ACKs, an ACK throttling mechanism is suggested as follows :
1) The system administrator can configure the number of challenge 1) The system administrator can configure the number of challenge
ACKs that can be sent out in a given interval. For example, in ACKs that can be sent out in a given interval. For example, in
any 5 second window, no more than 10 challenge ACKs should be any 5 second window, no more than 10 challenge ACKs should be
sent. sent.
2) The values for both the time and number of ACKs SHOULD be tunable 2) The values for both the time and number of ACKs SHOULD be tunable
skipping to change at page 16, line 5 skipping to change at page 17, line 5
An administrator who is more concerned about protecting his bandwidth An administrator who is more concerned about protecting his bandwidth
and CPU utilization may set smaller ACK throttling values whereas an and CPU utilization may set smaller ACK throttling values whereas an
administrator who is more interested in faster cleanup of stale administrator who is more interested in faster cleanup of stale
connections (i.e. concerned about excess TCP state) may decide to set connections (i.e. concerned about excess TCP state) may decide to set
a higher value thus allowing more RST's to be processed in any given a higher value thus allowing more RST's to be processed in any given
time period. time period.
The time limit SHOULD be tunable to help timeout brute force attacks The time limit SHOULD be tunable to help timeout brute force attacks
faster than a potential legitimate flood of RSTs. faster than a potential legitimate flood of RSTs.
7. Backward Compatibility and Other considerations 8. Backward Compatibility and Other considerations
All of the new required mitigation techniques in this document are All of the new required mitigation techniques in this document are
totally compatible with existing ([RFC0793]) compliant TCP totally compatible with existing ([RFC0793]) compliant TCP
implementations as this document introduces no new assumptions or implementations as this document introduces no new assumptions or
conditions. conditions.
There is a corner scenario in the above mitigations which will There is a corner scenario in the above mitigations which will
require more than one round trip time to successfully abort the require more than one round trip time to successfully abort the
connection as per the figure below. This scenario is similar to the connection as per the figure below. This scenario is similar to the
one in which the original RST was lost in the network. one in which the original RST was lost in the network.
skipping to change at page 17, line 5 skipping to change at page 18, line 5
5. RESPONSE arrives at A, but dropped since its outside of window. 5. RESPONSE arrives at A, but dropped since its outside of window.
6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 6. ESTAB <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSED 7. CLOSED CLOSED
For the mitigation to be maximally effective against the For the mitigation to be maximally effective against the
vulnerabilities discussed in this document, both ends of the TCP vulnerabilities discussed in this document, both ends of the TCP
connection need to have the fix. Although, having the mitigations at connection need to have the fix. Although, having the mitigations at
one end might prevent that end from being exposed to the attack, the one end might prevent that end from being exposed to the attack, the
connection is still vulnerable at the other end. connection is still vulnerable at the other end.
8. Middlebox considerations 9. Middlebox considerations
8.1. Middlebox that resend RST's 9.1. Middlebox that resend RST's
Consider a middlebox M-B tracking connections between two TCP end Consider a middlebox M-B tracking connections between two TCP end
hosts E-A and E-C. If E-C sends a RST with a sequence number that is hosts E-A and E-C. If E-C sends a RST with a sequence number that is
within the window but not an exact match to reset the connection and within the window but not an exact match to reset the connection and
M-B does not have the fix recommended in this document, it may clear M-B does not have the fix recommended in this document, it may clear
the connection and forward the RST to E-A saving an incorrect the connection and forward the RST to E-A saving an incorrect
sequence number. If E-A does not have the fix the connection would sequence number. If E-A does not have the fix the connection would
get cleared as required. However if E-A does have the required fix, get cleared as required. However if E-A does have the required fix,
it will send a challenge ACK to E-C. M-B, being a middlebox, may it will send a challenge ACK to E-C. M-B, being a middlebox, may
intercept this ACK and resend the RST on behalf of E-C with the old intercept this ACK and resend the RST on behalf of E-C with the old
skipping to change at page 17, line 35 skipping to change at page 18, line 35
the incoming ACK segment. It is outside the scope of this document the incoming ACK segment. It is outside the scope of this document
to suggest mitigations to the ill-behaved middleboxes. to suggest mitigations to the ill-behaved middleboxes.
Consider a similar scenario where the RST from M-B to E-A gets lost, Consider a similar scenario where the RST from M-B to E-A gets lost,
E-A will continue to hold the connection and E-A might send an ACK an E-A will continue to hold the connection and E-A might send an ACK an
arbitrary time later after the connection state was destroyed at M-B. arbitrary time later after the connection state was destroyed at M-B.
For this case, M-B will have to cache the RST for an arbitrary amount For this case, M-B will have to cache the RST for an arbitrary amount
of time till until it is confirmed that the connection has been of time till until it is confirmed that the connection has been
cleared at E-A. cleared at E-A.
8.2. Middleboxes that advance sequence numbers 9.2. Middleboxes that advance sequence numbers
Some middleboxes may compute RST sequence numbers at the higher end Some middleboxes may compute RST sequence numbers at the higher end
of the acceptable window. The scenario is the same as the earlier of the acceptable window. The scenario is the same as the earlier
case, but in this case instead of sending the cached RST, the case, but in this case instead of sending the cached RST, the
middlebox (M-B) sends a RST that computes its sequence number as the middlebox (M-B) sends a RST that computes its sequence number as the
sum of the acknowledgement field in the ACK and the window advertised sum of the acknowledgement field in the ACK and the window advertised
by the ACK that was sent by E-A to challenge the RST as depicted by the ACK that was sent by E-A to challenge the RST as depicted
below. The difference in the sequence numbers between step 1 and 2 below. The difference in the sequence numbers between step 1 and 2
below is due to data lost in the network. below is due to data lost in the network.
skipping to change at page 19, line 5 skipping to change at page 20, line 5
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. Security Considerations 10. Security Considerations
These changes to the TCP state machine do NOT protect an These changes to the TCP state machine do NOT protect an
implementation from on-path attacks. It also needs to be emphasized implementation from on-path attacks. It also needs to be emphasized
that while mitigations within this document make it harder for off- that while mitigations within this document make it harder for off-
path attackers to inject segments, it does NOT make it impossible. path attackers to inject segments, it does NOT make it impossible.
The only way to fully protect a TCP connection from both on and off The only way to fully protect a TCP connection from both on and off
path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP
[RFC4303]. [RFC4303].
Implementers also should be aware that the attacks detailed in this Implementers also should be aware that the attacks detailed in this
skipping to change at page 19, line 32 skipping to change at page 20, line 32
connections or degrade service. Such attacks may be subject to even connections or degrade service. Such attacks may be subject to even
less scrutiny than the TCP attacks addressed here, especially in less scrutiny than the TCP attacks addressed here, especially in
stacks not tuned for hostile environments. It is important to note stacks not tuned for hostile environments. It is important to note
that some ICMP messages, validated or not, are key to the proper that some ICMP messages, validated or not, are key to the proper
function of TCP. Those ICMP messages used to properly set the path function of TCP. Those ICMP messages used to properly set the path
maximum transmission unit are the most obvious example. There are a maximum transmission unit are the most obvious example. There are a
variety of ways to choose which, if any, ICMP messages to trust in variety of ways to choose which, if any, ICMP messages to trust in
the presence of off-path attackers and choosing between them depends the presence of off-path attackers and choosing between them depends
on the assumptions and guarantees developers and administrators can on the assumptions and guarantees developers and administrators can
make about their network. This specification does not attempt to do make about their network. This specification does not attempt to do
more than note this and related issues. more than note this and related issues. Unless implementers address
spoofed ICMP messages [I-D.ietf-tcpm-icmp-attacks], the mitigations
specified in this document may not provide the desired protection
level.
In any case, this RFC details only part of a complete strategy to In any case, this RFC details only part of a complete strategy to
prevent off-path attackers from disrupting services that use TCP. prevent off-path attackers from disrupting services that use TCP.
Administrators and implementers should consider the other attack Administrators and implementers should consider the other attack
vectors and determine appropriate mitigations in securing their vectors and determine appropriate mitigations in securing their
systems. systems.
Another notable consideration is that a reflector attack is possible Another notable consideration is that a reflector attack is possible
with the required RST/SYN mitigation techniques. In this attack, an with the required RST/SYN mitigation techniques. In this attack, an
off-path attacker can cause a victim to send an ACK segment for each off-path attacker can cause a victim to send an ACK segment for each
spoofed RST/SYN segment that lies within the current receive window spoofed RST/SYN segment that lies within the current receive window
of the victim. It should be noted, however, that this does not cause of the victim. It should be noted, however, that this does not cause
any amplification since the attacker must generate a segment for each any amplification since the attacker must generate a segment for each
one that the victim will generate. one that the victim will generate.
10. IANA Considerations 11. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
11. Contributors 12. Contributors
Mitesh Dalal and Amol Khare of Cisco Systems came up with the Mitesh Dalal and Amol Khare of Cisco Systems came up with the
solution for the RST/SYN attacks. Anantha Ramaiah and Randall solution for the RST/SYN attacks. Anantha Ramaiah and Randall
Stewart of Cisco Systems discovered the data injection vulnerability Stewart of Cisco Systems discovered the data injection vulnerability
and together with Patrick Mahan and Peter Lei of Cisco Systems found and together with Patrick Mahan and Peter Lei of Cisco Systems found
solutions for the same. Paul Goyette, Mark Baushke, Frank solutions for the same. Paul Goyette, Mark Baushke, Frank
Kastenholz, Art Stine and David Wang of Juniper Networks provided the Kastenholz, Art Stine and David Wang of Juniper Networks provided the
insight that apart from RSTs, SYNs could also result in formidable insight that apart from RSTs, SYNs could also result in formidable
attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of
Wind River Systems and Xiaodan Tang of QNX Software along with the Wind River Systems and Xiaodan Tang of QNX Software along with the
folks above helped in ratifying and testing the interoperability of folks above helped in ratifying and testing the interoperability of
the suggested solutions. the suggested solutions.
ACK throttling was introduced to this document by combining the ACK throttling was introduced to this document by combining the
suggestions from the tcpm working group. suggestions from the tcpm working group.
12. Acknowledgments 13. Acknowledgments
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
Joe Touch, Alfred Hoenes and other members of the tcpm WG for Joe Touch, Alfred Hoenes, Andre Oppermann and other members of the
suggestions and comments. tcpm WG for suggestions and comments.
13. References 14. References
13.1. Normative References 14.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [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 14.2. Informative References
[I-D.ietf-tcpm-tcp-antispoof] [I-D.ietf-tcpm-icmp-attacks]
Touch, J., "Defending TCP Against Spoofing Attacks", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-tcp-antispoof-06 (work in progress), draft-ietf-tcpm-icmp-attacks-03 (work in progress),
February 2007. March 2008.
[Medina05] [Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet. ACM Evolution of Transport Protocols in the Internet. ACM
Computer Communication Review, 35(2), April 2005. Computer Communication Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
(figure 6)". (figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP". Vulnerability Issues in TCP".
skipping to change at page 24, line 5 skipping to change at page 25, line 5
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003. Signature Option", RFC 3562, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[SITW] Watson, P., "Slipping in the Window: TCP Reset attacks, [SITW] Watson, P., "Slipping in the Window: TCP Reset attacks,
Presentation at 2004 CanSecWest Presentation at 2004 CanSecWest
http://www.cansecwest.com/archives.html". http://www.cansecwest.com/archives.html".
Authors' Addresses Authors' Addresses
Anantha Ramaiah Anantha Ramaiah
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 26, line 44 skipping to change at line 854
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 31 change blocks. 
69 lines changed or deleted 91 lines changed or added

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