draft-ietf-tcpm-tcp-uto-00.txt | draft-ietf-tcpm-tcp-uto-01.txt | |||
---|---|---|---|---|
TCP Maintenance and Minor L. Eggert | TCP Maintenance and Minor L. Eggert | |||
Extensions (tcpm) NEC | Extensions (tcpm) NEC | |||
Internet-Draft F. Gont | Internet-Draft F. Gont | |||
Expires: November 24, 2005 UTN/FRH | Expires: January 16, 2006 UTN/FRH | |||
May 23, 2005 | July 15, 2005 | |||
TCP User Timeout Option | TCP User Timeout Option | |||
draft-ietf-tcpm-tcp-uto-00 | draft-ietf-tcpm-tcp-uto-01 | |||
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 November 24, 2005. | This Internet-Draft will expire on January 16, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
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 aborted. TCP implementations | unacknowledged before a connection is forcefully closed. It is a | |||
typically use a single, system-wide user timeout value. The TCP User | local, per-connection parameter. The advisory TCP User Timeout | |||
Timeout Option allows conforming TCP implementations to exchange | Option allows conforming TCP implementations to exchange their local | |||
requests for individual, per-connection user timeouts. Lengthening | user timeouts. This exchange provides an in-protocol mechanism to | |||
the system-wide default user timeout allows established TCP | coordinate raising or lowering the two user timeouts of a connection. | |||
connections to survive extended periods of disconnection. On the | Increase the user timeouts allows established TCP connections to | |||
other hand, shortening the default user timeout allows busy servers | survive extended periods of disconnection. Decreasing user timeouts | |||
to explicitly notify their clients they will maintain the connection | allows busy servers to explicitly notify their clients that they will | |||
state information only accross short periods of disconnection. | maintain the connection state only across short periods of | |||
disconnection. | ||||
1. Introduction | 1. Introduction | |||
The Transmission Control Protocol (TCP) specification [1] defines a | The Transmission Control Protocol (TCP) specification [RFC0793] | |||
"user timeout" parameter that specifies the maximum amount of time | defines a local, per-connection "user timeout" parameter that | |||
that transmitted data may remain unacknowledged before TCP will abort | specifies the maximum amount of time that transmitted data may remain | |||
the corresponding connection. If a disconnection lasts longer than | unacknowledged before TCP will forcefully close the corresponding | |||
the user timeout, no acknowledgments will be received for any | connection. Applications can set and change this parameter with OPEN | |||
transmission attempt, including keep-alives [5], and the TCP | and SEND calls. If a network disconnection lasts longer than the | |||
connection will be aborted when the user timeout occurs. | user timeout, no acknowledgments will be received for any | |||
transmission attempt, including keep-alives [TCP-ILLU], and the TCP | ||||
connection will close when the user timeout occurs. In the absence | ||||
of an application-specified user timeout, the TCP specification | ||||
[RFC0793] defines a default user timeout of 5 minutes. | ||||
The TCP specification [1] does not constrain the permitted values for | The Host Requirements RFC [RFC1122] refines this definition by | |||
user timeouts. However, the Host Requirements RFC [2] mandates a | introducing two thresholds, R1 and R2 (R2 > R1), on the number of | |||
timeout of at least three minutes for the SYN-SENT case. Many TCP | retransmissions of a single segment. It suggests that TCP notify | |||
implementations default to user timeout values of a few minutes [5]. | applications when R1 is reached for a segment, and close the | |||
Instead of a single user timeout, some TCP implementations offer | connection once R2 is reached. [RFC1122] also refines the | |||
finer-grained policies. For example, Solaris supports different | recommended values for R1 (three retransmissions) and R2 (100 | |||
timeouts depending on whether a TCP connection is in the SYN-SENT, | seconds), noting that R2 for SYN segments should be at least 3 | |||
SYN-RECEIVED, or ESTABLISHED state [6]. | minutes. Instead of a single user timeout, some TCP implementations | |||
offer finer-grained policies. For example, Solaris supports | ||||
different timeouts depending on whether a TCP connection is in the | ||||
SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL]. | ||||
System-wide user timeouts are a useful basic policy. However, the | Although applications may set their local user timeout, there is no | |||
ability to selectively choose individual user timeout values for | in-protocol mechanism to signal changes in the local user timeout to | |||
different connections can improve TCP operation in scenarios that are | remote peers. This causes local changes to be ineffective, because, | |||
currently not well supported. One example of such scenarios are | for example, the peer will still close the connection after its user | |||
mobile hosts that change network attachment points based on current | timeout expires, even when a host has raised its local user timeout. | |||
location. Such hosts, maybe using MobileIP [7], HIP [8] or | The ability to modify the two user timeouts associated with a | |||
transport-layer mobility mechanisms [9], are only intermittently | connection in a coordinated manner can improve TCP operation in | |||
connected to the Internet. In between connected periods, mobile | scenarios that are currently not well supported. One example of such | |||
hosts may experience periods of disconnection during which no network | scenarios are mobile hosts that change network attachment points | |||
service is available [10][11][12]. Other factors that can cause | based on current location. Such hosts, maybe using MobileIP | |||
transient periods of disconnection are high levels of congestion as | [RFC3344], HIP [I-D.ietf-hip-arch] or transport-layer mobility | |||
well as link or routing failures inside the network. | mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected | |||
to the Internet. In between connected periods, mobile hosts may | ||||
experience periods of disconnection during which no network service | ||||
is available [SCHUETZ-THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other | ||||
factors that can cause transient periods of disconnection are high | ||||
levels of congestion as well as link or routing failures inside the | ||||
network. | ||||
In scenarios similar to the ones described above, a host may not know | In scenarios similar to the ones described above, a host may not know | |||
exactly when or for how long it will be disconnected from the | exactly when or for how long it will be disconnected from the | |||
network, but it might expect such events due to past mobility | network, but it might expect such events due to past mobility | |||
patterns and thus benefit from using longer user timeouts. In other | patterns and thus benefit from using longer user timeouts. In other | |||
scenarios, the length and time of a network disconnection may even be | scenarios, the length and time of a network disconnection may even be | |||
predictable. For example, an orbiting node on a satellite might | predictable. For example, an orbiting node on a satellite might | |||
experience disconnections due to line-of-sight blocking by other | experience disconnections due to line-of-sight blocking by other | |||
planetary bodies. The disconnection periods of such a node may be | planetary bodies. The disconnection periods of such a node may be | |||
easily computable from orbital mechanics. | easily computable from orbital mechanics. | |||
In the examples above, as well as in other cases, established TCP | This document specifies a new TCP option - the User Timeout Option | |||
connections between two peers may be aborted if a disconnection | (UTO) - that allows conforming hosts to exchange their local, per- | |||
exceeds the system-wide default user timeout. This document | connection user timeout information. This allows, for example, | |||
specifies a new TCP option - the User Timeout Option - that allows | mobile hosts to maintain TCP connections across disconnected periods | |||
conforming hosts to exchange per-connection user timeout requests. | that are longer than their peer's default user timeout. A second use | |||
This allows, for example, mobile hosts to maintain TCP connections | of the TCP User Timeout Option is advertisement of shorter-than- | |||
across disconnected periods that are longer than their system's | default user timeouts. This can allow busy servers to explicitly | |||
default user timeout. A second use of the TCP User Timeout Option is | notify their clients that they will maintain the state associated | |||
advertisement of shorter-than-default user timeouts. This can allow | with established connections only across short periods of | |||
busy servers to explicitly notify their clients that they will | disconnection. | |||
maintain the state associated with established connections only | ||||
across short periods of disconnection. | The same benefits can be obtained through an application-layer | |||
mechanism, i.e., coordinating changes to the user timeout values of a | ||||
connection through application messages. This approach does not | ||||
require a new TCP option, but requires application changes. | ||||
A different approach to tolerate longer periods of disconnection is | A different approach to tolerate longer periods of disconnection is | |||
simply increasing the system-wide user timeout on both peers. This | simply increasing the system-wide user timeout on both peers. This | |||
approach has the benefit of not requiring a new TCP option. However, | approach has the benefit of not requiring a new TCP option. However, | |||
it can also significantly increase the amount of connection state | it can also significantly increase the amount of connection state | |||
information a host must maintain, because a longer global timeout | information a busy server must maintain, because a longer global | |||
value will apply to all its connections. The proposed User Timeout | timeout value will apply to all its connections. The proposed TCP | |||
Option, on the other hand, allows hosts to selectively manage the | User Timeout Option, on the other hand, allows hosts to selectively | |||
user timeouts of individual connections. They must then only | manage the user timeouts of individual connections, reducing the | |||
maintain the state associated with selected connections across | amount of state they must maintain across disconnected periods. | |||
disconnected periods. | ||||
A second benefit of the TCP User Timeout Option is that it allows | ||||
hosts to both request specific user timeouts for new connections and | ||||
to request changes to the effective user timeouts of established | ||||
connections. The latter allows connections to start with short | ||||
timeouts and only request longer timeouts when disconnection is | ||||
imminent, and only for connections considered important. The ability | ||||
to request changes to user timeouts of established connections is | ||||
also useful to raise the user timeout after in-band authentication | ||||
has occurred. For example, peers could request longer user timeouts | ||||
for the TCP connections underlying two-way authenticated TLS | ||||
connections [13] after their authentication handshakes have | ||||
succeeded. | ||||
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 RFC 2119 [3]. | document are to be interpreted as described in [RFC2119]. | |||
3. Operation | 3. Operation | |||
Sending a TCP User Timeout Option suggests to the remote peer to use | Sending a TCP User Timeout Option suggests that the remote peer | |||
the indicated user timeout value for the corresponding connection. | SHOULD start using the indicated user timeout value for the | |||
Section 3.4 discusses the effects of different timeout values. | corresponding connection. The user timeout value included in a TCP | |||
User Timeout Option specifies the requested user timeout during the | ||||
synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN- | ||||
WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other | ||||
states MUST use standard timeout values [RFC0793][RFC1122]. [anchor4] | ||||
The user timeout value included in a TCP User Timeout Option | Note that an exchange of TCP User Timeout Options between peers is | |||
specifies the requested user timeout during a connection's | not a binding negotiation. Transmission of a TCP User Timeout Option | |||
synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, | is an advisory suggestion that the peer consider adapting its local | |||
CLOSING, or LAST-ACK.) Connections in other states MUST use standard | user timeout. Hosts remain free to forcefully close or abort | |||
timeout values [1][2]. [Comment.1] | connections at any time for any reason, whether or not they use | |||
custom user timeouts or have suggested to the peer to use them. | ||||
A host that supports the TCP User Timeout Option SHOULD include it in | ||||
the next possible segment to its peer whenever it starts using a new | ||||
user timeout for the connection. This allows the peer to adapt its | ||||
local user timeout for the connection accordingly. | ||||
When a host that supports the TCP User Timeout Option receives one, | When a host that supports the TCP User Timeout Option receives one, | |||
it decides whether to change the connection's local user timeout | it decides whether to change its local user timeout of the connection | |||
based on the received value. Generally, hosts SHOULD honor requests | based on the received value. Generally, hosts should honor requests | |||
for changes to the user timeout, unless security concerns or external | for changes to the user timeout (see Section 3.3), unless security | |||
policies indicate otherwise (see Section 5.) If so, hosts MAY ignore | concerns, resource constraints or external policies indicate | |||
incoming TCP User Timeout Options and MAY use a different user | otherwise (see Section 5). If so, hosts may ignore incoming TCP User | |||
timeout for the connection. | Timeout Options and use a different user timeout for the connection. | |||
It is important to note that the TCP User Timeout Option does not | When a host receives a TCP User Timeout Option, it first decides | |||
change the semantics of the TCP protocol. Hosts remain free to abort | whether to change its local user timeout for the connection (see | |||
connections at any time for any reason, whether or not they use | Section 3.3) and then decides whether to send a TCP User Timeout | |||
custom user timeouts or have suggested the peer to use them. | Option to its peer in response. If it has never sent a TCP User | |||
Timeout Option to its peer during the lifetime of the connection or | ||||
if it has changed its local user timeout, it SHOULD send TCP User | ||||
Timeout Option with its current local user timeout to its peer. | ||||
[anchor5] | ||||
A host that supports the TCP User Timeout Option SHOULD include one | ||||
in each packet that carries a SYN flag, but need not. [MEDINA] has | ||||
shown that unknown options are correctly handled by the vast majority | ||||
of modern TCP stacks. It is thus not necessary to require | ||||
negotiation use of the TCP User Timeout Option for a connection. | ||||
A TCP implementation that does not support the TCP User Timeout | ||||
Option MUST silently ignore it [RFC1122], thus ensuring | ||||
interoperability. | ||||
Hosts SHOULD impose upper and lower limits on the user timeouts they | Hosts SHOULD impose upper and lower limits on the user timeouts they | |||
use. Section 3.4 discusses user timeout limits. A TCP User Timeout | use. Section 3.3 discusses user timeout limits. A TCP User Timeout | |||
Option with a value of zero (i.e., "now") is nonsensical and MUST NOT | Option with a value of zero (i.e., "now") is nonsensical and is used | |||
be sent. If received, it MUST be ignored. Section 3.4 discusses | for a special purpose, see Section 3.4. Section 3.3 discusses | |||
potentially problematic effects of other user timeout durations. | potentially problematic effects of other user timeout durations. | |||
A TCP implementation that does not support the TCP User Timeout | 3.1 Reliability Considerations | |||
Option SHOULD silently ignore it [2], thus ensuring interoperability. | ||||
3.1 Option Format | The TCP User Timeout Option is an advisory TCP option that does not | |||
change processing for subsequent segments. Unlike other TCP options, | ||||
it need not be exchanged reliably. Consequently, the specification | ||||
in this section does not define a reliability handshake for TCP User | ||||
Timeout Option exchanges. When a segment that carries a TCP User | ||||
Timeout Option is lost, the option may never reach the intended peer. | ||||
Implementations MAY implement local mechanisms to improve delivery | ||||
reliability, such as retransmitting the TCP User Timeout Option when | ||||
they retransmit the segment that originally carried it or "attaching" | ||||
the option to a byte in the stream and retransmitting the option | ||||
whenever that byte or its ACK are retransmitted. | ||||
It is important to note that although these mechanisms can improve | ||||
transmission reliability for the TCP User Timeout Option, they do not | ||||
guarantee delivery (a three-way handshake would be required for | ||||
this). Consequently, implementations MUST NOT assume that a TCP User | ||||
Timeout Option is reliably transmitted. | ||||
3.2 Option Format | ||||
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 = X | 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 [1] to be assigned by IANA upon publication of | A TCP option number [RFC0793] to be assigned by IANA upon | |||
this document (see Section 6.) | publication of this document (see Section 6). | |||
Length (8 bits) | Length (8 bits) | |||
Length of the TCP option in octets [1]; 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.2 Operation During the SYN Handshake | 3.3 Duration of the User Timeout | |||
A host that supports the TCP User Timeout Option MUST include an | ||||
appropriate TCP User Timeout Option in its initial SYN segment to | ||||
indicate that it supports the option and to suggest an initial user | ||||
timeout for the connection. [Comment.2] | ||||
A host that supports the TCP User Timeout Option and receives a SYN | ||||
segment that includes one MUST respond with an appropriate TCP User | ||||
Timeout Option in its SYN-ACK segment. If an incoming SYN segment | ||||
does not include a TCP User Timeout Option, a host MUST NOT include | ||||
one in the SYN-ACK segment nor in any other segment, and it MUST | ||||
ignore the contents of any other received TCP User Timeout Option. | ||||
3.3 Operation During the Synchronized States | ||||
Unless both the SYN and SYN-ACK of a connection contained TCP User | ||||
Timeout Options, both hosts participating in the connection MUST NOT | ||||
send TCP User Timeout Options in any other segment. Additionally, | ||||
they both MUST ignore the contents of any received TCP User Timeout | ||||
Option. | ||||
If, however, both the SYN and SYN-ACK contained TCP User Timeout | ||||
Options, hosts MAY choose to include additional TCP User Timeout | ||||
Options in segments sent during the synchronized states (ESTABLISHED, | ||||
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). | ||||
Dynamically adapting the user timeout of a connection during its | ||||
lifetime could be useful in a number of scenarios, for example: | ||||
o TCP may adapt the user timeout based on observed network | ||||
characteristics. [Comment.3] | ||||
o TCP may use short timeouts when connections start and only suggest | ||||
longer timeouts when disconnection was imminent. | ||||
o TCP may use short user timeouts when connections start and only | ||||
raise them once in-band authentication has occurred, for example, | ||||
once a TLS handshake across the connection has succeeded [13]. | ||||
Generally, whenever a host decides to change the local user timeout | ||||
of a connection, it SHOULD include a TCP User Timeout Option | ||||
indicating the new user timeout in its next segment to the peer. | ||||
This allows the peer to adapt its local user timeout for the | ||||
connection accordingly. | ||||
TCP's SYN handshake has specific retransmission rules to guarantee | ||||
reliability. These mechanisms also guarantee that the exchange of | ||||
TCP User Timeout Options during the SYN handshake is reliable. This | ||||
is not the case for TCP User Timeout Option exchanges during the | ||||
synchronized states. When a segment carrying a TCP User Timeout | ||||
Option is lost, the peer will not update its local user timeout | ||||
accordingly. This draft does not currently describe mechanisms to | ||||
ensure the reliability of the option exchange in the synchronized | ||||
states, other than noting that periodic inclusion of the option may | ||||
be an appropriate interim mechanism for implementations concerned | ||||
with reliability. | ||||
3.4 Duration of the User Timeout | ||||
The TCP User Timeout Option allows hosts to exchange user timeout | The TCP User Timeout Option allows hosts to exchange user timeout | |||
values from zero seconds to over 9 hours at a granularity of seconds | values from 1 second to over 9 hours at a granularity of seconds and | |||
and from zero minutes to over 22 days at a granularity of minutes. | from 1 minute to over 22 days at a granularity of minutes. (An | |||
option value of zero is reserved for a special purpose, see | ||||
Section 3.4.) | ||||
Very short user timeout values can affect TCP transmissions over | Very short user timeout values can affect TCP transmissions over | |||
high-delay paths. If the user timeout occurs before an | high-delay paths. If the user timeout occurs before an | |||
acknowledgment for an outstanding segment arrives, possibly due to | acknowledgment for an outstanding segment arrives, possibly due to | |||
packet loss, the connection aborts. Many TCP implementations default | packet loss, the connection closes. Many TCP implementations default | |||
to user timeout values of a few minutes [5]. Although the TCP User | to user timeout values of a few minutes [TCP-ILLU]. Although the TCP | |||
Timeout Option allows suggestion of short timeouts, applications | User Timeout Option allows suggestion of short timeouts, applications | |||
advertising them should consider these effects. | advertising them SHOULD consider these effects. | |||
Long user timeout values allow hosts to tolerate extended periods of | Long user timeout values allow hosts to tolerate extended periods of | |||
disconnection. However, they also require hosts to maintain the TCP | disconnection. However, they also require hosts to maintain the TCP | |||
state information associated with connections for long periods of | state information associated with connections for long periods of | |||
time. Section 5 discusses the security implications of long timeout | time. Section 5 discusses the security implications of long timeout | |||
values. | values. | |||
To protect against these effects, implementations SHOULD impose | To protect against these effects, implementations SHOULD impose | |||
limits on the user timeout values they accept and use. The remainder | limits on the user timeout values they accept and use. The remainder | |||
of this section describes a RECOMMENDED scheme to limit user timeouts | of this section describes a RECOMMENDED scheme to limit user timeouts | |||
based on upper and lower limits. Under the RECOMMENDED scheme, each | based on upper and lower limits. Under the RECOMMENDED scheme, each | |||
TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection | TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection | |||
according to this formula: | according to this formula: | |||
USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) | USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT)) | |||
[Comment.4] | ||||
Each field is to be interpreted as follows: | Each field is to be interpreted as follows: | |||
USER_TIMEOUT | USER_TIMEOUT | |||
Resulting user timeout value to be adopted by the local TCP for a | Resulting user timeout value to be adopted by the local TCP for a | |||
connection. | connection. | |||
U_LIMIT | U_LIMIT | |||
Current upper limit imposed on the connection's user timeout by | Current upper limit imposed on the user timeout of a connection by | |||
the local host. | the local host. | |||
L_LIMIT | L_LIMIT | |||
Current lower limit imposed on the connection's user timeout by | Current lower limit imposed on the user timeout of a connection by | |||
the local host. | the local host. | |||
LOCAL_UTO | LOCAL_UTO | |||
Current local user timeout of the specific connection. | Current local user timeout of the specific connection. | |||
REMOTE_UTO | REMOTE_UTO | |||
Last "user timeout" value suggested by the remote peer by means of | Last "user timeout" value suggested by the remote peer by means of | |||
the TCP User Timeout Option. | the TCP User Timeout Option. | |||
This means that the maximum of the two announced values will be | This means that the maximum of the two announced values will be | |||
adopted for the user timeout of the connection. The rationale is | adopted for the user timeout of the connection. The rationale is | |||
that choosing the maximum of the two values will let the connection | that choosing the maximum of the two values will let the connection | |||
survive transient periods of disconnection. If the TCP that | survive longer periods of disconnection. If the TCP that announced | |||
announced the lower of the two user timeout values did so in order to | the lower of the two user timeout values did so in order to reduce | |||
reduce the amount of TCP state information that must be kept on the | the amount of TCP state information that must be kept on the host, it | |||
host, it can, nevertheless, abort the connection whenever it wants. | can, nevertheless, close or abort the connection whenever it wants. | |||
Enforcing a lower limit (L_LIMIT) protects against connection aborts | 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 or even per- | at other granularities, such as on per-host, per-user or even per- | |||
connection basis. Furthermore, these limits need not be static. For | connection basis. Furthermore, these limits need not be static. For | |||
example, they MAY be a function of system resource utilization or | example, they MAY be a function of system resource utilization or | |||
attack status and could be dynamically adapted. | attack status and could be dynamically adapted. | |||
The Host Requirements RFC [2] 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, a time interval of at least 100 | |||
seconds is RECOMMENDED. Consequently, the lower limit (LLIMIT) | seconds is RECOMMENDED. 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. | scheme described in this section. | |||
3.4 Special Option Values | ||||
Whenever it is legal to do so according to the specification in the | ||||
previous sections, TCP implementations MAY send a zero-second TCP | ||||
User Timeout Option, i.e, with a "User Timeout" field of zero and a | ||||
"Granularity" of zero. This signals their peers that they support | ||||
the option, but do not suggest a specific user timeout value at that | ||||
time. Essentially, a zero-second TCP User Timeout Option acts as a | ||||
"don't care" value. | ||||
The receiver of a zero-second TCP User Timeout Option SHOULD perform | ||||
the RECOMMENDED strategy for calculating a new local USER_TIMEOUT | ||||
described in Section 3.3 with a numeric value of zero seconds for | ||||
REMOTE_UTO. The sender SHOULD perform the calculation as described | ||||
in Section 3.3. Essentially, the sender SHOULD adapt the peer's UTO | ||||
and the receiver SHOULD continue using its local UTO. | ||||
A zero-minute TCP User Timeout Option, i.e., with a "User Timeout" | ||||
field of zero and a "Granularity" bit of one, is reserved for future | ||||
use. TCP implementations MUST NOT sent it and 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 UTO option. | the TCP User Timeout Option. | |||
One meta-issue of introducing new TCP options is that header space | ||||
available for TCP options is currently limited to 40 bytes. All | ||||
negotiable options are exchanged during the SYN/SYN-ACK handshake, | ||||
where option space is becoming limited. Current proposals to extend | ||||
the available option space may mitigate this issue [14]. | ||||
4.1 Middleboxes | 4.1 Middleboxes | |||
The large number of middleboxes (firewalls, proxies, protocol | The large number of middleboxes (firewalls, proxies, protocol | |||
scrubbers, etc.) currently present in the Internet pose some | scrubbers, etc.) currently present in the Internet pose some | |||
difficulty for deploying new TCP options. Some firewalls may block | difficulty for deploying new TCP options. Some firewalls may block | |||
segments that carry unknown options, preventing connection | segments that carry unknown options, preventing connection | |||
establishment when the SYN or SYN-ACK contains the UTO option. Some | establishment when the SYN or SYN-ACK contains a TCP User Timeout | |||
recent results, however, indicate that for new TCP options, this may | Option. Some recent results, however, indicate that for new TCP | |||
not be a significant threat, with only 0.2% of web requests failing | options, this may not be a significant threat, with only 0.2% of web | |||
when carrying an unknown option [15]. | requests failing when carrying an unknown option [MEDINA]. | |||
Stateful firewalls usually reset connections after a period of | Stateful firewalls usually reset connections after a period of | |||
inactivity. If such a firewall exists along the path between two | inactivity. If such a firewall exists along the path between two | |||
peers, it may abort connections regardless of the use of the UTO | peers, it may close or abort connections regardless of the use of the | |||
Option. In the future, such firewalls may learn to parse the UTO | TCP User Timeout Option. In the future, such firewalls may learn to | |||
option and modify their behavior accordingly. | parse the TCP User Timeout Option and modify their behavior or the | |||
option accordingly. | ||||
4.2 TCP Keep-Alives | 4.2 TCP Keep-Alives | |||
Some TCP implementations, such as the one in BSD systems, use a | Some TCP implementations, such as the one in BSD systems, use a | |||
different abort policy for TCP keepalives 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 of disconnection. | otherwise have survived the transient period of disconnection. | |||
Therefore, if a TCP peer enables TCP keep-alives for a connection | Therefore, if a TCP peer enables TCP keep-alives for a connection | |||
that is using the UTO Option, then the keep-alive timer MUST be set | that is using the TCP User Timeout Option, then the keep-alive timer | |||
to a value larger than that of the adopted USER TIMEOUT (specified by | MUST be set to a value larger than that of the adopted USER TIMEOUT. | |||
Equation 1). | ||||
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. TCP | resources for maintaining the state of throw-away connections. TCP | |||
implementations do not become more vulnerable to simple SYN flooding | implementations do not become more vulnerable to simple SYN flooding | |||
by implementing the TCP User Timeout Option, because user timeouts | by implementing the TCP User Timeout Option, because user timeouts | |||
negotiated during the handshake only affect the synchronized states | negotiated during the handshake only affect the synchronized states | |||
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), | (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), | |||
which simple SYN floods never reach. | 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 | |||
skipping to change at page 9, line 19 | skipping to change at page 9, line 28 | |||
negotiated during the handshake only affect the synchronized states | negotiated during the handshake only affect the synchronized states | |||
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), | (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK), | |||
which simple SYN floods never reach. | 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 cause resource exhaustion. [Comment.5] | already cause 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 [16], before accepting long user timeouts for the peer's | IPsec [I-D.ietf-ipsec-rfc2401bis], before accepting long user | |||
connections. Similarly, a host can only start to accept long user | timeouts for the peer's connections. Similarly, a host can only | |||
timeouts for an established connection after in-band authentication | start to accept long user timeouts for an established connection | |||
has occurred, for example, after a TLS handshake across the | after in-band authentication has occurred, for example, after a TLS | |||
connection has succeeded [13]. Although these are arguably the most | handshake across the connection has succeeded [RFC2246]. Although | |||
complete solutions, they depend on external mechanisms to establish a | these are arguably the most complete solutions, they depend on | |||
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. | single peer, it can limit their effects. Reducing the number of | |||
high-UTO connections a server supports in the face of an attack turns | ||||
that attack into a denial-of-service attack against the service of | ||||
high-UTO connections. | ||||
Per-peer limits cannot protect against distributed denial of service | 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 | |||
connections to untrusted peers that use long user timeouts may be | connections to untrusted peers that use long user timeouts may be | |||
effective. In general, using the peers' level of trust as a | effective. In general, using the peers' level of trust as a | |||
parameter during the load-shedding decision process may be useful. | parameter during the load-shedding decision process may be useful. | |||
Note that if TCP needs to close or abort connections with a long TCP | ||||
User Timeout Option to shed load, these connections are still no | ||||
worse off than without the option. | ||||
Finally, upper and lower limits on user timeouts, discussed in | Finally, upper and lower limits on user timeouts, discussed in | |||
Section 3.4, can be an effective tool to limit the impact of these | Section 3.3, 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 [4]. | This section is to be interpreted according to [RFC2434]. | |||
This document does not define any new namespaces. It uses an 8-bit | This document does not define any new namespaces. It uses an 8-bit | |||
TCP option number maintained by IANA at | TCP option number maintained by IANA 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 Allmann, David Borman, Marcus Brunner, Wesley Eddy, | suggestions: Mark Allmann, David Borman, Marcus Brunner, Wesley Eddy, | |||
Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Phil Karn, | Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy | |||
Michael Kerrisk, Kostas Pentikousis, Juergen Quittek, Joe Touch, | Harris, Phil Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis, | |||
Stefan Schmid, Simon Schuetz and Martin Stiemerling. | Juergen Quittek, Joe Touch, Stefan Schmid, Simon Schuetz and Martin | |||
Stiemerling. | ||||
Lars Eggert is partly funded by Ambient Networks, a research project | Lars Eggert is partly funded by Ambient Networks, a research project | |||
supported by the European Commission under its Sixth Framework | supported by the European Commission under its Sixth Framework | |||
Program. The views and conclusions contained herein are those of the | Program. The views and conclusions contained herein are those of the | |||
authors and should not be interpreted as necessarily representing the | authors and should not be interpreted as necessarily representing the | |||
official policies or endorsements, either expressed or implied, of | official policies or endorsements, either expressed or implied, of | |||
the Ambient Networks project or the European Commission. | the Ambient Networks project or the European Commission. | |||
8. References | 8. References | |||
8.1 Normative References | 8.1 Normative References | |||
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
September 1981. | RFC 793, September 1981. | |||
[2] Braden, R., "Requirements for Internet Hosts - Communication | [RFC1122] Braden, R., "Requirements for Internet Hosts - | |||
Layers", STD 3, RFC 1122, October 1989. | Communication Layers", STD 3, RFC 1122, October 1989. | |||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |||
October 1998. | ||||
8.2 Informative References | 8.2 Informative References | |||
[5] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley , | [DRIVE-THRU] | |||
1994. | Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE | |||
802.11b for Automobile Users", Proc. Infocom , March 2004. | ||||
[6] Sun Microsystems, "Solaris Tunable Parameters Reference | ||||
Manual", Part No. 806-7009-10, 2002. | ||||
[7] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, | ||||
August 2002. | ||||
[8] Moskowitz, R., "Host Identity Protocol Architecture", | ||||
draft-ietf-hip-arch-02 (work in progress), January 2005. | ||||
[9] Eddy, W., "Mobility Support For TCP", | [I-D.eddy-tcp-mobility] | |||
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. | |||
[10] Schuetz, S., "Network Support for Intermittently Connected | [I-D.ietf-hip-arch] | |||
Mobile Nodes", M.S. Thesis, University of Mannheim, Germany, | Moskowitz, R., "Host Identity Protocol Architecture", | |||
June 2004. | draft-ietf-hip-arch-02 (work in progress), January 2005. | |||
[11] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol | [I-D.ietf-ipsec-rfc2401bis] | |||
Enhancements for Intermittently Connected Hosts", under | Kent, S. and K. Seo, "Security Architecture for the | |||
submission (work in progress), November 2004. | Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work | |||
in progress), April 2005. | ||||
[12] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for | [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring | |||
Automobile Users", Proc. INFOCOM , March 2004. | Interactions Between Transport Protocols and Middleboxes", | |||
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet | ||||
Measurement , October 2004. | ||||
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", | |||
RFC 2246, January 1999. | RFC 2246, January 1999. | |||
[14] Eddy, W., "Extending the Space Available for TCP Options", | [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, | |||
draft-eddy-tcp-loo-03 (work in progress), May 2005. | August 2002. | |||
[15] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions | ||||
Between Transport Protocols and Middleboxes", To appear: Proc. | ||||
ACM SIGCOMM/USENIX Internet Measurement Conference , | ||||
October 2004. | ||||
[16] Kent, S. and K. Seo, "Security Architecture for the Internet | [SCHUETZ-CCR] | |||
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress), | Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, | |||
April 2005. | "Protocol Enhancements for Intermittently Connected | |||
Hosts", To appear: ACM Computer Communication Review, Vol. | ||||
35, No. 3, July 2005. | ||||
Editorial Comments | [SCHUETZ-THESIS] | |||
Schuetz, S., "Network Support for Intermittently Connected | ||||
Mobile Nodes", Diploma Thesis, University of Mannheim, | ||||
Germany, June 2004. | ||||
[Comment.1] LE: A future version of this document may extend per- | [SOLARIS-MANUAL] | |||
connection user timeouts to the SYN-SENT and SYN- | Sun Microsystems, "Solaris Tunable Parameters Reference | |||
RECEIVED states in a way that conforms to the required | Manual", Part No. 806-7009-10, 2002. | |||
minimum timeouts. | ||||
[Comment.2] LE: My original proposal was to allow hosts to choose | [TCP-ILLU] | |||
whether or not to include the option. It's open for | Stevens, W., "TCP/IP Illustrated, Volume 1: The | |||
discussion whether this flexibility is worth the | Protocols", Addison-Wesley , 1994. | |||
additional complexity. This is the corresponding text: | ||||
"A host that supports the TCP User Timeout Option MAY | ||||
omit the TCP User Timeout Option from the initial SYN if | ||||
it will not permit custom user timeouts for the specific | ||||
connection. It SHOULD omit the TCP User Timeout Option | ||||
from the initial SYN if there is evidence that the peer | ||||
does not support the TCP User Timeout Option, for | ||||
example, if a prior connection attempt including a TCP | ||||
User Timeout Option has failed. If a host does not | ||||
include a TCP User Timeout Option in its initial SYN, it | ||||
MUST NOT include it in any other segment either and MUST | ||||
ignore the contents of any received TCP User Timeout | ||||
Option." | ||||
[Comment.3] FG: My original proposal suggested that TCP might adapt | Editorial Comments | |||
the user timeout when signalled of congestion by means | ||||
of ECN. | ||||
[Comment.4] LE: This formula takes the maximum of the two announced | [anchor4] LE: A future version of this document may extend per- | |||
values. I'd use USER_TIMEOUT = max(L_LIMIT, | connection user timeouts to the SYN-SENT and SYN-RECEIVED | |||
min(LOCAL_UTO, REMOTE_UTO, U_LIMIT)), instead. This | states in a way that conforms to the required minimum | |||
version takes the minimum. My rationale is that the | timeouts. | |||
party announcing the lower value probably had a reason | ||||
for it and may hence not be prepared to handle a longer | ||||
value that it originally indicated. | ||||
[Comment.5] FG: IMO, in practice the TCP User Timeout option does | [anchor5] LE: Should it really always send UTO when it changes the | |||
not make the situation worse: the same type of attack | local timeout? I can imagine some ping-pong effect when | |||
can be performed even if the default "USER TIMEOUT" is | two hosts user different UTO adoption strategies. But | |||
used, since TCP requires no message exchange in order to | maybe that's OK? | |||
keep a connection open. | ||||
Authors' Addresses | Authors' Addresses | |||
Lars Eggert | Lars Eggert | |||
NEC Network Laboratories | NEC Network Laboratories | |||
Kurfuerstenanlage 36 | Kurfuerstenanlage 36 | |||
Heidelberg 69115 | Heidelberg 69115 | |||
Germany | Germany | |||
Phone: +49 6221 90511 43 | Phone: +49 6221 90511 43 | |||
skipping to change at page 13, line 16 | skipping to change at page 13, line 16 | |||
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/ | |||
Appendix A. Document Revision History | Appendix A. Document Revision History | |||
To be removed upon publication | ||||
+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||
| Revision | Comments | | | Revision | Comments | | |||
+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||
| 00 | Resubmission of | | | 00 | Resubmission of | | |||
| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | | | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the | | |||
| | secretariat after WG adoption. Thus, permit | | | | secretariat after WG adoption. Thus, permit | | |||
| | derivative works. Updated Lars Eggert's funding | | | | derivative works. Updated Lars Eggert's funding | | |||
| | attribution. Updated several references. No technical | | | | attribution. Updated several references. No technical | | |||
| | changes. | | | | changes. | | |||
| 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. | | ||||
+-----------+-------------------------------------------------------+ | +-----------+-------------------------------------------------------+ | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |