--- 1/draft-ietf-tcpm-tcp-uto-10.txt 2009-01-22 18:12:03.000000000 +0100 +++ 2/draft-ietf-tcpm-tcp-uto-11.txt 2009-01-22 18:12:03.000000000 +0100 @@ -1,44 +1,54 @@ TCP Maintenance and Minor L. Eggert Extensions (tcpm) Nokia Internet-Draft F. Gont Intended status: Standards Track UTN/FRH -Expires: June 4, 2009 December 1, 2008 +Expires: July 26, 2009 January 22, 2009 TCP User Timeout Option - draft-ietf-tcpm-tcp-uto-10 + draft-ietf-tcpm-tcp-uto-11 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 June 4, 2009. + This Internet-Draft will expire on July 26, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. 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 @@ -53,29 +63,29 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 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 + 5. Programming and Manageability Considerations . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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, a sender will receive no @@ -138,21 +148,21 @@ 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- - connection basis, e.g., through a socket option, or controlled by a + connection basis, e.g., through an API option, or controlled by a system-wide setting. TCP maintains four per-connection state variables to control the operation of the UTO option, three of which (ADV_UTO, ENABLED and CHANGEABLE) are new: USER_TIMEOUT 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 @@ -181,21 +191,21 @@ UTO option enables its use by setting ENABLED to true. It may choose an appropriate local UTO by explicitly setting ADV_UTO; otherwise, UTO is set to the default USER TIMEOUT value. Finally, the application should determine whether it will allow the local USER TIMEOUT to change based on received UTO options from the other end of a connection. The default is to allow this for connections that do not have specific user timeout concerns. If an application explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to prevent UTO options from the other end to override local application requests. Alternatively, applications can set or clear CHANGEABLE - directly through socket API calls. + directly through API calls. Performing these steps before an active or passive open causes UTO options to be exchanged in the SYN and SYN-ACK packets and is a reliable way to initially exchange, and potentially adapt to, UTO values. TCP implementations MAY provide system-wide default settings for the ENABLED, ADV_UTO and CHANGEABLE connection parameters. In addition to exchanging UTO options in the SYN segments, a connection that has enabled UTO options SHOULD include a UTO option in the first packet that does not have the SYN flag set. This helps @@ -251,21 +261,21 @@ high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection closes. Many TCP implementations default to USER TIMEOUT values of a few minutes. Although the UTO option allows suggestion of short timeouts, applications advertising them should consider these effects. Long USER TIMEOUT values allow hosts to tolerate extended periods without end-to-end connectivity. However, they also require hosts to maintain the TCP state information associated with connections for - long periods of time. Section 5 discusses the security implications + long periods of time. Section 6 discusses the security implications of long timeout values. To protect against these effects, implementations MUST impose limits on the user timeout values they accept and use. The remainder of this section describes a RECOMMENDED scheme to limit TCP's USER TIMEOUT based on upper and lower limits. Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end SHOULD compute the local USER TIMEOUT for a connection according to this formula: @@ -305,21 +315,21 @@ whenever it wants. It must be noted that the two endpoints of the connection will not 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 5 discusses the details of these attacks. + attacks. Section 6 discusses 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, per-outgoing- interface 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, it recommends a time interval @@ -374,21 +384,21 @@ (One tick mark represents one bit.) Figure 1: Format of the TCP User Timeout Option Figure 1 shows the format of the TCP User Timeout Option. It contains these fields: Kind (8 bits) This MUST be TBD, i.e., the TCP option number [RFC0793] assigned - by IANA upon publication of this document (see Section 6). [[Note + by IANA upon publication of this document (see Section 7). [[Note to the RFC Editor: Throughout this document, replace "TBD" with the TCP option number that IANA has allocated and remove this note.]] Length (8 bits) Length of the TCP option in octets [RFC0793]; its value MUST be 4. Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" @@ -438,21 +448,38 @@ 4.2. TCP Keep-Alives Some TCP implementations, such as those in BSD systems, use a different abort policy for TCP keep-alives than for user data. Thus, the TCP keep-alive mechanism might abort a connection that would otherwise have survived the transient period without connectivity. Therefore, if a connection that enables keep-alives is also using the TCP User Timeout Option, then the keep-alive timer MUST be set to a value larger than that of the adopted USER TIMEOUT. -5. Security Considerations +5. Programming and Manageability Considerations + + The IETF specification for TCP [RFC0793] includes a simple, abstract + application programming interface (API). The API for the UTO + extension in Section 3 is kept similarly abstract. TCP + implementations, however, usually provide more complex and feature- + rich APIs. The "socket" API that originated with BSD Unix and is now + standardized by POSIX is one such example [POSIX]. It is expected + that TCP implementations that choose to include the UTO extension + will extend their API to allow applications to use and configure its + parameters. + + The MIB objects defined in [RFC4022] and [RFC4898] allow management + of TCP connections. It is expected that revisions to these documents + will include definitions of objects for managing the UTO extension + defined in this document. + +6. Security Considerations Lengthening user timeouts has obvious security implications. Flooding attacks cause denial of service by forcing servers to commit resources for maintaining the state of throw-away connections. However, TCP implementations do not become more vulnerable to simple SYN flooding by implementing the TCP User Timeout Option, because user timeouts exchanged during the handshake only affect the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), which simple SYN floods never reach. @@ -460,26 +487,30 @@ throw-away connections it can amplify the effects of resource exhaustion attacks, because the attacked server must maintain the connection state associated with the throw-away connections for 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 [RFC5246]. Although - these are arguably the most complete solutions, they depend on - external mechanisms to establish a trust relationship. + timeouts for the peer's connections. (Implementors that decide to + use TCP-MD5 for this purpose are encouraged to monitor the + development of TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], its designated + successor, and update their implementation when it is published as an + RFC.) A similar approach is for a host to start accepting 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 [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 high-UTO connections a server supports in the face of an attack turns that attack into a denial-of-service attack against the service of @@ -500,87 +531,104 @@ effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. Note that if TCP needs to close or abort connections with a long TCP User Timeout Option to shed load, these connections are still no worse off than without the option. Finally, upper and lower limits on user timeouts, discussed in Section 3.1, can be an effective tool to limit the impact of these sorts of attacks. -6. IANA Considerations +7. IANA Considerations This section is to be interpreted according to [RFC5226]. 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 +8. Acknowledgments The following people have improved this document through thoughtful suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, 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 +9. References -8.1. Normative References +9.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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. -8.2. Informative References +9.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-tcp-auth-opt] + Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02 + (work in progress), November 2008. + [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. + [POSIX] IEEE Std. 1003.1-2001, "Standard for Information + Technology - Portable Operating System Interface (POSIX)", + Open Group Technical Standard: Base Specifications Issue + 6, ISO/IEC 9945:2002, December 2001. + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [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. + [RFC4022] Raghunarayan, R., "Management Information Base for the + Transmission Control Protocol (TCP)", RFC 4022, + March 2005. + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. + [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP + Extended Statistics MIB", RFC 4898, May 2007. + [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. @@ -582,24 +630,25 @@ [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 | +----------+--------------------------------------------------------+ + | -11 | Addressing IESG review 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. | | | | @@ -674,50 +723,10 @@ URI: http://research.nokia.com/people/lars_eggert/ Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo 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/ - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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, THE IETF TRUST 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. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - 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.