[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]