< draft-ietf-tcpm-rfc1948bis-01.txt   draft-ietf-tcpm-rfc1948bis-02.txt >
TCP Maintenance and Minor Extensions F. Gont TCP Maintenance and Minor Extensions F. Gont
(tcpm) UTN/FRH (tcpm) SI6 Networks / UTN-FRH
Internet-Draft S. Bellovin Internet-Draft S. Bellovin
Obsoletes: 1948 (if approved) Columbia University Obsoletes: 1948 (if approved) Columbia University
Updates: 793 (if approved) June 28, 2011 Updates: 793 (if approved) December 16, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: December 30, 2011 Expires: June 18, 2012
Defending Against Sequence Number Attacks Defending Against Sequence Number Attacks
draft-ietf-tcpm-rfc1948bis-01.txt draft-ietf-tcpm-rfc1948bis-02.txt
Abstract Abstract
This document specifies an algorithm for the generation of TCP This document specifies an algorithm for the generation of TCP
Initial Sequence Numbers (ISNs), such that the chances of an off-path Initial Sequence Numbers (ISNs), such that the chances of an off-path
attacker guessing the sequence numbers in use by a target connection attacker guessing the sequence numbers in use by a target connection
are reduced. This document revises (and formally obsoletes) RFC are reduced. This document revises (and formally obsoletes) RFC
1948, and takes the ISN generation algorithm originally proposed in 1948, and takes the ISN generation algorithm originally proposed in
that document to Standards Track. that document to Standards Track, formally updating RFC 793.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 30, 2011. This Internet-Draft will expire on June 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3
3. Proposed Initial Sequence Number generation algorithm . . . . 4 3. Proposed Initial Sequence Number generation algorithm . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Address-based trust relationship exploitation Appendix A. Address-based trust relationship exploitation
attacks . . . . . . . . . . . . . . . . . . . . . . . 10 attacks . . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10
Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12 Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12
Appendix C. Changes from previous versions of the document Appendix C. Changes from previous versions of the document
(this section should be removed by the RFC Editor (this section should be removed by the RFC Editor
before publication of this document as an RFC) . . . 12 before publication of this document as an RFC) . . . 12
C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12
C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12 C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12
C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13 C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
For a long time, the Internet has experienced a number of off-path For a long time, the Internet has experienced a number of off-path
attacks against TCP connections. These attacks have ranged from attacks against TCP connections. These attacks have ranged from
trust relationships exploitation to Denial of Service attacks trust relationships exploitation to Denial of Service attacks
[CPNI-TCP]. Discusion of some of these attacks dates back to at [CPNI-TCP]. Discussion of some of these attacks dates back to at
least 1985, when Morris [Morris1985] described a form of attack based least 1985, when Morris [Morris1985] described a form of attack based
on guessing what sequence numbers TCP [RFC0793] will use for new on guessing what sequence numbers TCP [RFC0793] will use for new
connections between two known end-points. connections between two known end-points.
In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection
of TCP ISNs, such that the chances of an off-path attacker guessing of TCP Initial Sequence Numbers (ISNs), such that the chances of an
valid sequence numbers are reduced. With the aforementioned off-path attacker guessing valid sequence numbers are reduced. With
algorithm, such attacks would remain possible if and only if the the aforementioned algorithm, such attacks would remain possible if
attacker already has the ability to perform "man in the middle" and only if the attacker already has the ability to perform "man in
attacks. the middle" attacks.
This document revises (and formally obsoletes) RFC 1948, and takes This document revises (and formally obsoletes) RFC 1948, and takes
the ISN generation algorithm originally proposed in that document to the ISN generation algorithm originally proposed in that document to
Standards Track. Standards Track.
Section 2 provides a brief discussion of the requirements for a good Section 2 provides a brief discussion of the requirements for a good
ISN generation algorithm. Section 3 specifies a good ISN selection ISN generation algorithm. Section 3 specifies a good ISN selection
algorithm. Finally, Appendix A provides a discussion of the trust- algorithm. Finally, Appendix A provides a discussion of the trust-
relationship exploitation attacks that originally motivated the relationship exploitation attacks that originally motivated the
publication of RFC 1948 [RFC1948]. publication of RFC 1948 [RFC1948].
skipping to change at page 4, line 7 skipping to change at page 4, line 7
It is interesting to note that, as a matter of fact, protection It is interesting to note that, as a matter of fact, protection
against stale segments from a previous incarnation of the connection against stale segments from a previous incarnation of the connection
is enforced by preventing the creation of a new incarnation of a is enforced by preventing the creation of a new incarnation of a
previous connection before 2*MSL have passed since a segment previous connection before 2*MSL have passed since a segment
corresponding to the old incarnation was last seen. This is corresponding to the old incarnation was last seen. This is
accomplished by the TIME-WAIT state, and TCP's "quiet time" concept accomplished by the TIME-WAIT state, and TCP's "quiet time" concept
(see Appendix B of [RFC1323]). (see Appendix B of [RFC1323]).
Based on the assumption that ISNs are monotonically-increasing across Based on the assumption that ISNs are monotonically-increasing across
connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an
incomming SYN segment to perform "heuristics" that enable the incoming SYN segment to perform "heuristics" that enable the creation
creation of a new incarnation of a connection while the previous of a new incarnation of a connection while the previous incarnation
incarnation is still in the TIME-WAIT state (see pp. 945 of is still in the TIME-WAIT state (see pp. 945 of [Wright1994]). This
[Wright1994]). This avoids an interoperability problem that may avoids an interoperability problem that may arise when a node
arise when a node establishes connections to a specific TCP end-point establishes connections to a specific TCP end-point at a high rate
at a high rate [Silbersack2005]. [Silbersack2005].
Unfortunately, the ISN generator described in [RFC0793] makes it Unfortunately, the ISN generator described in [RFC0793] makes it
trivial for an off-path attacker to predict the ISN that a TCP will trivial for an off-path attacker to predict the ISN that a TCP will
use for new connections, thus allowing a variety of attacks against use for new connections, thus allowing a variety of attacks against
TCP connections [CPNI-TCP]. One of the possible attacks that takes TCP connections [CPNI-TCP]. One of the possible attacks that takes
advantage of weak sequence numbers was first described in advantage of weak sequence numbers was first described in
[Morris1985], and its exploitation was widely publicized about 10 [Morris1985], and its exploitation was widely publicized about 10
years later [Shimomura1995]. [CERT2001] and [USCERT2001] are years later [Shimomura1995]. [CERT2001] and [USCERT2001] are
advisories about the security implications of weak ISN generators. advisories about the security implications of weak ISN generators.
[Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN
skipping to change at page 5, line 7 skipping to change at page 5, line 7
propose an improvement to the TCP ISN generation algorithm, that does propose an improvement to the TCP ISN generation algorithm, that does
not require TCP to keep state for all recently-terminated not require TCP to keep state for all recently-terminated
connections. connections.
3. Proposed Initial Sequence Number generation algorithm 3. Proposed Initial Sequence Number generation algorithm
TCP SHOULD generate its Initial Sequence Numbers with the expression: TCP SHOULD generate its Initial Sequence Numbers with the expression:
ISN = M + F(localip, localport, remoteip, remoteport) ISN = M + F(localip, localport, remoteip, remoteport)
where M is the 4 microsecond timer, and F is a pseudorandom function where M is the 4 microsecond timer, and F() is a pseudorandom
(PRF) of the connection-id. It is vital that F not be computable function (PRF) of the connection-id. F() MUST NOT be computable from
from the outside, or an attacker could still guess at sequence the outside, or an attacker could still guess at sequence numbers
numbers from the ISN used for some other connection. The PRF could from the ISN used for some other connection. The PRF could be
be implemented as a cryptographic hash of the concatenation of the implemented as a cryptographic hash of the concatenation of the
connection-id and some secret data; MD5 [RFC1321] would be a good connection-id and some secret data; MD5 [RFC1321] would be a good
choice for the hash function. choice for the hash function.
The result of F() is no more secure than the the secret key. If an The result of F() is no more secure than the secret key. If an
attacker is aware of which cryptographic hash function is being used attacker is aware of which cryptographic hash function is being used
by the victim (which we should expect), and the attacker can obtain by the victim (which we should expect), and the attacker can obtain
enough material (i.e., ISNs selected by the victim), the attacker may enough material (i.e., ISNs selected by the victim), the attacker may
simply search the entire secret-key space to find matches. To simply search the entire secret-key space to find matches. To
protect against this, the secret key should be of a reasonable protect against this, the secret key should be of a reasonable
length. Key lengths of 128 bits should be adequate. The secret key length. Key lengths of 128 bits should be adequate. The secret key
can either be a true random number [RFC4086], or some per-host can either be a true random number [RFC4086], or some per-host
secret. A possible mechanism for protecting the secret key would be secret. A possible mechanism for protecting the secret key would be
to change it on occasion. For example, the secret key could be to change it on occasion. For example, the secret key could be
changed whenever one of the following events occur: changed whenever one of the following events occur:
skipping to change at page 5, line 44 skipping to change at page 5, line 44
Note that changing the secret would change the ISN space used for Note that changing the secret would change the ISN space used for
reincarnated connections, and thus could lead to the 4.4BSD reincarnated connections, and thus could lead to the 4.4BSD
heuristics to fail; to maintain safety, either dead connection state heuristics to fail; to maintain safety, either dead connection state
could be kept or a quiet time observed for two maximum segment could be kept or a quiet time observed for two maximum segment
lifetimes before such a change. lifetimes before such a change.
It should be noted that while there have been concerns about the It should be noted that while there have been concerns about the
security properties of MD5 [RFC6151], the algorithm specified in this security properties of MD5 [RFC6151], the algorithm specified in this
document simply aims at reducing the chances of an off-path attacker document simply aims at reducing the chances of an off-path attacker
of guessing the ISN of a new connection, and thus in our threat model guessing the ISN of a new connection, and thus in our threat model it
it is not worth the effort for an attacker to try to learn the secret is not worth the effort for an attacker to try to learn the secret
key. Since MD5 is faster than other "stronger" alternatives, and is key. Since MD5 is faster than other "stronger" alternatives, and is
used in virtually all existing implementations of this algorithm, we used in virtually all existing implementations of this algorithm, we
consider that use of MD5 in the specified algorithm is acceptable. consider that use of MD5 in the specified algorithm is acceptable.
However, implementations should consider the trade-offs involved in However, implementations should consider the trade-offs involved in
using functions with stronger security properties, and employ them if using functions with stronger security properties, and employ them if
it is deemed appropriate. it is deemed appropriate.
4. Security Considerations 4. Security Considerations
Good sequence numbers are not a replacement for cryptographic Good sequence numbers are not a replacement for cryptographic
skipping to change at page 6, line 21 skipping to change at page 6, line 21
If random numbers are used as the sole source of the secret, they If random numbers are used as the sole source of the secret, they
MUST be chosen in accordance with the recommendations given in MUST be chosen in accordance with the recommendations given in
[RFC4086]. [RFC4086].
A security consideration that should be made about the algorithm A security consideration that should be made about the algorithm
proposed in this document is that it might allow an attacker to count proposed in this document is that it might allow an attacker to count
the number of systems behind a Network Address Translator (NAT) the number of systems behind a Network Address Translator (NAT)
[RFC3022]. Depending on the ISN generators implemented by each of [RFC3022]. Depending on the ISN generators implemented by each of
the systems behind the NAT, an attacker might be able to count the the systems behind the NAT, an attacker might be able to count the
number of systems behind a NAT by establishing a number of TCP number of systems behind a NAT by establishing a number of TCP
connections (using the public address of the NAT) and indentifying connections (using the public address of the NAT) and identifying the
the number of different sequence number "spaces". number of different sequence number "spaces".
[I-D.gont-behave-nat-security] discusses how this and other [I-D.gont-behave-nat-security] discusses how this and other
information leakages at NATs could be mitigated. information leakages at NATs could be mitigated.
An eavesdropper who can observe the initial messages for a connection An eavesdropper who can observe the initial messages for a connection
can determine its sequence number state, and may still be able to can determine its sequence number state, and may still be able to
launch sequence number guessing attacks by impersonating that launch sequence number guessing attacks by impersonating that
connection. However, such an eavesdropper can also hijack existing connection. However, such an eavesdropper can also hijack existing
connections [Joncheray1995], so the incremental threat is not that connections [Joncheray1995], so the incremental threat is not that
high. Still, since the offset between a fake connection and a given high. Still, since the offset between a fake connection and a given
real connection will be more or less constant for the lifetime of the real connection will be more or less constant for the lifetime of the
skipping to change at page 7, line 15 skipping to change at page 7, line 15
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgements 6. Acknowledgements
Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948,
on which this document is based. Frank Kastenholz contributed on which this document is based. Frank Kastenholz contributed
constructive comments to that memo. constructive comments to that memo.
The authors of this document woul like to thank (in chronological The authors of this document would like to thank (in chronological
order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William
Allen Simpson, Tim Shepard, Wesley Eddy, and Anantha Ramaiah, for Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben
providing valuable comments on earlier versions of this document. Campbell, for providing valuable comments on earlier versions of this
document.
Fernando Gont would like to thank the United Kingdom's Centre for the Fernando Gont would like to thank the United Kingdom's Centre for the
Protection of National Infrastructure (UK CPNI) for their continued Protection of National Infrastructure (UK CPNI) for their continued
support. support.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
skipping to change at page 13, line 20 skipping to change at page 13, line 20
updated and moved to an Appendix. updated and moved to an Appendix.
o The recommended hash algorithm has been changed to SHA-256, in o The recommended hash algorithm has been changed to SHA-256, in
response to the security concerns for MD5 [RFC1321]. response to the security concerns for MD5 [RFC1321].
o Formal requirements ([RFC2119]) are specified. o Formal requirements ([RFC2119]) are specified.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo UTN-FRH / SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fernando@gont.com.ar
URI: http://www.gont.com.ar URI: http://www.si6networks.com
Steven M. Bellovin Steven M. Bellovin
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
MC 0401 MC 0401
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7149 Phone: +1 212 939 7149
Email: bellovin@acm.org Email: bellovin@acm.org
 End of changes. 18 change blocks. 
34 lines changed or deleted 35 lines changed or added

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