--- 1/draft-ietf-tcpm-tcp-timestamps-01.txt 2010-12-07 15:12:54.000000000 +0100 +++ 2/draft-ietf-tcpm-tcp-timestamps-02.txt 2010-12-07 15:12:54.000000000 +0100 @@ -1,19 +1,19 @@ TCP Maintenance and Minor F. Gont Extensions (tcpm) UK CPNI -Internet-Draft November 16, 2010 +Internet-Draft December 7, 2010 Intended status: BCP -Expires: May 20, 2011 +Expires: June 10, 2011 Reducing the TIME-WAIT state using TCP timestamps - draft-ietf-tcpm-tcp-timestamps-01.txt + draft-ietf-tcpm-tcp-timestamps-02.txt Abstract This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. This document only modifies processing of SYN segments received for connections in the TIME-WAIT state; processing in all other states is unchanged. @@ -25,21 +25,21 @@ 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 May 20, 2011. + This Internet-Draft will expire on June 10, 2011. Copyright Notice Copyright (c) 2010 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 @@ -72,26 +72,27 @@ 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Behavior of the proposed mechanism in specific scenarios . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Connection request after system reboot . . . . . . . . . . 10 Appendix B. Changes from previous versions of the draft (to be removed by the RFC Editor before publishing this document as an RFC) . . . . . . . . . . . . . . 10 - B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10 - B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 - B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 10 - B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 - B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 - B.6. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 + B.1. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10 + B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10 + B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 + B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11 + B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 + B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 + B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments, that can be used to perform two functions: Round-Trip Time Measurement (RTTM), and Protection Against Wrapped Sequences (PAWS). For the purpose of PAWS, the timestamps sent on a connection are @@ -149,21 +150,21 @@ The following paragraphs summarize the processing of SYN segments received for connections in the TIME-WAIT state. The processing of SYN segments received for connections in all other states is unchanged. Both the ISN (Initial Sequence Number) and the timestamps option (if present) of the incoming SYN segment are included in the heuristics performed for allowing a high connection-establishment rate. Processing of SYN segments received for connections in the TIME-WAIT - state should occur as follows: + state SHOULD occur as follows: o If the previous incarnation of the connection used timestamps, then, * If TCP timestamps would be enabled for the new incarnation of the connection, and the timestamp contained in the incoming SYN segment is greater than the last timestamp seen on the previous incarnation of the connection (for that direction of the data transfer), honour the connection request (creating a connection in the SYN-RECEIVED state). @@ -245,23 +246,23 @@ heuristics described above, all these constraints are greatly relaxed. It is clear that the use of TCP timestamps for the heuristics described above benefit from timestamps that are monotonically increasing across connections between the same two TCP endpoints. Note: The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis], recommends the selection of timestamps such that they are - monotonically-increasing across connections. Specific - implementation details for such a Timestamps generation scheme can - be found in [I-D.gont-timestamps-generation]. + monotonically-increasing across connections. An example of such a + Timestamps generation scheme can be found in + [I-D.gont-timestamps-generation]. 3. Interaction with various timestamps generation algorithms The algorithm proposed in Section 2 clearly benefits of timestamps that are monotonically-increasing across connections to the same end- point. In particular, generation of timestamps such that they are monotonically-increasing timestamps are important for TCPs that perform the active open, as those are the timestamps that will be used for the proposed algorithm. @@ -298,21 +299,21 @@ algorithms which do not result in monotonically-increasing ISNs across connections. As noted in [Silbersack], such randomization schemes break prevent the mechanism proposed in this document from recycling connections that are in the TIME-WAIT state. However, as noted earlier in this section, in the worst-case scenario the heuristics fail, and the result is no worse than the current state- of-affairs. 4. Interaction with various ISN generation algorithms - [RFC0793] suggests that the ISNs of TCP conections be generated from + [RFC0793] suggests that the ISNs of TCP connections be generated from a global timer, such that they are monotonically-increasing across connections. However, this ISN-generation scheme leads to predictable ISNs, which have well-known security implications [CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme which results in monotonically-increasing timestamps across connections that are not easily-predictable by an off-path attacker. Some stacks (notably OpenBSD) implement ISN randomization algorithms which do not result in monotonically-increasing ISNs across connections. As noted in [Silbersack], such ISN randomization @@ -325,36 +326,36 @@ the timestamp contained in the incoming SYN is equal to the last timestamp seen on the connection in the TIME-WAIT state (for that direction of the data transfer). 5. Security Considerations While the algorithm described in this document for processing incoming SYN segments would benefit from TCP timestamps that are monotonically-increasing across connections, this document does not propose any specific algorithm for generating timestamps, nor does it - require monotonically-increasing timestamps across conenctions. + require monotonically-increasing timestamps across connections. [CPNI-TCP] contains a detailed discussion of the security implications of TCP timestamps. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgements The author of this document would like to thank (in alphabetical - order) Mark Allman, Wesley Eddy, Alfred Hoenes, John Heffner, - Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann - for providing valuable feedback on an earlier version of this - document. + order) Mark Allman, Wesley Eddy, Lars Eggert, Alfred Hoenes, John + Heffner, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander + Zimmermann for providing valuable feedback on an earlier version of + this document. Additionally, the author would like to thank David Borman for a fruitful discussion on TCP timestamps at IETF 73. Finally, the author would like to thank the United Kingdom's Centre for the Protection of National Infrastructure (UK CPNI) for their continued support. 8. References @@ -362,23 +363,20 @@ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. - [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", - RFC 1337, May 1992. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", http://www.cpni.gov.uk/Docs/ tn-03-09-security-assessment-TCP.pdf, 2009. @@ -398,39 +396,42 @@ 1999, pp. 1573-1583 . [Linux] The Linux Project, "http://www.kernel.org". [Opperman] Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- current", Post to the tcpm mailing-list. Available at: ht tp://www.ietf.org/mail-archive/web/tcpm/current/ msg02251.html, 2006. + [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", + RFC 1337, May 1992. + [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007. [Silbersack] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference . Appendix A. Behavior of the proposed mechanism in specific scenarios A.1. Connection request after system reboot - The question was raised on the tcpm mailing-list as to how this - algorithm would operate in case a computer reboots, keeps the same IP - address, looses memory of the previous time stamps, and then tries to - reestablish a previous connection. + This section clarifies how this algorithm would operate in case a + computer reboots, keeps the same IP address, looses memory of the + previous time stamps, and then tries to reestablish a previous + connection. Firstly, as specified in [RFC0793], hosts must not establish new connections for a period of 2*MSL after they boot (this is the "quiet time" concept). As a result, specs-wise, this scenario should never occur. If a host does not comply with the "quiet time concept", then the possible scenarios are: o If the selected timestamp for the new connection is monotonically- @@ -440,51 +441,56 @@ o Otherwise, the connection request may time out or be rejected (depending on whether the workaround described in [RFC1337] is implemented or not). This case corresponds to the current state- of-affairs without the algorithm proposed in this document. Appendix B. Changes from previous versions of the draft (to be removed by the RFC Editor before publishing this document as an RFC) -B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00 +B.1. Changes from draft-ietf-tcpm-tcp-timestamps-01 + + o Addresses AD-review comments by Lars Eggert. + +B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 o Addresses WG Last call comments received from Wesley Eddy, John Heffner and Joe Touch. o Minor editorial fix (reported by Wes Eddy). -B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 +B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 o Draft resubmitted as draft-ietf. -B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 +B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 o Changed the document title + o Removed all the text related to the algorithm earlier proposed for timestamps generation. o Addresses comments received from Alexander Zimmermann, Christian Huitema, Joe Touch, and others. -B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 +B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 o Minor edits (the I-D was just about to expire, so it was resubmitted with almost no changes). -B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 +B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 o Version -01 of the draft had expired, and hence the I-D is resubmitted to make it available again (no changes). -B.6. Changes from draft-gont-tcpm-tcp-timestamps-00 +B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 o Fixed author's affiliation. o Addressed feedback submitted by Alfred Hoenes (see: http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html), plus nits sent by Alfred off-list. Author's Address Fernando Gont