doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5482.txt b/doc/rfc/rfc5482.txt
new file mode 100644
index 0000000..8bef6cb
--- /dev/null
+++ b/doc/rfc/rfc5482.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          L. Eggert
+Request for Comments: 5482                                         Nokia
+Category: Standards Track                                        F. Gont
+                                                                 UTN/FRH
+                                                              March 2009
+
+
+                        TCP User Timeout Option
+
+Status of This Memo
+
+   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 (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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   The TCP user timeout controls how long transmitted data may remain
+   unacknowledged before a connection is forcefully closed.  It is a
+   local, per-connection parameter.  This document specifies a new TCP
+   option -- the TCP User Timeout Option -- that allows one end of a TCP
+   connection to advertise its current user timeout value.  This
+   information provides advice to the other end of the TCP connection to
+   adapt its user timeout accordingly.  Increasing the user timeouts on
+   both ends of a TCP connection allows it to survive extended periods
+   without end-to-end connectivity.  Decreasing the user timeouts allows
+   busy servers to explicitly notify their clients that they will
+   maintain the connection state only for a short time without
+   connectivity.
+
+
+
+
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 1]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions .....................................................3
+   3. Operation .......................................................4
+      3.1. Changing the Local User Timeout ............................5
+      3.2. UTO Option Reliability .....................................8
+      3.3. Option Format ..............................................8
+      3.4. Reserved Option Values .....................................9
+   4. Interoperability Issues .........................................9
+      4.1. Middleboxes ................................................9
+      4.2. TCP Keep-Alives ...........................................10
+   5. Programming and Manageability Considerations ...................10
+   6. Security Considerations ........................................10
+   7. IANA Considerations ............................................12
+   8. Acknowledgments ................................................12
+   9. References .....................................................12
+      9.1. Normative References ......................................12
+      9.2. Informative References ....................................13
+
+1.  Introduction
+
+   The Transmission Control Protocol (TCP) specification [RFC0793]
+   defines a local, per-connection "user timeout" parameter that
+   specifies the maximum amount of time that transmitted data may remain
+   unacknowledged before TCP will forcefully close the corresponding
+   connection.  Applications can set and change this parameter with OPEN
+   and SEND calls.  If an end-to-end connectivity disruption lasts
+   longer than the user timeout, a sender will receive no
+   acknowledgments for any transmission attempt, including keep-alives,
+   and it will close the TCP connection when the user timeout occurs.
+
+   This document specifies a new TCP option -- the TCP User Timeout
+   Option (UTO) -- that allows one end of a TCP connection to advertise
+   its current user timeout value.  This information provides advice to
+   the other end of the connection to adapt its user timeout
+   accordingly.  That is, TCP remains free to disregard the advice
+   provided by the UTO option if local policies suggest it to be
+   appropriate.
+
+   Increasing the user timeouts on both ends of a TCP connection allows
+   it to survive extended periods without end-to-end connectivity.
+   Decreasing the user timeouts allows busy servers to explicitly notify
+   their clients that they will maintain the connection state only for a
+   short time without connectivity.
+
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 2]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   In the absence of an application-specified user timeout, the TCP
+   specification [RFC0793] defines a default user timeout of 5 minutes.
+   The Host Requirements RFC [RFC1122] refines this definition by
+   introducing two thresholds, R1 and R2 (R2 > R1), that control the
+   number of retransmission attempts for a single segment.  It suggests
+   that TCP should notify applications when R1 is reached for a segment,
+   and close the connection when R2 is reached.  [RFC1122] also defines
+   the recommended values for R1 (3 retransmissions) and R2 (100
+   seconds), noting that R2 for SYN segments should be at least 3
+   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].
+
+   Although some TCP implementations allow applications to set their
+   local user timeout, TCP has no in-protocol mechanism to signal
+   changes to the local user timeout to the other end of a connection.
+   This causes local changes to be ineffective in allowing a connection
+   to survive extended periods without connectivity, because the other
+   end will still close the connection after its user timeout expires.
+
+   The ability to inform the other end of a connection about the local
+   user timeout can improve TCP operation in scenarios that are
+   currently not well supported.  One example of such a scenario is
+   mobile hosts that change network attachment points.  Such hosts,
+   maybe using Mobile IP [RFC3344], HIP [RFC4423], or transport-layer
+   mobility mechanisms [TCP_MOB], are only intermittently connected to
+   the Internet.  In between connected periods, mobile hosts may
+   experience periods without end-to-end connectivity.  Other factors
+   that can cause transient connectivity disruptions are high levels of
+   congestion or link or routing failures inside the network.  In these
+   scenarios, a host may not know exactly when or for how long
+   connectivity disruptions will occur, but it might be able to
+   determine an increased likelihood for such events based on past
+   mobility patterns and thus benefit from using longer user timeouts.
+   In other scenarios, the time and duration of a connectivity
+   disruption may even be predictable.  For example, a node in space
+   might experience connectivity disruptions due to line-of-sight
+   blocking by planetary bodies.  The timing of these events may be
+   computable from orbital mechanics.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 3]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+3.  Operation
+
+   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
+   system-wide setting.  TCP maintains four per-connection state
+   variables to control the operation of the UTO option, three of which
+   (ADV_UTO, ENABLED, and CHANGEABLE) are new:
+
+   USER_TIMEOUT
+      TCP's USER TIMEOUT parameter, as specified in [RFC0793].
+
+   ADV_UTO
+      UTO option advertised to the remote TCP peer.  This is an
+      application-specified value, and may be specified on a system-wide
+      basis.  If unspecified, it defaults to the default system-wide
+      USER TIMEOUT.
+
+   ENABLED (Boolean)
+      Flag that controls whether the UTO option is enabled for a
+      connection.  This flag applies to both sending and receiving.
+      Defaults to false.
+
+   CHANGEABLE (Boolean)
+      Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT
+      parameter) may be changed based on an UTO option received from the
+      other end of the connection.  Defaults to true and becomes false
+      when an application explicitly sets USER_TIMEOUT.
+
+   Note that an exchange of UTO options between both ends of a
+   connection is not a binding negotiation.  Transmission of a UTO
+   option is a suggestion that the other end consider adapting its user
+   timeout.  This adaptation only happens if the other end of the
+   connection has explicitly allowed it (both ENABLED and CHANGEABLE are
+   true).
+
+   Before opening a connection, an application that wishes to use the
+   UTO option enables its use by setting ENABLED to true.  It may choose
+   an appropriate local UTO by explicitly setting ADV_UTO; otherwise,
+   UTO is set to the default USER TIMEOUT value.  Finally, the
+   application should determine whether it will allow the local USER
+   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
+   not have specific user timeout concerns.  If an application
+   explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false in
+   order to prevent UTO options (from the other end) from overriding
+   local application requests.  Alternatively, applications can set or
+   clear CHANGEABLE directly through API calls.
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 4]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   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
+   reliable way to initially exchange, and potentially adapt to, UTO
+   values.  TCP implementations MAY provide system-wide default settings
+   for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
+
+   In addition to exchanging UTO options in the SYN segments, a
+   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
+   to minimize the amount of state information TCP must keep for
+   connections in non-synchronized states.  Also, it is particularly
+   useful when mechanisms such as "SYN cookies" [RFC4987] are
+   implemented, allowing a newly-established TCP connection to benefit
+   from the information advertised by the UTO option, even if the UTO
+   contained in the initial SYN segment was not recorded.
+
+   A host that supports the UTO option SHOULD include one in the next
+   possible outgoing segment whenever it starts using a new user timeout
+   for the connection.  This allows the other end of the connection to
+   adapt its local user timeout accordingly.  A TCP implementation that
+   does not support the UTO option MUST silently ignore it [RFC1122],
+   thus ensuring interoperability.
+
+   Hosts MUST impose upper and lower limits on the user timeouts they
+   use for a connection.  Section 3.1 discusses user timeout limits and
+   potentially problematic effects of some user timeout settings.
+
+   Finally, it is worth noting that TCP's option space is limited to 40
+   bytes.  As a result, if other TCP options are in use, they may
+   already consume all the available TCP option space, thus preventing
+   the use of the UTO option specified in this document.  Therefore, TCP
+   option space issues should be considered before enabling the UTO
+   option.
+
+3.1.  Changing the Local User Timeout
+
+   When a host receives a TCP User Timeout Option, it must decide
+   whether to change the local user timeout of the corresponding
+   connection.  If the CHANGEABLE flag is false, USER_TIMEOUT MUST NOT
+   be changed, regardless of the received UTO option.  Without this
+   restriction, the UTO option would modify TCP semantics, because an
+   application-requested USER TIMEOUT could be overridden by peer
+   requests.  In this case TCP SHOULD, however, notify the application
+   about the user timeout value received from the other end system.
+
+
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 5]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   In general, unless the application on the local host has requested a
+   specific USER TIMEOUT for the connection, CHANGEABLE will be true and
+   hosts SHOULD adjust the local TCP USER TIMEOUT (USER_TIMEOUT) in
+   response to receiving a UTO option, as described in the remainder of
+   this section.
+
+   The UTO option specifies the user timeout in seconds or minutes,
+   rather than in number of retransmissions or round-trip times (RTTs).
+   Thus, the UTO option allows hosts to exchange user timeout values
+   from 1 second to over 9 hours at a granularity of seconds, and from 1
+   minute to over 22 days at a granularity of minutes.
+
+   Very short USER TIMEOUT values can affect TCP transmissions over
+   high-delay paths.  If the user timeout occurs before an
+   acknowledgment for an outstanding segment arrives, possibly due to
+   packet loss, the connection closes.  Many TCP implementations default
+   to USER TIMEOUT values of a few minutes.  Although the UTO option
+   allows suggestion of short timeouts, applications advertising them
+   should consider these effects.
+
+   Long USER TIMEOUT values allow hosts to tolerate extended periods
+   without end-to-end connectivity.  However, they also require hosts to
+   maintain the TCP state information associated with connections for
+   long periods of time.  Section 6 discusses the security implications
+   of long timeout values.
+
+   To protect against these effects, implementations MUST impose limits
+   on the user timeout values they accept and use.  The remainder of
+   this section describes a RECOMMENDED scheme to limit TCP's USER
+   TIMEOUT based on upper and lower limits.
+
+   Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
+   SHOULD compute the local USER TIMEOUT for a connection according to
+   this formula:
+
+   USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))
+
+   Each field is to be interpreted as follows:
+
+   USER_TIMEOUT
+      USER TIMEOUT value to be adopted by the local TCP for this
+      connection.
+
+   U_LIMIT
+      Current upper limit imposed on the user timeout of a connection by
+      the local host.
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 6]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   ADV_UTO
+      User timeout advertised to the remote TCP peer in a TCP User
+      Timeout Option.
+
+   REMOTE_UTO
+      Last user timeout value received from the other end in a TCP User
+      Timeout Option.
+
+   L_LIMIT
+      Current lower limit imposed on the user timeout of a connection by
+      the local host.
+
+   The RECOMMENDED formula results in the maximum of the two advertised
+   values, adjusted for the configured upper and lower limits, to be
+   adopted for the user timeout of the connection on both ends.  The
+   rationale is that choosing the maximum of the two values will let the
+   connection survive longer periods without end-to-end connectivity.
+   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
+   must be kept on the host, it can close or abort the connection
+   whenever it wants.
+
+   It must be noted that the two endpoints of the connection will not
+   necessarily adopt the same user timeout.
+
+   Enforcing a lower limit (L_LIMIT) prevents connections from closing
+   due to transient network conditions, including temporary congestion,
+   mobility hand-offs, and routing instabilities.
+
+   An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
+   attacks.  Section 6 discusses the details of these attacks.
+
+   Note that these limits MAY be specified as system-wide constants or
+   at other granularities, such as on per-host, per-user, per-outgoing-
+   interface, or even per-connection basis.  Furthermore, these limits
+   need not be static.  For example, they MAY be a function of system
+   resource utilization or attack status and could be dynamically
+   adapted.
+
+   The Host Requirements RFC [RFC1122] does not impose any limits on the
+   length of the user timeout.  However, it recommends a time interval
+   of at least 100 seconds.  Consequently, the lower limit (L_LIMIT)
+   SHOULD be set to at least 100 seconds when following the RECOMMENDED
+   scheme described in this section.  Adopting a user timeout smaller
+   than the current retransmission timeout (RTO) for the connection
+   would likely cause the connection to be aborted unnecessarily.
+   Therefore, the lower limit (L_LIMIT) MUST be larger than the current
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 7]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   retransmission timeout (RTO) for the connection.  It is worth noting
+   that an upper limit may be imposed on the RTO, provided it is at
+   least 60 seconds [RFC2988].
+
+3.2.  UTO Option Reliability
+
+   The TCP User Timeout Option is an advisory TCP option that does not
+   change processing of subsequent segments.  Unlike other TCP options,
+   it need not be exchanged reliably.  Consequently, the specification
+   does not define a reliability handshake for UTO option exchanges.
+   When a segment that carries a UTO option is lost, the other end will
+   simply not have the opportunity to update its local USER TIMEOUT.
+
+   Implementations MAY implement local mechanisms to improve delivery
+   reliability, such as retransmitting a UTO option when they retransmit
+   a 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 UTO option, they do not guarantee
+   delivery (a three-way handshake would be required for this).
+   Consequently, implementations MUST NOT assume that UTO options are
+   transmitted reliably.
+
+3.3.  Option Format
+
+   Sending a TCP User Timeout Option informs the other end of the
+   connection of the current local user timeout and suggests that the
+   other end adapt its user timeout accordingly.  The user timeout value
+   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
+   synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-
+   WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).  Connections in other
+   states MUST use the default timeout values defined in [RFC0793] and
+   [RFC1122].
+
+      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
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Kind = 28   |   Length = 4  |G|        User Timeout         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   (One tick mark represents one bit.)
+
+              Figure 1: Format of the TCP User Timeout Option
+
+
+
+
+
+Eggert & Gont               Standards Track                     [Page 8]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   Figure 1 shows the format of the TCP User Timeout Option.  It
+   contains these fields:
+
+   Kind (8 bits)
+      This MUST be 28, i.e., the TCP option number [RFC0793] that has
+      been assigned by IANA (see Section 7).
+
+   Length (8 bits)
+      Length of the TCP option in octets [RFC0793]; its value MUST be 4.
+
+   Granularity (1 bit)
+      Granularity bit, indicating the granularity of 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
+      interval in the "User Timeout" field MUST be interpreted as
+      seconds.
+
+   User Timeout (15 bits)
+      Specifies the user timeout suggestion for this connection.  It
+      MUST be interpreted as a 15-bit unsigned integer.  The granularity
+      of the timeout (minutes or seconds) depends on the "G" field.
+
+3.4.  Reserved Option Values
+
+   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
+   for future use.  Current TCP implementations MUST NOT send it and
+   MUST ignore it upon reception.
+
+4.  Interoperability Issues
+
+   This section discusses interoperability issues related to introducing
+   the TCP User Timeout Option.
+
+4.1.  Middleboxes
+
+   A TCP implementation that does not support the TCP User Timeout
+   Option MUST silently ignore it [RFC1122], thus ensuring
+   interoperability.  In a study of the effects of middleboxes on
+   transport protocols, Medina et al. have shown that the vast majority
+   of modern TCP stacks correctly handle unknown TCP options [MEDINA].
+   In this study, 3% of connections failed when an unknown TCP option
+   appeared in the middle of a connection.  Because the number of
+   failures caused by unknown options is small and they are a result of
+   incorrectly implemented TCP stacks that violate existing requirements
+   to ignore unknown options, they do not warrant special measures.
+   Thus, this document does not define a mechanism to negotiate support
+   of the TCP User Timeout Option during the three-way handshake.
+
+
+
+Eggert & Gont               Standards Track                     [Page 9]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   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
+   of inactivity.  If such a firewall exists along the path, it may
+   close or abort connections regardless of the use of the TCP User
+   Timeout Option.  In the future, such firewalls may learn to parse the
+   TCP User Timeout Option in unencrypted TCP segments and adapt
+   connection state management accordingly.
+
+4.2.  TCP Keep-Alives
+
+   Some TCP implementations, such as those in BSD systems, use a
+   different abort policy for TCP keep-alives than for user data.  Thus,
+   the TCP keep-alive mechanism might abort a connection that would
+   otherwise have survived the transient period without connectivity.
+   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
+   value larger than that of the adopted USER TIMEOUT.
+
+5.  Programming and Manageability Considerations
+
+   The IETF specification for TCP [RFC0793] includes a simple, abstract
+   application programming interface (API).  Similarly, the API for the
+   UTO extension in Section 3 is kept 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.
+   Flooding attacks cause denial of service by forcing servers to commit
+   resources for maintaining the state of throw-away connections.
+   However, TCP implementations do not become more vulnerable to simple
+
+
+
+Eggert & Gont               Standards Track                    [Page 10]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   SYN flooding by implementing the TCP User Timeout Option, because
+   user timeouts exchanged during the handshake only affect the
+   synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
+   CLOSING, LAST-ACK), which simple SYN floods never reach.
+
+   However, when an attacker completes the three-way handshakes of its
+   throw-away connections, it can amplify the effects of resource
+   exhaustion attacks because the attacked server must maintain the
+   connection state associated with the throw-away connections for
+   longer durations.  Because connection state is kept longer, lower-
+   frequency attack traffic, which may be more difficult to detect, can
+   already exacerbate resource exhaustion.
+
+   Several approaches can help mitigate this issue.  First,
+   implementations can require prior peer authentication, e.g., using
+   IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
+   timeouts for the peer's connections.  (Implementors that decide to
+   use TCP-MD5 for this purpose are encouraged to monitor the
+   development of TCP-AO [AUTH_OPT], its designated successor, and
+   update their implementation when it is published as an RFC.)  A
+   similar approach is for a host to start accepting long user 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
+   would introduce a per-peer limit on the number of connections that
+   may use increased user timeouts.  Several variants of this approach
+   are possible, such as fixed limits or shortening accepted user
+   timeouts with a rising number of connections.  Although this
+   alternative does not eliminate resource exhaustion attacks from a
+   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
+   attacks, where multiple clients coordinate a resource exhaustion
+   attack that uses long user timeouts.  To protect against such
+   attacks, TCP implementations could reduce the duration of accepted
+   user timeouts with increasing resource utilization.
+
+   TCP implementations under attack may be forced to shed load by
+   resetting established connections.  Some load-shedding heuristics,
+   such as resetting connections with long idle times first, can
+   negatively affect service for intermittently connected, trusted peers
+
+
+
+Eggert & Gont               Standards Track                    [Page 11]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   that have suggested long user timeouts.  On the other hand, resetting
+   connections to untrusted peers that use long user timeouts may be
+   effective.  In general, using the peers' level of trust as a
+   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
+   Section 3.1, can be an effective tool to limit the impact of these
+   sorts of attacks.
+
+7.  IANA Considerations
+
+   This section is to be interpreted according to [RFC5226].
+
+   This document does not define any new namespaces.  IANA has allocated
+   a new 8-bit TCP option number (28) for the UTO option from the "TCP
+   Option Kind Numbers" registry maintained at http://www.iana.org.
+
+8.  Acknowledgments
+
+   The following people have improved this document through thoughtful
+   suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
+   Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade
+   Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,
+   Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,
+   Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha
+   Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, and
+   Martin Stiemerling.
+
+   Lars Eggert is partly funded by [TRILOGY], a research project
+   supported by the European Commission under its Seventh Framework
+   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.1.  Normative References
+
+   [RFC0793]   Postel, J., "Transmission Control Protocol", STD 7,
+               RFC 793, September 1981.
+
+   [RFC1122]   Braden, R., "Requirements for Internet Hosts -
+               Communication Layers", STD 3, RFC 1122, October 1989.
+
+
+
+Eggert & Gont               Standards Track                    [Page 12]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+9.2.  Informative References
+
+   [AUTH_OPT]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+               Authentication Option", Work in Progress, November 2008.
+
+   [MEDINA]    Medina, A., Allman, M., and S. Floyd, "Measuring
+               Interactions Between Transport Protocols and
+               Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on
+               Internet 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 Signature Option", RFC 2385, August 1998.
+
+   [RFC2988]   Paxson, V. and M. Allman, "Computing TCP's Retransmission
+               Timer", RFC 2988, November 2000.
+
+   [RFC3344]   Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
+               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
+               Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4423]   Moskowitz, R. and P. Nikander, "Host Identity Protocol
+               (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
+               Mitigations", RFC 4987, August 2007.
+
+
+
+
+
+Eggert & Gont               Standards Track                    [Page 13]
+
+RFC 5482                TCP User Timeout Option               March 2009
+
+
+   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
+               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [SOLARIS]   Sun Microsystems, "Solaris Tunable Parameters Reference
+               Manual", Part No. 806-7009-10, 2002.
+
+   [TCP_MOB]   Eddy, W., "Mobility Support For TCP", Work in Progress,
+               April 2004.
+
+   [TRILOGY]   "Trilogy Project", <http://www.trilogy-project.org/>.
+
+Authors' Addresses
+
+   Lars Eggert
+   Nokia Research Center
+   P.O. Box 407
+   Nokia Group  00045
+   Finland
+
+   Phone: +358 50 48 24461
+   EMail: lars.eggert@nokia.com
+   URI:   http://research.nokia.com/people/lars_eggert/
+
+
+   Fernando Gont
+   Universidad Tecnologica Nacional / Facultad Regional Haedo
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   EMail: fernando@gont.com.ar
+   URI:   http://www.gont.com.ar/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eggert & Gont               Standards Track                    [Page 14]
+