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