--- 1/draft-ietf-tcpm-tcp-uto-03.txt 2006-10-25 23:13:49.000000000 +0200 +++ 2/draft-ietf-tcpm-tcp-uto-04.txt 2006-10-25 23:13:49.000000000 +0200 @@ -1,19 +1,19 @@ TCP Maintenance and Minor L. Eggert Extensions (tcpm) NEC Internet-Draft F. Gont -Expires: January 20, 2007 UTN/FRH - July 19, 2006 +Intended status: Standards Track UTN/FRH +Expires: April 25, 2007 October 22, 2006 TCP User Timeout Option - draft-ietf-tcpm-tcp-uto-03 + draft-ietf-tcpm-tcp-uto-04 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 January 20, 2007. + This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a new TCP option - the TCP User Timeout Option - that allows a TCP to advertise its current user timeout for a connection. Thus, the remote TCP may modify its local user timeout @@ -51,36 +51,36 @@ clients that they will maintain the connection state only across short periods of disconnection. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.2. Reliability Considerations . . . . . . . . . . . . . . . . 8 - 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 - 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9 - 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 + 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 13 + Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 14 Appendix B. Document Revision History . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 16 + 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 a network disconnection lasts longer than the user timeout, no acknowledgments will be received for @@ -176,28 +176,34 @@ Note that an exchange of TCP User Timeout Options between peers is not a binding negotiation. Transmission of a TCP User Timeout Option is an advisory suggestion that the peer consider adapting its local user timeout. Hosts remain free to adopt a different user timeout, or to forcefully close or abort connections at any time for any reason, whether or not they use custom user timeouts or have suggested the peer to use them. A host that supports the TCP User Timeout Option SHOULD include one - in each packet that carries a SYN flag, but need not. [MEDINA] has - shown that unknown options are correctly handled by the vast majority - of modern TCP stacks. It is thus not necessary to require - negotiation of the use of the TCP User Timeout Option during the - three-way handshake of a connection. However, including a TCP User - Timeout Option in each segment that has the SYN flag set will result - in TCP being able to adopt a user timeout with knowledge of that used - by the peer TCP, since the beginning of the data transfer phase. + in each packet that carries a SYN flag. The presence of this option + is not a negotiation of the capability, but simply an advisory + message specifying the currently preferred user timeout value. This + allows TCP to adopt a user timeout with knowledge of that used by the + peer TCP from the very beginning of the data transfer phase. + Additionally, a TCP that supports the User Timeout Option and has + sent a SYN segment as a result of an active OPEN SHOULD include an + UTO in the first packet that does not have the SYN flag set. This + helps to minimize the amount of state information a TCP must keep for + connections in non-synchronized states, and is particularly useful + when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are + implemented, allowing a newly-established TCP connection to benefit + from the information advertised by the UTO option, even if the UTO + contained in the initial SYN segment was not recorded. A host that supports the TCP User Timeout Option SHOULD include it in the next possible segment to its peer whenever it starts using a new user timeout for the connection. This allows the peer to adapt its local user timeout for the connection accordingly. When a host that supports the TCP User Timeout Option receives one, it will use the received value to compute the local user timeout for the connection. Generally, hosts should honor requests for changes to the user timeout (see Section 3.1), unless security concerns, @@ -288,42 +295,42 @@ This means that, provided they are within the upper and lower limits, the maximum of the two announced values will be adopted for the user timeout of the connection. The rationale is that choosing the maximum of the two values will let the connection survive longer periods of disconnection. If the TCP that announced the lower of the two user timeout values did so in order to reduce the amount of TCP state information that must be kept on the host, it can, nevertheless, close or abort the connection whenever it wants. It must be noted that the two endpoints of the connection will not - necesarilly adopt the same user timeout. + necessarily adopt the same user timeout. Enforcing a lower limit (L_LIMIT) prevents connections from closing due to transient network conditions, including temporary congestion, mobility hand-offs and routing instabilities. An upper limit (U_LIMIT) can reduce the effect of resource exhaustion attacks. Section 5discusses the details of these attacks. Note that these limits MAY be specified as system-wide constants or at other granularities, such as on per-host, per-user or even per- connection basis. Furthermore, these limits need not be static. For example, they MAY be a function of system resource utilization or attack status and could be dynamically adapted. The Host Requirements RFC [RFC1122] does not impose any limits on the length of the user timeout. However, a time interval of at least 100 seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds when following the RECOMMENDED scheme described in this section. Adopting a user timeout smaller than the current retransmission timeout (RTO) for the connection - would likely cause the connection to be aborted unnecesarily. + would likely cause the connection to be aborted unnecessarily. Therefore, the lower limit (L_LIMIT) MUST be larger than the current retransmission timeout (RTO) for the connection. 3.2. Reliability Considerations The TCP User Timeout Option is an advisory TCP option that does not change processing of subsequent segments. Unlike other TCP options, it need not be exchanged reliably. Consequently, the specification in this section does not define a reliability handshake for TCP User Timeout Option exchanges. When a segment that carries a TCP User @@ -399,28 +410,32 @@ use. TCP implementations MUST NOT send it and MUST ignore it upon reception. 4. Interoperability Issues This section discusses interoperability issues related to introducing the TCP User Timeout Option. 4.1. Middleboxes - The large number of middleboxes (firewalls, proxies, protocol - scrubbers, etc.) currently present in the Internet pose some - difficulty for deploying new TCP options. Some firewalls may block - segments that carry unknown options, preventing connection - establishment when the SYN or SYN-ACK segment contain a TCP User - Timeout Option. Some recent results, however, indicate that for new - TCP options, this may not be a significant threat, with only 0.2% of - web requests failing when carrying an unknown option [MEDINA]. + A TCP implementation that does not support the TCP User Timeout + Option MUST silently ignore it [RFC1122], thus ensuring + interoperability. In a study of the effects of middleboxes on + transport protocols, Medina et al. have shown that unknown TCP + options are correctly handled by the vast majority of modern TCP + stacks [MEDINA]. In this study, 3% of connections failed when an + unknown TCP option appeared in the middle of a connection. Because + these failures violate existing requirements to ignore unknown + options, they do not warrant taking special measures to handle these + cases. In particular, we do not define a separate mechanism to + negotiate support of the TCP User Timeout Option on the three-way + handshake. Stateful firewalls usually reset connections after a period of inactivity. If such a firewall exists along the path between two peers, it may close or abort connections regardless of the use of the TCP User Timeout Option. In the future, such firewalls may learn to parse the TCP User Timeout Option and modify their behavior or the option accordingly. 4.2. TCP Keep-Alives @@ -498,26 +513,26 @@ This section is to be interpreted according to [RFC2434]. This document does not define any new namespaces. It uses an 8-bit TCP option number maintained by IANA at http://www.iana.org/assignments/tcp-parameters. 7. Acknowledgments The following people have improved this document through thoughtful - suggestions: Mark Allman, David Borman, Bob Braden, Marcus Brunner, - Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, - Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Phil - Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, Juergen - Quittek, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and - Martin Stiemerling. + 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, + Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas + Pentikousis, Juergen Quittek, Joe Touch, Stefan Schmid, Simon + Schuetz, Tim Shepard and Martin Stiemerling. Lars Eggert is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. 8. References @@ -535,24 +550,29 @@ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 8.2. Informative References [I-D.eddy-tcp-mobility] Eddy, W., "Mobility Support For TCP", draft-eddy-tcp-mobility-00 (work in progress), April 2004. + [I-D.ietf-tcpm-syn-flood] + Eddy, W., "TCP SYN Flooding Attacks and Common + Mitigations", draft-ietf-tcpm-syn-flood-00 (work in + progress), July 2006. + [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring - Interactions Between Transport Protocols and Middleboxes", - Proc. 4th ACM SIGCOMM/USENIX Conference on Internet - Measurement , October 2004. + Interactions Between Transport Protocols and + Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on + Internet Measurement , October 2004. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [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. @@ -596,24 +616,27 @@ connections. The proposed TCP User Timeout Option, on the other hand, allows hosts to selectively manage the user timeouts of individual connections, reducing the amount of state they must maintain across disconnected periods. Appendix B. Document Revision History To be removed upon publication - +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ + | 04 | Clarified the results obtained by Medina et al. Added | + | | text to suggest inclusion of the UTO in the first | + | | non-SYN segment by the TCP that sent a SYN in response | + | | to an active OPEN. | | 03 | Corrected use of RFC2119 terminology. Clarified how | | | use of the TCP UTO is triggered. Clarified reason for | | | sending a UTO in the SYN and SYN/ACK segments. | | | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO | | | options. Removed text that suggested that a UTO | | | should be sent upon receipt of an UTO from the remote | | | peer. Required minimum value for the lower limit of | | | the user timeout. Moved alternative solutions to | | | appendix. Miscellaneous editorial changes. | | 02 | Corrected terminology by replacing terms like | @@ -655,21 +678,37 @@ Fernando Gont Universidad Tecnologica Nacional Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472 Email: fernando@gont.com.ar URI: http://www.gont.com.ar/ -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -679,30 +718,14 @@ such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - Acknowledgment - Funding for the RFC Editor function is currently provided by the - Internet Society. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).