draft-ietf-tcpm-rfc1948bis-00.txt   draft-ietf-tcpm-rfc1948bis-01.txt 
TCP Maintenance and Minor Extensions F. Gont TCP Maintenance and Minor Extensions F. Gont
(tcpm) UTN/FRH (tcpm) 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) April 23, 2011 Updates: 793 (if approved) June 28, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: October 25, 2011 Expires: December 30, 2011
Defending Against Sequence Number Attacks Defending Against Sequence Number Attacks
draft-ietf-tcpm-rfc1948bis-00.txt draft-ietf-tcpm-rfc1948bis-01.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 of guessing the sequence numbers in use by a target attacker guessing the sequence numbers in use by a target connection
connection are reduced. This document is a revision of RFC 1948, and are reduced. This document revises (and formally obsoletes) RFC
takes the ISN generation algorithm originally proposed in that 1948, and takes the ISN generation algorithm originally proposed in
document to Standards Track. that document to Standards Track.
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 October 25, 2011. This Internet-Draft will expire on December 30, 2011.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 (ISN) generation algorithm . 4 3. Proposed Initial Sequence Number generation algorithm . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Address-based trust relationship exploitation Appendix A. Address-based trust relationship exploitation
attacks . . . . . . . . . . . . . . . . . . . . . . . 9 attacks . . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10
Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 11 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) . . . 11 before publication of this document as an RFC) . . . 12
C.1. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 11 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12
C.2. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 12 C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
During the last 25 years, the Internet has experienced a number of For a long time, the Internet has experienced a number of off-path
off-path attacks against TCP connections. These attacks have ranged attacks against TCP connections. These attacks have ranged from
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]. Discusion 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. 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 Initial Sequence Numbers (ISNs), such that the chances of an of TCP ISNs, such that the chances of an off-path attacker guessing
off-path attacker of guessing valid sequence numbers are reduced. valid sequence numbers are reduced. With the aforementioned
With the aforementioned algorithm, such attacks would remain possible algorithm, such attacks would remain possible if and only if the
if and only if the Bad Guy already had the ability to launch even attacker already has the ability to perform "man in the middle"
more devastating attacks. attacks.
This document is a revision of RFC 1948, and takes the ISN generation This document revises (and formally obsoletes) RFC 1948, and takes
algorithm originally proposed in that document to Standards Track. the ISN generation algorithm originally proposed in that document to
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 ISN generation algorithm. Section 3 specifies a good ISN selection
randomization algorithm. Finally, Appendix A provides a discussion algorithm. Finally, Appendix A provides a discussion of the trust-
of the trust-relationship exploitation attacks that originally relationship exploitation attacks that originally motivated the
motivated the publication of RFC 1948 [RFC1948]. publication of RFC 1948 [RFC1948].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Generation of Initial Sequence Numbers 2. Generation of Initial Sequence Numbers
RFC 793 [RFC0793] suggests that the choice of the Initial Sequence RFC 793 [RFC0793] suggests that the choice of the ISN of a connection
Number of a connection is not arbitrary, but aims to reduce the is not arbitrary, but aims to reduce the chances of a stale segment
chances of a stale segment from being accepted by a new incarnation from being accepted by a new incarnation of a previous connection.
of a previous connection. RFC 793 [RFC0793] suggests the use of a RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator
global 32-bit ISN generator that is incremented by 1 roughly every 4 that is incremented by 1 roughly every 4 microseconds.
microseconds.
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 incomming SYN segment to perform "heuristics" that enable the
creation of a new incarnation of a connection while the previous creation of a new incarnation of a connection while the previous
incarnation is still in the TIME-WAIT state (see pp. 945 of incarnation is still in the TIME-WAIT state (see pp. 945 of
[Wright1994]). This avoids an interoperability problem that may [Wright1994]). This avoids an interoperability problem that may
arise when a systems establishes connections to a specific TCP end- arise when a node establishes connections to a specific TCP end-point
point at a high rate [Silbersack2005]. at a high rate [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
generators, and a survey of the algorithms in use by popular TCP generators, and a survey of the algorithms in use by popular TCP
implementations. implementations.
Simple randomization of the TCP Initial Sequence Numbers would Simple random selection of the TCP ISNs would mitigate those attacks
mitigate those attacks that require an attacker to guess valid that require an attacker to guess valid sequence numbers. However,
sequence numbers. However, it would also break the 4.4BSD it would also break the 4.4BSD "heuristics" to accept a new incoming
"heuristics" to accept a new incoming connection when there is a connection when there is a previous incarnation of that connection in
previous incarnation of that connection in the TIME-WAIT state the TIME-WAIT state [Silbersack2005].
[Silbersack2005].
We can prevent sequence number guessing attacks by giving each We can prevent sequence number guessing attacks by giving each
connection -- that is, each 4-tuple of (localip, localport, remoteip, connection -- that is, each 4-tuple of (localip, localport, remoteip,
remoteport) -- a separate sequence number space. Within each space, remoteport) -- a separate sequence number space. Within each space,
the initial sequence number is incremented according to [RFC0793]; the ISN is incremented according to [RFC0793]; however, there is no
however, there is no obvious relationship between the numbering in obvious relationship between the numbering in different spaces.
different spaces.
The obvious way to do this is to maintain state for dead connections, An obvious way to prevent sequence number guessing attacks while not
and the easiest way to do that is to change the TCP state transition breaking the 4.4BSD heuristics would be to maintain state for dead
diagram so that both ends of all connections go to TIME-WAIT state. connections, and the easiest way to do that would be to change the
That would work, but it's inelegant and consumes storage space. TCP state transition diagram so that both end-points of all
Instead, we propose an improvement to the TCP ISN generation connections go to TIME-WAIT state. That would work, but would
algorithm. consume system memory to store the additional state. Instead, we
propose an improvement to the TCP ISN generation algorithm, that does
not require TCP to keep state for all recently-terminated
connections.
3. Proposed Initial Sequence Number (ISN) 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 function
(PRF) of the connection-id. It is vital that F not be computable (PRF) of the connection-id. It is vital that F not be computable
from the outside, or an attacker could still guess at sequence from the outside, or an attacker could still guess at sequence
numbers from the initial sequence number used for some other numbers from the ISN used for some other connection. The PRF could
connection. The PRF could be implemented as a cryptographic hash of be implemented as a cryptographic hash of the concatenation of the
the concatenation of the connection-id and some secret data; MD5 connection-id and some secret data; MD5 [RFC1321] would be a good
[RFC1321] would be a good choice for the hash function. The secret choice for the hash function.
data can either be a true random number [RFC4086], or it can be the
combination of some per-host secret and the boot time of the machine.
The boot time is included to ensure that the secret is changed on
occasion.
Note that the secret cannot easily be changed on a live machine. The result of F() is no more secure than the the secret key. If an
Doing so would change the initial sequence numbers used for attacker is aware of which cryptographic hash function is being used
reincarnated connections; to maintain safety, either dead connection by the victim (which we should expect), and the attacker can obtain
state must be kept or a quiet time observed for two maximum segment enough material (i.e., ISNs selected by the victim), the attacker may
lifetimes after such a change. simply search the entire secret-key space to find matches. To
protect against this, the secret key should be of a reasonable
length. Key lengths of 128 bits should be adequate. The secret key
can either be a true random number [RFC4086], or some per-host
secret. A possible mechanism for protecting the secret key would be
to change it on occasion. For example, the secret key could be
changed whenever one of the following events occur:
o The system is being bootstrapped (e.g., the secret key could be a
combination of some secret and the boot time of the machine).
o Some predefined/random time has expired.
o The secret key has been used sufficiently often that it should be
regarded as insecure now.
Note that changing the secret would change the ISN space used for
reincarnated connections, and thus could lead to the 4.4BSD
heuristics to fail; to maintain safety, either dead connection state
could be kept or a quiet time observed for two maximum segment
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 hence we consider that of guessing the ISN of a new connection, and thus in our threat model
use of MD5 in the specified algorithm is acceptable. it 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
used in virtually all existing implementations of this algorithm, we
consider that use of MD5 in the specified algorithm is acceptable.
However, implementations should consider the trade-offs involved in
using functions with stronger security properties, and employ them if
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
authentication, such as that provided by IPsec [RFC4301] or TCP-AO authentication, such as that provided by IPsec [RFC4301] or TCP-AO
[RFC5925]. At best, they're a palliative measure. [RFC5925]. At best, they are a palliative measure.
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 indentifying
the number of different sequence number "spaces". the 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 isn't 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
secret, it is important to ensure that attackers can never capture secret, it is important to ensure that attackers can never capture
such packets. Typical attacks that could disclose them include both such packets. Typical attacks that could disclose them include both
eavesdropping and the variety of routing attacks discussed in eavesdropping and the variety of routing attacks discussed in
[Bellovin1989]. [Bellovin1989].
Off-path attacks against TCP connections require the attacker to
guess or know the four-tuple (localip, localport, remoteip,
remoteport) that identifies the target connection. TCP port number
randomization [RFC6056] reduces the chances of an attacker of
guessing such four-tuple by obfuscating the selection of TCP
ephemeral ports, therefore contributing to the mitigation of such
attacks. [RFC6056] provides advice on the selection of TCP ephemeral
ports, such that the overall protection of TCP connections against
off-path attacks is improved.
[CPNI-TCP] contains a discussion of all the currently-known attacks [CPNI-TCP] contains a discussion of all the currently-known attacks
that require an attacker to know or be able to guess the TCP sequence that require an attacker to know or be able to guess the TCP sequence
numbers in use by the target connection. numbers in use by the target connection.
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 woul 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, and Tim Shepard, for providing valuable comments on Allen Simpson, Tim Shepard, Wesley Eddy, and Anantha Ramaiah, for
earlier versions of this document. 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 7, line 14 skipping to change at page 7, line 43
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.
7.2. Informative References 7.2. Informative References
[Bellovin1989] [Bellovin1989]
Morris, R., "Security Problems in the TCP/IP Protocol Morris, R., "Security Problems in the TCP/IP Protocol
Suite", Computer Communications Review, vol. 19, no. 2, Suite", Computer Communications Review, vol. 19, no. 2,
pp. 32-48, 1989. pp. 32-48, 1989.
[CERT2001] [CERT2001]
CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in
TCP/IP Initial Sequence Numbers", TCP/IP Initial Sequence Numbers",
skipping to change at page 9, line 43 skipping to change at page 10, line 30
authentication mechanisms are available [RFC4954]. Another example authentication mechanisms are available [RFC4954]. Another example
is the authentication of DNS secondary servers [RFC1034] by means of is the authentication of DNS secondary servers [RFC1034] by means of
their IP addresses for allowing DNS zone transfers [RFC5936], or any their IP addresses for allowing DNS zone transfers [RFC5936], or any
other access control mechanism based on IP addresses. other access control mechanism based on IP addresses.
In 1985, Morris [Morris1985] described a form of attack based on In 1985, Morris [Morris1985] described a form of attack based on
guessing what sequence numbers TCP [RFC0793] will use for new guessing what sequence numbers TCP [RFC0793] will use for new
connections. Briefly, the attacker gags a host trusted by the connections. Briefly, the attacker gags a host trusted by the
target, impersonates the IP address of the trusted host when talking target, impersonates the IP address of the trusted host when talking
to the target, and completes the 3-way handshake based on its guess to the target, and completes the 3-way handshake based on its guess
at the next initial sequence number to be used. An ordinary at the next ISN to be used. An ordinary connection to the target is
connection to the target is used to gather sequence number state used to gather sequence number state information. This entire
information. This entire sequence, coupled with address-based sequence, coupled with address-based authentication, allows the
authentication, allows the attacker to execute commands on the target attacker to execute commands on the target host.
host.
Clearly, the proper solution for these attacks is cryptographic Clearly, the proper solution for these attacks is cryptographic
authentication [RFC4301] [RFC4120] [RFC4251]. authentication [RFC4301] [RFC4120] [RFC4251].
The following subsection provides technical details for the trust The following subsection provides technical details for the trust
relationship exploitation attack described by Morris [Morris1985]. relationship exploitation attack described by Morris [Morris1985].
A.1. Blind TCP connection-spoofing A.1. Blind TCP connection-spoofing
In order to understand the particular case of sequence number In order to understand the particular case of sequence number
skipping to change at page 10, line 24 skipping to change at page 11, line 10
A->B: SYN, ISNa A->B: SYN, ISNa
That is, it sends a packet with the SYN ("synchronize sequence That is, it sends a packet with the SYN ("synchronize sequence
number") bit set and an initial sequence number ISNa. number") bit set and an initial sequence number ISNa.
B replies with B replies with
B->A: SYN, ISNb, ACK(ISNa) B->A: SYN, ISNb, ACK(ISNa)
In addition to sending its own initial sequence number, it In addition to sending its own ISN, it acknowledges A's. Note that
acknowledges A's. Note that the actual numeric value ISNa must the actual numeric value ISNa must appear in the message.
appear in the message.
A concludes the handshake by sending A concludes the handshake by sending
A->B: ACK(ISNb) A->B: ACK(ISNb)
RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by
1 in the low-order position about every 4 microseconds. Instead, 1 in the low-order position about every 4 microseconds. Instead,
Berkeley-derived kernels traditionally incremented it by a constant Berkeley-derived kernels traditionally incremented it by a constant
every second, and by another constant for each new connection. Thus, every second, and by another constant for each new connection. Thus,
if you opened a connection to a machine, you knew to a very high if you opened a connection to a machine, you knew to a very high
skipping to change at page 11, line 30 skipping to change at page 12, line 16
connection, and thus by the time the connection is reset, the connection, and thus by the time the connection is reset, the
attacker has already won. attacker has already won.
In the past, attackers exploited a common TCP implementation bug In the past, attackers exploited a common TCP implementation bug
to prevent the connection from being reset (see subsection "A to prevent the connection from being reset (see subsection "A
Common TCP Bug" in [RFC1948]). However, all TCP implementations Common TCP Bug" in [RFC1948]). However, all TCP implementations
that used to implement this bug have been fixed for a long time. that used to implement this bug have been fixed for a long time.
Appendix B. Changes from RFC 1948 Appendix B. Changes from RFC 1948
o This document aims at Standards Track (rather than Informaitonal). o This document aims at Standards Track (rather than Informational).
o Formal requirements ([RFC2119]) are specified. o Formal requirements ([RFC2119]) are specified.
o The discussion of address-based trust relationship attacks has o The discussion of address-based trust relationship attacks has
been updated and moved to an Appendix. been updated and moved to an Appendix.
o The subsection entitled "A Common TCP Bug" (describing a common o The subsection entitled "A Common TCP Bug" (describing a common
bug in the BSD TCP implementation) has been removed. bug in the BSD TCP implementation) has been removed.
Appendix C. Changes from previous versions of the document (this Appendix C. Changes from previous versions of the document (this
section should be removed by the RFC Editor before section should be removed by the RFC Editor before
publication of this document as an RFC) publication of this document as an RFC)
C.1. Changes from draft-gont-tcpm-rfc1948bis-00 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00
o Addresses WGLC feedback (posted on-list) by Wesley Eddy, and some
comments submitted by Anantha Ramaiah.
C.2. Changes from draft-gont-tcpm-rfc1948bis-00
o The recommended hash algorithm has been changed back to MD5 o The recommended hash algorithm has been changed back to MD5
[RFC1321], with a note that the security implications of MD5 have [RFC1321], with a note that the security implications of MD5 have
been carefully considered. been carefully considered.
o The subsection entitled "An old BSD bug" (describing a common bug o The subsection entitled "An old BSD bug" (describing a common bug
in the BSD TCP implementation) has been removed. in the BSD TCP implementation) has been removed.
o Minor editorial changes. o Minor editorial changes.
C.2. Changes from RFC 1948 C.3. Changes from RFC 1948
o New document aims at Standards Track (rather than Informaitonal). o New document aims at Standards Track (rather than Informational).
o The discussion of address-based trust relationship attacks was o The discussion of address-based trust relationship attacks was
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
 End of changes. 34 change blocks. 
90 lines changed or deleted 131 lines changed or added

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