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/ |