Network Working Group L. Eggert
`Internet-Draft NEC
`Expires: October 13, 2004 April 14, 2004
`
` TCP Abort Timeout Option
` draft-eggert-tcpm-tcp-abort-timeout-option-00
`
`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 October 13, 2004.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2004). All Rights Reserved.
`
`Abstract
`
` The TCP Abort Timeout Option allows conforming TCP implementations to
` negotiate individual, per-connection abort timeouts. Lengthening
` abort timeouts allows established TCP connections to survive periods
` of disconnection.
`
`1. Introduction
`
`Page 1 of 20
`
`GOOGLE EXHIBIT 1006
`
`

`

` Some hosts are only intermittently connected to the Internet. One
` example is mobile hosts that change network attachment points based
`
`Eggert Expires October 13, 2004 [Page 1]
`
`Page 2 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` on current location, for example using MobileIP [5] or HIP [6]. In
` between connected periods, mobile hosts may experience disconnected
` periods during which no network service is available. When such hosts
` use the Transmission Control Protocol (TCP) [1], their established
` TCP connections can abort during periods of disconnection.
`
` The TCP specification [1] includes a "user timeout" that defines the
` maximum amount of time that segments may remain unacknowledged before
` TCP will abort the connection. If a disconnection lasts longer than
` the user timeout, the TCP connection will abort. 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 [7].
`
` 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 [8]. (The Host Requirements
` document [2] requires the timeout to be at least three minutes for
` the SYN-SENT case.)
`
` This document specifies a new TCP option - the Abort Timeout Option -
` that allows conforming hosts to negotiate per-connection abort
` timeouts. This allows mobile hosts to maintain TCP connections across
` disconnected periods that are longer than their system’s default
` abort timeout.
`
` 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].
`
`2. Specification
`
` Figure 1 shows the format of the TCP Abort Timeout Option. In Figure
` 1, "X" is a TCP option number to be assigned by IANA upon publication
` of this document (see Section 5.) "Abort Timeout" is the desired
` abort timeout of the connection, specified in seconds.
`
`Page 3 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 2]
`
`Page 4 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` +----------+----------+
` | Kind=X | Length=6 |
` +----------+----------+----------+----------+
` | Abort Timeout |
` +----------+----------+----------+----------+
`
` Figure 1: TCP Abort Timeout Option
`
`2.1 Operation
`
` A host wishing to negotiate a specific abort timeout for a connection
` MAY include the TCP Abort Timeout Option in any segment with a SYN
` flag, i.e., either the initial SYN or the SYN-ACK. It MUST NOT
` include an Abort Timeout Option in any other segment.
`
` The timeout value included in the option specifies the proposed abort
` timeout for the connection. Connections use abort timeouts negotiated
` with Abort Timeout Options during the ESTABLISHED state only. When
` connections are in other states, normal timeouts are used [1][2].
`
` A host proposing an abort timeout to its peer MUST be prepared to
` accept a shorter timeout value than proposed after the negotiation.
` See Section 2.2 for a discussion of valid timeout values.
`
` Upon receipt of a segment with the Abort Timeout Option, the
` receiving host decides whether to accept, shorten, or reject its
` peer’s proposed abort timeout. Section 2.3 discusses the specifics of
` this decision.
`
` When a receiving host accepts or shortens the offered abort timeout,
` it MUST include an Abort Timeout Option with the corresponding
` timeout value in the next segment it sends. This will either be the
` SYN-ACK, if it received the peer’s Timeout Abort Option in the SYN
` segment, or the first ACK if it received the option in the SYN-ACK
` segment.
`
` This specification allows both the initiator of a TCP connection
` (i.e., the node sending the SYN) as well as the responder of a TCP
` connection (i.e., the node receiving the SYN) to initiate an abort
` timeout negotiation during the connection’s three-way handshake.
` Figure 2 illustrates the two allowed exchanges.
`
`Page 5 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 3]
`
`Page 6 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` Initiator Responder Initiator Responder
` | | | |
` | SYN+ATO | | SYN |
` |---------------->| |---------------->|
` | | | |
` | SYN/ACK+ATO | | SYN/ACK+ATO |
` |<----------------| |<----------------|
` | | | |
` | ACK | | ACK+ATO |
` |---------------->| |---------------->|
` | | | |
` V V V V
`
` Figure 2: Allowed TCP Abort Timeout Option (ATO) Exchanges
`
` If the receiving host accepts the peer’s offered abort timeout, it
` MUST echo the offered timeout value in the Abort Timeout Option it
` sends. If it shortens the timeout, it MUST send an Abort Timeout
` Option with a timeout value that is correspondingly less than the
` offered one. In both cases, it MUST then use the selected abort
` timeout value for the connection.
`
` If the receiving host decides to reject its peer’s offered abort
` timeout, it MUST NOT include an Abort Timeout Option in the next
` segment it sends. It MUST then also use its default timeout value for
` the connection.
`
` Whether it accepts, shortens or rejects the peer’s offer, the
` receiving host MUST NOT include an Abort Timeout Option in any other
` segment.
`
` The host that initially proposed the Abort Timeout Option analyzes
` the next segment it receives from its peer. If the next reply segment
` does not contain an Abort Timeout Option, the connection MUST use the
` default abort timeout. If it does, the connection MUST use the abort
` timeout contained inside the Abort Timeout Option. This can be a
` different abort timeout than initially proposed, if the peer decided
` to shorten it.
`
` A TCP implementation that does not support the TCP Abort Timeout
` Option SHOULD silently ignore it [2]. This causes the connection to
` use the default abort timeout, thus ensuring interoperability. For
` the same reason, TCP implementations that support the TCP Abort
` Timeout Option SHOULD ignore it when they receive the option in a
` segment other than a SYN or first ACK. Future extensions to this
` document may modify the latter rule (see Section 3.)
`
`Page 7 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 4]
`
`Page 8 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
`2.2 Length of the Abort Timeout
`
` The TCP specification [1] does not define a range for permitted abort
` timeouts. Similarly, this document does not restrict the range of
` timeout values used with the TCP Abort Timeout Option. The 32-bit
` value in the option can express abort timeouts from zero seconds to
` over 136 years.
`
` Very short timeout values can affect TCP retransmissions over
` high-delay paths. Many TCP implementations default to abort timeout
` values of a few minutes [7]. Although the TCP Abort Timeout Option
` allows negotiation of shorter timeouts, applications requesting such
` short timeouts 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.
`
`2.3 Accepting, Shortening or Rejecting an Abort Timeout Option
`
` As described in Section 2, when a host receives a TCP Abort Timeout
` Option from its peer, it may accept, shorten, or reject the offer. To
` accept the offer, the host echoes the proposed value back to its peer
` by including a TCP Abort Timeout Option in its next segment. To
` shorten the offer, it lowers the timeout value accordingly before
` sending. To reject the offer, it does not include such an option in
` its next segment.
`
` The decision of whether to accept, shorten, or reject an offered
` timeout is a local policy decision. This document does not further
` discuss this decision, other than discussing relevant security
` considerations in Section 4.
`
`3. Future Extensions and Open Questions
`
` This section discusses possible future extensions or modifications of
` the TCP Abort Timeout Option described in this document. Community
` input on these items is highly appreciated.
`
`3.1 Timeout Negotiation for Established Connections
`
` The processing of the Abort Timeout Option defined in Section 2
` requires timeout negotiation to occur during a connection’s three-way
` handshake. Although this simplifies the protocol, it eliminates the
`
`Page 9 of 20
`
`

`

` possibility of negotiating new timeouts after connection
` establishment.
`
`Eggert Expires October 13, 2004 [Page 5]
`
`Page 10 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` Negotiation of timeouts for established connections may be useful.
` Connections could default to starting with shorter timeouts and only
` negotiate longer timeouts when disconnection was imminent. This may
` reduce the amount of state held during times of disconnection. A
` future revision of this document may specify means for negotiating
` timeouts for established connections.
`
`3.2 Abort Timeout Option Granularity and Length
`
` Currently, the Abort Timeout Option specifies abort timeouts as
` 32-bit values with a granularity of seconds (Section 2.)
` Consequently, the current option format can express aborts timeouts
` from zero seconds to over 136 years.
`
` It may be useful to permit finer-grained timeouts, e.g., milliseconds
` instead of seconds. Likewise, it may be useful to lengthen or shorten
` the timeout field in the option to permit longer timeouts or reduce
` the required header space. For example, a 16-bit timeout value with a
` granularity of seconds allows timeout values up to 18.2 hours,
` whereas a 32-bit timestamp with millisecond granularity allows
` timeout values up to 49.7 days.
`
`3.3 Upper and Lower Bounds on Abort Timeouts
`
` With the current Abort Timeout Option, initiators can propose abort
` timeouts and recipients may reduce the offered timeout values. This
` scheme grants recipients some level of control over abort timeouts
` for their connections. When initiators propose very long timeouts,
` recipients may reduce the timeout offer to an acceptable length that
` may still be longer than the default. In a sense, timeouts offered by
` initiators are upper bounds on the actual timeouts used for
` established connections.
`
` The current Abort Timeout negotiation does not permit initiators to
` specify a corresponding lower bound. Recipients may arbitrarily
` shorten timeout offers, potentially resulting in much shorter
` timeouts than initiators desired. A straightforward extension of the
` current TCP Timeout Option would offer both upper and lower bounds
` for user timeouts. Recipients of the extended offer would then choose
` a specific timeout within the offered bounds.
`
`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 Abort Timeout Option, because abort timeouts
`
`Page 11 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 6]
`
`Page 12 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` negotiated during the handshake only affect the ESTABLISHED state,
` 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
` IPsec [9], before accepting long abort timeouts for the peer’s
` connections. Although this is arguably the most complete solution, it
` depends on external mechanisms to establish trust.
`
` 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 length 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.
`
`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 in http://www.iana.org/
` assignments/tcp-parameters.
`
`Page 13 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 7]
`
`Page 14 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
` IANA is requested to assign a TCP option number upon publication of
` this document.
`
`6. Acknowledgments
`
` The following people have improved this document through thoughtful
` suggestions: Simon Schuetz, Stefan Schmid, Martin Stiemerling, and
` Marcus Brunner.
`
`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] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
` 2002.
`
` [6] Moskowitz, R., "Host Identity Protocol Architecture",
` draft-moskowitz-hip-arch-05 (work in progress), October 2003.
`
` [7] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
` Addison-Wesley , 1994.
`
` [8] Sun Microsystems, "Solaris Tunable Parameters Reference Manual",
` Part No. 806-7009-10, 2002.
`
` [9] Kent, S. and R. Atkinson, "Security Architecture for the
` Internet Protocol", RFC 2401, November 1998.
`
`Page 15 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 8]
`
`Page 16 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 2004
`
`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. |
` +-----------+-------------------------------------------------------+
`
`Page 17 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 9]
`
`Page 18 of 20
`
`

`

`
`Internet-Draft TCP Abort Timeout Option April 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 IETF’s procedures with respect to rights in IETF 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.
`
`Page 19 of 20
`
`

`

`Eggert Expires October 13, 2004 [Page 10]
`
`Page 20 of 20
`
`