TCP Maintenance and Minor L. Eggert Extensions (tcpm) NEC Internet-Draft F. Gont Expires: January 10, 2005 UTN/FRH July 12, 2004 TCP User TimeOut (UTO) Option draft-eggert-gont-tcpm-tcp-uto-option-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The original TCP specification (RFC793) defines a "USER TIMEOUT" parameter that sets the policy as to when a user connection should be aborted. However, TCP provides no means of letting users suggest an abort policy to a remote peer dynamically. Even though a fixed Eggert & Gont Expires January 10, 2005 [Page 1] Internet-Draft TCP User TimeOut (UTO) Option July 2004 policy may work well in many cases, there are a number of scenarios where a fixed USER TIMEOUT value may be inappropriate, and some means of setting the abort policy dynamically may be necessary for TCP to be used effectively in such scenarios. This document defines a new TCP option, which lets a TCP peer suggest a USER TIMEOUT value to a remote TCP during the connection-establishment phase, and modify it during the life of a connection, thus adapting TCP's connection-abort policy as necessary. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Option Format . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Range of valid values . . . . . . . . . . . . . . . . . . . . 6 5. System limits on the USER TIMEOUT . . . . . . . . . . . . . . 7 6. Interoperability issues . . . . . . . . . . . . . . . . . . . 7 6.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2 TCP Keep-alive mechanism . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 10.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 A. Document Revision History . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Eggert & Gont Expires January 10, 2005 [Page 2] Internet-Draft TCP User TimeOut (UTO) Option July 2004 1. Introduction The original TCP specification [1] defines a USER TIMEOUT parameter, which sets the policy as to when a connection should be aborted. This parameter is usually set on a per-system basis, and there is no way for a TCP to suggest a value of USER TIMEOUT to be used for a connection by a remote peer. Many TCP implementations default to USER TIMEOUT values of a few minutes [5]. Instead of a single USER TIMEOUT, some TCP implementations offer finer-grained policies. For example, Solaris supports different timeouts depending on whether a TCP connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [6]. Even though having such a fixed policy may work well in many cases, there are scenarios in which the default USER TIMEOUT may be inappropriate. These scenarios include, but are not limeted to, the following: o A mobile host connected to a network by means of a wireless link may move through locations where its network connectivity is interrupted by physical surroundings or lack of infrastructure. o High levels of congestion may develope during the life of a connection, resulting in transient periods of disconnection. In such cases, valid connections may be aborted due to an incorrect abort policy. There are scenarios in which a host may not know exactly when or for how long it may experience network disconnection, but due to its mobility pattern, it might expect such events, and thus benefit from using a longer USER TIMEOUT to mitigate their impact. For example, as a mobile smartphone moves between cells of coverage, its motion and connectivity may be unpredictable in the short term. In the long-term, however, its network connectivity may be expected to return. There are scenarios in which the length of time a host will experience network disconnection is even predictable. For example, if an orbiting node on a satellite experiences disconnections due to line-of-sight blocking by other bodies, the duration of the disconnection periods may be easily computable from orbital mechanics. In the described scenarios, as well as in other ones, established TCP connections between two peers may be aborted if a disconnection exceeds the system-wide default USER TIMEOUT. Eggert & Gont Expires January 10, 2005 [Page 3] Internet-Draft TCP User TimeOut (UTO) Option July 2004 This document defines a new TCP option, that lets TCP implementations suggest a USER TIMEOUT value during the connection-establishment phase, and modify it during the life of a connection, thus adapting TCP's connection-abort policy as necessary. 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 RFC 2119 [2]. 3. Specification 3.1 Option Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = X | Length = 4 |G| User Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that one tick mark represents one bit position Figure 1: User Timeout (UTO) Option Format Each field is to be interpreted as follows: Kind (8 bits): This is the "Kind" field as specified in [1]. The "X" in Figure 1 is an option number to be assigned by IANA upon publication of this document (see Section 7). Length (8 bits): Length of the TCP option in octets [1]; its value MUST be 4. G (1 bit): This is the "Granularity" bit. It indicates the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as being specified in minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as being specified in seconds. User Timeout (15 bits): This field, together with the Granularity bit, specifies the USER TIMEOUT suggested by the remote peer for this connection. It MUST be interpreted as a 15-bit unsigned integer. The units of this field are specified by the "G" bit. Eggert & Gont Expires January 10, 2005 [Page 4] Internet-Draft TCP User TimeOut (UTO) Option July 2004 3.2 Operation A TCP implementation that supports the User TimeOut (UTO) Option MUST set this option when performing a connection request (i.e., in its initial SYN segment) to indicate that the option is supported, and to suggest a USER TIMEOUT value to be used for the connection. A TCP implementation that supports the TCP User TimeOut Option and receives a SYN segment that includes one SHOULD include a TCP User TimeOut Option in its SYN-ACK segment. If an incoming SYN segment does not include a TCP User TimeOut Option, the local TCP MUST NOT include the UTO option in the SYN-ACK segment nor in any other segment, and MUST ignore any TCP User Timeout Option received during the life of the connection. A TCP implementation that does not support the TCP User TimeOut Option SHOULD silently ignore it [3], thus ensuring interoperability. A TCP MAY also use this option during the life of a connection, to suggest a new value for the USER TIMEOUT parameter, thus adapting it to the current network conditions. This could be useful in a number of scenarios which include, but are not limited to, the following: o A TCP that is notified of congestion by means of ECN [7] could set this option to suggest a USER TIMEOUT value that reflects the current network conditions. o A TCP could start connections with short timeouts, and suggest longer timeouts only when disconnection is imminent. o A TCP could start connections with short timeouts, and raise the USER TIMEOUT after in-band authentication has occurred. For example, TCP peers could suggest longer USER TIMEOUT values for TCP connections for which a TLS handshake across the connection has succeeded [8]. The setting of this option means "I suggest we use a USER TIMEOUT of X". The value of "X" may be larger or smaller than the default USER TIMEOUT (see Section 4). Hosts SHOULD impose upper and lower limits on the USER TIMEOUT. A discussion of these limits can be found in Section 5. Each TCP will adopt a USER TIMEOUT as defined by equation (1): Eggert & Gont Expires January 10, 2005 [Page 5] Internet-Draft TCP User TimeOut (UTO) Option July 2004 USER_TIMEOUT = min( U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) Equation 1: USER TIMEOUT to be adopted for the connection Each field is to be interpreted as follows: USER_TIMEOUT: USER TIMEOUT value to be adopted by the local TCP for this connection. U_LIMIT: Current upper limit imposed by this host on the USER TIMEOUT of this connection. L_LIMIT: Current lower limit imposed by this host on the USER TIMEOUT of this connection. LOCAL_UTO: The "USER TIMEOUT" value suggested for this connection by the local TCP, by means of the UTO Option. REMOTE_UTO: Last "USER TIMEOUT" value suggested by the remote TCP peer by means of the UTO Option. The adopted USER TIMEOUT SHOULD be used only for connections that are in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT). Connections in other states MUST use the default USER TIMEOUT values [1][3]. Note that the USER TIMEOUT is not negotiated in any way. Each peer just "suggests" what USER TIMEOUT should be adopted for the connection. As can be inferred from the equation above, each peer may end up adopting a different timeout value. It is important to note that TCP User TimeOut Options do not change the semantics of the TCP protocol. Hosts remain free to abort connections at any time for any reason, whether or not they use custom user timeouts or have suggested the peer to use them. 4. Range of valid values The User TimeOut Option allows a TCP peer to suggest USER TIMEOUT values from zero seconds to over 9 hours at a granularity of seconds, and from zero minutes to over 22 days at a granularity of minutes. However, implementations SHOULD impose limits on the USER TIMEOUT Eggert & Gont Expires January 10, 2005 [Page 6] Internet-Draft TCP User TimeOut (UTO) Option July 2004 values actually adopted. A discussion of these limits can be found in Section 5. Setting the USER TIMEOUT to very short values can affect TCP connections over high-delay paths or very unreliable links: If the user timeout occurs before an acknowledgement for an outstanding segment arrives, possibly due to packet loss, the connection is aborted. Although the TCP User TimeOut Option allows the use of short timeouts, applications suggesting them should consider these effects. Long USER TIMEOUT values allow hosts to tolerate extended periods of disconnection. However, they also require hosts to maintain the TCP state associated with connections for long periods of time. Section 8 discusses the security implications of long USER TIMEOUT values. 5. System limits on the USER TIMEOUT Implementations SHOULD impose an upper limit (U_LIMIT) and a lower limit (L_LIMIT) on the value of the USER TIMEOUT. A lower limit gives some minimum tolerance for changing network conditions, mobility periods that take a host completely off the network for some time, and time for convergence of binding updates when a host moves. An upper limit helps prevent attacks in which resources are exhausted by creating connections to the target host and then throwing them away without signalling this to the attacked host's TCP. (See Section 8). An upper limit could also help to save resources on a busy server. Note that these limits MAY be set, for example, on a per-host or per-user basis. Furthermore, these limits need not be fixed. For example, they MAY be a function of the system resources that are available when the USER TIMEOUT is to be selected for a connection. The Host Requirements RFC [3] does not impose any limits for the USER TIMEOUT. However, a time interval of at least 100 seconds is RECOMMENDED. Thus, the lower limit (L_LIMIT) SHOULD be set to at least 100 seconds. A TCP User Timeout Option with a value of zero (i.e., "now") is nonsensical and MUST NOT be sent. If received, it MUST be ignored. 6. Interoperability issues Eggert & Gont Expires January 10, 2005 [Page 7] Internet-Draft TCP User TimeOut (UTO) Option July 2004 6.1 Firewalls Stateful firewalls are known to reset connections after some fixed period of inactivity is detected. In case there is such a firewall between the TCP peers, then, regardless of the use of the UTO Option, connections may be lost due to the firewall policy. 6.2 TCP Keep-alive mechanism In case a TCP peer enables the TCP Keep-alive mechanism for a connection that is using the UTO Option, then the Keep-alive timer MUST be set to a value larger than that of the adopted USER TIMEOUT (specified by Equation 1). 7. IANA Considerations This section is to be interpreted according to [4]. 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. 8. Security Considerations Use of the UTO Option implies that the adopted USER TIMEOUT may be larger than the default USER TIMEOUT. This could cause a host to maintain state for a connection for a longer period of time than if the default USER TIMEOUT were used. An attacker could try to exhaust resources on the target host by establishing lots of connections and aborting them without signalling this to the attacked host's TCP. Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using IPsec [9], before accepting long abort timeouts for the peer's connections. Similarly, a host can start to accept long abort timeouts for an established connection only after in-band authentication has occurred, for example, after a TLS handshake across the connection has succeeded [8]. 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 large 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. Eggert & Gont Expires January 10, 2005 [Page 8] Internet-Draft TCP User TimeOut (UTO) Option July 2004 Per-peer limits cannot protect against distributed denial of service attacks, where multiple clients coordinate a resource exhaustion attack that uses long user timeouts. To protect against such attacks, TCP implementations could reduce the duration of accepted user timeouts with increasing resource utilization. TCP implementations under attack may be forced to shed load by resetting established connections. Some load-shedding heuristics, such as resetting connections with long idle times first, can negatively affect service for intermittently connected, trusted peers that have negotiated long user timeouts. On the other hand, resetting connections to untrusted peers that use long user timeouts may be effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. In any case, it must be noted that the same type of attack can be performed even if the default "USER TIMEOUT" is used, since TCP requires no message exchange in order to keep a connection open. In any case, the system limits discussed in Section 5 would serve as a counter-measure against attackers trying to exploit the UTO option for this type of attack. Note that TCP implementations do not become more vulnerable to simple SYN flooding attacks by implementing the Usert TimeOut Option, because the adopted user timeouts are used only for connections that are in one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK or TIME-WAIT) [1]. which which connections resulting from simple SYN floods never reach. 9. Acknowledgements The following people have improved this document through thoughtful suggestions: Mark Allmann, Marcus Brunner, Wesley Eddy, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Michael Kerrisk, Kostas Pentikousis, Juergen Quittek, Stefan Schmid, Simon Schuetz, and Martin Stiemerling. 10. References 10.1 Normative References [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Braden, R., "Requirements for Internet Hosts - Communication Eggert & Gont Expires January 10, 2005 [Page 9] Internet-Draft TCP User TimeOut (UTO) Option July 2004 Layers", STD 3, RFC 1122, October 1989. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 10.2 Informative References [5] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley , 1994. [6] Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002. [7] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [9] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Authors' Addresses Lars Eggert NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg 69115 DE Phone: +49 6221 90511 43 Fax: +49 6221 90511 55 EMail: lars.eggert@netlab.nec.de URI: http://www.netlab.nec.de/ 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 Eggert & Gont Expires January 10, 2005 [Page 10] Internet-Draft TCP User TimeOut (UTO) Option July 2004 Appendix A. Document Revision History +-----------+-------------------------------------------------------+ | Revision | Comments | +-----------+-------------------------------------------------------+ | 00 | Initial version, merges | | | draft-eggert-tcpm-tcp-abort-timeout-option-00 and | | | draft-gont-tcpm-tcp-auto-option-00. | +-----------+-------------------------------------------------------+ Eggert & Gont Expires January 10, 2005 [Page 11] Internet-Draft TCP User TimeOut (UTO) Option July 2004 Intellectual Property Statement 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. 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 (2004). 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. Eggert & Gont Expires January 10, 2005 [Page 12]