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
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]
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.
Eggert Expires October 13, 2004 [Page 2]
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.
Eggert Expires October 13, 2004 [Page 3]
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.)
Eggert Expires October 13, 2004 [Page 4]
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
possibility of negotiating new timeouts after connection
establishment.
Eggert Expires October 13, 2004 [Page 5]
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
Eggert Expires October 13, 2004 [Page 6]
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.
Eggert Expires October 13, 2004 [Page 7]
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.
Eggert Expires October 13, 2004 [Page 8]
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. |
+-----------+-------------------------------------------------------+
Eggert Expires October 13, 2004 [Page 9]
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.
Eggert Expires October 13, 2004 [Page 10]