draft-ietf-tcpm-tcpsecure-01.txt   draft-ietf-tcpm-tcpsecure-02.txt 
Network Working Group M. Dalal Network Working Group M. Dalal
Internet-Draft Editor Internet-Draft Editor
Expires: December 1, 2004 June 2, 2004 Expires: May 23, 2005 November 22, 2004
Transmission Control Protocol security considerations Transmission Control Protocol security considerations
draft-ietf-tcpm-tcpsecure-01.txt draft-ietf-tcpm-tcpsecure-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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 become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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-Drafts. Internet-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 December 1, 2004. This Internet-Draft will expire on May 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 17 skipping to change at page 2, line 19
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 Compatability and Other considerations . . . . . . . 10 5. Backward Compatibility and Other considerations . . . . . . . 10
6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 12 6. Middlebox considerations . . . . . . . . . . . . . . . . . . . 12
6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 12 6.1 Middlebox that cache RST's . . . . . . . . . . . . . . . . 12
6.2 Middleboxes that advance sequence numbers . . . . . . . . 12 6.2 Middleboxes that advance sequence numbers . . . . . . . . 12
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
9.2 Informative References . . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 17
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 [2] 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 infrastucture, agree upon a pre-shared key. In the absence of PKI infrastr1ucture,
this may be incovenient. IPSec with manual keys can be used to avoid this may be inconvenient. IPSec with manual keys can be used to
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-bit value and changes dramatically within the life of a 32-bit value and changes dramatically within the life of a
connection. Neverthless, both of them are complimentary solutions connection. Nevertheless, both of them are complimentary solutions
that will make it difficult to launch attacks discussed below. that will make it difficult to launch attacks discussed below.
This proposal provides immediate protection to a TCP session even Alternative proposals, including the use of cookies (or, use of the
when implemented on only one peer. Alternative proposals, including timestamp option as a cookie) require both peers to implement the
the use of cookies (or, use of the timestamp option as a cookie) changes before any additional protection can be realized.
require both peers to implement the 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
a TCP connection the attacker would have to guess a single sequence a TCP connection the attacker would have to guess a single sequence
number in the TCP sequence space. This would in effect require an number in the TCP sequence space. This would in effect require an
attacker to generate (2^^32) segments in order to reset a connection. attacker to generate (2^^32) segments in order to reset a connection.
Recent papers have shown this to not necessarily be the case. An Recent papers have shown this to not necessarily be the case. An
attacker need only guess a number that lies between the last sequence attacker need only guess a number that lies between the last sequence
number acknowledged and the last sequence number acknowledged added number acknowledged and the last sequence number acknowledged added
to the receiver window (RCV.WND).([4]).Modern operating systems to the receiver window (RCV.WND)[4]. Modern operating systems
normally default the RCV.WND to about 32,768 bytes. This means that normally default the RCV.WND to about 32,768 bytes. This means that
a blind attacker need only guess 65,535 RST segments (2^^32/RCV.WND) a blind attacker need only guess 65,535 RST segments (2^^32/RCV.WND)
in order to reset a connection. At DSL speeds this means that most in order to reset a connection. At DSL speeds this means that most
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
skipping to change at page 5, line 51 skipping to change at page 5, line 51
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 challenge/ exact sequence number, the consequences of this new
response will be that the peer requires an extra round trip time challenge/response will be that the peer requires an extra round
before the connection can be reset. trip time 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 accomodate 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.
skipping to change at page 9, line 20 skipping to change at page 9, line 20
attacks. It is quite possible to inject data into a TCP connection attacks. It is quite possible to inject data into a TCP connection
by simply guessing a sequence value that is within the window. The by simply guessing a sequence value that is within the window. The
ACK value of any data segment is considered valid as long as it does ACK value of any data segment is considered valid as long as it does
not acknowledge data ahead of the next segment to send. In other not acknowledge data ahead of the next segment to send. In other
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 sucessfully 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 occuring 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 sucessful.
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
number since not only must he/she guess the sequence number in number since not only must he/she guess the sequence number in
window, but must also guess a proper ACK value within a scoped range. window, but must also guess a proper ACK value within a scoped range.
This solution reduces but does not eliminate the ability to generate This solution reduces but does not eliminate the ability to generate
false segments. It does however reduce the probability that invalid false segments. It does however reduce the probability that invalid
data will be injected to a more acceptable level. For those data will be injected to a more acceptable level. For those
applications that wish to close this attack completely RFC2385 [2] applications that wish to close this attack completely RFC2385 [2]
should be deployed between the two endpoints. should be deployed between the two endpoints.
5. Backward Compatability and Other considerations 5. Backward Compatibility and Other considerations
1) The proposed solution is backward compatible as it uses the 1) The proposed solution is backward compatible as it uses the
semantics laid down in RFC793 [1] to defend against it's own semantics laid down in RFC793 [1] to defend against it's own
weakness. Referring to the figure below, if we assume that the weakness. Referring to the figure below, if we assume that the
RST (1.c) was in flight when the ACK (2) left TCP A, TCP B has no RST (1.c) was in flight when the ACK (2) left TCP A, TCP B has no
way of knowing what triggered the ACK. For all it cares, the ACK way of knowing what triggered the ACK. For all it cares, the ACK
might have been a result of the data or the RST that it had sent might have been a result of the data or the RST that it had sent
earlier. Hence in either case, TCP B must reply to this ACK with earlier. Hence in either case, TCP B must reply to this ACK with
an appropriate RST that is in keeping with RFC793 [1]. an appropriate RST that is in keeping with RFC793 [1].
skipping to change at page 10, line 32 skipping to change at page 10, line 32
an ACK. A spoofer can simply send packets with sequence numbers an ACK. A spoofer can simply send packets with sequence numbers
that are outside the acceptable window of the attacker or send an that are outside the acceptable window of the attacker or send an
ACK that acknowledges something that is not yet sent. Further, an ACK that acknowledges something that is not yet sent. Further, an
attacker can also simply generate data packets that fall within attacker can also simply generate data packets that fall within
the window to cause an ACK to be sent. RFC793 [1] also mandates the window to cause an ACK to be sent. RFC793 [1] also mandates
that an ACK be sent if the incoming SYN to an established that an ACK be sent if the incoming SYN to an established
connection falls outside the acceptable window. All these connection falls outside the acceptable window. All these
scenarios can be used to launch a flood attack. However, the scenarios can be used to launch a flood attack. However, the
potential harm of such attacks are low and can be easily detected potential harm of such attacks are low and can be easily detected
due to the volume of packets generated. The latter is a strong due to the volume of packets generated. The latter is a strong
deterrant to such attacks. deterrent to such attacks.
3) There is a corner scenario in the above proposed solutions which 3) There is a corner scenario in the above proposed solutions which
will require more than one round trip time to successfully abort will require more than one round trip time to successfully abort
the connection as per the figure below. This scenario is similar the connection as per the figure below. This scenario is similar
to the one in which the original RST was lost in the network. to the one in which the original RST was lost in the network.
TCP A TCP B TCP A TCP B
1.a. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED 1.a. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED
b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED b. (delayed) ... <SEQ=400><ACK=101><CTL=ACK><DATA> <-- ESTABLISHED
c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED c. (in flight) ... <SEQ=500><ACK=101><CTL=RST> <-- CLOSED
skipping to change at page 12, line 5 skipping to change at page 11, line 8
(for 1.c) (for 1.c)
... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE ... <SEQ=400><ACK=0><CTL=RST> <-- RESPONSE
4.a. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A 4.a. ESTABLISHED <-- <SEQ=400><ACK=101><CTL=ACK><DATA> 1.b reaches A
b. ESTABLISHED --> <SEQ=101><ACK=500><CTL=ACK> b. ESTABLISHED --> <SEQ=101><ACK=500><CTL=ACK>
c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED c. (in flight) ... <SEQ=500><ACK=0><CTL=RST> <-- CLOSED
5. RESPONSE arrives at A, but is dropped because of being out of window. 5. RESPONSE arrives at A, but is dropped because of being out of window.
6. ESTABLISHED <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A 6. ESTABLISHED <-- <SEQ=500><ACK=0><CTL=RST> 4.c reaches A
7. CLOSED CLOSE 7. CLOSED CLOSE
4) For the solution to be totally effective against the
vulnerabilities discussed in this document, both ends of the TCP
connection need to have the fix. Although, having it at one end
might prevent that end from being exposed to the attack, the
connection is still vulnerable at the other end.
6. Middlebox considerations 6. Middlebox considerations
The following scenarios were brought to notice by the tcpm working The following scenarios were brought to notice by the tcpm working
group members as middlebox issues which may cause the proposed group members as middlebox issues which may cause the proposed
solution to behave in an unexpected manner. solution to behave in an unexpected manner.
6.1 Middlebox that cache RST's 6.1 Middlebox that cache RST's
Consider a middlebox B tracking connection between two TCP endhosts A Consider a middlebox B tracking connection between two TCP endhosts A
and C. If C sends a RST with a sequence number that is within the and C. If C sends a RST with a sequence number that is within the
skipping to change at page 12, line 29 skipping to change at page 12, line 29
proposed fix above, it will send a challenge ACK. B being a proposed fix above, it will send a challenge ACK. B being a
middlebox will intercept this ACK and resend the RST cached earlier middlebox will intercept this ACK and resend the RST cached earlier
that was responsible for bringing down the connection. However, the that was responsible for bringing down the connection. However, the
RST will again be not acceptable and will trigger a challenge ACK RST will again be not acceptable and will trigger a challenge ACK
again. This will cause a RST/ACK war to happen. However, we are not again. This will cause a RST/ACK war to happen. However, we are not
aware of middleboxes that actually do this and believe the design aware of middleboxes that actually do this and believe the design
itself is flawed in that given the scenario that the RST from B to A itself is flawed in that given the scenario that the RST from B to A
got lost on the way, A will continue to hold the connection and A got lost on the way, A will continue to hold the connection and A
might send an ACK an arbitrary time after the connection was brought might send an ACK an arbitrary time after the connection was brought
down at B. In this case, B will have to cache the RST for an down at B. In this case, B will have to cache the RST for an
arbitrary amount of time till its confirmed that the connection has arbitrary amount of time till it's confirmed that the connection has
been cleared at A. been cleared at A.
6.2 Middleboxes that advance sequence numbers 6.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 setup is the same as the earlier case, of the acceptable window. The setup is the same as the earlier case,
but in this case instead of sending the cached RST, the middlebox but in this case instead of sending the cached RST, the middlebox
sends a RST that computes it's sequence number as a sum of the ack sends a RST that computes it's sequence number as a sum of the ack
field in the ACK and the window advertised by the ACK that was sent field in the ACK and the window advertised by the ACK that was sent
by A to challenge the RST as depicted below. The difference in the by A to challenge the RST as depicted below. The difference in the
 End of changes. 

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