--- 1/draft-ietf-tcpm-rfc1948bis-01.txt 2011-12-16 23:13:56.282702409 +0100 +++ 2/draft-ietf-tcpm-rfc1948bis-02.txt 2011-12-16 23:13:56.306671610 +0100 @@ -1,47 +1,47 @@ TCP Maintenance and Minor Extensions F. Gont -(tcpm) UTN/FRH +(tcpm) SI6 Networks / UTN-FRH Internet-Draft S. Bellovin Obsoletes: 1948 (if approved) Columbia University -Updates: 793 (if approved) June 28, 2011 +Updates: 793 (if approved) December 16, 2011 Intended status: Standards Track -Expires: December 30, 2011 +Expires: June 18, 2012 Defending Against Sequence Number Attacks - draft-ietf-tcpm-rfc1948bis-01.txt + draft-ietf-tcpm-rfc1948bis-02.txt Abstract This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,49 +54,49 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 3. Proposed Initial Sequence Number generation algorithm . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Address-based trust relationship exploitation attacks . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12 Appendix C. Changes from previous versions of the document (this section should be removed by the RFC Editor before publication of this document as an RFC) . . . 12 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12 C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12 C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction For a long time, the Internet has experienced a number of off-path attacks against TCP connections. These attacks have ranged from 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 on guessing what sequence numbers TCP [RFC0793] will use for new connections between two known end-points. In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection - of TCP ISNs, such that the chances of an off-path attacker guessing - valid sequence numbers are reduced. With the aforementioned - algorithm, such attacks would remain possible if and only if the - attacker already has the ability to perform "man in the middle" - attacks. + of TCP Initial Sequence Numbers (ISNs), such that the chances of an + off-path attacker guessing valid sequence numbers are reduced. With + the aforementioned algorithm, such attacks would remain possible if + and only if the attacker already has the ability to perform "man in + the middle" attacks. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. Section 2 provides a brief discussion of the requirements for a good ISN generation algorithm. Section 3 specifies a good ISN selection algorithm. Finally, Appendix A provides a discussion of the trust- relationship exploitation attacks that originally motivated the publication of RFC 1948 [RFC1948]. @@ -116,26 +116,26 @@ It is interesting to note that, as a matter of fact, protection against stale segments from a previous incarnation of the connection is enforced by preventing the creation of a new incarnation of a previous connection before 2*MSL have passed since a segment corresponding to the old incarnation was last seen. This is accomplished by the TIME-WAIT state, and TCP's "quiet time" concept (see Appendix B of [RFC1323]). Based on the assumption that ISNs are monotonically-increasing across connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an - incomming SYN segment to perform "heuristics" that enable the - creation of a new incarnation of a connection while the previous - incarnation is still in the TIME-WAIT state (see pp. 945 of - [Wright1994]). This avoids an interoperability problem that may - arise when a node establishes connections to a specific TCP end-point - at a high rate [Silbersack2005]. + incoming SYN segment to perform "heuristics" that enable the creation + of a new incarnation of a connection while the previous incarnation + is still in the TIME-WAIT state (see pp. 945 of [Wright1994]). This + avoids an interoperability problem that may arise when a node + establishes connections to a specific TCP end-point at a high rate + [Silbersack2005]. Unfortunately, the ISN generator described in [RFC0793] makes it 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 TCP connections [CPNI-TCP]. One of the possible attacks that takes advantage of weak sequence numbers was first described in [Morris1985], and its exploitation was widely publicized about 10 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are advisories about the security implications of weak ISN generators. [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN @@ -163,29 +163,29 @@ 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 generation algorithm TCP SHOULD generate its Initial Sequence Numbers with the expression: ISN = M + F(localip, localport, remoteip, remoteport) - 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 - from the outside, or an attacker could still guess at sequence - numbers from the ISN used for some other connection. The PRF could - be implemented as a cryptographic hash of the concatenation of the + where M is the 4 microsecond timer, and F() is a pseudorandom + function (PRF) of the connection-id. F() MUST NOT be computable from + the outside, or an attacker could still guess at sequence numbers + from the ISN used for some other connection. The PRF could be + implemented as a cryptographic hash of the concatenation of the connection-id and some secret data; MD5 [RFC1321] would be a good 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 by the victim (which we should expect), and the attacker can obtain enough material (i.e., ISNs selected by the victim), the attacker may 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: @@ -200,22 +200,22 @@ 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 security properties of MD5 [RFC6151], the algorithm specified in this 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 - it is not worth the effort for an attacker to try to learn the secret + guessing the ISN of a new connection, and thus in our threat model 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 Good sequence numbers are not a replacement for cryptographic @@ -225,22 +225,22 @@ If random numbers are used as the sole source of the secret, they MUST be chosen in accordance with the recommendations given in [RFC4086]. A security consideration that should be made about the algorithm proposed in this document is that it might allow an attacker to count the number of systems behind a Network Address Translator (NAT) [RFC3022]. Depending on the ISN generators implemented by each of 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 - connections (using the public address of the NAT) and indentifying - the number of different sequence number "spaces". + connections (using the public address of the NAT) and identifying the + number of different sequence number "spaces". [I-D.gont-behave-nat-security] discusses how this and other information leakages at NATs could be mitigated. An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection. However, such an eavesdropper can also hijack existing connections [Joncheray1995], so the incremental threat is not that 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 @@ -266,24 +266,25 @@ 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, on which this document is based. Frank Kastenholz contributed 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 - Allen Simpson, Tim Shepard, Wesley Eddy, and Anantha Ramaiah, for - providing valuable comments on earlier versions of this document. + Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben + Campbell, for providing valuable comments on earlier versions of this + document. Fernando Gont would like to thank the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI) for their continued support. 7. References 7.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, @@ -550,28 +551,28 @@ updated and moved to an Appendix. o The recommended hash algorithm has been changed to SHA-256, in response to the security concerns for MD5 [RFC1321]. o Formal requirements ([RFC2119]) are specified. Authors' Addresses Fernando Gont - Universidad Tecnologica Nacional / Facultad Regional Haedo + UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fernando@gont.com.ar - URI: http://www.gont.com.ar + URI: http://www.si6networks.com Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US Phone: +1 212 939 7149 Email: bellovin@acm.org