draft-ietf-tcpm-tcp-timestamps-04.txt   rfc6191.txt 
TCP Maintenance and Minor F. Gont Internet Engineering Task Force (IETF) F. Gont
Extensions (tcpm) UK CPNI Request for Comments: 6191 UK CPNI
Internet-Draft February 4, 2011 BCP: 159 April 2011
Intended status: BCP Category: Best Current Practice
Expires: August 8, 2011 ISSN: 2070-1721
Reducing the TIME-WAIT state using TCP timestamps Reducing the TIME-WAIT State Using TCP Timestamps
draft-ietf-tcpm-tcp-timestamps-04.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.
Status of this Memo 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 This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 8, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6191.
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
skipping to change at page 2, line 21 skipping to change at page 2, line 19
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
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 Timestamp 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 . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
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
be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 10
B.1. Changes from draft-ietf-tcpm-tcp-timestamps-03 . . . . . . 10
B.2. Changes from draft-ietf-tcpm-tcp-timestamps-02 . . . . . . 10
B.3. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10
B.4. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 11
B.5. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 11
B.6. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11
B.7. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11
B.8. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11
B.9. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 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
required to be monotonically increasing. While there is no required to be monotonically increasing. While there is no
requirement that timestamps are monotonically increasing across TCP requirement that timestamps are monotonically increasing across TCP
connections, the generation of timestamps such that they are connections, the generation of timestamps such that they are
monotonically increasing across connections between the same two monotonically increasing across connections between the same two
endpoints allows the use of timestamps for improving the handling of endpoints allows the use of timestamps for improving the handling of
SYN segments that are received while the corresponding four-tuple is SYN segments that are received while the corresponding four-tuple is
in the TIME-WAIT state. That is, the timestamp option could be used in the TIME-WAIT state. That is, the Timestamps option could be used
to perform heuristics to determine whether to allow the creation of a to perform heuristics to determine whether to allow the creation of a
new incarnation of a connection that is in the TIME-WAIT state. new incarnation of a connection that is in the TIME-WAIT state.
This use of TCP timestamps is simply an extrapolation of the use of This use of TCP timestamps is simply an extrapolation of the use of
Initial Sequence Numbers (ISNs) for the same purpose, as allowed by Initial Sequence Numbers (ISNs) for the same purpose, as allowed by
RFC 1122 [RFC1122], and it has been incorporated in a number of TCP RFC 1122 [RFC1122], and it has been incorporated in a number of TCP
implementations, such as that included in the Linux kernel [Linux]. implementations, such as that included in the Linux kernel [Linux].
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. Improved processing of incoming connection requests 2. Improved Processing of Incoming Connection Requests
In a number of scenarios a socket pair may need to be reused while In a number of scenarios, a socket pair may need to be reused while
the corresponding four-tuple is still in the TIME-WAIT state in a the corresponding four-tuple is still in the TIME-WAIT state in a
remote TCP peer. For example, a client accessing some service on a remote TCP peer. For example, a client accessing some service on a
host may try to create a new incarnation of a previous connection, host may try to create a new incarnation of a previous connection,
while the corresponding four-tuple is still in the TIME-WAIT state at while the corresponding four-tuple is still in the TIME-WAIT state at
the remote TCP peer (the server). This may happen if the ephemeral the remote TCP peer (the server). This may happen if the ephemeral
port numbers are being reused too quickly, either because of a bad port numbers are being reused too quickly, either because of a bad
policy of selection of ephemeral ports, or simply because of a high policy of selection of ephemeral ports, or simply because of a high
connection rate to the corresponding service. In such scenarios, the connection rate to the corresponding service. In such scenarios, the
establishment of new connections that reuse a four-tuple that is in establishment of new connections that reuse a four-tuple that is in
the TIME-WAIT state would fail. This problem is discussed in detail the TIME-WAIT state would fail. This problem is discussed in detail
in [INFOCOM-99]. in [INFOCOM-99].
In order to avoid this problem, RFC 1122 [RFC1122] (in Section In order to avoid this problem, Section 4.2.2.13 of RFC 1122
4.2.2.13) states that when a connection request is received with a [RFC1122] states that when a connection request is received with a
four-tuple that is in the TIME-WAIT state, the connection request four-tuple that is in the TIME-WAIT state, the connection request may
could be accepted if the sequence number of the incoming SYN segment be accepted if the sequence number of the incoming SYN segment is
is greater than the last sequence number seen on the previous 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). This requirement aims at avoiding the sequence number transfer). The goal of this requirement is to prevent the overlap of
space of the new and old incarnations of the connection to overlap, the sequence number spaces of the old and new incarnations of the
thus avoiding old segments from the previous incarnation of the connection so that segments from the old incarnation are not accepted
connection to be accepted as valid by the new connection. as valid by the new incarnation.
The same policy may be extrapolated to TCP timestamps. That is, when The same policy may be extrapolated to TCP timestamps. That is, when
a connection request is received with a four-tuple that is in the a connection request is received with a four-tuple that is in the
TIME-WAIT state, the connection request could be accepted if the TIME-WAIT state, the connection request could be accepted if the
timestamp of the incoming SYN segment is greater than the last timestamp of the incoming SYN segment is greater than the last
timestamp seen on the previous incarnation of the connection (for timestamp seen on the previous incarnation of the connection (for
that direction of the data transfer). that direction of the data transfer).
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), honor 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 greater 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), honour the connection request (creating a connection transfer), honor the connection request (creating a 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 greater 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), honor the connection request (creating a
a connection in the SYN-RECEIVED state). 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, honor the incoming connection request (creating
(creating a connection in the SYN-RECEIVED state). 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 greater 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 incoming connection request of the data transfer), honor the incoming connection request
(creating a connection in the SYN-RECEIVED state). (creating 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.
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
client has enabled TCP timestamps), and that the SYN/ACK segment client has enabled TCP Timestamps), and that the SYN/ACK segment
that would be sent in response to it would also contain a that would be sent in response to it would also contain a
Timestamps option (i.e., the server has enabled TCP timestamps). Timestamps option (i.e., the server has enabled TCP Timestamps).
In such a scenario, TCP timestamps would be enabled for the new In such a scenario, TCP Timestamps would be enabled for the new
incarnation of the connection. incarnation of the connection.
The "last sequence number seen on the previous incarnation of the The "last sequence number seen on the previous incarnation of the
connection (for the same direction of the data transfer)" refers connection (for the same direction of the data transfer)" refers
to the last sequence number used by the previous incarnation of to the last sequence number used by the previous incarnation of
the connection (for the same direction of the data transfer), and the connection (for the same direction of the data transfer), and
not to the last value seen in the Sequence Number field of the not to the last value seen in the Sequence Number field of the
corresponding segments. That is, it refers to the sequence number corresponding segments. That is, it refers to the sequence number
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 Timestamps 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 250,000 times per second). As a result, any connection that
more than 250000 bytes of data at more than 250 kilobytes/second transfers more than 250,000 bytes of data at more than 250 kilobytes/
could lead to scenarios in which the last sequence number seen on a second could lead to scenarios in which the last sequence number seen
connection that moves into the TIME-WAIT state is still greater than on a connection that moves into the TIME-WAIT state is still greater
the sequence number of an incoming SYN segment that aims at creating than the sequence number of an incoming SYN segment that aims at
a new incarnation of the same connection. In those scenarios, the creating a new incarnation of the same connection. In those
4.4BSD heuristics would fail, and therefore the connection request scenarios, the ISN heuristics would fail, and therefore the
would usually time out. By including the TCP timestamp option in the connection request would usually time out. By including the TCP
heuristics described above, all these constraints are greatly Timestamps option in the heuristics described above, all these
relaxed. constraints are greatly 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, [1323bis], recommends the
recommends the selection of timestamps such that they are selection of timestamps such that they are monotonically
monotonically-increasing across connections. An example of such a increasing across connections. An example of such a timestamp
Timestamps generation scheme can be found in generation scheme can be found in [TS-Generation].
[I-D.gont-timestamps-generation].
3. Interaction with various timestamps generation algorithms 3. Interaction with Various Timestamp Generation Algorithms
The algorithm proposed in Section 2 clearly benefits of timestamps The algorithm proposed in Section 2 clearly benefits from timestamps
that are monotonically-increasing across connections to the same end- that are monotonically increasing across connections to the same
point. In particular, generation of timestamps such that they are endpoint. In particular, generation of timestamps such that they are
monotonically-increasing timestamps are important for TCPs that monotonically increasing is important for TCP instances that perform
perform the active open, as those are the timestamps that will be the active open, as those are the timestamps that will be used for
used for the proposed algorithm. the proposed algorithm.
While monotonically-increasing timestamps ensure that the proposed While monotonically increasing timestamps ensure that the proposed
algorithm will be able to reduce the TIME-WAIT state of a previous algorithm will be able to reduce the TIME-WAIT state of a previous
incarnation of a connection, implementation of the algorithm does not incarnation of a connection, implementation of the algorithm (by
imply by itself a requirement on the timestamps generation algorithm itself) does not imply a requirement on the timestamp generation
of other TCPs. algorithm of other TCP implementations.
In the worst-case scenario, an incoming SYN corresponding to a new In the worst-case scenario, an incoming SYN corresponding to a new
incarnation of a connection in the TIME-WAIT contains a timestamp incarnation of a connection in the TIME-WAIT contains a timestamp
that is smaller than the last timestamp seen on the previous that is smaller than the last timestamp seen on the previous
incarnation of the connection, the heuristics fail, and the result is incarnation of the connection, the heuristics fail, and the result is
no worse than the current state-of-affairs. That is, the SYN segment no worse than the current state of affairs. That is, the SYN segment
is ignored (as specified in [RFC1337]), and thus the connection is ignored (as specified in [RFC1337]), and thus the connection
request times out, or is accepted after future retransmissions of the request times out, or is accepted after future retransmissions of the
SYN. SYN.
Some stacks may implement timestamps generation algorithms that do Some stacks may implement timestamp generation algorithms that do not
not lead to monotonically-increasing timestamps across connections lead to monotonically increasing timestamps across connections with
with the same remote endpoint. An example of such algorithms is the the same remote endpoint. An example of such algorithms is the one
one described in [RFC4987] and [Opperman], that allows the described in [RFC4987] and [Opperman], which allows the
implementation of extended TCP SYN cookies. implementation of extended TCP SYN cookies.
Note: Note:
It should be noted that the "extended TCP SYN cookies" could co- It should be noted that the "extended TCP SYN cookies" could
exist with an algorithm for generating timestamps such that they coexist 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 TCP instances that perform the active open,
timestamps for TCPs that perform the passive open could be while timestamps for TCP instances that perform the passive open
generated according to [Opperman]. could be generated according to [Opperman].
Some stacks (notably OpenBSD) implement timestamps randomization Some stacks (notably OpenBSD) implement timestamp 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 may 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
of-affairs. 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 ISNs across connections that results in monotonically increasing ISNs across connections that
that are not easily-predictable by an off-path attacker. 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 BSD's 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
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
[I-D.ietf-tcpm-tcp-security] contains a detailed discussion of the [TCP-Security] contains a detailed discussion of the security
security implications of TCP timestamps and of different Timestamps implications of TCP Timestamps and of different timestamp generation
generation algorithms. algorithms.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements 6. Acknowledgements
This document is based on part of the contents of the technical This document is based on part of the contents of the technical
report "Security Assessment of the Transmission Control Protocol report "Security Assessment of the Transmission Control Protocol
(TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the United (TCP)" [CPNI-TCP] written by Fernando Gont on behalf of the United
Kingdom's Centre for the Protection of National Infrastructure (UK Kingdom's Centre for the Protection of National Infrastructure (UK
CPNI). CPNI).
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, Francis Dupont, Wesley Eddy, Lars Eggert, Alfred order) Mark Allman, Francis Dupont, Wesley Eddy, Lars Eggert, John
Hoenes, John Heffner, Christian Huitema, Eric Rescorla, Joe Touch, Heffner, Alfred Hoenes, Christian Huitema, Eric Rescorla, Joe Touch,
and Alexander Zimmermann for providing valuable feedback on an and Alexander Zimmermann for providing valuable feedback on an
earlier version of 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 Fernando Gont's attendance to IETF meetings was supported by ISOC's
"Fellowship to the IETF" program.
8.1. Normative References 7. References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 7.1. Normative References
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
Communication Layers", STD 3, RFC 1122, October 1989. RFC 793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1122] Braden, R., "Requirements for Internet Hosts -
for High Performance", RFC 1323, May 1992. Communication Layers", STD 3, RFC 1122,
October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
Requirement Levels", BCP 14, RFC 2119, March 1997. Extensions for High Performance", RFC 1323,
May 1992.
8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CPNI-TCP] 7.2. Informative References
CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf>.
[I-D.gont-timestamps-generation] [1323bis] Borman, D., Braden, R., and V. Jacobson, "TCP
Gont, F. and A. Oppermann, "On the generation of TCP Extensions for High Performance", Work in Progress,
timestamps", draft-gont-timestamps-generation-00 (work in March 2009.
progress), June 2010.
[I-D.ietf-tcpm-1323bis] [CPNI-TCP] CPNI, "Security Assessment of the Transmission
Borman, D., Braden, R., and V. Jacobson, "TCP Extensions Control Protocol (TCP)", 2009,
for High Performance", draft-ietf-tcpm-1323bis-01 (work in <http://www.cpni.gov.uk/Docs/
progress), March 2009. tn-03-09-security-assessment-TCP.pdf>.
[I-D.ietf-tcpm-tcp-security] [INFOCOM-99] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT
Gont, F., "Security Assessment of the Transmission Control state in TCP and Its Effect on Busy Servers", Proc.
Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in IEEE Infocom, 1999, pp. 1573-1583.
progress), January 2011.
[INFOCOM-99] [Linux] Linux Kernel Organization, "The Linux Kernel
Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in Archives", <http://www.kernel.org>.
TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,
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,
September 2006, <http://www.ietf.org/mail-archive/
web/tcpm/current/msg02251.html>.
[Opperman] [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in
Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- TCP", RFC 1337, May 1992.
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", [RFC1948] Bellovin, S., "Defending Against Sequence Number
RFC 1337, May 1992. Attacks", RFC 1948, May 1996.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
RFC 1948, May 1996. Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [Silbersack] Silbersack, M., "Improving TCP/IP security through
Mitigations", RFC 4987, August 2007. randomization without sacrificing interoperability",
EuroBSDCon 2005.
[Silbersack] [TCP-Security] Gont, F., "Security Assessment of the Transmission
Silbersack, M., "Improving TCP/IP security through Control Protocol (TCP)", Work in Progress,
randomization without sacrificing interoperability", January 2011.
EuroBSDCon 2005 Conference .
Appendix A. Behavior of the proposed mechanism in specific scenarios [TS-Generation] Gont, F. and A. Oppermann, "On the generation of TCP
timestamps", Work in Progress, June 2010.
A.1. Connection request after system reboot Appendix A. Behavior of the Proposed Mechanism in Specific Scenarios
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, loses memory of the
previous timestamps, 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 (Maximum Segment Lifetime) after connections for a period of 2*MSL (Maximum Segment Lifetime) after
they boot (this is the "quiet time" concept). As a result, specs- they boot (this is the "quiet time" concept). As a result, in terms
wise, this scenario should never occur. of specifications, this scenario should never occur.
If a host does not comply with the "quiet time concept", a connection If a host does not comply with the "quiet time concept", a connection
request might be sent to a remote host while there is a previous request might be sent to a remote host while there is a previous
incarnation of the same connection in the TIME-WAIT state at the incarnation of the same connection in the TIME-WAIT state at the
remote host. In such a scenario, as a result of having lost memory remote host. In such a scenario, as a result of having lost memory
of previous time stamps, the resulting timestamps might not be of previous timestamps, the resulting timestamps might not be
monotonically-increasing, and hence the proposed algorithm might be monotonically increasing, and hence the proposed algorithm might be
unable to recycle the previous incarnation of the connection that is unable to recycle the previous incarnation of the connection that is
in the TIME-WAIT state. This case corresponds to the current state- in the TIME-WAIT state. 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
by the RFC Editor before publishing this document as an
RFC)
B.1. Changes from draft-ietf-tcpm-tcp-timestamps-03
o Addresses Tim Polk's DISCUSS.
B.2. Changes from draft-ietf-tcpm-tcp-timestamps-02
o Addresses COMMENTs received during IESG review, and maybe Tim
Polk's DISCUSS.
B.3. Changes from draft-ietf-tcpm-tcp-timestamps-01
o Addresses AD-review comments by Lars Eggert.
B.4. 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.5. Changes from draft-gont-tcpm-tcp-timestamps-04
o Draft resubmitted as draft-ietf.
B.6. 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.7. 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.8. 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.9. 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 Author's Address
Fernando Gont Fernando Gont
UK Centre for the Protection of National Infrastructure UK Centre for the Protection of National Infrastructure
Email: fernando@gont.com.ar EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk URI: http://www.cpni.gov.uk
 End of changes. 76 change blocks. 
255 lines changed or deleted 175 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/