wdiff draft-ietf-tcpm-tcp-uto-04.txt draft-ietf-tcpm-tcp-uto-05.txt

TCP Maintenance and Minor L. Eggert
Extensions (tcpm) NEC Nokia
Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH
Expires: April 25, September 6, 2007 March 5, 2007 October 22, 2006

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
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 April 25, September 6, 2007.

Abstract

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 for
a connection. Thus, value. This
information allows the remote TCP may modify other end to adapt 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.
accordingly. Increasing the user timeouts allows established on both ends of a TCP
connections
connection allows it to survive extended periods of disconnection. 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 across for a short periods of disconnection. 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. UTO Option Reliability Considerations . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 8
3.4. Special Reserved Option Values . . . . . . . . . . . . . . . . . . 9
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 9
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 9
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Alternative solutions . . . . . . . . . . . . . . . . 14
Appendix B. Document Revision History . . . . . . . . . . . . . . 14 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 14
Intellectual Property and Copyright Statements . . . . . . . . . . 17 16

1. Introduction

The Transmission Control Protocol (TCP) specification
[RFC0793]defines [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 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], 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 that control the
number of
retransmissions 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 once 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 TCP has no in-protocol mechanism to signal
changes in to the local user timeout to remote peers. the other end. This causes
local changes to be ineffective, ineffective in allowing a connection to survive
extended periods without connectivity, because the peer other end will
still close the connection after its user timeout expires, even when the host has
raised its local user timeout. expires.

The ability to suggest inform the remote
peer a other end about the local user timeout to be used for
the connection can improve TCP's 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
MobileIP 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 of disconnection during which no network service
is available. without end-to-end
connectivity. Other factors that can cause transient periods of
disconnection connectivity
disruptions are high levels of congestion as well as or link or routing failures
inside the network. In scenarios similar to the ones described above, these scenarios, a host may not know exactly
when or for how long it connectivity disruptions will be disconnected from the
network, occur, but it
might expect be able to determine an increased likelihood for such events due to
based on past mobility patterns and thus benefit from using longer
user timeouts. In other scenarios, the length and time and duration of a network disconnection
connectivity disruption may even be predictable. For example, an
orbiting node on a non-geostationary satellite might experience disconnections
connectivity disruptions due to line-of-sight blocking by other
planetary bodies. The disconnection periods timing of
such a node these events may be easily computable from
orbital mechanics.

This document specifies a new TCP option - the TCP User Timeout
Option
(UTO) - that allows one end of a TCP connection to advertise its
current local user timeout
parameter. Thus, based on the value. This information advertised by allows the remote
TCP peer, a TCP may modify other end to
adapt 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 Increasing the user
timeout. A second use timeouts on
both ends of the a TCP User Timeout Option is
advertisement of shorter-than-default connection allows it to survive extended periods
without end-to-end connectivity. Decreasing the user timeouts. This can allow timeouts allows
busy servers to explicitly notify their clients that they will
maintain the connection 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). 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

Use of the TCP User Timeout Option informs 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 remote peer operation of the
current local user timeout for the connection, UTO options, two of which
(ENABLED and suggests the TCP
peer CHANGEABLE) are new:

ENABLED (Boolean)
Flag that controls whether UTO options are enabled for a
connection. Defaults to adapt its user timeout accordingly. The false.

LOCAL_UTO
Local user timeout value
included in a TCP User Timeout Option specifies effect for this connection. This is either
the requested system-wide default or an application-specified value.
Defaults to the system-wide default.

CHANGEABLE (Boolean)
Flag that controls whether the local user timeout during may be changed
based on UTO options received from 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]. end. Defaults to
true and becomes false when an application explicitly sets
LOCAL_UTO.

Note that an exchange of TCP User Timeout Options UTO options between peers both ends of a
connection is not a binding negotiation. Transmission of a TCP User Timeout Option UTO
option is an advisory a suggestion that the peer other end consider adapting its local user
timeout. Hosts remain free to adopt This adaptation only happens if the the other end has
explicitly enabled it (CHANGEABLE is true).

Before opening a different user timeout,
or connection, an application that wishes to forcefully close or abort connections at any time for any
reason, whether or not they use custom user timeouts or have
suggested 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 peer system default. Finally, the application should
determine whether it will allow the local UTO to use them.

A host that supports change based on
received UTO options from the TCP User Timeout Option SHOULD include one
in each packet that carries a SYN flag. other end. The presence of this option default is not a negotiation of the capability, but simply an advisory
message specifying the currently preferred user timeout value. This
allows TCP to adopt allow
this for connections that do not have a specific user timeout with knowledge of
concerns, i.e., connections that used by operate with the
peer TCP default LOCAL_UTO.
If an application explicitly sets LOCAL_UTO, CHANGEABLE MUST become
false, to prevent UTO options from the very beginning of 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 data transfer phase.
Additionally, SYN and SYN-ACK packets and is a TCP that supports
reliable way to initially exchange and potentially adapt to UTO
values. Systems MAY provide system-wide default settings for the User Timeout Option
ENABLED, LOCAL_UTO and has
sent a CHANGEABLE connection parameters when
applications do not initialize them themselves.

In addition to exchanging UTO options in the SYN segment as a result of an active OPEN segments, a
connection that has enabled UTO options SHOULD include an a UTO option
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
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 UTO options SHOULD include it in the next
possible outgoing segment to its peer whenever it starts using a new user timeout
for the connection. This allows the peer other end 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 TCP implementation that does not support the TCP User Timeout
Option UTO options MUST silently
ignore it them [RFC1122], thus ensuring interoperability.

Hosts MUST impose upper and lower limits on the user timeouts they
use.
use for a connection. 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 limits and is used for a special
purpose, see Section 3.4. Section 3.1
discusses potentially problematic effects of other user timeout durations. 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 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 values always take
precedence over timeout values
value received from the peer in a TCP User
Timeout Option. [anchor3] Consequently, other end.

In general, unless the application on the local host has requested a
specific user timeout LOCAL_UTO for the connection,
e.g., through the OPEN or SEND calls, CHANGEABLE will be true and
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 in response to receiving a
UTO option, as described in the peer. remainder of this section.

The User Timeout Option UTO option specifies the user timeout in terms of time
units, in seconds or minutes,
rather than in terms of number of retransmissions or round-
trip 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. (RTTs).
Thus, the TCP User Timeout Option 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. (An option value of zero is reserved for a
special purpose, see Section 3.4.)

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]. minutes. Although the TCP
User Timeout Option 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.
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, and when CHANGEABLE is true, each
TCP end
SHOULD compute the user timeout (USER_TIMEOUT) LOCAL_UTO for a connection according to this formula:

USER_TIMEOUT

LOCAL_UTO = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))

Each field is to be interpreted as follows:

USER_TIMEOUT
Resulting user timeout value to be adopted by the local TCP for a
connection.

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 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 current LOCAL_UTO and the two announced values will be adopted for the last user timeout of 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 of disconnection. without end-to-
end connectivity. If the TCP 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 5 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 [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. It is worth noting
that an upper limit may be imposed on the RTO, provided it is at
least 60 seconds [RFC2988].

3.2. UTO Option Reliability Considerations

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 UTO option exchanges.
When a segment that carries a TCP User
Timeout Option UTO option is lost, the option may never reach other end will
simply not have the intended peer. opportunity to update its local UTO.

Implementations MAY implement local mechanisms to improve delivery
reliability, such as retransmitting the TCP User Timeout Option a UTO option when they retransmit the
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, UTO options, they do not guarantee
delivery (a three-way handshake would be required for this).
Consequently, implementations should not MUST NOT assume that UTO options are
transmitted reliably.

3.3. Option Format

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 TCP
User Timeout Option is reliably transmitted.

3.3. Option Format 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)
A TCP option number [RFC0793] to be assigned by IANA upon
publication of this document (see Section 6).

Length (8 bits)
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 (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.

3.4. Special Reserved 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.

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.

A zero-minute

An empty TCP User Timeout Option, i.e., one with a "User Timeout"
field of zero and a "Granularity" bit of one, 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 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
these 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 taking special measures to handle these
cases. In particular, we do measures.
Thus, this document does not define a separate mechanism to negotiate support
of the TCP User Timeout Option on 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, 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 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. without connectivity.
Therefore, if a TCP peer connection enables TCP keep-alives for a connection 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 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]. [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
high-UTO connections a server supports in the face of an attack turns
that attack into a denial-of-service attack against the service of
high-UTO connections.

Per-peer limits cannot protect against distributed denial of service
attacks, where multiple clients coordinate a resource exhaustion
attack that uses long user timeouts. To protect against such
attacks, TCP implementations could reduce the duration of accepted
user 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 suggested long user timeouts. On the other hand, resetting
connections to untrusted peers that use long user timeouts may be
effective. In general, using the peers' level of trust as a
parameter during the load-shedding decision process may be useful.
Note that if TCP needs to close or abort connections with a long TCP
User Timeout Option to shed load, these connections are still no
worse off than without the option.

Finally, upper and lower limits on user timeouts, discussed in
Section 3.1, can be an effective tool to limit the impact of these
sorts of attacks.

6. IANA Considerations

This section is to be interpreted according to [RFC2434].

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.

7. Acknowledgments

The following people have improved this document through thoughtful
suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas
Pentikousis, Juergen Quittek, Joe Touch, Stefan Schmid, Simon
Schuetz, Tim Shepard and Martin Stiemerling.

Lars Eggert is partly funded by Ambient Networks, a research project
supported by the European Commission under its Sixth Framework
Program. The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the Ambient Networks project or the European Commission.

8. References

8.1. Normative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.

[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
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 draft-ietf-tcpm-syn-flood-01 (work in
progress), July 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.

[RFC2246] Dierks, T.

[RFC2988] Paxson, V. and C. Allen, "The TLS Protocol Version 1.0", M. Allman, "Computing TCP's Retransmission
Timer", RFC 2246, January 1999. 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 Lars: With the TCP API on both sides of a connection. This approach would not
require a new TCP option, but would require CHANGEABLE flag, which prevents
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 LOCAL_UTO when an 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, indicated
that it can also significantly
increase cares about 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 value, I think the formula can
become LOCAL_UTO = min(U_LIMIT, max(REMOTE_UTO, L_LIMIT)),
i.e., we adopt whatever the other hand, allows hosts end suggests, given that
it is with in acceptable limits. I didn't want to selectively manage the user timeouts of individual connections,
reducing the amount of state they must maintain across disconnected
periods. make
this change without discussing it first, however.

Appendix B. A. Document Revision History

To be removed upon publication

Authors' Addresses

Lars Eggert
NEC Network Laboratories
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Nokia Research Center
P.O. Box 407
Nokia Group 00045
Finland

Phone: +49 6221 90511 43
Fax: +49 6221 90511 55 +358 50 48 24461
Email: lars.eggert@netlab.nec.de lars.eggert@nokia.com
URI: http://www.netlab.nec.de/ http://research.nokia.com/people/lars_eggert/
Fernando Gont
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

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 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
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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).