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