draft-ietf-tcpm-tcp-uto-10.txt   draft-ietf-tcpm-tcp-uto-11.txt 
TCP Maintenance and Minor L. Eggert TCP Maintenance and Minor L. Eggert
Extensions (tcpm) Nokia Extensions (tcpm) Nokia
Internet-Draft F. Gont Internet-Draft F. Gont
Intended status: Standards Track UTN/FRH Intended status: Standards Track UTN/FRH
Expires: June 4, 2009 December 1, 2008 Expires: July 26, 2009 January 22, 2009
TCP User Timeout Option TCP User Timeout Option
draft-ietf-tcpm-tcp-uto-10 draft-ietf-tcpm-tcp-uto-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 4, 2009. This Internet-Draft will expire on July 26, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 18 skipping to change at page 2, line 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6 3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8 3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10 3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10
4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10 4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10 4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Programming and Manageability Considerations . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Document Revision History . . . . . . . . . . . . . . 14 Appendix A. Document Revision History . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Operation 3. Operation
Use of the TCP User Timeout Option can be enabled either on a per- Use of the TCP User Timeout Option can be enabled either on a per-
connection basis, e.g., through a socket 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
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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, to
prevent UTO options from the other end to override local application prevent UTO options from the other end to override local application
requests. Alternatively, applications can set or clear CHANGEABLE requests. Alternatively, applications can set or clear CHANGEABLE
directly through socket API calls. 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
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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 closes. Many TCP implementations default packet loss, the connection closes. Many TCP implementations default
to USER TIMEOUT values of a few minutes. Although the UTO option to USER TIMEOUT values of a few minutes. Although the UTO option
allows suggestion of short timeouts, applications advertising them allows suggestion of short timeouts, applications advertising them
should consider these effects. should consider these effects.
Long USER TIMEOUT values allow hosts to tolerate extended periods Long USER TIMEOUT values allow hosts to tolerate extended periods
without end-to-end connectivity. However, they also require hosts to without end-to-end connectivity. However, they also require hosts to
maintain the TCP state information associated with connections for maintain the TCP state information associated with connections for
long periods of time. Section 5 discusses the security implications long periods of time. Section 6 discusses the security implications
of long timeout values. of long timeout values.
To protect against these effects, implementations MUST impose limits To protect against these effects, implementations MUST impose limits
on the user timeout values they accept and use. The remainder of on the user timeout values they accept and use. The remainder of
this section describes a RECOMMENDED scheme to limit TCP's USER this section describes a RECOMMENDED scheme to limit TCP's USER
TIMEOUT based on upper and lower limits. TIMEOUT based on upper and lower limits.
Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
SHOULD compute the local USER TIMEOUT for a connection according to SHOULD compute the local USER TIMEOUT for a connection according to
this formula: this formula:
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 5 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
skipping to change at page 9, line 32 skipping to change at page 9, line 32
(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 TBD, i.e., the TCP option number [RFC0793] assigned
by IANA upon publication of this document (see Section 6). [[Note by IANA upon publication of this document (see Section 7). [[Note
to the RFC Editor: Throughout this document, replace "TBD" with to the RFC Editor: Throughout this document, replace "TBD" with
the TCP option number that IANA has allocated and remove this the TCP option number that IANA has allocated and remove this
note.]] 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"
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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. Security Considerations 5. Programming and Manageability Considerations
The IETF specification for TCP [RFC0793] includes a simple, abstract
application programming interface (API). The API for the UTO
extension in Section 3 is kept similarly abstract. TCP
implementations, however, usually provide more complex and feature-
rich APIs. The "socket" API that originated with BSD Unix and is now
standardized by POSIX is one such example [POSIX]. It is expected
that TCP implementations that choose to include the UTO extension
will extend their API to allow applications to use and configure its
parameters.
The MIB objects defined in [RFC4022] and [RFC4898] allow management
of TCP connections. It is expected that revisions to these documents
will include definitions of objects for managing the UTO extension
defined in this document.
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.
skipping to change at page 11, line 27 skipping to change at page 11, line 44
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. Similarly, a host can start to timeouts for the peer's connections. (Implementors that decide to
accept long user timeouts for an established connection only after use TCP-MD5 for this purpose are encouraged to monitor the
in-band authentication has occurred, for example, after a TLS development of TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], its designated
handshake across the connection has succeeded [RFC5246]. Although successor, and update their implementation when it is published as an
these are arguably the most complete solutions, they depend on RFC.) A similar approach is for a host to start accepting long user
external mechanisms to establish a trust relationship. timeouts for an established connection only after in-band
authentication has occurred, for example, after a TLS handshake
across the connection has succeeded [RFC5246]. Although these are
arguably the most complete solutions, they depend on external
mechanisms to establish a trust relationship.
A second alternative that does not depend on external mechanisms A second alternative that does not depend on external mechanisms
would introduce a per-peer limit on the number of connections that would introduce a per-peer limit on the number of connections that
may use increased user timeouts. Several variants of this approach may use increased user timeouts. Several variants of this approach
are possible, such as fixed limits or shortening accepted user are possible, such as fixed limits or shortening accepted user
timeouts with a rising number of connections. Although this timeouts with a rising number of connections. Although this
alternative does not eliminate resource exhaustion attacks from a alternative does not eliminate resource exhaustion attacks from a
single peer, it can limit their effects. Reducing the number of single peer, it can limit their effects. Reducing the number of
high-UTO connections a server supports in the face of an attack turns high-UTO connections a server supports in the face of an attack turns
that attack into a denial-of-service attack against the service of that attack into a denial-of-service attack against the service of
skipping to change at page 12, line 18 skipping to change at page 12, line 40
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 Note that if TCP needs to close or abort connections with a long TCP
User Timeout Option to shed load, these connections are still no User Timeout Option to shed load, these connections are still no
worse off than without the option. worse off than without the option.
Finally, upper and lower limits on user timeouts, discussed in Finally, upper and lower limits on user timeouts, discussed in
Section 3.1, can be an effective tool to limit the impact of these Section 3.1, can be an effective tool to limit the impact of these
sorts of attacks. sorts of attacks.
6. IANA Considerations 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. It requests that
IANA allocate a new 8-bit TCP option number for the UTO option from IANA allocate a new 8-bit TCP option number for the UTO option from
the registry maintained at the registry maintained at
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
7. 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.
8. References 9. References
8.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.
8.2. Informative References 9.2. Informative References
[I-D.eddy-tcp-mobility] [I-D.eddy-tcp-mobility]
Eddy, W., "Mobility Support For TCP", Eddy, W., "Mobility Support For TCP",
draft-eddy-tcp-mobility-00 (work in progress), April 2004. draft-eddy-tcp-mobility-00 (work in progress), April 2004.
[I-D.ietf-tcpm-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 Middleboxes",
Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
Measurement , October 2004. Measurement , October 2004.
[POSIX] IEEE Std. 1003.1-2001, "Standard for Information
Technology - Portable Operating System Interface (POSIX)",
Open Group Technical Standard: Base 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 MD5
Signature Option", RFC 2385, August 1998. 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
Transmission Control Protocol (TCP)", RFC 4022,
March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP
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-MANUAL]
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.
skipping to change at page 14, line 8 skipping to change at page 15, line 4
[SOLARIS-MANUAL] [SOLARIS-MANUAL]
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/. [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
Appendix A. Document Revision History Appendix A. Document Revision History
[[Note to the RFC Editor: Section to be removed upon publication.]] [[Note to the RFC Editor: Section to be removed upon publication.]]
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| -11 | Addressing IESG review comments. |
| | |
| -10 | Addressing the gen-art review comments from Scott | | -10 | Addressing the gen-art review comments from Scott |
| | Brim. Updated reference to [RFC5246]. Added funding | | | Brim. Updated reference to [RFC5246]. Added funding |
| | source acknowledgment. | | | source acknowledgment. |
| | | | | |
| -09 | Resubmission after expiration. Updated reference to | | -09 | Resubmission after expiration. Updated reference to |
| | [RFC5226]. | | | [RFC5226]. |
| | | | | |
| -08 | Addressed additional, minor working group last call | | -08 | Addressed additional, minor working group last call |
| | comments. | | | comments. |
| | | | | |
skipping to change at page 17, line 4 skipping to change at line 733
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/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 25 change blocks. 
33 lines changed or deleted 82 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/