draft-ietf-tcpm-tcp-uto-06.txt   draft-ietf-tcpm-tcp-uto-07.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) Nokia Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: December 13, 2007 June 11, 2007 Expires: May 8, 2008 November 5, 2007
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-06 draft-ietf-tcpm-tcp-uto-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 13, 2007. This Internet-Draft will expire on May 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The TCP user timeout controls how long transmitted data may remain The TCP user timeout controls how long transmitted data may remain
unacknowledged before a connection is forcefully closed. It is a unacknowledged before a connection is forcefully closed. It is a
local, per-connection parameter. This document specifies a new TCP local, per-connection parameter. This document specifies a new TCP
option - the TCP User Timeout Option - that allows one end of a TCP option - the TCP User Timeout Option - that allows one end of a TCP
connection to advertise its current user timeout value. This connection to advertise its current user timeout value. This
information provides advice to the other end to adapt its user information provides advice to the other end of the TCP connection to
timeout accordingly. Increasing the user timeouts on both ends of a adapt its user timeout accordingly. Increasing the user timeouts on
TCP connection allows it to survive extended periods without end-to- both ends of a TCP connection allows it to survive extended periods
end connectivity. Decreasing the user timeouts allows busy servers without end-to-end connectivity. Decreasing the user timeouts allows
to explicitly notify their clients that they will maintain the busy servers to explicitly notify their clients that they will
connection state only for a short time without connectivity. maintain the connection state only for a short time without
connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 9 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document Revision History . . . . . . . . . . . . . . 13 Appendix A. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
The Transmission Control Protocol (TCP) specification [RFC0793] The Transmission Control Protocol (TCP) specification [RFC0793]
defines a local, per-connection "user timeout" parameter that defines a local, per-connection "user timeout" parameter that
specifies the maximum amount of time that transmitted data may remain specifies the maximum amount of time that transmitted data may remain
unacknowledged before TCP will forcefully close the corresponding unacknowledged before TCP will forcefully close the corresponding
connection. Applications can set and change this parameter with OPEN connection. Applications can set and change this parameter with OPEN
and SEND calls. If an end-to-end connectivity disruption lasts and SEND calls. If an end-to-end connectivity disruption lasts
longer than the user timeout, no acknowledgments will be received for longer than the user timeout, no acknowledgments will be received for
any transmission attempt, including keep-alives, and the TCP any transmission attempt, including keep-alives, and the TCP
connection will close when the user timeout occurs. connection will close when the user timeout occurs.
This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly.
That is, TCP remains free to disregard the advice provided by the UTO
option if local policies suggest it to be appropriate.
Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a
short time without connectivity.
In the absence of an application-specified user timeout, the TCP In the absence of an application-specified user timeout, the TCP
specification [RFC0793] defines a default user timeout of 5 minutes. specification [RFC0793] defines a default user timeout of 5 minutes.
The Host Requirements RFC [RFC1122] refines this definition by The Host Requirements RFC [RFC1122] refines this definition by
introducing two thresholds, R1 and R2 (R2 > R1), that control the introducing two thresholds, R1 and R2 (R2 > R1), that control the
number of retransmission attempts for a single segment. It suggests number of retransmission attempts for a single segment. It suggests
that TCP should notify applications when R1 is reached for a segment, that TCP should notify applications when R1 is reached for a segment,
and close the connection when R2 is reached. [RFC1122] also defines and close the connection when R2 is reached. [RFC1122] also defines
the recommended values for R1 (three retransmissions) and R2 (100 the recommended values for R1 (three retransmissions) and R2 (100
seconds), noting that R2 for SYN segments should be at least 3 seconds), noting that R2 for SYN segments should be at least 3
minutes. Instead of a single user timeout, some TCP implementations minutes. Instead of a single user timeout, some TCP implementations
offer finer-grained policies. For example, Solaris supports offer finer-grained policies. For example, Solaris supports
different timeouts depending on whether a TCP connection is in the different timeouts depending on whether a TCP connection is in the
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL].
Although some TCP implementations allow applications to set their Although some TCP implementations allow applications to set their
local user timeout, TCP has no in-protocol mechanism to signal local user timeout, TCP has no in-protocol mechanism to signal
changes to the local user timeout to the other end. This causes changes to the local user timeout to the other end of a connection.
local changes to be ineffective in allowing a connection to survive This causes local changes to be ineffective in allowing a connection
extended periods without connectivity, because the other end will to survive extended periods without connectivity, because the other
still close the connection after its user timeout expires. end will still close the connection after its user timeout expires.
The ability to inform the other end about the local user timeout for The ability to inform the other end of a connection about the local
the connection can improve TCP operation in scenarios that are user timeout can improve TCP operation in scenarios that are
currently not well supported. One example of such scenarios are currently not well supported. One example of such scenarios are
mobile hosts that change network attachment points based on current mobile hosts that change network attachment points based on current
location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423] location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423]
or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are
only intermittently connected to the Internet. In between connected only intermittently connected to the Internet. In between connected
periods, mobile hosts may experience periods without end-to-end periods, mobile hosts may experience periods without end-to-end
connectivity. Other factors that can cause transient connectivity connectivity. Other factors that can cause transient connectivity
disruptions are high levels of congestion or link or routing failures disruptions are high levels of congestion or link or routing failures
inside the network. In these scenarios, a host may not know exactly inside the network. In these scenarios, a host may not know exactly
when or for how long connectivity disruptions will occur, but it when or for how long connectivity disruptions will occur, but it
might be able to determine an increased likelihood for such events might be able to determine an increased likelihood for such events
based on past mobility patterns and thus benefit from using longer based on past mobility patterns and thus benefit from using longer
user timeouts. In other scenarios, the time and duration of a user timeouts. In other scenarios, the time and duration of a
connectivity disruption may even be predictable. For example, an connectivity disruption may even be predictable. For example, an
orbiting node on a non-geostationary satellite might experience orbiting node on a non-geostationary satellite might experience
connectivity disruptions due to line-of-sight blocking by other connectivity disruptions due to line-of-sight blocking by other
planetary bodies. The timing of these events may be computable from planetary bodies. The timing of these events may be computable from
orbital mechanics. orbital mechanics.
This document specifies a new TCP option - the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its
current user timeout value. This information provides advice to the
other end of the connection to adapt its user timeout accordingly.
That is, TCP remains free to disregard the advice provided by the UTO
option if local policies suggest it to be appropriate.
Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a
short time without connectivity.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
Use of the TCP User Timeout Option can be enabled either on a per- Use of the TCP User Timeout Option can be enabled either on a per-
application basis, e.g., through a socket option, or controlled by a connection basis, e.g., through a socket option, or controlled by a
system-wide setting. TCP maintains four per-connection state system-wide setting. TCP maintains four per-connection state
variables to control the operation of the UTO option, three of which variables to control the operation of the UTO option, three of which
(LOCAL_UTO, ENABLED and CHANGEABLE) are new: (ADV_UTO, ENABLED and CHANGEABLE) are new:
USER_TIMEOUT USER_TIMEOUT
TCP's USER TIMEOUT parameter, as specified in [RFC0793]. TCP's USER TIMEOUT parameter, as specified in [RFC0793].
LOCAL_UTO ADV_UTO
UTO option advertised to the remote TCP peer. This is an UTO option advertised to the remote TCP peer. This is an
application-specified value, and may be specified on a system-wide application-specified value, and may be specified on a system-wide
basis. If unspecified, it default to the default system-wide USER basis. If unspecified, it defaults to the default system-wide
TIMEOUT. USER TIMEOUT.
ENABLED (Boolean) ENABLED (Boolean)
Flag that controls whether the UTO option is enabled for a Flag that controls whether the UTO option is enabled for a
connection. Defaults to false. connection. Defaults to false.
CHANGEABLE (Boolean) CHANGEABLE (Boolean)
Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT Flag that controls whether USER_TIMEOUT (TCP's USER_TIMEOUT
parameter) may be changed based on an UTO option received from the parameter) may be changed based on an UTO option received from the
other end. Defaults to true and becomes false when an application other end of the connection. Defaults to true and becomes false
explicitly sets USER_TIMEOUT. when an application explicitly sets USER_TIMEOUT.
Note that an exchange of UTO options between both ends of a Note that an exchange of UTO options between both ends of a
connection is not a binding negotiation. Transmission of a UTO connection is not a binding negotiation. Transmission of a UTO
option is a suggestion that the other end consider adapting its user option is a suggestion that the other end consider adapting its user
timeout. This adaptation only happens if the the other end has timeout. This adaptation only happens if the the other end of the
explicitly allowed it (both ENABLED and CHANGEABLE are true). connection has explicitly allowed it (both ENABLED and CHANGEABLE are
true).
Before opening a connection, an application that wishes to use the Before opening a connection, an application that wishes to use the
UTO option SHOULD enable its use by setting ENABLED to true. It MAY UTO option enables its use by setting ENABLED to true. It may choose
pick an appropriate local UTO by setting LOCAL_UTO, which is an appropriate local UTO by explicitly setting ADV_UTO; otherwise,
otherwise set to the default USER TIMEOUT value. Finally, the UTO is set to the default USER TIMEOUT value. Finally, the
application should determine whether it will allow the local USER application should determine whether it will allow the local USER
TIMEOUT to change based on received UTO options from the other end. TIMEOUT to change based on received UTO options from the other end of
The default is to allow this for connections that do not have a a connection. The default is to allow this for connections that do
specific user timeout concerns. If an application explicitly sets not have specific user timeout concerns. If an application
the USER TIMEOUT, CHANGEABLE MUST become false, to prevent UTO explicitly sets the USER TIMEOUT, CHANGEABLE MUST become false, to
options from the other end to override local application requests. prevent UTO options from the other end to override local application
Alternatively, applications MAY set or clear CHANGEABLE directly. requests. Alternatively, applications can set or clear CHANGEABLE
directly through socket API calls.
Performing these steps before an active or passive open causes UTO Performing these steps before an active or passive open causes UTO
options to be exchanged in the SYN and SYN-ACK packets and is a options to be exchanged in the SYN and SYN-ACK packets and is a
reliable way to initially exchange and potentially adapt to UTO reliable way to initially exchange, and potentially adapt to, UTO
values. Systems MAY provide system-wide default settings for the values. TCP implementations MAY provide system-wide default settings
ENABLED, LOCAL_UTO and CHANGEABLE connection parameters. for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
In addition to exchanging UTO options in the SYN segments, a In addition to exchanging UTO options in the SYN segments, a
connection that has enabled UTO options SHOULD include a UTO option connection that has enabled UTO options SHOULD include a UTO option
in the first packet that does not have the SYN flag set. This helps in the first packet that does not have the SYN flag set. This helps
to minimize the amount of state information TCP must keep for to minimize the amount of state information TCP must keep for
connections in non-synchronized states, and is particularly useful connections in non-synchronized states, and is particularly useful
when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are when mechanisms such as "SYN cookies" [I-D.ietf-tcpm-syn-flood] are
implemented, allowing a newly-established TCP connection to benefit implemented, allowing a newly-established TCP connection to benefit
from the information advertised by the UTO option, even if the UTO from the information advertised by the UTO option, even if the UTO
contained in the initial SYN segment was not recorded. contained in the initial SYN segment was not recorded.
A host that supports the UTO option SHOULD include one in the next A host that supports the UTO option SHOULD include one in the next
possible outgoing segment whenever it starts using a new user timeout possible outgoing segment whenever it starts using a new user timeout
for the connection. This allows the other end to adapt its local for the connection. This allows the other end of the connection to
user timeout for the connection accordingly. A TCP implementation adapt its local user timeout accordingly. A TCP implementation that
that does not support the UTO option MUST silently ignore it does not support the UTO option MUST silently ignore it [RFC1122],
[RFC1122], thus ensuring interoperability. thus ensuring interoperability.
Hosts MUST impose upper and lower limits on the user timeouts they Hosts MUST impose upper and lower limits on the user timeouts they
use for a connection. Section 3.1 discusses user timeout limits and use for a connection. Section 3.1 discusses user timeout limits and
discusses potentially problematic effects of some user timeout potentially problematic effects of some user timeout settings.
settings.
Finally, it is worth noting that TCP's option space is limited to 40 Finally, it is worth noting that TCP's option space is limited to 40
bytes. As a result, if other TCP options are in use, they may bytes. As a result, if other TCP options are in use, they may
already consume all the available TCP option space, thus preventing already consume all the available TCP option space, thus preventing
the use of the UTO option specified in this document. Therefore, TCP the use of the UTO option specified in this document. Therefore, TCP
option space issues should be considered before enabling the UTO option space issues should be considered before enabling the UTO
option. option.
3.1. Changing the Local User Timeout 3.1. Changing the Local User Timeout
When a host receives a TCP User Timeout Option, it must decide When a host receives a TCP User Timeout Option, it must decide
whether to change the local user timeout of the corresponding whether to change the local user timeout of the corresponding
connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT connection. If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT
be changed, regardless of the received UTO option. Without this be changed, regardless of the received UTO option. Without this
restriction, the UTO option would modify TCP semantics, because an restriction, the UTO option would modify TCP semantics, because an
application-requested USER TIMEOUT could be overridden by peer application-requested USER TIMEOUT could be overridden by peer
requests. In this case, they SHOULD, however, notify the application requests. In this case TCP SHOULD, however, notify the application
about the user timeout value received from the other end. about the user timeout value received from the other end system.
In general, unless the application on the local host has requested a In general, unless the application on the local host has requested a
specific USER TIMEOUT for the connection, CHANGEABLE will be true and specific USER TIMEOUT for the connection, CHANGEABLE will be true and
hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in
response to receiving a UTO option, as described in the remainder of response to receiving a UTO option, as described in the remainder of
this section. this section.
The UTO option specifies the user timeout in seconds or minutes, The UTO option specifies the user timeout in seconds or minutes,
rather than in number of retransmissions or round-trip times (RTTs). rather than in number of retransmissions or round-trip times (RTTs).
Thus, the UTO option allows hosts to exchange user timeout values Thus, the UTO option allows hosts to exchange user timeout values
skipping to change at page 7, line 14 skipping to change at page 7, line 14
To protect against these effects, implementations MUST impose limits To protect against these effects, implementations MUST impose limits
on the user timeout values they accept and use. The remainder of on the user timeout values they accept and use. The remainder of
this section describes a RECOMMENDED scheme to limit TCP's USER this section describes a RECOMMENDED scheme to limit TCP's USER
TIMEOUT based on upper and lower limits. TIMEOUT based on upper and lower limits.
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
SHOULD compute the local USER TIMEOUT for a connection according to SHOULD compute the local USER TIMEOUT for a connection according to
this formula: this formula:
USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
Each field is to be interpreted as follows: Each field is to be interpreted as follows:
USER_TIMEOUT USER_TIMEOUT
USER TIMEOUT value to be adopted by the local TCP for this USER TIMEOUT value to be adopted by the local TCP for this
connection. connection.
U_LIMIT U_LIMIT
Current upper limit imposed on the user timeout of a connection by Current upper limit imposed on the user timeout of a connection by
the local host. the local host.
LOCAL_UTO ADV_UTO
User timeout advertised to the remote TCP peer in a TCP User User timeout advertised to the remote TCP peer in a TCP User
Timeout Option. Timeout Option.
REMOTE_UTO REMOTE_UTO
Last "user timeout" value received from the other end in a TCP Last user timeout value received from the other end in a TCP User
User Timeout Option. Timeout Option.
L_LIMIT L_LIMIT
Current lower limit imposed on the user timeout of a connection by Current lower limit imposed on the user timeout of a connection by
the local host. the local host.
This means that, provided they are within the upper and lower limits, The RECOMMENDED formula results in the maximum of the two advertised
the maximum of the two advertised values will be adopted for the user values to be adopted for the user timeout of the connection on both
timeout of the connection. The rationale is that choosing the ends, provided they are within the upper and lower limits. The
maximum of the two values will let the connection survive longer rationale is that choosing the maximum of the two values will let the
periods without end-to-end connectivity. If the end that announced connection survive longer periods without end-to-end connectivity.
the lower of the two user timeout values did so in order to reduce If the end that announced the lower of the two user timeout values
the amount of TCP state information that must be kept on the host, it did so in order to reduce the amount of TCP state information that
can, nevertheless, close or abort the connection whenever it wants. must be kept on the host, it can close or abort the connection
whenever it wants.
It must be noted that the two endpoints of the connection will not It must be noted that the two endpoints of the connection will not
necessarily adopt the same user timeout. necessarily adopt the same user timeout.
Enforcing a lower limit (L_LIMIT) prevents connections from closing Enforcing a lower limit (L_LIMIT) prevents connections from closing
due to transient network conditions, including temporary congestion, due to transient network conditions, including temporary congestion,
mobility hand-offs and routing instabilities. mobility hand-offs and routing instabilities.
An upper limit (U_LIMIT) can reduce the effect of resource exhaustion An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
attacks. Section 5 discusses the details of these attacks. attacks. Section 5 discusses the details of these attacks.
Note that these limits MAY be specified as system-wide constants or Note that these limits MAY be specified as system-wide constants or
at other granularities, such as on per-host, per-user, per-outgoing- at other granularities, such as on per-host, per-user, per-outgoing-
interface or even per-connection basis. Furthermore, these limits interface or even per-connection basis. Furthermore, these limits
need not be static. For example, they MAY be a function of system need not be static. For example, they MAY be a function of system
resource utilization or attack status and could be dynamically resource utilization or attack status and could be dynamically
adapted. adapted.
The Host Requirements RFC [RFC1122] does not impose any limits on the 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 length of the user timeout. However, it recommends a time interval
seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT) of at least 100 seconds. Consequently, the lower limit (L_LIMIT)
SHOULD be set to at least 100 seconds when following the RECOMMENDED SHOULD be set to at least 100 seconds when following the RECOMMENDED
scheme described in this section. Adopting a user timeout smaller scheme described in this section. Adopting a user timeout smaller
than the current retransmission timeout (RTO) for the connection than the current retransmission timeout (RTO) for the connection
would likely cause the connection to be aborted unnecessarily. would likely cause the connection to be aborted unnecessarily.
Therefore, the lower limit (L_LIMIT) MUST be larger than the current Therefore, the lower limit (L_LIMIT) MUST be larger than the current
retransmission timeout (RTO) for the connection. It is worth noting retransmission timeout (RTO) for the connection. It is worth noting
that an upper limit may be imposed on the RTO, provided it is at that an upper limit may be imposed on the RTO, provided it is at
least 60 seconds [RFC2988]. least 60 seconds [RFC2988].
3.2. UTO Option Reliability 3.2. UTO Option Reliability
skipping to change at page 8, line 51 skipping to change at page 9, line 8
It is important to note that although these mechanisms can improve It is important to note that although these mechanisms can improve
transmission reliability for the UTO option, they do not guarantee transmission reliability for the UTO option, they do not guarantee
delivery (a three-way handshake would be required for this). delivery (a three-way handshake would be required for this).
Consequently, implementations MUST NOT assume that UTO options are Consequently, implementations MUST NOT assume that UTO options are
transmitted reliably. transmitted reliably.
3.3. Option Format 3.3. Option Format
Sending a TCP User Timeout Option informs the other end of the Sending a TCP User Timeout Option informs the other end of the
current local user timeout for the connection and suggests that the connection of the current local user timeout and suggests that the
other end adapt its user timeout accordingly. The user timeout value other end adapt its user timeout accordingly. The user timeout value
included in a UTO option contains the LOCAL_UTO value, that is included in a UTO option contains the ADV_UTO value, that is expected
expected to be adopted for the TCP's USER TIMEOUT parameter during to be adopted for the TCP's USER TIMEOUT parameter during the
the synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-
FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other
states MUST use the default timeout values defined in [RFC0793] and states MUST use the default timeout values defined in [RFC0793] and
[RFC1122]. [RFC1122].
0 1 2 3 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 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 | | Kind = TBD | Length = 4 |G| User Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(One tick mark represents one bit.) (One tick mark represents one bit.)
Figure 1: Format of the TCP User Timeout Option Figure 1: Format of the TCP User Timeout Option
Figure 1 shows the format of the TCP User Timeout Option. It Figure 1 shows the format of the TCP User Timeout Option. It
contains these fields: contains these fields:
Kind (8 bits) Kind (8 bits)
A TCP option number [RFC0793] to be assigned by IANA upon This MUST be TBD, i.e., the TCP option number [RFC0793] assigned
publication of this document (see Section 6). by IANA upon publication of this document (see Section 6). [[Note
to RFC Editor: Replace "TBD" with the TCP option number that IANA
has allocated throughout this document, and remove this note.]]
Length (8 bits) Length (8 bits)
Length of the TCP option in octets [RFC0793]; its value MUST be 4. Length of the TCP option in octets [RFC0793]; its value MUST be 4.
Granularity (1 bit) Granularity (1 bit)
Granularity bit, indicating the granularity of the "User Timeout" Granularity bit, indicating the granularity of the "User Timeout"
field. When set (G = 1), the time interval in 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 field MUST be interpreted as minutes. Otherwise (G = 0), the time
interval in the "User Timeout" field MUST be interpreted as interval in the "User Timeout" field MUST be interpreted as
seconds. seconds.
User Timeout (15 bits) User Timeout (15 bits)
Specifies the user timeout suggestion for this connection.. It Specifies the user timeout suggestion for this connection. It
MUST be interpreted as a 15-bit unsigned integer. The granularity MUST be interpreted as a 15-bit unsigned integer. The granularity
of the timeout (minutes or seconds) depends on the "G" field. of the timeout (minutes or seconds) depends on the "G" field.
3.4. Reserved Option Values 3.4. Reserved Option Values
An TCP User Timeout Option with a "User Timeout" field of zero and a An TCP User Timeout Option with a "User Timeout" field of zero and a
"Granularity" bit of either minutes (1) or seconds (0) is reserved "Granularity" bit of either minutes (1) or seconds (0) is reserved
for future use. TCP implementations MUST NOT send it and MUST ignore for future use. Current TCP implementations MUST NOT send it and
it upon reception. MUST ignore it upon reception.
4. Interoperability Issues 4. Interoperability Issues
This section discusses interoperability issues related to introducing This section discusses interoperability issues related to introducing
the TCP User Timeout Option. the TCP User Timeout Option.
4.1. Middleboxes 4.1. Middleboxes
A TCP implementation that does not support the TCP User Timeout A TCP implementation that does not support the TCP User Timeout
Option MUST silently ignore it [RFC1122], thus ensuring Option MUST silently ignore it [RFC1122], thus ensuring
skipping to change at page 10, line 29 skipping to change at page 10, line 36
failures caused by unknown options is small and they are a result of failures caused by unknown options is small and they are a result of
incorrectly implemented TCP stacks that violate existing requirements incorrectly implemented TCP stacks that violate existing requirements
to ignore unknown options, they do not warrant special measures. to ignore unknown options, they do not warrant special measures.
Thus, this document does not define a mechanism to negotiate support Thus, this document does not define a mechanism to negotiate support
of the TCP User Timeout Option during the three-way handshake. of the TCP User Timeout Option during the three-way handshake.
Stateful firewalls usually time out connection state after a period Stateful firewalls usually time out connection state after a period
of inactivity. If such a firewall exists along the path, it may of inactivity. If such a firewall exists along the path, it may
close or abort connections regardless of the use of the TCP User close or abort connections regardless of the use of the TCP User
Timeout Option. In the future, such firewalls may learn to parse the Timeout Option. In the future, such firewalls may learn to parse the
TCP User Timeout Option and adapt connection state management TCP User Timeout Option in unencrypted TCP segments and adapt
accordingly. connection state management accordingly.
4.2. TCP Keep-Alives 4.2. TCP Keep-Alives
Some TCP implementations, such as those in BSD systems, use a Some TCP implementations, such as those in BSD systems, use a
different abort policy for TCP keep-alives than for user data. Thus, different abort policy for TCP keep-alives than for user data. Thus,
the TCP keep-alive mechanism might abort a connection that would the TCP keep-alive mechanism might abort a connection that would
otherwise have survived the transient period without connectivity. otherwise have survived the transient period without connectivity.
Therefore, if a connection enables keep-alives that is also using the Therefore, if a connection that enables keep-alives is also using the
TCP User Timeout Option, then the keep-alive timer MUST be set to a TCP User Timeout Option, then the keep-alive timer MUST be set to a
value larger than that of the adopted USER TIMEOUT. value larger than that of the adopted USER TIMEOUT.
5. Security Considerations 5. Security Considerations
Lengthening user timeouts has obvious security implications. Lengthening user timeouts has obvious security implications.
Flooding attacks cause denial of service by forcing servers to commit Flooding attacks cause denial of service by forcing servers to commit
resources for maintaining the state of throw-away connections. resources for maintaining the state of throw-away connections.
However, TCP implementations do not become more vulnerable to simple However, TCP implementations do not become more vulnerable to simple
SYN flooding by implementing the TCP User Timeout Option, because SYN flooding by implementing the TCP User Timeout Option, because
skipping to change at page 11, line 15 skipping to change at page 11, line 26
However, when an attacker completes the three-way handshakes of its However, when an attacker completes the three-way handshakes of its
throw-away connections it can amplify the effects of resource throw-away connections it can amplify the effects of resource
exhaustion attacks, because the attacked server must maintain the exhaustion attacks, because the attacked server must maintain the
connection state associated with the throw-away connections for connection state associated with the throw-away connections for
longer durations. Because connection state is kept longer, lower- longer durations. Because connection state is kept longer, lower-
frequency attack traffic, which may be more difficult to detect, can frequency attack traffic, which may be more difficult to detect, can
already exacerbate resource exhaustion. already exacerbate resource exhaustion.
Several approaches can help mitigate this issue. First, Several approaches can help mitigate this issue. First,
implementations can require prior peer authentication, e.g., using implementations can require prior peer authentication, e.g., using
IPsec [RFC4301], before accepting long user timeouts for the peer's IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
connections. Similarly, a host can start to accept long user timeouts for the peer's connections. Similarly, a host can start to
timeouts for an established connection only after in-band accept long user timeouts for an established connection only after
authentication has occurred, for example, after a TLS handshake in-band authentication has occurred, for example, after a TLS
across the connection has succeeded [RFC4346]. Although these are handshake across the connection has succeeded [RFC4346]. Although
arguably the most complete solutions, they depend on external these are arguably the most complete solutions, they depend on
mechanisms to establish a trust relationship. external mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
high-UTO connections a server supports in the face of an attack turns 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 that attack into a denial-of-service attack against the service of
skipping to change at page 12, line 9 skipping to change at page 12, line 20
Note that if TCP needs to close or abort connections with a long TCP 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 User Timeout Option to shed load, these connections are still no
worse off than without the option. worse off than without the option.
Finally, upper and lower limits on user timeouts, discussed in Finally, upper and lower limits on user timeouts, discussed in
Section 3.1, can be an effective tool to limit the impact of these Section 3.1, can be an effective tool to limit the impact of these
sorts of attacks. sorts of attacks.
6. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to
[I-D.narten-iana-considerations-rfc2434bis].
This document does not define any new namespaces. It uses an 8-bit This document does not define any new namespaces. It requests that
TCP option number maintained by IANA at IANA allocate a new 8-bit TCP option number for the UTO option from
the registry maintained at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. Acknowledgments 7. Acknowledgments
The following people have improved this document through thoughtful The following people have improved this document through thoughtful
suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden, suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted
Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,
Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid
Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe
skipping to change at page 12, line 34 skipping to change at page 12, line 47
Stiemerling. Stiemerling.
Lars Eggert has been partly funded by Ambient Networks, a research Lars Eggert has been partly funded by Ambient Networks, a research
project supported by the European Commission under its Sixth project supported by the European Commission under its Sixth
Framework Program. Framework Program.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-08 (work in
progress), October 2007.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 8.2. Informative References
[I-D.eddy-tcp-mobility] [I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", Eddy, W., "Mobility Support For TCP",
draft-eddy-tcp-mobility-00 (work in progress), April 2004. draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-syn-flood] [I-D.ietf-tcpm-syn-flood]
Eddy, W., "TCP SYN Flooding Attacks and Common Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", draft-ietf-tcpm-syn-flood-05 (work in Mitigations", draft-ietf-tcpm-syn-flood-05 (work in
progress), May 2007. progress), May 2007.
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
Interactions Between Transport Protocols and Middleboxes", Interactions Between Transport Protocols and Middleboxes",
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
Measurement , October 2004. Measurement , October 2004.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
 End of changes. 42 change blocks. 
103 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/