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

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