draft-ietf-tcpm-tcp-uto-11.txt   rfc5482.txt 
TCP Maintenance and Minor L. Eggert Network Working Group L. Eggert
Extensions (tcpm) Nokia Request for Comments: 5482 Nokia
Internet-Draft F. Gont Category: Standards Track F. Gont
Intended status: Standards Track UTN/FRH UTN/FRH
Expires: July 26, 2009 January 22, 2009
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-11
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 of the TCP connection to information provides advice to the other end of the TCP connection to
adapt its user timeout accordingly. Increasing the user timeouts on adapt its user timeout accordingly. Increasing the user timeouts on
both ends of a TCP connection allows it to survive extended periods both ends of a TCP connection allows it to survive extended periods
without end-to-end connectivity. Decreasing the user timeouts allows without end-to-end connectivity. Decreasing the user timeouts allows
busy servers to explicitly notify their clients that they will busy servers to explicitly notify their clients that they will
maintain the connection state only for a short time without maintain the connection state only for a short time without
connectivity. connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions .....................................................3
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation .......................................................4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout ............................5
3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability .....................................8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Option Format ..............................................8
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10 3.4. Reserved Option Values .....................................9
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues .........................................9
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes ................................................9
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives ...........................................10
5. Programming and Manageability Considerations . . . . . . . . . 11 5. Programming and Manageability Considerations ...................10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations ........................................10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations ............................................12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments ................................................12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References .....................................................12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References ......................................12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References ....................................13
Appendix A. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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, a sender will receive no longer than the user timeout, a sender will receive no
acknowledgments for any transmission attempt, including keep-alives, acknowledgments for any transmission attempt, including keep-alives,
and it will close the TCP connection when the user timeout occurs. and it will close the TCP connection when the user timeout occurs.
This document specifies a new TCP option - the TCP User Timeout This document specifies a new TCP option -- the TCP User Timeout
Option - that allows one end of a TCP connection to advertise its Option (UTO) -- that allows one end of a TCP connection to advertise
current user timeout value. This information provides advice to the its current user timeout value. This information provides advice to
other end of the connection to adapt its user timeout accordingly. the other end of the connection to adapt its user timeout
That is, TCP remains free to disregard the advice provided by the UTO accordingly. That is, TCP remains free to disregard the advice
option if local policies suggest it to be appropriate. 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 Increasing the user timeouts on both ends of a TCP connection allows
it to survive extended periods without end-to-end connectivity. it to survive extended periods without end-to-end connectivity.
Decreasing the user timeouts allows busy servers to explicitly notify Decreasing the user timeouts allows busy servers to explicitly notify
their clients that they will maintain the connection state only for a their clients that they will maintain the connection state only for a
short time without connectivity. 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 (3 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].
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 of a connection. changes to the local user timeout to the other end of a connection.
This causes local changes to be ineffective in allowing a connection This causes local changes to be ineffective in allowing a connection
to survive extended periods without connectivity, because the other to survive extended periods without connectivity, because the other
end will 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 of a connection about the local The ability to inform the other end of a connection about the local
user timeout 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 a scenario is currently not well supported. One example of such a scenario is
mobile hosts that change network attachment points. Such hosts, mobile hosts that change network attachment points. Such hosts,
maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer maybe using Mobile IP [RFC3344], HIP [RFC4423], or transport-layer
mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently mobility mechanisms [TCP_MOB], are only intermittently connected to
connected to the Internet. In between connected periods, mobile the Internet. In between connected periods, mobile hosts may
hosts may experience periods without end-to-end connectivity. Other experience periods without end-to-end connectivity. Other factors
factors that can cause transient connectivity disruptions are high that can cause transient connectivity disruptions are high levels of
levels of congestion or link or routing failures inside the network. congestion or link or routing failures inside the network. In these
In these scenarios, a host may not know exactly when or for how long scenarios, a host may not know exactly when or for how long
connectivity disruptions will occur, but it might be able to connectivity disruptions will occur, but it might be able to
determine an increased likelihood for such events based on past determine an increased likelihood for such events based on past
mobility patterns and thus benefit from using longer user timeouts. mobility patterns and thus benefit from using longer user timeouts.
In other scenarios, the time and duration of a connectivity In other scenarios, the time and duration of a connectivity
disruption may even be predictable. For example, a node in space disruption may even be predictable. For example, a node in space
might experience connectivity disruptions due to line-of-sight might experience connectivity disruptions due to line-of-sight
blocking by planetary bodies. The timing of these events may be blocking by planetary bodies. The timing of these events may be
computable from orbital mechanics. computable from orbital mechanics.
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 either enabled on a per-
connection basis, e.g., through an API option, or controlled by a connection basis, e.g., through an API 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
(ADV_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].
ADV_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 defaults to the default system-wide basis. If unspecified, it defaults to the default system-wide
USER TIMEOUT. USER TIMEOUT.
skipping to change at page 5, line 26 skipping to change at page 4, line 48
true). 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 enables its use by setting ENABLED to true. It may choose UTO option enables its use by setting ENABLED to true. It may choose
an appropriate local UTO by explicitly setting ADV_UTO; otherwise, an appropriate local UTO by explicitly setting ADV_UTO; otherwise,
UTO is 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 of TIMEOUT to change based on received UTO options from the other end of
a connection. The default is to allow this for connections that do a connection. The default is to allow this for connections that do
not have specific user timeout concerns. If an application not have specific user timeout concerns. If an application
explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false in
prevent UTO options from the other end to override local application order to prevent UTO options (from the other end) from overriding
requests. Alternatively, applications can set or clear CHANGEABLE local application requests. Alternatively, applications can set or
directly through API calls. clear CHANGEABLE directly through 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. TCP implementations MAY provide system-wide default settings values. TCP implementations MAY provide system-wide default settings
for the ENABLED, ADV_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. Also, it is particularly
when mechanisms such as "SYN cookies" [RFC4987] are implemented, useful when mechanisms such as "SYN cookies" [RFC4987] are
allowing a newly-established TCP connection to benefit from the implemented, allowing a newly-established TCP connection to benefit
information advertised by the UTO option, even if the UTO contained from the information advertised by the UTO option, even if the UTO
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 of the connection to for the connection. This allows the other end of the connection to
adapt its local user timeout accordingly. A TCP implementation that adapt its local user timeout accordingly. A TCP implementation that
does not support the UTO option MUST silently ignore it [RFC1122], does not support the UTO option MUST silently ignore it [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
skipping to change at page 8, line 4 skipping to change at page 7, line 32
If the end that announced the lower of the two user timeout values If the end that announced the lower of the two user timeout values
did so in order to reduce the amount of TCP state information that did so in order to reduce the amount of TCP state information that
must be kept on the host, it can close or abort the connection must be kept on the host, it can close or abort the connection
whenever it wants. 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 6 discusses the details of these attacks. attacks. Section 6 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, it recommends a time interval length of the user timeout. However, it recommends a time interval
of at least 100 seconds. 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
skipping to change at page 8, line 35 skipping to change at page 8, line 15
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
The TCP User Timeout Option is an advisory TCP option that does not The TCP User Timeout Option is an advisory TCP option that does not
change processing of subsequent segments. Unlike other TCP options, change processing of subsequent segments. Unlike other TCP options,
it need not be exchanged reliably. Consequently, the specification it need not be exchanged reliably. Consequently, the specification
does not define a reliability handshake for UTO option exchanges. does not define a reliability handshake for UTO option exchanges.
When a segment that carries a UTO option is lost, the other end will When a segment that carries a UTO option is lost, the other end will
simply not have the opportunity to update its local UTO. simply not have the opportunity to update its local USER TIMEOUT.
Implementations MAY implement local mechanisms to improve delivery Implementations MAY implement local mechanisms to improve delivery
reliability, such as retransmitting a UTO option when they retransmit reliability, such as retransmitting a UTO option when they retransmit
a segment that originally carried it, or "attaching" the option to a a segment that originally carried it, or "attaching" the option to a
byte in the stream and retransmitting the option whenever that byte byte in the stream and retransmitting the option whenever that byte
or its ACK are retransmitted. or its ACK are retransmitted.
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
connection of the current local user timeout 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 ADV_UTO value, that is expected included in a UTO option contains the ADV_UTO value that is expected
to be adopted for the TCP's USER TIMEOUT parameter during the to be adopted for the TCP's USER TIMEOUT parameter during the
synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN- synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, 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 = TBD | Length = 4 |G| User Timeout | | Kind = 28 | 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)
This MUST be TBD, i.e., the TCP option number [RFC0793] assigned This MUST be 28, i.e., the TCP option number [RFC0793] that has
by IANA upon publication of this document (see Section 7). [[Note been assigned by IANA (see Section 7).
to the RFC Editor: Throughout this document, replace "TBD" with
the TCP option number that IANA has allocated 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 A 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. Current TCP implementations MUST NOT send it and for future use. Current TCP implementations MUST NOT send it and
MUST ignore 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
skipping to change at page 10, line 32 skipping to change at page 10, line 5
transport protocols, Medina et al. have shown that the vast majority transport protocols, Medina et al. have shown that the vast majority
of modern TCP stacks correctly handle unknown TCP options [MEDINA]. of modern TCP stacks correctly handle unknown TCP options [MEDINA].
In this study, 3% of connections failed when an unknown TCP option In this study, 3% of connections failed when an unknown TCP option
appeared in the middle of a connection. Because the number of appeared in the middle of a connection. Because the number of
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.
Implementations may want to exchange UTO options on the very first
data segments after the three-way handshake to determine if such a
middlebox exists on the path. When segments carrying UTO options are
persistently lost, an implementation should turn off the use of UTO
for the connection. When the connection itself is reset, an
implementation may be able to transparently re-establish another
connection instance that does not use UTO before any application data
has been successfully exchanged.
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 in unencrypted TCP segments and adapt TCP User Timeout Option in unencrypted TCP segments and adapt
connection state management 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 that enables keep-alives 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. Programming and Manageability Considerations 5. Programming and Manageability Considerations
The IETF specification for TCP [RFC0793] includes a simple, abstract The IETF specification for TCP [RFC0793] includes a simple, abstract
application programming interface (API). The API for the UTO application programming interface (API). Similarly, the API for the
extension in Section 3 is kept similarly abstract. TCP UTO extension in Section 3 is kept abstract. TCP implementations,
implementations, however, usually provide more complex and feature- however, usually provide more complex and feature-rich APIs. The
rich APIs. The "socket" API that originated with BSD Unix and is now "socket" API that originated with BSD Unix and is now standardized by
standardized by POSIX is one such example [POSIX]. It is expected POSIX is one such example [POSIX]. It is expected that TCP
that TCP implementations that choose to include the UTO extension implementations that choose to include the UTO extension will extend
will extend their API to allow applications to use and configure its their API to allow applications to use and configure its parameters.
parameters.
The MIB objects defined in [RFC4022] and [RFC4898] allow management The MIB objects defined in [RFC4022] and [RFC4898] allow management
of TCP connections. It is expected that revisions to these documents of TCP connections. It is expected that revisions to these documents
will include definitions of objects for managing the UTO extension will include definitions of objects for managing the UTO extension
defined in this document. defined in this document.
6. Security Considerations 6. 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
user timeouts exchanged during the handshake only affect the user timeouts exchanged during the handshake only affect the
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK), which simple SYN floods never reach. CLOSING, LAST-ACK), which simple SYN floods never reach.
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] or TCP-MD5 [RFC2385], before accepting long user IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
timeouts for the peer's connections. (Implementors that decide to timeouts for the peer's connections. (Implementors that decide to
use TCP-MD5 for this purpose are encouraged to monitor the use TCP-MD5 for this purpose are encouraged to monitor the
development of TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], its designated development of TCP-AO [AUTH_OPT], its designated successor, and
successor, and update their implementation when it is published as an update their implementation when it is published as an RFC.) A
RFC.) A similar approach is for a host to start accepting long user similar approach is for a host to start accepting long user timeouts
timeouts for an established connection only after in-band for an established connection only after in-band authentication has
authentication has occurred, for example, after a TLS handshake occurred, for example, after a TLS handshake across the connection
across the connection has succeeded [RFC5246]. Although these are has succeeded [RFC5246]. Although these are arguably the most
arguably the most complete solutions, they depend on external complete solutions, they depend on external mechanisms to establish a
mechanisms to establish a trust relationship. 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
high-UTO connections. high-UTO connections.
Per-peer limits cannot protect against distributed denial of service Per-peer limits cannot protect against distributed denial-of-service
attacks, where multiple clients coordinate a resource exhaustion attacks, where multiple clients coordinate a resource exhaustion
attack that uses long user timeouts. To protect against such attack that uses long user timeouts. To protect against such
attacks, TCP implementations could reduce the duration of accepted attacks, TCP implementations could reduce the duration of accepted
user timeouts with increasing resource utilization. user timeouts with increasing resource utilization.
TCP implementations under attack may be forced to shed load by TCP implementations under attack may be forced to shed load by
resetting established connections. Some load-shedding heuristics, resetting established connections. Some load-shedding heuristics,
such as resetting connections with long idle times first, can such as resetting connections with long idle times first, can
negatively affect service for intermittently connected, trusted peers negatively affect service for intermittently connected, trusted peers
that have suggested long user timeouts. On the other hand, resetting that have suggested long user timeouts. On the other hand, resetting
skipping to change at page 12, line 44 skipping to change at page 12, line 20
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.
7. IANA Considerations 7. IANA Considerations
This section is to be interpreted according to [RFC5226]. This section is to be interpreted according to [RFC5226].
This document does not define any new namespaces. It requests that This document does not define any new namespaces. IANA has allocated
IANA allocate a new 8-bit TCP option number for the UTO option from a new 8-bit TCP option number (28) for the UTO option from the "TCP
the registry maintained at Option Kind Numbers" registry maintained at http://www.iana.org.
http://www.iana.org/assignments/tcp-parameters.
8. Acknowledgments 8. 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,
Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade
Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,
Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,
Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha
Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, and
Martin Stiemerling. Martin Stiemerling.
Lars Eggert is partly funded by [TRILOGY], a research project Lars Eggert is partly funded by [TRILOGY], a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
Fernando Gont wishes to thank Secretaria de Extension Universitaria
at Universidad Tecnologica Nacional and Universidad Tecnologica
Nacional/Facultad Regional Haedo for supporting him in this work.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative References 9.2. Informative References
[I-D.eddy-tcp-mobility] [AUTH_OPT] Touch, J., Mankin, A., and R. Bonica, "The TCP
Eddy, W., "Mobility Support For TCP", Authentication Option", Work in Progress, November 2008.
draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02
(work in progress), November 2008.
[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
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on
Measurement , October 2004. Internet Measurement, October 2004.
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information [POSIX] IEEE Std. 1003.1-2001, "Standard for Information
Technology - Portable Operating System Interface (POSIX)", Technology - Portable Operating System Interface
Open Group Technical Standard: Base Specifications Issue (POSIX)", Open Group Technical Standard: Base
6, ISO/IEC 9945:2002, December 2001. Specifications Issue 6, ISO/IEC 9945:2002, December 2001.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
Signature Option", RFC 2385, August 1998. 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.
[RFC4022] Raghunarayan, R., "Management Information Base for the [RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022, Transmission Control Protocol (TCP)", RFC 4022,
March 2005. March 2005.
skipping to change at page 14, line 38 skipping to change at page 14, line 8
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP
Extended Statistics MIB", RFC 4898, May 2007. Extended Statistics MIB", RFC 4898, May 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SOLARIS-MANUAL] [SOLARIS] Sun Microsystems, "Solaris Tunable Parameters Reference
Sun Microsystems, "Solaris Tunable Parameters Reference
Manual", Part No. 806-7009-10, 2002. Manual", Part No. 806-7009-10, 2002.
[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. [TCP_MOB] Eddy, W., "Mobility Support For TCP", Work in Progress,
April 2004.
Appendix A. Document Revision History
[[Note to the RFC Editor: Section to be removed upon publication.]] [TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>.
+----------+--------------------------------------------------------+
| Revision | Comments |
+----------+--------------------------------------------------------+
| -11 | Addressing IESG review comments. |
| | |
| -10 | Addressing the gen-art review comments from Scott |
| | Brim. Updated reference to [RFC5246]. Added funding |
| | source acknowledgment. |
| | |
| -09 | Resubmission after expiration. Updated reference to |
| | [RFC5226]. |
| | |
| -08 | Addressed additional, minor working group last call |
| | comments. |
| | |
| -07 | Addressed working group last call comments. |
| | |
| -06 | Includes a note on the limited space for TCP options |
| | and miscellaneous editorial changes (suggested by |
| | Anantha Ramaiah). Includes possible enforcement of |
| | per-outgoing-interface limits for the UTO, and |
| | miscellaneous editorial changes (suggested by Alfred |
| | Hoenes). Includes relevant changes to reflect WG |
| | consensus how the local user timeout should be |
| | selected (i.e., record both the current user timeout, |
| | and the advertised UTO). |
| | |
| -05 | Made behavior on when to change/not change the local |
| | UTO in response to incoming options consistent through |
| | the document. This required some reshuffling of text |
| | and also removed the need for the special "don't care" |
| | option value. |
| | |
| -04 | Clarified the results obtained by Medina et al. Added |
| | text to suggest inclusion of the UTO in the first |
| | non-SYN segment by the TCP that sent a SYN in response |
| | to an active OPEN. |
| | |
| -03 | Corrected use of RFC2119 terminology. Clarified how |
| | use of the TCP UTO is triggered. Clarified reason for |
| | sending a UTO in the SYN and SYN/ACK segments. |
| | Removed discussion of the SO_SNDTIMEO and SO_RCVTIMEO |
| | socket options. Removed text that suggested that a |
| | UTO should be sent upon receipt of an UTO from the |
| | other end. Required minimum value for the lower limit |
| | of the user timeout. Moved alternative solutions to |
| | appendix. Miscellaneous editorial changes. |
| | |
| -02 | Corrected terminology by replacing terms like |
| | "negotiate", "coordinate", etc. that were left from |
| | pre-WG-document times when the UTO was a more |
| | formalized exchange instead of the advisory one it is |
| | now. Application-requested UTOs take precedence over |
| | ones received from the peer (pointed out by Ted |
| | Faber). Added a brief mention of SO_SNDTIMEO and a |
| | slightly longer discussion of SO_RCVTIMEO. |
| | |
| -01 | Clarified and corrected the description of the |
| | existing user timeout in RFC793 and RFC1122. Removed |
| | distinction between operating during the 3WHS and the |
| | established states and introduced zero-second "don't |
| | care" UTOs in response to mailing list feedback. |
| | Updated references and addressed many other comments |
| | from the mailing list. |
| | |
| -00 | Resubmission of |
| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the |
| | secretariat after WG adoption. Thus, permit |
| | derivative works. Updated Lars Eggert's funding |
| | attribution. Updated several references. No |
| | technical changes. |
+----------+--------------------------------------------------------+
Authors' Addresses Authors' Addresses
Lars Eggert Lars Eggert
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
Nokia Group 00045 Nokia Group 00045
Finland Finland
Phone: +358 50 48 24461 Phone: +358 50 48 24461
Email: lars.eggert@nokia.com EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert/ URI: http://research.nokia.com/people/lars_eggert/
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar/ URI: http://www.gont.com.ar/
 End of changes. 41 change blocks. 
211 lines changed or deleted 119 lines changed or added

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