draft-ietf-tcpm-tcpsecure-08.txt   draft-ietf-tcpm-tcpsecure-09.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: January 9, 2008 July 8, 2007 Expires: July 10, 2008 January 7, 2008
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-08.txt draft-ietf-tcpm-tcpsecure-09.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 January 9, 2008. This Internet-Draft will expire on July 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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 8 skipping to change at page 3, line 8
inject a RST, SYN or DATA segment into a TCP connection by inject a RST, SYN or DATA segment into a TCP connection by
systematically guessing the sequence number of the spoofed segment to systematically guessing the sequence number of the spoofed segment to
be in the current receive window. This can cause the connection to be in the current receive window. This can cause the connection to
either abort or possibly cause data corruption. This document either abort or possibly cause data corruption. This document
specifies small modifications to the way TCP handles inbound segments specifies small modifications to the way TCP handles inbound segments
that can reduce the chances of a successful attack. that can reduce the chances of a successful attack.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Basic Attack Methodology . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.2. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 4
1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
3.1. Description of the attack . . . . . . . . . . . . . . . . 9 3.1. Description of the attack . . . . . . . . . . . . . . . . 9
3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11 4. Blind reset attack using the SYN bit . . . . . . . . . . . . . 11
4.1. Description of the attack . . . . . . . . . . . . . . . . 11 4.1. Description of the attack . . . . . . . . . . . . . . . . 11
4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13
5.1. Description of the attack . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 13
5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 36 skipping to change at page 4, line 36
RST - Where an attacker injects a RST segment hoping to cause the RST - Where an attacker injects a RST segment hoping to cause the
connection to be torn down. connection to be torn down.
SYN - Where an attacker injects a SYN hoping to cause the receiver SYN - Where an attacker injects a SYN hoping to cause the receiver
to believe the peer has restarted and so tear down the connection to believe the peer has restarted and so tear down the connection
state. state.
DATA - Where an attacker tries to inject a DATA segment to corrupt DATA - Where an attacker tries to inject a DATA segment to corrupt
the contents of the transmission. the contents of the transmission.
The mitigations described in this document SHOULD be implemented by 1.1. Applicability Statement
TCP stacks. Those mitigations have required and optional aspects
that are further described below.
1.1. Basic Attack Methodology The mitigations presented in this document talks about some known in-
window attacks and the solutions to the same. The mitigations
suggested in this draft SHOULD be implemented in devices where the
TCP connections are most vulnerable to the attacks described in this
document. Some examples of such TCP connections are the ones that
tend to be long-lived where the connection end points can be
determined, in cases where no auxiliary anti-spoofing protection
mechanisms like TCP MD5 [RFC2385] can be deployed. These mitigations
MAY be implemented in other cases.
1.2. Basic Attack Methodology
Focusing upon the RST attack, we examine this attack in more detail Focusing upon the RST attack, we examine this attack in more detail
to get an overview as to how it works and how this document addresses to get an overview as to how it works and how this document addresses
the issue. For this attack the goal is for the attacker to cause one the issue. For this attack the goal is for the attacker to cause one
of the two endpoints of the connection to incorrectly tear down the of the two endpoints of the connection to incorrectly tear down the
connection state, effectively aborting the connection. One of the connection state, effectively aborting the connection. One of the
important things to note is that, for the attack to succeed the RST important things to note is that, for the attack to succeed the RST
needs to be in the valid receive window. It also needs to be needs to be in the valid receive window. It also needs to be
emphasized that the receive window is independent of the current emphasized that the receive window is independent of the current
congestion window of the TCP connection. The attacker would try to congestion window of the TCP connection. The attacker would try to
skipping to change at page 6, line 5 skipping to change at page 6, line 12
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
DATA). DATA).
1.2. Attack probabilities 1.3. Attack probabilities
Every application has control of a number of factors that effect Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack. These drastically the probability of a successful spoofing attack. These
factors include such things as: factors include such things as:
Window Size - Normally settable by the application but often times Window Size - Normally settable by the application but often times
defaulting to 32,768 or 65,535 depending upon the operating system defaulting to 32,768 or 65,535 depending upon the operating system
([Medina05]). ([Medina05]).
Server Port number - This value is normally a fixed value so that a Server Port number - This value is normally a fixed value so that a
skipping to change at page 13, line 52 skipping to change at page 13, line 52
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 SHOULD implement the following mitigation. TCP stacks
which implement this mitigation, requires that an additional input which implement this mitigation MUST add an additional input check to
check MUST be added to any incoming segment. The ACK value is any incoming segment. The ACK value is considered acceptable only if
considered acceptable only if it is in the range of ((SND.UNA - it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK SND.NXT). All incoming segments whose ACK value doesn't satisfy the
value doesn't satisfy the above condition MUST be discarded silently. above condition MUST be discarded silently. A new state variable
A new state variable MAX.SND.WND is defined as the largest window MAX.SND.WND is defined as the largest window that the local sender
that the local sender has ever received from its peer. This window has ever received from its peer. This window may be scaled to a
may be scaled to a value larger than 65,535 bytes ([RFC1323]). This value larger than 65,535 bytes ([RFC1323]). This small check will
small check will reduce the vulnerability to an attacker guessing a reduce the vulnerability to an attacker guessing a valid sequence
valid sequence number, since he/she not only must guess the in-window number, since he/she not only must guess the in-window sequence
sequence number, but also guess a proper ACK value within a scoped number, but also guess a proper ACK value within a scoped range.
range. This mitigation reduces, but does not eliminate, the ability This mitigation reduces, but does not eliminate, the ability to
to generate false segments. It does however reduce the probability generate false segments. It does however reduce the probability that
that invalid data will be injected. 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 the presence of 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 9.
6. ACK throttling 6. ACK throttling
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, an ACK throttling mechanism is suggested as follows : challenge ACKs, an ACK throttling mechanism is suggested as follows :
1) The system administrator can configure the number of challenge 1) The system administrator can configure the number of challenge
ACK's that can be sent out in a given interval. For example, in ACKs that can be sent out in a given interval. For example, in
any 5 second window, no more than 10 challenge ACK's should be any 5 second window, no more than 10 challenge ACKs should be
sent. sent.
2) The values for both the time and number of ACK's SHOULD be tunable 2) The values for both the time and number of ACKs SHOULD be tunable
by the system administrator to accommodate different perceived by the system administrator to accommodate different perceived
levels of threat and/or system resources. levels of threat and/or system resources.
It should be noted that these numbers are empirical in nature and It should be noted that these numbers are empirical in nature and
have been obtained from the RST throttling mechanisms existing in have been obtained from the RST throttling mechanisms existing in
some implementations. Also note that no timer is needed to implement some implementations. Also note that no timer is needed to implement
the above mechanism, instead a timestamp and a counter can be used. the above mechanism, instead a timestamp and a counter can be used.
An implementation SHOULD include an ACK throttling mechanism to be An implementation SHOULD include an ACK throttling mechanism to be
conservative. Currently there is no known bad behavior that can be conservative. Currently there is no known bad behavior that can be
skipping to change at page 26, line 7 skipping to change at page 26, line 7
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 853-5257 Phone: +1 (408) 853-5257
Email: mdalal@cisco.com Email: mdalal@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 13 change blocks. 
30 lines changed or deleted 39 lines changed or added

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