draft-ietf-tcpm-tcp-timestamps-00.txt   draft-ietf-tcpm-tcp-timestamps-01.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UK CPNI Extensions (tcpm) UK CPNI
Internet-Draft June 10, 2010 Internet-Draft November 16, 2010
Intended status: BCP Intended status: BCP
Expires: December 12, 2010 Expires: May 20, 2011
Reducing the TIME-WAIT state using TCP timestamps Reducing the TIME-WAIT state using TCP timestamps
draft-ietf-tcpm-tcp-timestamps-00.txt draft-ietf-tcpm-tcp-timestamps-01.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. incoming SYN segment. This document only modifies processing of SYN
segments received for connections in the TIME-WAIT state; processing
in all other states is unchanged.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 12, 2010. This Internet-Draft will expire on May 20, 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 22 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Corner-cases . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Interaction with various ISN generation algorithms . . . . . . 7
4.1. Connection request after system reboot . . . . . . . . . . 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. Changes from previous versions of the draft (to Appendix A. Behavior of the proposed mechanism in specific
scenarios . . . . . . . . . . . . . . . . . . . . . . 10
A.1. Connection request after system reboot . . . . . . . . . . 10
Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 9 this document as an RFC) . . . . . . . . . . . . . . 10
A.1. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 9 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10
A.2. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 9 B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10
A.3. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 9 B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 10
A.4. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 10 B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11
A.5. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 10 B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 B.6. 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 used to include a timestamp value in its segments, that can be used to
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 timestamp option could be used
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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. the TIME-WAIT state would fail. This problem is discussed in detail
in [INFOCOM-99].
In order to avoid this problem, RFC 1122 [RFC1122] (in Section In order to avoid this problem, RFC 1122 [RFC1122] (in Section
4.2.2.13) states that when a connection request is received with a 4.2.2.13) 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
could be accepted if the sequence number of the incoming SYN segment could be accepted if 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). This requirement aims at avoiding the sequence number transfer). This requirement aims at avoiding the sequence number
space of the new and old incarnations of the connection to overlap, space of the new and old incarnations of the connection to overlap,
thus avoiding old segments from the previous incarnation of the thus avoiding old segments from the previous incarnation of the
connection to be accepted as valid by the new connection. connection to be accepted as valid by the new connection.
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. Both the ISN received for connections in the TIME-WAIT state. The processing of
(Initial Sequence Number) and the timestamp option (if present) of SYN segments received for connections in all other states is
the incoming SYN segment are included in the heuristics performed for unchanged. Both the ISN (Initial Sequence Number) and the timestamps
allowing a high connection-establishment rate. option (if present) of the incoming SYN segment are included in the
heuristics performed for allowing a high connection-establishment
Processing of SYN segments received for connections in the rate.
synchronized states should occur as follows:
o If a SYN segment is received for a connection in any synchronized
state other than TIME-WAIT, respond with an ACK, applying rate-
throttling.
o If the corresponding connection is in the TIME-WAIT state, then, Processing of SYN segments received for connections in the TIME-WAIT
state should occur as follows:
* 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 * If TCP timestamps would be enabled for the new incarnation of
of the connection, and the timestamp contained in the the connection, and the timestamp contained in the incoming SYN
incoming SYN segment is greater than the last timestamp seen segment is greater than the last timestamp seen on the previous
on the previous incarnation of the connection (for that incarnation of the connection (for that direction of the data
direction of the data transfer), honour the connection transfer), honour the connection request (creating a 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 * If TCP timestamps would be enabled for the new incarnation of
of the connection, the timestamp contained in the incoming the connection, the timestamp contained in the incoming SYN
SYN segment is equal to the last timestamp seen on the segment is equal to the last timestamp seen on the previous
previous incarnation of the connection (for that direction incarnation of the connection (for that direction of the data
of the data transfer), and the Sequence Number of the transfer), and the Sequence Number of the incoming SYN segment
incoming SYN segment is larger than the last sequence number is larger than the last sequence number seen on the previous
seen on the previous incarnation of the connection (for that incarnation of the connection (for that direction of the data
direction of the data transfer), then honour the connection transfer), then honour the connection request (creating a
request (creating a connection in the SYN-RECEIVED state). connection in the SYN-RECEIVED state).
+ If TCP timestamps would not be enabled for the new * If TCP timestamps would not be enabled for the new incarnation
incarnation of the connection, but the Sequence Number of of the connection, but the Sequence Number of the incoming SYN
the incoming SYN segment is larger than the last sequence segment is larger than the last sequence number seen on the
number seen on the previous incarnation of the connection previous incarnation of the connection (for the same direction
(for the same direction of the data transfer), honour the of the data transfer), honour the connection request (creating
connection request (creating a connection in the SYN- a connection in the SYN-RECEIVED state).
RECEIVED state).
+ Otherwise, silently drop the incoming SYN segment, thus * Otherwise, silently drop the incoming SYN segment, thus leaving
leaving the previous incarnation of the connection in the the previous incarnation of the connection in the TIME-WAIT
TIME-WAIT state. state.
* 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 * If TCP timestamps would be enabled for the new incarnation of
of the connection, honour the incoming connection request. the connection, honour the incoming connection request.
+ If TCP timestamps would not be enabled for the new * If TCP timestamps would not be enabled for the new incarnation
incarnation of the connection, but the Sequence Number of of the connection, but the Sequence Number of the incoming SYN
the incoming SYN segment is larger than the last sequence segment is larger than the last sequence number seen on the
number seen on the previous incarnation of the connection previous incarnation of the connection (for the same direction
(for the same direction of the data transfer), then honour of the data transfer), then honour the incoming connection
the incoming connection request (even if the sequence number request (even if the sequence number of the incoming SYN
of the incoming SYN segment falls within the receive window segment falls within the receive window of the previous
of the previous incarnation of the connection). incarnation of the connection).
+ Otherwise, silently drop the incoming SYN segment, thus * Otherwise, silently drop the incoming SYN segment, thus leaving
leaving the previous incarnation of the connection in the the previous incarnation of the connection in the TIME-WAIT
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
skipping to change at page 6, line 28 skipping to change at page 6, line 23
incarnation of the same connection. In those scenarios, the 4.4BSD incarnation of the same connection. In those scenarios, the 4.4BSD
heuristics would fail, and therefore the connection request would heuristics would fail, and therefore the connection request would
usually time out. By including the TCP timestamp option in the 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:
The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis],
recommends the selection of timestamps such that they are
monotonically-increasing across connections. Specific
implementation details for such a Timestamps generation scheme can
be found in [I-D.gont-timestamps-generation].
3. Interaction with various timestamps generation algorithms 3. Interaction with various timestamps generation algorithms
The algorithm proposed in Section 2 clearly benefits of timestamps The algorithm proposed in Section 2 clearly benefits of timestamps
that are monotonically-increasing across connections to the same end- that are monotonically-increasing across connections to the same end-
point. In particular, generation of timestamps such that they are point. In particular, generation of timestamps such that they are
monotonically-increasing timestamps are important for TCPs that monotonically-increasing timestamps are important for TCPs that
perform the active open, as those are the timestamps that will be perform the active open, as those are the timestamps that will be
used for the proposed algorithm. used for the proposed algorithm.
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 does not
imply by itself a requirement on the timestamps generation algorithm imply by itself a requirement on the timestamps generation algorithm
of other TCPs. of other TCPs.
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, no worse than the current state-of-affairs. That is, the SYN segment
o The TIME_WAIT state is assassinated, with the connection request is ignored (as specified in [RFC1337]), and thus the connection
being rejected (as specified in [RFC0793]), or, request times out, or is accepted after future retransmissions of the
SYN.
o The SYN segment is ignored (as specified in [RFC1337]), and thus
the connection request times out, or is accepted after future
retransmissions of the SYN
Some stacks may implement timestamps generation algorithms that do Some stacks may implement timestamps generation algorithms that do
not lead to monotonically-increasing timestamps across connections not lead to monotonically-increasing timestamps across connections
with the same remote endpoint. An example of such algorithms is the with the same remote endpoint. An example of such algorithms is the
one described in [RFC4987] and [Opperman], that allows the one described in [RFC4987] and [Opperman], that allows the
implementation of extended TCP SYN cookies. implementation of extended TCP SYN cookies.
Note: Note:
It should be noted that this algorithm could co-exist with an It should be noted that the "extended TCP SYN cookies" could co-
algorithm for generating timestamps such that they are exist with an algorithm for generating timestamps such that they
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].
4. Corner-cases Some stacks (notably OpenBSD) implement timestamps randomization
algorithms which do not result in monotonically-increasing ISNs
4.1. Connection request after system reboot across connections. As noted in [Silbersack], such randomization
schemes break prevent the mechanism proposed in this document from
The question was raised on the tcpm mailing-list as to how this recycling connections that are in the TIME-WAIT state. However, as
algorithm would operate in case a computer reboots, keeps the same IP noted earlier in this section, in the worst-case scenario the
address, looses memory of the previous time stamps, and then tries to heuristics fail, and the result is no worse than the current state-
reestablish a previous connection. of-affairs.
Firstly, as specified in [RFC0793], hosts must not establish new 4. Interaction with various ISN generation algorithms
connections for a period of 2*MSL after they boot (this is the "quiet
time" concept). As a result, specs-wise, this scenario should never
occur.
If a host does not comply with the "quiet time concept", then the [RFC0793] suggests that the ISNs of TCP conections be generated from
possible scenarios are: a global timer, such that they are monotonically-increasing across
connections. However, this ISN-generation scheme leads to
predictable ISNs, which have well-known security implications
[CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme
which results in monotonically-increasing timestamps across
connections that are not easily-predictable by an off-path attacker.
o If the selected timestamp for the new connection is monotonically- Some stacks (notably OpenBSD) implement ISN randomization algorithms
increasing with respect to the last timestamp seen on the previous which do not result in monotonically-increasing ISNs across
incarnation of the connection, the TIME-WAIT state is tossed, and connections. As noted in [Silbersack], such ISN randomization
the new connection request succeeds. schemes break the BSD improved handling of SYN segments received for
connections that are in the TIME-WAIT state.
o Otherwise, the connection request may time out or be rejected An implementation of the mechanism proposed in this document would
(depending on whether the workaround described in [RFC1337] is enable recycling of the TIME-WAIT state even in the presence of ISNs
implemented or not). This case corresponds to the current state- that are not monotonically-increasing across connections, except when
of-affairs without the algorithm proposed in this document. the timestamp contained in the incoming SYN is equal to the last
timestamp seen on the connection in the TIME-WAIT state (for that
direction of the data transfer).
5. Security Considerations 5. Security Considerations
While the algorithm described in this document for processing While the algorithm described in this document for processing
incoming SYN segments would benefit from TCP timestamps that are incoming SYN segments would benefit from TCP timestamps that are
monotonically-increasing across connections, this document does not monotonically-increasing across connections, this document does not
propose any specific algorithm for generating timestamps, nor does it propose any specific algorithm for generating timestamps, nor does it
require monotonically-increasing timestamps across conenctions. require monotonically-increasing timestamps across conenctions.
[CPNI-TCP] contains a detailed discussion of the security [CPNI-TCP] contains a detailed discussion of the security
implications of TCP timestamps. implications of TCP timestamps.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 7. Acknowledgements
The author of this document would like to thank (in alphabetical The author of this document would like to thank (in alphabetical
order) Mark Allman, Christian huitema, Alfred Hoenes, Eric Rescorla, order) Mark Allman, Wesley Eddy, Alfred Hoenes, John Heffner,
Joe Touch, and Alexander Zimmermann for providing valuable feedback Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann
on an earlier version of this document. for providing valuable feedback on an 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 9, line 15 skipping to change at page 9, line 18
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[CPNI-TCP] [CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", http://www.cpni.gov.uk/Docs/ Protocol (TCP)", http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf, 2009. tn-03-09-security-assessment-TCP.pdf, 2009.
[I-D.gont-timestamps-generation]
Gont, F. and A. Oppermann, "On the generation of TCP
timestamps", draft-gont-timestamps-generation-00 (work in
progress), June 2010.
[I-D.ietf-tcpm-1323bis]
Borman, D., Braden, R., and V. Jacobson, "TCP Extensions
for High Performance", draft-ietf-tcpm-1323bis-01 (work in
progress), March 2009.
[INFOCOM-99]
Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,
1999, pp. 1573-1583 .
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[Opperman] [Opperman]
Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-
current", Post to the tcpm mailing-list. Available at: ht current", Post to the tcpm mailing-list. Available at: ht
tp://www.ietf.org/mail-archive/web/tcpm/current/ tp://www.ietf.org/mail-archive/web/tcpm/current/
msg02251.html, 2006. msg02251.html, 2006.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
Appendix A. Changes from previous versions of the draft (to be removed [Silbersack]
Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability",
EuroBSDCon 2005 Conference .
Appendix A. Behavior of the proposed mechanism in specific scenarios
A.1. Connection request after system reboot
The question was raised on the tcpm mailing-list as to how this
algorithm would operate in case a computer reboots, keeps the same IP
address, looses memory of the previous time stamps, and then tries to
reestablish a previous connection.
Firstly, as specified in [RFC0793], hosts must not establish new
connections for a period of 2*MSL after they boot (this is the "quiet
time" concept). As a result, specs-wise, this scenario should never
occur.
If a host does not comply with the "quiet time concept", then the
possible scenarios are:
o If the selected timestamp for the new connection is monotonically-
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
(depending on whether the workaround described in [RFC1337] is
implemented or not). This case corresponds to the current state-
of-affairs without the algorithm proposed in this document.
Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
A.1. Changes from draft-gont-tcpm-tcp-timestamps-04 B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00
o Addresses WG Last call comments received from Wesley Eddy, John
Heffner and Joe Touch.
o Minor editorial fix (reported by Wes Eddy).
B.2. Changes from draft-gont-tcpm-tcp-timestamps-04
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
A.2. Changes from draft-gont-tcpm-tcp-timestamps-03 B.3. 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.
A.3. Changes from draft-gont-tcpm-tcp-timestamps-02 B.4. 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).
A.4. Changes from draft-gont-tcpm-tcp-timestamps-01 B.5. 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).
A.5. Changes from draft-gont-tcpm-tcp-timestamps-00 B.6. 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. 39 change blocks. 
114 lines changed or deleted 181 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/