TCP Maintenance and Minor L. Eggert Extensions (tcpm) NEC Internet-Draft July 12, 2004 Expires: January 10, 2005 TCP Abort Timeout Option draft-eggert-tcpm-tcp-abort-timeout-option-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I 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 TCP Abort Timeout Option allows conforming TCP implementations to exchange requests for individual, per-connection abort timeouts. The TCP abort timeout controls how long transmitted data may remain unacknowledged before a connection is aborted. TCP implementations typically use a single, system-wide timeout value. Using individual, per-connection timeouts allows established TCP connections to survive extended periods of disconnection. Eggert Expires January 10, 2005 [Page 1] Internet-Draft TCP Abort Timeout Option July 2004 1. Introduction The Transmission Control Protocol (TCP) specification [1] includes a "user timeout" that defines the maximum amount of time that transmitted segments may remain unacknowledged before TCP will abort the connection. If a disconnection lasts longer than the user timeout, no acknowledgments are received for any transmission attempt, including keep-alives [5], and the TCP connection will abort when the user timeout occurs. The TCP specification [1] does not constrain the permitted values for user timeouts. 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 mechanisms. For example, Solaris supports different timeouts depending on whether a TCP connection is in the SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [6]. (The host requirements RFC [2] mandates a timeout of at least three minutes for the SYN-SENT case.) System-wide user timeouts are a useful basic mechanism. However, the ability to selectively choose individual user timeout values for different connections can improve TCP operation in scenarios that are currently not well supported. Mobile hosts that change network attachment points based on current location are one example. Such hosts, maybe using MobileIP [7] or HIP [8], are only intermittently connected to the Internet. In between connected periods, mobile hosts may experience periods of disconnection during which no network service is available [9][10][11]. Other factors that can cause disconnections are high levels of transient congestion and link or routing failures inside the network. In scenarios similar to the ones described above, a host may not know exactly when or for how long it will be disconnected from the network, but it might expect such events due to past mobility patterns and thus benefit from using longer abort timeouts. In other scenarios, the length and time of a network disconnection may even be predictable. For example, an orbiting node on a satellite experiences disconnections due to line-of-sight blocking by other planetary bodies. The disconnection times and durations of such a host may be easily computable from orbital mechanics. In these examples above, as well as other cases, established TCP connections between two peers can abort when a disconnection exceeds the system-wide default user timeout. This document specifies a new TCP option - the Abort Timeout Option - that allows conforming hosts to exchange per-connection abort timeout requests. This allows, for Eggert Expires January 10, 2005 [Page 2] Internet-Draft TCP Abort Timeout Option July 2004 example, mobile hosts to maintain TCP connections across disconnected periods that are longer than their system's default user timeout. A second use of the TCP Abort Timeout Option is exchange of shorter-than-default abort timeouts. This can allow busy servers to explicitly notify their clients that they will maintain the state associated with established connections only across short periods of disconnection. TCP Abort Timeout Options allow hosts to both request specific abort timeouts for new connections and to request changes to the effective abort timeouts of established connections. The latter allows connections to start with short timeouts and only request longer timeouts when disconnection was imminent, and only for connections considered important. The ability to request changes to abort timeouts of established connections is also useful to raise the abort timeout after in-band authentication has occurred. For example, peers could request longer abort timeouts for the TCP connections underlying two-way authenticated TLS connections [12] after their authentication handshakes. 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 [3]. 3. Specification 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| Abort Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (One tick mark represents one bit.) Figure 1: Format of the TCP Abort timeout Option Figure 1 shows the format of the TCP Abort Timeout Option. It contains these fields: Kind (8 bits): A TCP option number [1] to be assigned by IANA upon publication of this document (see Section 5.) Length (8 bits): Length of the TCP option in octets [1]; its value MUST be 4. Eggert Expires January 10, 2005 [Page 3] Internet-Draft TCP Abort Timeout Option July 2004 Granularity (1 bit): Granularity bit, indicating the granularity of the "Abort Timeout" field. When set (G = 1), the time interval in the "Abort Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "Abort Timeout" field MUST be interpreted as seconds. Abort Timeout (15 bits): Specifies the abort timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field. 3.1 Operation Sending a TCP Abort Timeout Option signals to the receiving peer that the sender will start to use the indicated abort timeout value locally for the connection and is requesting that the receiving peer should start to use a corresponding abort timeout for it. Section 3.2 discusses the effects of different timeout values. When a host that supports the TCP Abort Timeout Option receives one, it decides whether to change the connection's local abort timeout accordingly. Generally, hosts SHOULD honor requests for changes to the abort timeout, unless security concerns or external policies indicate otherwise (see Section 4.) If so, hosts MAY ignore incoming TCP Abort Timeout Options and MAY use a different abort timeout for the connection. A TCP Abort Timeout Option with a value of zero (i.e., "now") is nonsensical and MUST NOT be sent. If received, it MUST be ignored. Section 3.2 discusses potentially problematic effects of other abort timeout durations. Hosts SHOULD impose upper and lower limits on the abort timeouts they use. Section 3.2 discusses abort timeout limits. The abort timeout value included in a TCP Abort Timeout Option specifies the requested abort timeout during a connection's synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK.) Connections in other states MUST use standard timeout values [1][2]. (NB: A future version of this document may extend per-connection abort timeouts to the SYN-SENT and SYN-RECEIVED states in a way that conforms to the required minimum timeouts.) A TCP implementation that does not support the TCP Abort Timeout Eggert Expires January 10, 2005 [Page 4] Internet-Draft TCP Abort Timeout Option July 2004 Option SHOULD silently ignore it [2], thus ensuring interoperability. It is important to note that TCP Abort 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 abort timeouts or have requested the peer to use them. Connections may also terminate due to other reasons, such as stateful firewalls that terminate connections after apparent periods of idleness. 3.1.1 Operation during the SYN Handshake A host that supports the TCP Abort Timeout Option and wishes to use individual abort timeouts for a connection MUST include an appropriate TCP Abort Timeout Option in its initial SYN segment. A host that supports the TCP Abort Timeout Option MAY omit the TCP Abort Timeout Option from the initial SYN if custom abort timeouts are not required for a specific connection. It SHOULD omit the TCP Abort Timeout Option from the initial SYN if there is evidence that the peer does not support the TCP Abort Timeout Option, for example, if a prior connection attempt including a TCP Abort Timeout Option has failed. If a host does not include a TCP Abort Timeout Option in its initial SYN, it MUST NOT include it in any other segment either and MUST ignore the contents of any received TCP Abort Timeout Option. A host that supports the TCP Abort Timeout Option and receives a SYN segment that includes one SHOULD respond with an appropriate TCP Abort Timeout Option in its SYN-ACK segment. If an incoming SYN segment does not include a TCP Abort Timeout Option, a host MUST NOT include one in the SYN-ACK segment or any other segment either and it MUST ignore the contents of any other received TCP Abort Timeout Option. 3.1.2 Operation during the Synchronized States During the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK) and unless both the SYN and SYN-ACK of a connection contained TCP Abort Timeout Options, both hosts participating in the connection MUST NOT send TCP Abort Timeout Options in any other segment. Additionally, they both MUST ignore the contents of any received TCP Abort Timeout Option. Otherwise, whenever a host changes the local abort timeout of a connection, it SHOULD include a TCP Abort Timeout Option indicating the new abort timeout in its next segment to the peer. This allows Eggert Expires January 10, 2005 [Page 5] Internet-Draft TCP Abort Timeout Option July 2004 the peer to adapt its local abort timeout for the connection accordingly. 3.2 Duration of the Abort Timeout The TCP Abort Timeout Option allows host to exchange abort 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. Very short abort timeout values can affect TCP transmissions over high-delay paths. If the abort timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection aborts. Many TCP implementations default to abort timeout values of a few minutes [5]. Although the TCP Abort Timeout Option allows negotiation of short timeouts, applications requesting them should consider these effects. Long abort 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 4 discusses the security implications of long timeout values. To protect against these effects, implementations SHOULD impose limits on the abort timeout values they accept and use. The remainder of this section describes a RECOMMENDED scheme to limit abort timeouts based on upper and lower limits. Under the RECOMMENDED scheme to limit abort timeouts, each TCP SHOULD compute the abort timeout (USER_TIMEOUT) for a connection according to this formula: USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) Each field is to be interpreted as follows: USER_TIMEOUT: Resulting abort timeout value to be adopted by the local TCP for a connection. U_LIMIT: Current upper limit imposed on the connection's abort timeout by the local host. L_LIMIT: Current lower limit imposed on the connection's abort timeout by the local host. Eggert Expires January 10, 2005 [Page 6] Internet-Draft TCP Abort Timeout Option July 2004 LOCAL_UTO: Current local abort timeout of the specific connection. REMOTE_UTO: Last received abort timeout option the peer uses for the connection, i.e., contents of the last-received TCP Abort Timeout Option. Enforcing a lower limit (L_LIMIT) protects against connection aborts due to transient network conditions, including temporary congestion, mobility hand-offs or routing instabilities. An upper limit (U_LIMIT) can reduce the effect of resource exhaustion attacks. Section 4 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 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 [2] does not impose any limits on the length of the abort timeout. However, a time interval of at least 100 seconds is RECOMMENDED. Consequently, the lower limit (LLIMIT) SHOULD be set to at least 100 seconds when following the RECOMMENDED scheme described in this section. 4. Security Considerations Lengthening abort 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. TCP implementations do not become more vulnerable to simple SYN flooding by implementing the TCP Abort Timeout Option, because abort timeouts negotiated 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. However, when an attacker completes the three-way handshakes of its 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 cause resource exhaustion. Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using Eggert Expires January 10, 2005 [Page 7] Internet-Draft TCP Abort Timeout Option July 2004 IPsec [13], before accepting long abort timeouts for the peer's connections. Similarly, a host can only start to accept long abort timeouts for an established connection after in-band authentication has occurred, for example, after a TLS handshake across the connection has succeeded [12]. 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 abort timeouts. Several variants of this approach are possible, such as fixed limits or shortening accepted abort 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. Per-peer limits cannot protect against distributed denial of service attacks, where multiple clients coordinate a resource exhaustion attack that uses long abort timeouts. To protect against such attacks, TCP implementations could reduce the duration of accepted abort 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 abort timeouts. On the other hand, resetting connections to untrusted peers that use long abort timeouts may be effective. In general, using the peers' level of trust as a parameter during the load-shedding decision process may be useful. Finally, upper and lower limits on abort timeouts, discussed in Section 3.2, can be an effective tool to limit the impact of these sorts of attacks. 5. 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. 6. Acknowledgments This revision of the document incorporates several ideas from Fernando Gont's "Adaptive User Timeout" mechanism [14] that is based on the -00 revision of this document. The two documents are Eggert Expires January 10, 2005 [Page 8] Internet-Draft TCP Abort Timeout Option July 2004 currently being merged, but a few issues remain to be resolved. In the meantime, this revision documents the current state of the "abort timeout" proposal. The following people have improved this document through thoughtful suggestions: Mark Allmann, Marcus Brunner, Wesley Eddy, Tom Henderson, Joseph Ishac, Michael Kerrisk, Kostas Pentikousis, Juergen Quittek, Stefan Schmid, Simon Schuetz, and Martin Stiemerling. 7. References 7.1 Normative References [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [2] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.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] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [8] Moskowitz, R., "Host Identity Protocol Architecture", draft-moskowitz-hip-arch-05 (work in progress), October 2003. [9] Schuetz, S., "Network Support for Intermittently Connected Mobile Nodes", M.S. Thesis, University of Mannheim, Germany, June 2004. [10] Schuetz, S., Eggert, L., Schmid, S. and M. Brunner, "Protocol Enhancements for Intermittently Connected Hosts", under submission (work in progress), July 2004. [11] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for Eggert Expires January 10, 2005 [Page 9] Internet-Draft TCP Abort Timeout Option July 2004 Automobile Users", Proc. INFOCOM 2004, March 2004. [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [13] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [14] Gont, F., "TCP Adaptive User TimeOut (AUTO) Option", draft-gont-tcpm-tcp-auto-option-00 (work in progress), May 2004. [15] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Author's Address 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/ Appendix A. Document Revision History +-----------+-------------------------------------------------------+ | Revision | Comments | +-----------+-------------------------------------------------------+ | 00 | Initial version. | | 01 | Updated draft based on WG feedback. Also incorporated | | | some ideas from Fernando Gont's "Adaptive User | | | Timeout" proposal [14] that is based on the -00 | | | revision of this document. | +-----------+-------------------------------------------------------+ Eggert Expires January 10, 2005 [Page 10] Internet-Draft TCP Abort Timeout 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 Expires January 10, 2005 [Page 11]