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