draft-ietf-tcpm-tcpsecure-02.txt   draft-ietf-tcpm-tcpsecure-03.txt 
Network Working Group M. Dalal Network Working Group M. Dalal
Internet-Draft Editor Internet-Draft Editor
Expires: May 23, 2005 November 22, 2004 Expires: November 19, 2005 May 18, 2005
Transmission Control Protocol security considerations Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-02.txt draft-ietf-tcpm-tcpsecure-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she becomes aware will be disclosed, in accordance with
RFC 3668. 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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 23, 2005. This Internet-Draft will expire on November 19, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
TCP (RFC793 [1]) is widely deployed and one of the most often used TCP (RFC793 [1]) is widely deployed and one of the most often used
reliable end to end protocols for data communication. Yet when it reliable end to end protocols for data communication. Yet when it
was defined over 20 years ago the internet, as we know it, was a was defined over 20 years ago the internet, as we know it, was a
different place lacking many of the threats that are now common. different place lacking many of the threats that are now common.
Recently several rather serious threats have been detailed that can Recently several rather serious threats have been detailed that can
pose new methods for both denial of service and possibly data pose new methods for both denial of service and possibly data
injection by blind attackers. This document details those threats injection by blind attackers. This document details those threats
skipping to change at page 2, line 19 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Blind reset attack using the RST bit . . . . . . . . . . . . . 5 2. Blind reset attack using the RST bit . . . . . . . . . . . . . 5
2.1 Description of the attack . . . . . . . . . . . . . . . . 5 2.1 Description of the attack . . . . . . . . . . . . . . . . 5
2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Blind reset attack using the SYN bit . . . . . . . . . . . . . 7 3. Blind reset attack using the SYN bit . . . . . . . . . . . . . 7
3.1 Description of the attack . . . . . . . . . . . . . . . . 7 3.1 Description of the attack . . . . . . . . . . . . . . . . 7
3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Blind data injection attack . . . . . . . . . . . . . . . . . 9 4. Blind data injection attack . . . . . . . . . . . . . . . . . 9
4.1 Description of the attack . . . . . . . . . . . . . . . . 9 4.1 Description of the attack . . . . . . . . . . . . . . . . 9
4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Solution . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Backward Compatibility and Other considerations . . . . . . . 10 5. Backward Compatibility and Other considerations . . . . . . . 11
6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 12 6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 13
6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 12 6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 13
6.2 Middleboxes that advance sequence numbers . . . . . . . . 12 6.2 Middleboxes that advance sequence numbers . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18
1. Introduction 1. Introduction
TCP (RFC793 [1]) is widely deployed and one of the most often used TCP (RFC793 [1]) is widely deployed and one of the most often used
reliable end to end protocols for data communication. Yet when it reliable end to end protocols for data communication. Yet when it
was defined over 20 years ago the internet, as we know it, was a was defined over 20 years ago the internet, as we know it, was a
different place lacking many of the threats that are now common. different place lacking many of the threats that are now common.
Recently several rather serious threats have been detailed that can Recently several rather serious threats have been detailed that can
pose new methods for both denial of service and possibly data pose new methods for both denial of service and possibly data
injection by blind attackers. This document details those threats injection by blind attackers. This document details those threats
skipping to change at page 3, line 32 skipping to change at page 3, line 32
be in the base TCP document and the lack of these procedures is more be in the base TCP document and the lack of these procedures is more
an artifact of the time when TCP was developed than any strict an artifact of the time when TCP was developed than any strict
requirement of the protocol. requirement of the protocol.
For some uses of TCP, an alternative protection against the threats For some uses of TCP, an alternative protection against the threats
that these changes address has already been implemented and deployed that these changes address has already been implemented and deployed
in the TCP MD5 Signature Option (RFC2385 [2]). Because this option in the TCP MD5 Signature Option (RFC2385 [2]). Because this option
is not negotiated and is implemented with a manually established is not negotiated and is implemented with a manually established
shared key or password, it has been used for protecting uses of TCP shared key or password, it has been used for protecting uses of TCP
in which the endpoints are managed, such as for BGP peers. RFC3562 in which the endpoints are managed, such as for BGP peers. RFC3562
[2] provides importance guidance for users of RFC2385 [2] for [3] provides importance guidance for users of RFC2385 [2] for
decreasing their vulnerability to key-guessing. decreasing their vulnerability to key-guessing.
Yet another commonly known mitigation technique is cryptography, Yet another commonly known mitigation technique is cryptography,
especially IPSec. For IPSec to work, both ends of the connection especially IPSec. For IPSec to work, both ends of the connection
need to agree on the properties to use for the connection and also need to agree on the properties to use for the connection and also
agree upon a pre-shared key. In the absence of PKI infrastr1ucture, agree upon a pre-shared key. In the absence of PKI infrastructure,
this may be inconvenient. IPSec with manual keys can be used to this may be inconvenient. IPSec with manual keys can be used to
avoid using ISAKMP. However, this adds considerable burden on the avoid using ISAKMP. However, this adds considerable burden on the
administration of such solution. If ISAKMP were to be used, this administration of such solution. If ISAKMP were to be used, this
would typically require all firewalls in the path between the two TCP would typically require all firewalls in the path between the two TCP
endpoints to allow UDP traffic for atleast ISAKMP to function. endpoints to allow UDP traffic for atleast ISAKMP to function.
Further, IPSec and NAT have long been known to have interoperability Further, IPSec and NAT have long been known to have interoperability
issues. issues.
TCP implementations SHOULD also introduce ephemeral port TCP implementations SHOULD also introduce ephemeral port
randomization. By randomizing ephemeral ports an attacker would have randomization. By randomizing ephemeral ports an attacker would have
a less easy time in guessing the four tuples needed to mount a a less easy time in guessing the four tuples needed to mount a
successful attack. Since ephemeral ports are 16 bit values and are a successful attack. Since ephemeral ports are 16 bit values and are a
subset of the entire available port numbers, it is a weaker defense subset of the entire available port numbers, it is a weaker defense
than an exact sequence number match as proposed here which is a than an exact sequence number match as proposed here which is a 32-
32-bit value and changes dramatically within the life of a bit value and changes dramatically within the life of a connection.
connection. Nevertheless, both of them are complimentary solutions Nevertheless, both of them are complimentary solutions that will make
that will make it difficult to launch attacks discussed below. it difficult to launch attacks discussed below.
Alternative proposals, including the use of cookies (or, use of the Alternative proposals, including the use of cookies (or, use of the
timestamp option as a cookie) require both peers to implement the timestamp option as a cookie) require both peers to implement the
changes before any additional protection can be realized. changes before any additional protection can be realized.
2. Blind reset attack using the RST bit 2. Blind reset attack using the RST bit
2.1 Description of the attack 2.1 Description of the attack
It has been traditionally thought that for a blind attacker to reset It has been traditionally thought that for a blind attacker to reset
skipping to change at page 5, line 30 skipping to change at page 5, line 30
connections (assuming the attacker can accurately guess both ports) connections (assuming the attacker can accurately guess both ports)
can be reset in under 200 seconds (usually far less). With the rise can be reset in under 200 seconds (usually far less). With the rise
of broadband availability and increasing available bandwidth, many of broadband availability and increasing available bandwidth, many
Operating Systems have raised their default RCV.WND to as much as Operating Systems have raised their default RCV.WND to as much as
64k, thus making these attacks even easier. 64k, thus making these attacks even easier.
2.2 Solution 2.2 Solution
RFC793 [1] currently requires handling of a segment with the RST bit RFC793 [1] currently requires handling of a segment with the RST bit
when in a synchronized state to be processed as follows: when in a synchronized state to be processed as follows:
1) If the RST bit is set and the sequence number is outside the 1) If the RST bit is set and the sequence number is outside the
expected window, silently drop the segment. expected window, silently drop the segment.
2) If the RST bit is set and the sequence number is acceptable i.e.: 2) If the RST bit is set and the sequence number is acceptable i.e.:
(RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. (RCV.NXT <= SEG.SEQ < RCV.NXT+RCV.WND) then reset the connection.
Instead, the following changes should be made to provide some Instead, the following changes should be made to provide some
protection against such an attack. protection against such an attack.
A) If the RST bit is set and the sequence number is outside the A) If the RST bit is set and the sequence number is outside the
expected window, silently drop the segment. expected window, silently drop the segment.
B) If the RST bit is set and the sequence number exactly matches the B) If the RST bit is set and the sequence number exactly matches the
next expected sequence number, reset the connection. next expected sequence number, reset the connection.
C) If the RST bit is set and the sequence number does not exactly C) If the RST bit is set and the sequence number does not exactly
match the next expected sequence value, yet is within the match the next expected sequence value, yet is within the
acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an acceptable window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND) send an
acknowledgment: acknowledgment:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable segment After sending the acknowledgment, drop the unacceptable segment
and return. and return.
This solution forms a challenge/response with any RST where the This solution forms a challenge/response with any RST where the
value does not exactly match the expected value and yet the RST is value does not exactly match the expected value and yet the RST is
within the window. In cases of a legitimate reset without the within the window. In cases of a legitimate reset without the
exact sequence number, the consequences of this new exact sequence number, the consequences of this new challenge/
challenge/response will be that the peer requires an extra round response will be that the peer requires an extra round trip time
trip time before the connection can be reset. before the connection can be reset.
In order to alleviate multiple RSTs/SYNs from triggering multiple In order to alleviate multiple RSTs/SYNs from triggering multiple
challenge ACKs, a ACK throttling mechanism SHOULD be implemented. challenge ACKs, a ACK throttling mechanism SHOULD be implemented.
Suggested values are to send no more than 10 challenge ACKs in a 5 Suggested values are to send no more than 10 challenge ACKs in a 5
second window. These values MUST be tunable to accomodate different second window. These values MUST be tunable to accommodate different
requirements. ACK throttling if implemented successfully can lead to requirements. ACK throttling if implemented successfully can lead to
several advantages. Besides preventing the RST/ACK war outlined in several advantages. Besides preventing the RST/ACK war outlined in
the section below, it can also alleviate spurious fast retransmits at the section below, it can also alleviate spurious fast retransmits at
the remote end caused by flood of duplicate ACKs and also save the remote end caused by flood of duplicate ACKs and also save
spurious processing required to send an ACK on the victim side. spurious processing required to send an ACK on the victim side.
3. Blind reset attack using the SYN bit 3. Blind reset attack using the SYN bit
3.1 Description of the attack 3.1 Description of the attack
skipping to change at page 7, line 21 skipping to change at page 7, line 21
RST bit an attacker can use the SYN bit as well to tear down a RST bit an attacker can use the SYN bit as well to tear down a
connection. Using the same guessing technique, repeated SYN's can be connection. Using the same guessing technique, repeated SYN's can be
generated with sequence numbers incrementing by an amount not larger generated with sequence numbers incrementing by an amount not larger
than the window size apart and thus eventually cause the connection than the window size apart and thus eventually cause the connection
to be terminated. to be terminated.
3.2 Solution 3.2 Solution
RFC793 [1] currently requires handling of a segment with the SYN bit RFC793 [1] 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, changing the handling of the SYN to the following will Instead, changing the handling of the SYN to the following will
provide complete protection from this attack: provide complete protection from this attack:
1) If the SYN bit is set, irrespective of the sequence number, send 1) If the SYN bit is set, irrespective of the sequence number, send
an ACK to the remote peer: an ACK to the remote peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, drop the unacceptable segment After sending the acknowledgment, drop the unacceptable segment
and return. and return.
This solution agains forms a challenge response with the peer as
in the previous section. This solution again forms a challenge response with the peer as in
the previous section.
By always sending an ACK to the sender, a challenge/response is setup By always sending an ACK to the sender, a challenge/response is setup
with the peer. A legitimate peer, after restart, would not have a with the peer. A legitimate peer, after restart, would not have a
TCB in the synchronized state. Thus when the ACK arrives the peer TCB in the synchronized state. Thus when the ACK arrives the peer
should send a RST segment with the sequence number derived from the should send a RST segment with the sequence number derived from the
ACK field that caused the RST. ACK field that caused the RST.
Note, there is one corner case for the SYN attack problem that will Note, there is one corner case for the SYN attack problem that will
prevent the successful reset of the connection. This is a result of prevent the successful reset of the connection. This is a result of
the RFC793 [1] specification and is nothing to do with the proposed the RFC793 [1] specification and is nothing to do with the proposed
skipping to change at page 9, line 24 skipping to change at page 9, line 24
words an ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <= words an ACK value is acceptable if it is (SND.UNA-(2^^31-1)) <=
SEG.ACK <= SND.NXT). This means that an attacker simply need guess SEG.ACK <= SND.NXT). This means that an attacker simply need guess
two ACK values with every guessed sequence number so that the chances two ACK values with every guessed sequence number so that the chances
of successfully injecting data into a connection are 1 in ((2^^32 / of successfully injecting data into a connection are 1 in ((2^^32 /
RCV.WND) * 2). 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 either:
a) An ACK war will ensue with the receiver indicating that it has a) An ACK 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 a corrective ACK with a value less than and the sender sending a corrective ACK with a value less than
RCV.NXT (the real sequence number of the last byte sent). RCV.NXT (the real sequence number of the last byte sent).
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.
In either case the injected data will be made readable to the upper In either case the injected data will be made readable to the upper
layer and in case <a> the connection will eventually be reset by one layer and in case <a> the connection will eventually be reset by one
of the sides. Note that the protections illustrated in this section of the sides. Note that the protections illustrated in this section
neither cause an ACK war nor prevent one from occurring if data is neither cause an ACK war nor prevent one from occurring if data is
actually injected into a connection. The ACK war is a natural actually injected into a connection. The ACK war is a natural
consequence of any data injection that is sucessful. consequence of any data injection that is successful.
4.2 Solution 4.2 Solution
An additional input check should be added to any incoming segment. An additional input check should be added to any incoming segment.
The ACK value should be acceptable only if it is in the range of The ACK value should be acceptable only if it is in the range of
((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). MAX.SND.WND is
defined as the largest window that the local receiver has ever defined as the largest window that the local receiver has ever
advertised to it's peer. This window is the scaled value i.e. the advertised to it's peer. This window is the scaled value i.e. the
value may be larger than 65,535 bytes. This small check will greatly value may be larger than 65,535 bytes. This small check will greatly
reduce the vulnerability of an attacker guessing a valid sequence reduce the vulnerability of an attacker guessing a valid sequence
skipping to change at page 16, line 31 skipping to change at page 17, line 31
Author's Address Author's Address
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 Intellectual Property Statement
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
skipping to change at page 17, line 41 skipping to change at page 18, line 41
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/