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/ |