draft-ietf-tcpm-tcp-timestamps-02.txt   draft-ietf-tcpm-tcp-timestamps-03.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UK CPNI Extensions (tcpm) UK CPNI
Internet-Draft December 7, 2010 Internet-Draft December 20, 2010
Intended status: BCP Intended status: BCP
Expires: June 10, 2011 Expires: June 23, 2011
Reducing the TIME-WAIT state using TCP timestamps Reducing the TIME-WAIT state using TCP timestamps
draft-ietf-tcpm-tcp-timestamps-02.txt draft-ietf-tcpm-tcp-timestamps-03.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 June 10, 2011. This Internet-Draft will expire on June 23, 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 32 skipping to change at page 2, line 32
2. Improved processing of incoming connection requests . . . . . 3 2. Improved processing of incoming connection requests . . . . . 3
3. Interaction with various timestamps generation algorithms . . 6 3. Interaction with various timestamps generation algorithms . . 6
4. Interaction with various ISN generation algorithms . . . . . . 7 4. Interaction with various ISN generation algorithms . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . 9
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-01 . . . . . . 10 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-02 . . . . . . 10
B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10 B.2. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10
B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10 B.3. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10
B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11 B.4. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10
B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11 B.5. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11
B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11 B.6. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11
B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11 B.7. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11
B.8. 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 43 skipping to change at page 4, line 43
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).
* If TCP timestamps would be enabled for the new incarnation of * If TCP timestamps would be enabled for the new incarnation of
the connection, the timestamp contained in the incoming SYN the connection, the timestamp contained in the incoming SYN
segment is equal to the last timestamp seen on the previous segment is equal to 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), and the Sequence Number of the incoming SYN segment transfer), and the Sequence Number of the incoming SYN segment
is larger than the last sequence number seen on the previous is greater than the last sequence number 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), then honour the connection request (creating a transfer), honour the connection request (creating a connection
connection in the SYN-RECEIVED state). in the SYN-RECEIVED state).
* If TCP timestamps would not be enabled for the new incarnation * If TCP timestamps would not be enabled for the new incarnation
of the connection, but the Sequence Number of the incoming SYN of the connection, but the Sequence Number of the incoming SYN
segment is larger than the last sequence number seen on the segment is greater than the last sequence number seen on the
previous incarnation of the connection (for the same direction previous incarnation of the connection (for the same direction
of the data transfer), honour the connection request (creating of the data transfer), honour the connection request (creating
a connection in the SYN-RECEIVED state). a connection in the SYN-RECEIVED state).
* Otherwise, silently drop the incoming SYN segment, thus leaving * Otherwise, silently drop the incoming SYN segment, thus leaving
the previous incarnation of the connection in the TIME-WAIT the previous incarnation of the connection in the TIME-WAIT
state. state.
o If the previous incarnation of the connection did not use o If the previous incarnation of the connection did not use
timestamps, then, timestamps, 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, honour the incoming connection request. the connection, honour the incoming connection request
(creating a connection in the SYN-RECEIVED state).
* If TCP timestamps would not be enabled for the new incarnation * If TCP timestamps would not be enabled for the new incarnation
of the connection, but the Sequence Number of the incoming SYN of the connection, but the Sequence Number of the incoming SYN
segment is larger than the last sequence number seen on the segment is greater than the last sequence number seen on the
previous incarnation of the connection (for the same direction previous incarnation of the connection (for the same direction
of the data transfer), then honour the incoming connection of the data transfer), honour the incoming connection request
request (even if the sequence number of the incoming SYN (creating a connection in the SYN-RECEIVED state).
segment falls within the receive window of the previous
incarnation of the connection).
* Otherwise, silently drop the incoming SYN segment, thus leaving * Otherwise, silently drop the incoming SYN segment, thus leaving
the previous incarnation of the connection in the TIME-WAIT the previous incarnation of the connection in the TIME-WAIT
state. state.
Note: Note:
In the above explanation, the phrase "TCP timestamps would be In the above explanation, the phrase "TCP timestamps would be
enabled for the new incarnation for the connection" means that the enabled for the new incarnation for the connection" means that the
incoming SYN segment contains a TCP Timestamps option (i.e., the incoming SYN segment contains a TCP Timestamps option (i.e., the
skipping to change at page 6, line 9 skipping to change at page 6, line 8
corresponding to the FIN flag of the previous incarnation of the corresponding to the FIN flag of the previous incarnation of the
connection, for that direction of the data transfer. connection, for that direction of the data transfer.
Many implementations do not include the TCP timestamp option when Many implementations do not include the TCP timestamp option when
performing the above heuristics, thus imposing stricter constraints performing the above heuristics, thus imposing stricter constraints
on the generation of Initial Sequence Numbers, the average data on the generation of Initial Sequence Numbers, the average data
transfer rate of the connections, and the amount of data transferred transfer rate of the connections, and the amount of data transferred
with them. RFC 793 [RFC0793] states that the ISN generator should be with them. RFC 793 [RFC0793] states that the ISN generator should be
incremented roughly once every four microseconds (i.e., roughly incremented roughly once every four microseconds (i.e., roughly
250000 times per second). As a result, any connection that transfers 250000 times per second). As a result, any connection that transfers
more than 250000 bytes of data at more than 250 KB/s could lead to more than 250000 bytes of data at more than 250 kilobytes/second
scenarios in which the last sequence number seen on a connection that could lead to scenarios in which the last sequence number seen on a
moves into the TIME-WAIT state is still greater than the sequence connection that moves into the TIME-WAIT state is still greater than
number of an incoming SYN segment that aims at creating a new the sequence number of an incoming SYN segment that aims at creating
incarnation of the same connection. In those scenarios, the 4.4BSD a new incarnation of the same connection. In those scenarios, the
heuristics would fail, and therefore the connection request would 4.4BSD heuristics would fail, and therefore the connection request
usually time out. By including the TCP timestamp option in the would usually time out. By including the TCP timestamp option in the
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
skipping to change at page 7, line 24 skipping to change at page 7, line 23
It should be noted that the "extended TCP SYN cookies" could co- It should be noted that the "extended TCP SYN cookies" could co-
exist with an algorithm for generating timestamps such that they exist with an algorithm for generating timestamps such that they
are monotonically-increasing. Monotonically increasing timestamps are monotonically-increasing. Monotonically increasing timestamps
could be generated for TCPs that perform the active open, while could be generated for TCPs that perform the active open, while
timestamps for TCPs that perform the passive open could be timestamps for TCPs that perform the passive open could be
generated according to [Opperman]. generated according to [Opperman].
Some stacks (notably OpenBSD) implement timestamps randomization Some stacks (notably OpenBSD) implement timestamps randomization
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 may 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 connections 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 ISNs across connections
connections that are not easily-predictable by an off-path attacker. 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
schemes break the BSD improved handling of SYN segments received for schemes break the BSD improved handling of SYN segments received for
connections that are in the TIME-WAIT state. connections that are in the TIME-WAIT state.
An implementation of the mechanism proposed in this document would An implementation of the mechanism proposed in this document would
enable recycling of the TIME-WAIT state even in the presence of ISNs enable recycling of the TIME-WAIT state even in the presence of ISNs
that are not monotonically-increasing across connections, except when that are not monotonically-increasing across connections, except when
skipping to change at page 8, line 13 skipping to change at page 8, line 12
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 connections. 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 and of different Timestamps generation
algorithms.
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, Lars Eggert, Alfred Hoenes, John order) Mark Allman, Francis Dupont, Wesley Eddy, Lars Eggert, Alfred
Heffner, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Hoenes, John Heffner, Christian Huitema, Eric Rescorla, Joe Touch,
Zimmermann for providing valuable feedback on an earlier version of and Alexander Zimmermann for providing valuable feedback on an
this document. earlier version of 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 10, line 6 skipping to change at page 10, line 4
[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
This section clarifies how this algorithm would operate in case a This section clarifies how this algorithm would operate in case a
computer reboots, keeps the same IP address, looses memory of the computer reboots, keeps the same IP address, looses memory of the
previous time stamps, and then tries to reestablish a previous previous timestamps, and then tries to 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 (Maximum Segment Lifetime) after
time" concept). As a result, specs-wise, this scenario should never they boot (this is the "quiet time" concept). As a result, specs-
occur. 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-
increasing with respect to the last timestamp seen on the previous
incarnation of the connection, the TIME-WAIT state is tossed, and
the new connection request succeeds.
o Otherwise, the connection request may time out or be rejected If a host does not comply with the "quiet time concept", a connection
(depending on whether the workaround described in [RFC1337] is request might be sent to a remote host while there is a previous
implemented or not). This case corresponds to the current state- incarnation of the same connection in the TIME-WAIT state at the
of-affairs without the algorithm proposed in this document. remote host. In such a scenario, as a result of having lost memory
of previous time stamps, the resulting timestamps might not be
monotonically-increasing, and hence the proposed algorithm might be
unable to recycle the previous incarnation of the connection that is
in the TIME-WAIT state. 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 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-01 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-02
o Addresses COMMENTs received during IESG review, and maybe Tim
Polk's DISCUSS.
B.2. Changes from draft-ietf-tcpm-tcp-timestamps-01
o Addresses AD-review comments by Lars Eggert. o Addresses AD-review comments by Lars Eggert.
B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 B.3. 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.3. Changes from draft-gont-tcpm-tcp-timestamps-04 B.4. Changes from draft-gont-tcpm-tcp-timestamps-04
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 B.5. 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.5. Changes from draft-gont-tcpm-tcp-timestamps-02 B.6. 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.6. Changes from draft-gont-tcpm-tcp-timestamps-01 B.7. 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.7. Changes from draft-gont-tcpm-tcp-timestamps-00 B.8. 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. 29 change blocks. 
62 lines changed or deleted 63 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/