--- 1/draft-ietf-tcpm-tcp-uto-04.txt 2007-03-08 23:14:45.000000000 +0100 +++ 2/draft-ietf-tcpm-tcp-uto-05.txt 2007-03-08 23:14:45.000000000 +0100 @@ -1,19 +1,19 @@ TCP Maintenance and Minor L. Eggert -Extensions (tcpm) NEC +Extensions (tcpm) Nokia Internet-Draft F. Gont Intended status: Standards Track UTN/FRH -Expires: April 25, 2007 October 22, 2006 +Expires: September 6, 2007 March 5, 2007 TCP User Timeout Option - draft-ietf-tcpm-tcp-uto-04 + draft-ietf-tcpm-tcp-uto-05 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,289 +24,273 @@ 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 April 25, 2007. + This Internet-Draft will expire on September 6, 2007. Copyright Notice - Copyright (C) The Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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 - based on knowledge of the peer's user timeout. 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. Increasing the user timeouts allows established TCP - connections to survive extended periods of disconnection. Decreasing - the user timeouts allows busy servers to explicitly notify their - clients that they will maintain the connection state only across - short periods of disconnection. + 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 allows the other end to adapt its user timeout + accordingly. Increasing the user timeouts on both ends of a TCP + connection allows it to survive extended periods without end-to-end + connectivity. Decreasing the user timeouts allows busy servers to + explicitly notify their clients that they will maintain the + connection state only for a short time without connectivity. 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 . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Special Option Values . . . . . . . . . . . . . . . . . . 9 - 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 - 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 + 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 + 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9 + 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 9 + 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 14 - Appendix B. Document Revision History . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 + Appendix A. Document Revision History . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 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 a network disconnection lasts + 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 [TCP-ILLU], and the - TCP connection will close when the user timeout occurs. In the - absence of an application-specified user timeout, the TCP - specification [RFC0793] defines a default user timeout of 5 minutes. + any transmission attempt, including keep-alives, and the TCP + connection will close when the user timeout occurs. + In the absence of an application-specified user timeout, the TCP + specification [RFC0793] defines a default user timeout of 5 minutes. The Host Requirements RFC [RFC1122] refines this definition by - introducing two thresholds, R1 and R2 (R2 > R1), on the number of - retransmissions of a single segment. It suggests that TCP should - notify applications when R1 is reached for a segment, and close the - connection once R2 is reached. [RFC1122] also defines the - recommended values for R1 (three retransmissions) and R2 (100 + introducing two thresholds, R1 and R2 (R2 > R1), that control the + number of retransmission attempts for a single segment. It suggests + that TCP should notify applications when R1 is reached for a segment, + and close the connection when R2 is reached. [RFC1122] also defines + the recommended values for R1 (three retransmissions) and R2 (100 seconds), noting that R2 for SYN segments should be at least 3 minutes. 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 [SOLARIS-MANUAL]. Although some TCP implementations allow applications to set their - local user timeout, there is no in-protocol mechanism to signal - changes in the local user timeout to remote peers. This causes local - changes to be ineffective, because the peer will still close the - connection after its user timeout expires, even when the host has - raised its local user timeout. The ability to suggest the remote - peer a user timeout to be used for the connection can improve TCP's - operation in scenarios that are currently not well supported. One - example of such scenarios are mobile hosts that change network - attachment points based on current location. Such hosts, maybe using - MobileIP [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 of disconnection during which no network service - is available. Other factors that can cause transient periods of - disconnection are high levels of congestion as well as link or - routing failures inside the network. + local user timeout, TCP has no in-protocol mechanism to signal + changes to the local user timeout to the other end. 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. - 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 user timeouts. In other - scenarios, the length and time of a network disconnection may even be - predictable. For example, an orbiting node on a non-geostationary - satellite might experience disconnections due to line-of-sight - blocking by other planetary bodies. The disconnection periods of - such a node may be easily computable from orbital mechanics. + The ability to inform the other end about the local user timeout for + the connection can improve TCP operation in scenarios that are + currently not well supported. One example of such scenarios are + 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. - This document specifies a new TCP option - the User Timeout Option - (UTO) - that allows a TCP to advertise its current local user timeout - parameter. Thus, based on the information advertised by the remote - TCP peer, a TCP may modify its own user timeout accordingly. This - allows, for example, mobile hosts to maintain TCP connections across - disconnected periods that are longer than their peer's default user - timeout. A second use of the TCP User Timeout Option is - advertisement of shorter-than-default user timeouts. This can allow + 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 allows the other end to + adapt its user timeout accordingly. Increasing the user timeouts on + both ends of a TCP connection allows it to survive extended periods + without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will - maintain the state associated with established connections only - across short periods of disconnection. - - Use of the TCP User Timeout Option could be triggered either by an - API call or by a system-wide toggle. The API could be, for example, - a Socket option that would need to be explicitly set by the - corresponding application. This option would default to "off". A - system-wide toggle would allow a system administrator to enable the - use of the TCP User Timeout Option on a system-wide basis, and set - the option a desired value. This system-wide toggle would allow the - use of the option by application programs that have not been - explicitly coded to do so. If such a system-wide toggle were - provided, it would default to "off". - - In all cases, use of the TCP User Timeout Option would depend on an - active decision, either by the application programmer (by means of an - API call), or by a system administrator (by means of a system-wide - toggle). + maintain the connection state only for a short time without + connectivity. 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 - Sending a TCP User Timeout Option informs the remote peer of the - current local user timeout for the connection, and suggests the TCP - peer to adapt its user timeout accordingly. The user timeout value - included in a TCP User Timeout Option specifies the requested user - timeout during the synchronized states of a connection (ESTABLISHED, - FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). - Connections in other states MUST the default timeout values defined - in [RFC0793] [RFC1122]. + Use of the TCP User Timeout Option can be enabled either on a per- + application basis, e.g., through a socket option, or controlled by a + system-wide setting. TCP maintains three per-connection state + variables to control the operation of UTO options, two of which + (ENABLED and CHANGEABLE) are new: - 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. + ENABLED (Boolean) + Flag that controls whether UTO options are enabled for a + connection. Defaults to false. - A host that supports the TCP User Timeout Option SHOULD include one - 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 + LOCAL_UTO + Local user timeout in effect for this connection. This is either + the system-wide default or an application-specified value. + Defaults to the system-wide default. + + CHANGEABLE (Boolean) + Flag that controls whether the local user timeout may be changed + based on UTO options received from the other end. Defaults to + true and becomes false when an application explicitly sets + LOCAL_UTO. + + 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 + timeout. This adaptation only happens if the the other end has + explicitly enabled it (CHANGEABLE is true). + + Before opening a connection, an application that wishes to use UTO + options SHOULD enable their use by setting ENABLED to true. It MAY + pick an appropriate local UTO by setting LOCAL_UTO, which is + otherwise set to the system default. Finally, the application should + determine whether it will allow the local UTO to change based on + received UTO options from the other end. The default is to allow + this for connections that do not have a specific user timeout + concerns, i.e., connections that operate with the default LOCAL_UTO. + If an application explicitly sets LOCAL_UTO, CHANGEABLE MUST become + false, to prevent UTO options from the other end to override local + application requests. Alternatively, applications MAY set or clear + CHANGEABLE directly. + + 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. Systems MAY provide system-wide default settings for the + ENABLED, LOCAL_UTO and CHANGEABLE connection parameters when + applications do not initialize them themselves. + + 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 + to minimize the amount of state information 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, - resource constraints or external policies indicate otherwise (see - Section 5). If so, hosts may use a different user timeout for the - connection. + A host that supports UTO options SHOULD include it in the next + possible outgoing segment whenever it starts using a new user timeout + for the connection. This allows the other end to adapt its local + user timeout for the connection accordingly. - A TCP implementation that does not support the TCP User Timeout - Option MUST silently ignore it [RFC1122], thus ensuring - interoperability. + A TCP implementation that does not support UTO options MUST silently + ignore them [RFC1122], thus ensuring interoperability. Hosts MUST impose upper and lower limits on the user timeouts they - use. Section 3.1 discusses user timeout limits, and describes a - RECOMMENDED scheme to apply them. A TCP User Timeout Option with a - value of zero (i.e., "now") is nonsensical and is used for a special - purpose, see Section 3.4. Section 3.1 discusses potentially - problematic effects of other user timeout durations. + use for a connection. Section 3.1 discusses user timeout limits and + discusses potentially problematic effects of user timeout settings. 3.1. Changing the Local User Timeout When a host receives a TCP User Timeout Option, it must decide whether to change the local user timeout of the corresponding - connection. Application-requested user timeout values always take - precedence over timeout values received from the peer in a TCP User - Timeout Option. [anchor3] Consequently, unless the application on the - local host has requested a specific user timeout for the connection, - e.g., through the OPEN or SEND calls, hosts SHOULD adjust their local - user timeout in response to receiving a TCP User Timeout Option, as - described in the remainder of this section. If the local application - has requested a specific local user timeout, TCP implementations MUST - NOT change it in response to receiving a TCP User Timeout Option. In - this case, they SHOULD, however, notify the application about the - user timeout value received from the peer. + connection. If the CHANGEABLE flag is false, LOCAL_UTO MUST NOT be + changed, regardless of the received UTO option. Without this + restriction, UTO would modify TCP semantics, because application- + requested UTOs could be overridden by peer requests. In this case, + they SHOULD, however, notify the application about the user timeout + value received from the other end. - The User Timeout Option specifies the user timeout in terms of time - units, rather than in terms of number of retransmissions or round- - trip times (RTTs), as in most cases the periods of disconnection have - to do with operation and mobility patterns, rather than with the - current network conditions. Thus, the TCP User Timeout Option allows - hosts to exchange user timeout values from 1 second to over 9 hours - at a granularity of seconds, and from 1 minute to over 22 days at a - granularity of minutes. (An option value of zero is reserved for a - special purpose, see Section 3.4.) + In general, unless the application on the local host has requested a + specific LOCAL_UTO for the connection, CHANGEABLE will be true and + hosts SHOULD adjust the local user timeout in response to receiving a + UTO option, as described in the remainder of this section. + + The UTO option specifies the user timeout in in seconds or minutes, + rather than in number of retransmissions or round-trip times (RTTs). + Thus, the UTO option allows hosts to exchange user timeout values + from 1 second to over 9 hours at a granularity of seconds, and from 1 + minute to over 22 days at a granularity of minutes. Very short user timeout values can affect TCP transmissions over 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 [TCP-ILLU]. Although the TCP - User Timeout Option allows suggestion of short timeouts, applications - advertising them should consider these effects. + 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 of - disconnection. 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 of long timeout - values. + 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 + 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 user timeouts - based on upper and lower limits. Under the RECOMMENDED scheme, each - TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection - according to this formula: + based on upper and lower limits. - USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) + Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end + SHOULD compute LOCAL_UTO for a connection according to this formula: - Each field is to be interpreted as follows: + LOCAL_UTO = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) - USER_TIMEOUT - Resulting user timeout value to be adopted by the local TCP for a - connection. + Each field is to be interpreted as follows: U_LIMIT Current upper limit imposed on the user timeout of a connection by the local host. L_LIMIT Current lower limit imposed on the user timeout of a connection by the local host. - LOCAL_UTO - Current local user timeout of this specific connection. - REMOTE_UTO - Last "user timeout" value suggested by the remote peer by means of - the TCP User Timeout Option. + Last "user timeout" value received from the other end in a TCP + User Timeout Option. 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. + the maximum of current LOCAL_UTO and the last user timeout value + received from the other end will become the new LOCAL_UTO for the + connection. The rationale is that choosing the maximum of the two + values will let the connection survive longer periods without end-to- + end connectivity. If the end 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. [anchor3] 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 5discusses the details of these attacks. @@ -318,53 +302,60 @@ 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 unnecessarily. Therefore, the lower limit (L_LIMIT) MUST be larger than the current - retransmission timeout (RTO) for the connection. + retransmission timeout (RTO) for the connection. It is worth noting + that an upper limit may be imposed on the RTO, provided it is at + least 60 seconds [RFC2988]. -3.2. Reliability Considerations +3.2. UTO Option Reliability 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 - Timeout Option is lost, the option may never reach the intended peer. + does not define a reliability handshake for UTO option exchanges. + When a segment that carries a UTO option is lost, the other end will + simply not have the opportunity to update its local UTO. Implementations MAY implement local mechanisms to improve delivery - reliability, such as retransmitting the TCP User Timeout Option when - they retransmit the segment that originally carried it, or - "attaching" the option to a byte in the stream and retransmitting the - option whenever that byte or its ACK are retransmitted. + reliability, such as retransmitting a UTO option when they retransmit + a segment that originally carried it, or "attaching" the option to a + byte in the stream and retransmitting the option whenever that byte + or its ACK are retransmitted. It is important to note that although these mechanisms can improve - transmission reliability for the TCP User Timeout Option, they do not - guarantee delivery (a three-way handshake would be required for - this). Consequently, implementations should not assume that a TCP - User Timeout Option is reliably transmitted. + transmission reliability for UTO options, they do not guarantee + delivery (a three-way handshake would be required for this). + Consequently, implementations MUST NOT assume that UTO options are + transmitted reliably. 3.3. Option Format - 0 1 2 3 + Sending a TCP User Timeout Option informs the other end of the + current local user timeout for the connection and suggests that the + other end adapt its user timeout accordingly. The user timeout value + included in a UTO option contains the local user timeout (LOCAL_UTO) + used during the synchronized states of a connection (ESTABLISHED, + FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). + Connections in other states MUST use the default timeout values + defined in [RFC0793] and [RFC1122]. + 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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (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) @@ -375,111 +366,95 @@ 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" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds. User Timeout (15 bits) - Specifies the user 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.4. Special Option Values - - Whenever it is legal to do so according to the specification in the - previous sections, TCP implementations MAY send a zero-second TCP - User Timeout Option, i.e, with a "User Timeout" field of zero and a - "Granularity" of zero. This signals their peers that they support - the option, but do not suggest a specific user timeout value at that - time. Essentially, a zero-second TCP User Timeout Option acts as a - "don't care" value. + Specifies the user timeout (LOCAL_UTO) used 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. - Thus, the sender SHOULD adapt its local user timeout according to the - peer's UTO, and the receiver SHOULD continue using its local user - timeout. In order to achieve this, the receiver of a zero-second TCP - User Timeout Option SHOULD perform the RECOMMENDED strategy for - calculating a new local USER_TIMEOUT described in Section 3.1, with a - numeric value of zero seconds for REMOTE_UTO. The sender SHOULD - perform the same calculation as described in Section 3.1, with a - numeric value of zero seconds for LOCAL_UTO. +3.4. Reserved Option Values - A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" - field of zero and a "Granularity" bit of one, is reserved for future - use. TCP implementations MUST NOT send it and MUST ignore it upon - reception. + An empty TCP User Timeout Option, i.e., one with a "User Timeout" + field of zero and a "Granularity" bit of either minutes (1) or + seconds (0), is reserved for future 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 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. + transport protocols, Medina et al. have shown that the vast majority + of modern TCP stacks correctly handle unknown TCP options [MEDINA]. + In this study, 3% of connections failed when an unknown TCP option + appeared in the middle of a connection. Because the number of + failures caused by unknown options is small and they are a result of + incorrectly implemented TCP stacks that violate existing requirements + to ignore unknown options, they do not warrant special measures. + Thus, this document does not define a mechanism to negotiate support + of the TCP User Timeout Option during 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. + inactivity. If such a firewall exists along the path, 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 + contents - accordingly. 4.2. TCP Keep-Alives - Some TCP implementations, such as the one in BSD systems, use a + 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 of disconnection. - Therefore, if a TCP peer enables TCP keep-alives for a connection - that is 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. + otherwise have survived the transient period without connectivity. + Therefore, if a connection enables keep-alives that 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 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. 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. + already exacerbate resource exhaustion. Several approaches can help mitigate this issue. First, implementations can require prior peer authentication, e.g., using IPsec [RFC4301], 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 [RFC2246]. Although these are + across the connection has succeeded [RFC4346]. 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 @@ -552,98 +527,80 @@ 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. + Mitigations", draft-ietf-tcpm-syn-flood-01 (work in + progress), December 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. + [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. [SOLARIS-MANUAL] Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002. - [TCP-ILLU] - Stevens, W., "TCP/IP Illustrated, Volume 1: The - Protocols", Addison-Wesley , 1994. - Editorial Comments - [anchor3] Without this, UTO would modify TCP semantics, because - application-requested UTOs could be overridden by peer - requests. - -Appendix A. Alternative solutions - - The same benefits could be obtained through an application-layer - mechanism, i.e., exchanging user timeout information via application - messages and having the application adjust the user timeouts through - the TCP API on both sides of a connection. This approach would not - require a new TCP option, but would require changing all application - implementations that desire to tolerate extended periods of - disconnection, and in most cases would also require a modification to - the corresponding application layer protocol. With the proposed TCP - option, application changes may not be necessary at all, or may be - restricted to sender- or receiver-side only, and there is no need to - modify the corresponding application protocol. - - A different approach to tolerate longer periods of disconnection - would be to simply increase the system-wide user timeout on both - peers. This approach has the benefit of not requiring a new TCP - option or application changes. However, it can also significantly - increase the amount of connection state a busy server must maintain, - because a longer global timeout value would apply to all its - 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. + [anchor3] Lars: With the new CHANGEABLE flag, which prevents + changing of LOCAL_UTO when an application has indicated + that it cares about the value, I think the formula can + become LOCAL_UTO = min(U_LIMIT, max(REMOTE_UTO, L_LIMIT)), + i.e., we adopt whatever the other end suggests, given that + it is with in acceptable limits. I didn't want to make + this change without discussing it first, however. -Appendix B. Document Revision History +Appendix A. Document Revision History To be removed upon publication + +----------+--------------------------------------------------------+ | Revision | Comments | +----------+--------------------------------------------------------+ + | 05 | Made behavior on when to change/not change the local | + | | UTO in response to incoming options consistent through | + | | the document. This required some reshuffling of text | + | | and also removed the need for the special "don't care" | + | | option value. | | 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 | + | | should be sent upon receipt of an UTO from the other | + | | end. 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 | | | "negotiate", "coordinate", etc. that were left from | | | pre-WG-document times when the UTO was a more | | | formalized exchange instead of the advisory one it is | | | now. Application-requested UTOs take precedence over | | | ones received from the peer (pointed out by Ted | | | Faber). Added a brief mention of SO_SNDTIMEO and a | | | slightly longer discussion of SO_RCVTIMEO. | @@ -658,54 +615,52 @@ | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | | secretariat after WG adoption. Thus, permit | | | derivative works. Updated Lars Eggert's funding | | | attribution. Updated several references. No | | | technical changes. | +----------+--------------------------------------------------------+ Authors' Addresses Lars Eggert - NEC Network Laboratories - Kurfuerstenanlage 36 - Heidelberg 69115 - Germany - - Phone: +49 6221 90511 43 - Fax: +49 6221 90511 55 - Email: lars.eggert@netlab.nec.de - URI: http://www.netlab.nec.de/ + Nokia Research Center + P.O. Box 407 + Nokia Group 00045 + Finland + Phone: +358 50 48 24461 + Email: lars.eggert@nokia.com + URI: http://research.nokia.com/people/lars_eggert/ Fernando Gont - Universidad Tecnologica Nacional + 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 Internet Society (2006). + Copyright (C) The IETF Trust (2007). 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 + 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