draft-ietf-tcpm-tcp-uto-09.txt   draft-ietf-tcpm-tcp-uto-10.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) Nokia Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: December 15, 2008 June 13, 2008 Expires: June 4, 2009 December 1, 2008
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-09 draft-ietf-tcpm-tcp-uto-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 15, 2008. This Internet-Draft will expire on June 4, 2009.
Abstract Abstract
The TCP user timeout controls how long transmitted data may remain The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed. It is a unacknowledged before a connection is forcefully closed. It is a
local, per-connection parameter. This document specifies a new TCP local, per-connection parameter. This document specifies a new TCP
option - the TCP User Timeout Option - that allows one end of a TCP option - the TCP User Timeout Option - that allows one end of a TCP
connection to advertise its current user timeout value. This connection to advertise its current user timeout value. This
information provides advice to the other end of the TCP connection to information provides advice to the other end of the TCP connection to
adapt its user timeout accordingly. Increasing the user timeouts on adapt its user timeout accordingly. Increasing the user timeouts on
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document Revision History . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification [RFC0793] The Transmission Control Protocol (TCP) specification [RFC0793]
defines a local, per-connection "user timeout" parameter that defines a local, per-connection "user timeout" parameter that
specifies the maximum amount of time that transmitted data may remain specifies the maximum amount of time that transmitted data may remain
unacknowledged before TCP will forcefully close the corresponding unacknowledged before TCP will forcefully close the corresponding
connection. Applications can set and change this parameter with OPEN connection. Applications can set and change this parameter with OPEN
and SEND calls. If an end-to-end connectivity disruption lasts and SEND calls. If an end-to-end connectivity disruption lasts
longer than the user timeout, no acknowledgments will be received for longer than the user timeout, a sender will receive no
any transmission attempt, including keep-alives, and the TCP acknowledgments for any transmission attempt, including keep-alives,
connection will close when the user timeout occurs. and it will close the TCP connection when the user timeout occurs.
This document specifies a new TCP option - the TCP User Timeout This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly. other end of the connection to adapt its user timeout accordingly.
That is, TCP remains free to disregard the advice provided by the UTO That is, TCP remains free to disregard the advice provided by the UTO
option if local policies suggest it to be appropriate. option if local policies suggest it to be appropriate.
Increasing the user timeouts on both ends of a TCP connection allows Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity. it to survive extended periods without end-to-end connectivity.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Although some TCP implementations allow applications to set their Although some TCP implementations allow applications to set their
local user timeout, TCP has no in-protocol mechanism to signal local user timeout, TCP has no in-protocol mechanism to signal
changes to the local user timeout to the other end of a connection. changes to the local user timeout to the other end of a connection.
This causes local changes to be ineffective in allowing a connection This causes local changes to be ineffective in allowing a connection
to survive extended periods without connectivity, because the other to survive extended periods without connectivity, because the other
end will still close the connection after its user timeout expires. end will still close the connection after its user timeout expires.
The ability to inform the other end of a connection about the local The ability to inform the other end of a connection about the local
user timeout can improve TCP operation in scenarios that are user timeout can improve TCP operation in scenarios that are
currently not well supported. One example of such a scenario is currently not well supported. One example of such a scenario is
mobile hosts that change network attachment points based on current mobile hosts that change network attachment points. Such hosts,
location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423] maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer
or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently
only intermittently connected to the Internet. In between connected connected to the Internet. In between connected periods, mobile
periods, mobile hosts may experience periods without end-to-end hosts may experience periods without end-to-end connectivity. Other
connectivity. Other factors that can cause transient connectivity factors that can cause transient connectivity disruptions are high
disruptions are high levels of congestion or link or routing failures levels of congestion or link or routing failures inside the network.
inside the network. In these scenarios, a host may not know exactly In these scenarios, a host may not know exactly when or for how long
when or for how long connectivity disruptions will occur, but it connectivity disruptions will occur, but it might be able to
might be able to determine an increased likelihood for such events determine an increased likelihood for such events based on past
based on past mobility patterns and thus benefit from using longer mobility patterns and thus benefit from using longer user timeouts.
user timeouts. In other scenarios, the time and duration of a In other scenarios, the time and duration of a connectivity
connectivity disruption may even be predictable. For example, an disruption may even be predictable. For example, a node in space
orbiting node on a non-geostationary satellite might experience might experience connectivity disruptions due to line-of-sight
connectivity disruptions due to line-of-sight blocking by other blocking by planetary bodies. The timing of these events may be
planetary bodies. The timing of these events may be computable from computable from orbital mechanics.
orbital mechanics.
2. Conventions 2. Conventions
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
Use of the TCP User Timeout Option can be enabled either on a per- Use of the TCP User Timeout Option can be enabled either on a per-
skipping to change at page 4, line 48 skipping to change at page 4, line 47
TCP's USER TIMEOUT parameter, as specified in [RFC0793]. TCP's USER TIMEOUT parameter, as specified in [RFC0793].
ADV_UTO ADV_UTO
UTO option advertised to the remote TCP peer. This is an UTO option advertised to the remote TCP peer. This is an
application-specified value, and may be specified on a system-wide application-specified value, and may be specified on a system-wide
basis. If unspecified, it defaults to the default system-wide basis. If unspecified, it defaults to the default system-wide
USER TIMEOUT. USER TIMEOUT.
ENABLED (Boolean) ENABLED (Boolean)
Flag that controls whether the UTO option is enabled for a Flag that controls whether the UTO option is enabled for a
connection. Defaults to false. connection. This flag applies to both sending and receiving.
Defaults to false.
CHANGEABLE (Boolean) CHANGEABLE (Boolean)
Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT
parameter) may be changed based on an UTO option received from the parameter) may be changed based on an UTO option received from the
other end of the connection. Defaults to true and becomes false other end of the connection. Defaults to true and becomes false
when an application explicitly sets USER_TIMEOUT. when an application explicitly sets USER_TIMEOUT.
Note that an exchange of UTO options between both ends of a Note that an exchange of UTO options between both ends of a
connection is not a binding negotiation. Transmission of a UTO connection is not a binding negotiation. Transmission of a UTO
option is a suggestion that the other end consider adapting its user option is a suggestion that the other end consider adapting its user
skipping to change at page 11, line 30 skipping to change at page 11, line 30
longer durations. Because connection state is kept longer, lower- longer durations. Because connection state is kept longer, lower-
frequency attack traffic, which may be more difficult to detect, can frequency attack traffic, which may be more difficult to detect, can
already exacerbate resource exhaustion. already exacerbate resource exhaustion.
Several approaches can help mitigate this issue. First, Several approaches can help mitigate this issue. First,
implementations can require prior peer authentication, e.g., using implementations can require prior peer authentication, e.g., using
IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
timeouts for the peer's connections. Similarly, a host can start to timeouts for the peer's connections. Similarly, a host can start to
accept long user timeouts for an established connection only after accept long user timeouts for an established connection only after
in-band authentication has occurred, for example, after a TLS in-band authentication has occurred, for example, after a TLS
handshake across the connection has succeeded [RFC4346]. Although handshake across the connection has succeeded [RFC5246]. Although
these are arguably the most complete solutions, they depend on these are arguably the most complete solutions, they depend on
external mechanisms to establish a trust relationship. external mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
skipping to change at page 12, line 31 skipping to change at page 12, line 31
This document does not define any new namespaces. It requests that This document does not define any new namespaces. It requests that
IANA allocate a new 8-bit TCP option number for the UTO option from IANA allocate a new 8-bit TCP option number for the UTO option from
the registry maintained at the registry maintained at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade
Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,
Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,
Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha
Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Martin Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and
Stiemerling. Martin Stiemerling.
Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework
Program.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 13, line 33 skipping to change at page 13, line 38
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SOLARIS-MANUAL] [SOLARIS-MANUAL]
Sun Microsystems, "Solaris Tunable Parameters Reference Sun Microsystems, "Solaris Tunable Parameters Reference
Manual", Part No. 806-7009-10, 2002. Manual", Part No. 806-7009-10, 2002.
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
Appendix A. Document Revision History Appendix A. Document Revision History
[[Note to the RFC Editor: Section to be removed upon publication.]] [[Note to the RFC Editor: Section to be removed upon publication.]]
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| -10 | Addressing the gen-art review comments from Scott |
| | Brim. Updated reference to [RFC5246]. Added funding |
| | source acknowledgment. |
| | |
| -09 | Resubmission after expiration. Updated reference to | | -09 | Resubmission after expiration. Updated reference to |
| | [RFC5226]. | | | [RFC5226]. |
| | | | | |
| -08 | Addressed additional, minor working group last call | | -08 | Addressed additional, minor working group last call |
| | comments. | | | comments. |
| | | | | |
| -07 | Addressed working group last call comments. | | -07 | Addressed working group last call comments. |
| | | | | |
| -06 | Includes a note on the limited space for TCP options | | -06 | Includes a note on the limited space for TCP options |
| | and miscellaneous editorial changes (suggested by | | | and miscellaneous editorial changes (suggested by |
 End of changes. 14 change blocks. 
35 lines changed or deleted 46 lines changed or added

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