draft-ietf-tcpm-tcp-soft-errors-02.txt   draft-ietf-tcpm-tcp-soft-errors-03.txt 
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Intended status: Informational Intended status: Informational
Expires: April 12, 2007 Expires: July 29, 2007
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-02.txt draft-ietf-tcpm-tcp-soft-errors-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2007. This Internet-Draft will expire on July 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document discusses the problem of long delays between connection This document discusses the problem of long delays between connection
establishment attempts that may arise in a number of scenarios, establishment attempts that may arise in a number of scenarios,
including one in which dual stack nodes that have IPv6 enabled by including one in which dual stack nodes that have IPv6 enabled by
default are deployed in IPv4 or mixed IPv4 and IPv6 environments. default are deployed in IPv4 or mixed IPv4 and IPv6 environments.
Additionally, this document describes a modification to TCP's Additionally, this document describes a non-standard, but widely
reaction to soft errors that has been implemented in a variety of implemented modification to TCP's reaction to ICMP "soft errors" that
TCP/IP stacks to help overcome this problem. can help overcome this problem.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3 2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3
2.1. Reaction to ICMP error messages that indicate hard 2.1. Reaction to ICMP error messages that indicate hard
errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reaction to ICMP error messages that indicate soft 2.2. Reaction to ICMP error messages that indicate soft
errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4 errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems that may arise from TCP's reaction to soft errors . . 5 3. Problems that may arise from TCP's reaction to soft errors . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5 3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5
3.2. Problems that may arise with Dual Stack IPv6 on by 3.2. Problems that may arise with Dual Stack IPv6 on by
Default . . . . . . . . . . . . . . . . . . . . . . . . . 5 Default . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. A workaround for long delays between 4. A workaround for long delays between
connection-establishment attempts . . . . . . . . . . . . . . 6 connection-establishment attempts . . . . . . . . . . . . . . 6
5. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 7 5. A more conservative approach . . . . . . . . . . . . . . . . . 7
5.1. Non-deterministic transient network failures . . . . . . . 7 6. Possible drawbacks . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Deterministic transient network failures . . . . . . . . . 7 6.1. Non-deterministic transient network failures . . . . . . . 8
6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Deterministic transient network failures . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Other possible solutions . . . . . . . . . . . . . . 10 Appendix A. Change log (to be removed before publication of
A.1. A more conservative approach . . . . . . . . . . . . . . . 10 the document as an RFC) . . . . . . . . . . . . . . . 10
A.2. Asynchronous Application Notification . . . . . . . . . . 11 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 10
A.3. Issuing several connection requests in parallel . . . . . 11 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 11
Appendix B. Change log (to be removed before publication of A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 11
the document as an RFC) . . . . . . . . . . . . . . . 12 A.4. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 11
B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 12 A.5. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 11
B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 12 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 11
B.3. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
B.4. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13
B.5. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The handling of network failures can be separated into two different The handling of network failures can be separated into two different
actions: fault isolation and fault recovery. Fault isolation actions: fault isolation and fault recovery. Fault isolation
consists of the actions that hosts and routers take to determine that consists of the actions that hosts and routers take to determine that
there is a network failure. Fault recovery, on the other hand, there is a network failure. Fault recovery, on the other hand,
consists of the actions that hosts and routers perform to survive a consists of the actions that hosts and routers perform in an attempt
network failure.[RFC0816] to survive a network failure.[RFC0816]
In the Internet architecture, the Internet Control Message Protocol In the Internet architecture, the Internet Control Message Protocol
(ICMP) [RFC0792] is used to perform the fault isolation function, (ICMP) [RFC0792] is one fault isolation technique to report network
that is, to report network error conditions to the hosts sending error conditions to the hosts sending datagrams over the network.
datagrams over the network.
When a host is signalled of a network error, there is still the issue When a host is signaled of a network error, there is still the issue
of what to do to let communication survive, if possible, the network of what to do to let communication survive, if possible, the network
failure. The fault recovery strategy may depend on the type of failure. The fault recovery strategy may depend on the type of
network failure taking place, and the time the error condition is network failure taking place, and the time the error condition is
detected. detected.
This document analyzes the fault recovery strategy of TCP [RFC0793], This document analyzes the fault recovery strategy of TCP [RFC0793],
and the problems that may arise due to TCP's policy of reaction to and the problems that may arise due to TCP's reaction to ICMP soft
soft errors. Among others, it analyzes the problems that may arise errors. Among others, it analyzes the problems that may arise in
in scenarios where dual stack nodes that have IPv6 enabled by default scenarios where dual stack nodes that have IPv6 enabled by default
are deployed in IPv4 or mixed IPv4 and IPv6 environments. are deployed in IPv4 or mixed IPv4 and IPv6 environments.
Additionally, it documents a modification to TCP's policy of reaction Additionally, we document a modification to TCP's reaction to ICMP
to ICMP messages indicating "soft errors", that has been implemented messages indicating "soft errors" during connection startup, that has
in a variety of TCP/IP stacks to help overcome the problems discussed been implemented in a variety of TCP/IP stacks to help overcome the
in this document. problems outlined below. We stress that this modification runs
contrary to the standard behavior and this document unambiguously
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", does not change the standard reaction.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Error Handling in TCP 2. Error Handling in TCP
Network errors can be divided into soft and hard errors. Soft errors Network errors can be divided into soft and hard errors. Soft errors
are considered to be transient network failures, which are likely to are considered to be transient network failures, which are likely to
be solved in the near term. Hard errors, on the other hand, are be solved in the near term. Hard errors, on the other hand, are
considered to reflect permanent network error conditions, which are considered to reflect network error conditions which are unlikely to
unlikely to be solved in the near future. be solved in the near future.
Therefore, it may make sense for the fault recovery action to be The "Requirements for Internet Hosts -- Communication Layers" RFC
different depending on the type of error being detected. [RFC1122] states, in section 4.2.3.9., that the ICMP "Destination
Unreachable" messages that indicate soft errors are ICMP codes 0
(network unreachable), 1 (host unreachable), and 5 (source route
failed). Even though ICMPv6 didn't exist when [RFC1122] was written,
one could extrapolate the concept of soft errors to ICMPv6 Type 1
Codes 0 (no route to destination) and 3 (address unreachable).
When there is a network failure that's not signalled to the sending When there is a network failure that's not signaled to the sending
host, such as a gateway corrupting packets, TCP's fault recovery host, such as a gateway corrupting packets, TCP's fault recovery
action is to repeatedly retransmit the segment until either it gets action is to repeatedly retransmit the segment until either it gets
acknowledged, or the connection times out. In case the connection acknowledged, or the connection times out.
times out before the segment is acknowledged, TCP won't be able to
provide more information than the timeout condition.
In case a host does receive an ICMP error message referring to an In case a host does receive an ICMP error message referring to an
ongoing TCP connection, the IP layer will pass this message up to ongoing TCP connection, the IP layer will pass this message up to
corresponding TCP instance to raise awareness of the network failure. corresponding TCP instance to raise awareness of the network failure.
[RFC1122] [RFC1122]
TCP's reaction to ICMP messages will depend on the type of error TCP's reaction to ICMP messages will depend on the type of error
being signalled. being signaled.
2.1. Reaction to ICMP error messages that indicate hard errors 2.1. Reaction to ICMP error messages that indicate hard errors
When receiving an ICMP error message that indicates a hard error When receiving an ICMP error message that indicates a hard error
condition, TCP will simply abort the corresponding connection, condition, TCP will simply abort the corresponding connection,
regardless of the state the connection is in. regardless of the state the connection is in.
The "Requirements for Internet Hosts -- Communication Layers" RFC The "Requirements for Internet Hosts -- Communication Layers" RFC
[RFC1122] states, in section 4.2.3.9, that TCP SHOULD abort [RFC1122] states, in section 4.2.3.9, that TCP SHOULD abort
connections when receiving ICMP error messages that indicate hard connections when receiving ICMP error messages that indicate hard
errors. This policy is based on the premise that, as hard errors errors. This policy is based on the premise that, as hard errors
indicate network error conditions that won't change in the near term, indicate network error conditions that won't change in the near term,
it will not be possible for TCP to recover from this type of network it will not be possible for TCP to usefully recover from this type of
failure. network failure.
2.2. Reaction to ICMP error messages that indicate soft errors 2.2. Reaction to ICMP error messages that indicate soft errors
If an ICMP error message is received that indicates a soft error, TCP If an ICMP error message is received that indicates a soft error, TCP
will just record this information [Stevens], and repeatedly will repeatedly retransmit the packet until it either gets
retransmit the data until either they get acknowledged or the acknowledged or the connection times out. In addition, the TCP may
connection times out. record the information for possible later use [Stevens].
The "Requirements for Internet Hosts -- Communication Layers" RFC The "Requirements for Internet Hosts -- Communication Layers" RFC
[RFC1122] states, in section 4.2.3.9, that TCP MUST NOT abort [RFC1122] states, in section 4.2.3.9, that TCP MUST NOT abort
connections when receiving ICMP error messages that indicate soft connections when receiving ICMP error messages that indicate soft
errors. This policy is based on the premise that, as soft errors are errors. This policy is based on the premise that, as soft errors are
transient network failures that will hopefully be solved in the near transient network failures that will hopefully be solved in the near
term, one of the retransmissions will succeed. term, one of the retransmissions will succeed.
In case the connection timer expires, and an ICMP error message has In case the connection timer expires, and an ICMP soft error message
been received before the timeout, TCP will use this information to has been received before the timeout, TCP can use this information to
provide the user with a more specific error message. [Stevens] provide the user with a more specific error message. [Stevens]
This handling of soft errors exploits the valuable feature of the This reaction to soft errors exploits the valuable feature of the
Internet that for many network failures, the network can be Internet that for many network failures, the network can be
dynamically reconstructed without any disruption of the endpoints. dynamically reconstructed without any disruption of the endpoints.
3. Problems that may arise from TCP's reaction to soft errors 3. Problems that may arise from TCP's reaction to soft errors
3.1. General Discussion 3.1. General Discussion
Even though TCP's fault recovery strategy in the presence of soft Even though TCP's fault recovery strategy in the presence of soft
errors allows for TCP connections to survive transient network errors allows for TCP connections to survive transient network
failures, there are scenarios in which this policy may cause failures, there are scenarios in which this policy may cause
undesirable effects. undesirable effects.
For example, consider the case in which an application on a local For example, consider the case in which an application on a local
host is trying to communicate with a destination whose name resolves host is trying to communicate with a destination whose name resolves
to several IP addresses. The application on the local host will try to several IP addresses. The application on the local host will try
to establish a connection with the destination host, cycling through to establish a connection with the destination host, cycling through
the list of IP addresses, until one succeeds [RFC1123]. Suppose that the list of IP addresses, until one succeeds [RFC1123]. Suppose that
some (but not all) of the addresses in the returned list are some (but not all) of the addresses in the returned list are
permanently unreachable. If they are the first IP addresses in the permanently unreachable. If such a permanently unreachable address
list, the application will usually try to use these addresses first. is the first in the list, the application will likely try to use the
permanently unreachable address first and block waiting for a timeout
before trying alternate addresses.
As discussed in Section 2, this unreachability condition may or may As discussed in Section 2, this unreachability condition may or may
not be signalled to the sending host. If the local TCP is not not be signaled to the sending host. If the local TCP is not
signalled concerning the error condition, there is very little that signaled concerning the error condition, there is very little that
can be done other than repeatedly retransmit the SYN segment, and can be done other than repeatedly retransmit the SYN segment, and
wait for the existing timeout mechanism in TCP, or an application wait for the existing timeout mechanism in TCP, or an application
timeout, to be triggered. However, even if unreachability is timeout, to be triggered. However, even if unreachability is
signalled by some intermediate router to the local TCP by means of an signaled by some intermediate router to the local TCP by means of an
ICMP error message, the local TCP will record the error message and ICMP soft error message, the local TCP will still repeatedly
will still repeatedly retransmit the SYN segment until the connection retransmit the SYN segment until the connection timer expires (in the
timer expires. The "Requirements For Internet Hosts -- Communication hopes that the error is transient). The "Requirements For Internet
Layers" RFC [RFC1122] states that this timer MUST be large enough to Hosts -- Communication Layers" RFC [RFC1122] states that this timer
provide retransmission of the SYN segment for at least 3 minutes. MUST be large enough to provide retransmission of the SYN segment for
This would mean that the application on the local host would spend at least 3 minutes. This would mean that the application on the
several minutes for each unreachable address it uses for trying to local host would spend several minutes for each unreachable address
establish a TCP connection. These long delays between connection it uses for trying to establish a TCP connection. These long delays
establishment attempts would be inappropriate for interactive between connection establishment attempts would be inappropriate for
applications such as the web. [Shneiderman] [Thadani] many interactive applications such as the web. ([Shneiderman] and
[Thadani] offer some insight into the interactive systems.) This
highlights that there is no one definition of a "transient error" and
that the level of persistence in the face of failure represents a
tradeoff.
3.2. Problems that may arise with Dual Stack IPv6 on by Default 3.2. Problems that may arise with Dual Stack IPv6 on by Default
Another scenario in which this type of problem may occur is that A particular scenario in which the above sketched type of problem may
where dual stack nodes that have IPv6 enabled by default are deployed occur regularly is that where dual stack nodes that have IPv6 enabled
in IPv4 or mixed IPv4 and IPv6 environments, and the IPv6 by default are deployed in IPv4 or mixed IPv4 and IPv6 environments,
connectivity is non-existent [I-D.ietf-v6ops-v6onbydefault]. and the IPv6 connectivity is non-existent
[I-D.ietf-v6ops-v6onbydefault].
As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two
possible variants of this scenario, which differ in whether the lack possible variants of this scenario, which differ in whether the lack
of connectivity is signalled to the sending node, or not. of connectivity is signaled to the sending node, or not.
In cases where packets sent to a destination are silently dropped and In cases where packets sent to a destination are silently dropped and
no ICMPv6 [RFC4443] errors are generated, there is very little that no ICMPv6 [RFC4443] errors are generated, there is little that can be
can be done other than waiting for the existing connection timeout done other than waiting for the existing connection timeout mechanism
mechanism in TCP, or an application timeout, to be triggered. in TCP, or an application timeout to be triggered.
In cases where a node has no default routers and Neighbor In cases where a node has no default routers and Neighbor
Unreachability Detection (NUD) fails for destinations assumed to be Unreachability Detection (NUD) fails for destinations assumed to be
on-link, or where firewalls or other systems that enforce scope on-link, or where firewalls or other systems that enforce scope
boundaries send ICMPv6 errors, the sending node will be signalled of boundaries send ICMPv6 errors, the sending node will be signaled of
the unreachability problem. However, as discussed in Section 2.2, the unreachability problem. However, as discussed in Section 2.2,
TCP implementations will not abort connections when receiving ICMP standard TCP implementations will not abort connections when
error messages that indicate soft errors. receiving ICMP error messages that indicate soft errors.
4. A workaround for long delays between connection-establishment 4. A workaround for long delays between connection-establishment
attempts attempts
As discussed in Section 1, it may make sense for the fault recovery As discussed in Section 1, it may make sense for the fault recovery
action to depend not only on the type of error being reported, but action to depend not only on the type of error being reported, but
also on the state of the connection against which the error is also on the state of the connection against which the error is
reported. For example, one could infer that when an error arrives in reported. For example, one could infer that when an error arrives in
response to opening a new connection, it is probably caused by response to opening a new connection, it is probably caused by
opening the connection improperly, rather than by a transient network opening the connection improperly, rather than by a transient network
failure. [RFC0816] failure. [RFC0816]
A variety of TCP/IP stacks have modified TCP's reaction to soft A number of TCP implementations have modified their reaction to soft
errors, to make it abort a connection in the SYN-SENT or the SYN- errors, to treat the errors as hard errors in the SYN-SENT or SYN-
RECEIVED state if it receives an ICMP "Destination Unreachable" RECEIVED states. It must be noted that this change violates section
message that indicates a soft error about that connection. 4.2.3.9 of [RFC1122], which states that these Unreachable messages
indicate soft error conditions and TCP MUST NOT abort the
corresponding connection.
The "Requirements for Internet Hosts -- Communication Layers" RFC This workaround has been implemented, for example, in the Linux
[RFC1122] states, in section 4.2.3.9., that the ICMP "Destination kernel since version 2.0.0 (released in 1996) [Linux]. Section 5
Unreachable" messages that indicate soft errors are ICMP codes 0 discusses a more conservative approach than that sketched above, that
(network unreachable), 1 (host unreachable), and 5 (source route is implemented in FreeBSD.
failed). Even though ICMPv6 didn't exist when [RFC1122] was written,
one could extrapolate the concept of soft errors to ICMPv6 Type 1
Codes 0 (no route to destination) and 3 (address unreachable).
It must be noted that this behaviour violates section 4.2.3.9 of We note that the TCPM WG could not arrive at consensus on allowing
[RFC1122], since it states that as these Unreachable messages the above described behavior as part of the standard. Therefore,
indicate soft error conditions, TCP MUST NOT abort the corresponding treating soft errors as hard errors during connection establishment,
connection. while widespread, is not part of standard TCP behavior and this
document does not change that state of affairs.
This workaround has been implemented, for example, in the Linux 5. A more conservative approach
kernel since version 2.0.0 (released in 1996) [Linux]. Appendix A.1
discusses a more conservative approach than the one introduced in
this section.
5. Possible drawbacks A more conservative approach than simply treating soft errors as hard
errors as described above would be to abort a connection in the SYN-
SENT or SYN-RECEIVED states only after an ICMP Destination
Unreachable has been received a specified number of times, and the
SYN segment has been retransmitted more than some specified number of
times.
Two new parameters would have to be introduced to TCP, to be used
only during the connection-establishment phase: MAXSYNREXMIT and
MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN
segment would have to be retransmitted before a connection is
aborted. MAXSOFTERROR would specify the number of ICMP messages
indicating soft errors that would have to be received before a
connection is aborted.
Two additional state variables would need to be introduced to store
additional state information during the connection-establishment
phase: "nsynrexmit" and "nsofterror". Both would be initialized to
zero when a connection attempt is initiated, with "nsynrexmit" being
incremented by one every time the SYN segment is retransmitted and
"nsofterror" being incremented by one every time an ICMP message that
indicates a soft error is received.
A connection in the SYN-SENT or SYN-RECEIVED states would be aborted
if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was
simultaneously greater than MAXSOFTERROR.
This approach would give the network more time to solve the
connectivity problem than simply aborting a connection attempt upon
reception of the first soft error. However, it should be noted that
depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR
parameters, this approach could still lead to long delays between
connection establishment attempts, thus not solving the problem. For
example, BSD systems abort connections in the SYN-SENT or the SYN-
RECEIVED state when a second ICMP error is received, and the SYN
segment has been retransmitted more than three times. They also set
up a "connection-establishment timer" that imposes an upper limit on
the time the connection establishment attempt has to succeed, which
expires after 75 seconds [Stevens2]. Even when this policy may be
better than the three-minutes timeout policy specified in [RFC1122],
it may still be inappropriate for handling the potential problems
described in this document. This more conservative approach has been
implemented in BSD systems since, at least, 1994 [Stevens2].
We also note that the approach given in this section is a generalized
version of the approach sketched in the previous section. In
particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero
the schemes are identical.
6. Possible drawbacks
The following subsections discuss some of the possible drawbacks The following subsections discuss some of the possible drawbacks
arising from the use of the modification to TCP's reaction to soft arising from the use of the non-standard modifications to TCP's
errors described in Section 4. reaction to soft errors described in Section 4 and Section 5.
5.1. Non-deterministic transient network failures 6.1. Non-deterministic transient network failures
In case there's a transient network failure affecting all of the In case a transient network failure affects all of the addresses
addresses returned by the name-to-address translation function, all returned by the name-to-address translation function, all
destinations could be unreachable for some short period of time. In destinations could be unreachable for some short period of time. In
such a scenario, the application could quickly cycle through all the such a scenario, the application could quickly cycle through all the
IP addresses in the list and return an error, when it could have let IP addresses in the list and return an error, when it could have let
TCP retry a destination a few seconds later, when the transient TCP retry a destination a few seconds later, when the transient
problem could have disappeared. problem could have disappeared.
However, it must be noted that non-interactive applications, such as 6.2. Deterministic transient network failures
a Mail Transfer Agent (MTA), usually must implement application-layer
retry mechanisms, and thus are able to handle these scenarios
appropriately. For interactive applications, the user would likely
not be satisfied with a connection attempt that succeeds only after
several seconds, anyway. [Guynes]
5.2. Deterministic transient network failures
There are some scenarios in which transient network failures could be There are some scenarios in which transient network failures could be
deterministic. For example, consider the case in which upstream deterministic. For example, consider the case in which upstream
network connectivity is triggered by network use. That is, network network connectivity is triggered by network use. That is, network
connectivity is instantiated only on an "as needed" basis. In this connectivity is instantiated only on an "as needed" basis. In this
scenario, the connection triggering the upstream connectivity would scenario, the connection triggering the upstream connectivity would
deterministically receive ICMP Destination Unreachables while the deterministically receive ICMP Destination Unreachables while the
upstream connectivity is being activated, and thus would be aborted. upstream connectivity is being activated, and thus would be aborted.
As discussed in Section 5.1, applications usually implement
mechanisms to handle these scenarios appropriately. Also, connection
attempts are usually preceded by a UDP-based DNS name-to-address
lookup. Thus, unless the name-to-address mapping has been cached by
a local nameserver or resolver, it will be the DNS query that will
trigger the upstream network connectivity, and thus the corresponding
connection will not be aborted.
6. Future work
A Higher-Level API would be useful for isolating applications from
protocol details. The API could contain the intelligence required to
resolve the hostname, try each destination address, etc. One could
even argue that this document wouldn't have existed if application
programmers had been using a Higher-Level API. However, such an API
would need to be designed, standardized, implemented, deployed, and
documented even before application programmers start (if ever) to use
it.
7. Security Considerations 7. Security Considerations
This document describes a modification to TCP's reaction to soft This document describes a non-standard modification to TCP's reaction
errors that has been implemented in a variety of TCP/IP stacks. This to soft errors that has been implemented in a variety of TCP
modification makes TCP abort a connection in the SYN-SENT or the SYN- implementations. This modification makes TCP abort a connection in
RECEIVED states when it receives an ICMP "Destination Unreachable" the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP
message that indicates a "soft error" about that connection. While "Destination Unreachable" message that indicates a "soft error".
this modification could be exploited to reset valid connections, it Therefore, the modification could be exploited to reset valid
must be noted that this behaviour is meant only for connections in connections during the connection-establishment phase.
the SYN-SENT or the SYN-RECEIVED states, and thus the window of
exposure is very short.
In any case, it must be noted that the workaround discussed in this The non-standard workaround described in this document makes TCP more
document neither strengthens nor weakens TCP's resistance to attack. vulnerable to attack---even if only slightly. However, we note that
An attacker wishing to reset ongoing TCP connections could perform an attacker wishing to reset ongoing TCP connections could send any
the attack by sending any of the ICMP error messages that indicate of the ICMP hard error messages in any connection state.
"hard errors", not only for connections in the SYN-SENT or the SYN-
RECEIVED states, but for connections in any state.
A discussion of the use of ICMP to perform a variety of attacks A discussion of the use of ICMP to perform a variety of attacks
against TCP, and a number of counter-measures that eliminate or against TCP, and a number of counter-measures that minimize the
greatly minimize the impact of these attacks can be found in impact of these attacks can be found in [I-D.ietf-tcpm-icmp-attacks].
[I-D.ietf-tcpm-icmp-attacks].
A discussion of the security issues arising from the use of ICMPv6 A discussion of the security issues arising from the use of ICMPv6
can be found in [RFC4443]. can be found in [RFC4443].
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Ron Bonica, Sally Floyd, Guillermo Gont, The author wishes to thank Mark Allman, Ron Bonica, Sally Floyd,
Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi Sarolahti, Pekka Guillermo Gont, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Pasi
Savola, and Joe Touch, for contributing many valuable comments on Sarolahti, Pekka Savola, and Joe Touch, for contributing many
earlier versions of this document. valuable comments on earlier versions of this document.
9. Contributors 9. Contributors
Mika Liljeberg was the first to describe how their implementation Mika Liljeberg was the first to describe how their implementation
treated soft errors. Based on that, the solution discussed in treated soft errors. Based on that, the solution discussed in
Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by Section 4 was documented in [I-D.ietf-v6ops-v6onbydefault] by
Sebastien Roy, Alain Durand and James Paugh. Sebastien Roy, Alain Durand and James Paugh.
10. References 10. References
skipping to change at page 9, line 38 skipping to change at page 10, line 12
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
10.2. Informative References 10.2. Informative References
[Guynes] Guynes, J., "Impact of System Response Time on State [Guynes] Guynes, J., "Impact of System Response Time on State
Anxiety", Communications of the ACM , 1988. Anxiety", Communications of the ACM , 1988.
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-00 (work in progress), draft-ietf-tcpm-icmp-attacks-01 (work in progress),
February 2006. October 2006.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816,
July 1982. July 1982.
skipping to change at page 10, line 19 skipping to change at page 10, line 39
[Stevens] "TCP/IP Illustrated, Volume 1: The Protocols", Addison- [Stevens] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-
Wesley , 1994. Wesley , 1994.
[Stevens2] [Stevens2]
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley , 1994. The Implementation", Addison-Wesley , 1994.
[Thadani] Thadani, A., "Interactive User Productivity", IBM Systems [Thadani] Thadani, A., "Interactive User Productivity", IBM Systems
Journal No. 1, 1981. Journal No. 1, 1981.
Appendix A. Other possible solutions Appendix A. Change log (to be removed before publication of the
document as an RFC)
A.1. A more conservative approach
A more conservative approach would be to abort a connection in the
SYN-SENT or SYN-RECEIVED states only after an ICMP Destination
Unreachable has been received a specified number of times, and the
SYN segment has been retransmitted more than some specified number of
times.
Two new parameters would have to be introduced to TCP, to be used
only during the connection-establishment phase: MAXSYNREXMIT and
MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN
segment would have to be retransmitted before a connection is
aborted. MAXSOFTERROR would specify the number of ICMP messages
indicating soft errors that would have to be received before a
connection is aborted.
Two additional variables would need to be introduced to store
additional state information during the connection-establishment
phase: "nsynrexmit" and "nsofterror". Both would be initialized to
zero. "nsynrexmit" would be incremented by one every time the SYN
segment is retransmitted. "nsofterror" would be incremented by one
every time an ICMP message that indicates a soft error is received.
A connection in the SYN-SENT or SYN-RECEIVED states would be aborted
if nsynrexmit was greater than MAXSYNREXMIT and "nsofterror" was
simultaneously greater than MAXSOFTERROR.
This approach would give the network more time to solve the
connectivity problem. However, it should be noted that depending on
the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters,
this approach could still lead to long delays between connection
establishment attempts, thus not solving the problem. For example,
BSD systems abort connections in the SYN-SENT or the SYN-RECEIVED
state when a second ICMP error is received, and the SYN segment has
been retransmitted more than three times. They also set up a
"connection-establishment timer" that imposes an upper limit on the
time the connection establishment attempt has to succeed, which
expires after 75 seconds [Stevens2]. Even when this policy may be
better than the three-minutes timeout policy specified in [RFC1122],
it may still be inappropriate for handling the potential problems
described in this document. This more conservative approach has been
implemented in BSD systems since, at least, 1994 [Stevens2].
A.2. Asynchronous Application Notification
In section 4.2.4.1, [RFC1122] states that there MUST be a mechanism
for reporting soft TCP error conditions to the application. Such a
mechanism (assuming one is implemented) could be used by applications
to cycle through the destination IP addresses. However, this
approach would increase application complexity, and would take a long
time to kick in, as it would require all existing applications to be
modified.
A.3. Issuing several connection requests in parallel A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-02
For those scenarios in which a domain name maps to several IP o Moved appendix on FreeBSD's approach to the body of the draft.
addresses, several connection requests could be issued in parallel,
each one to a different destination IP address. The host would then
use the first connection attempt to succeed, eliminating the
potential delay in establishing a connection with the destination
host. However, this would mean that every attempt to connect to a
multihomed host would imply sending several SYN segments, making it
hard for network operators to distinguish valid connection attempts
from those performing Denial of Service (DoS) attacks.
An alternative approach would be as follows. A host would issue a o Removed rest of the appendix, as suggested by Ron Bonica and Mark
connection request to the first IP address in the list returned by Allman.
the name-to-address mapping function. If this connection request
didn't succeed in some time, a connection request to the second IP
address in the list would be issued in parallel. If none of these
connection requests succeeded in some time, and there were still more
addresses left in the list, they would be tried in the same way.
While this approach would, in principle, avoid the problems of the
previous approach, it might be hard to define the time interval to
wait before issuing each parallel connection request. A short time
interval would lead to the problems caused by the previous approach,
while a long time interval would likely still lead to long delays in
establishing a connection with the destination host.
In any case, it must be noted that both approaches have the same o Reworded some parts of the document to make the text more neutral.
drawbacks as the solution described in Appendix A.2: they would
increase application complexity, and would take too long to begin to
be used by applications.
Appendix B. Change log (to be removed before publication of the o Miscellaneous editorial changes.
document as an RFC)
B.1. Changes from draft-ietf-tcpm-tcp-soft-errors-01 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-01
o Addressed feedback posted by Sally Floyd (remove sentence in o Addressed feedback posted by Sally Floyd (remove sentence in
Section 2.1 regarding processing of RST segments) Section 2.1 regarding processing of RST segments)
B.2. Changes from draft-ietf-tcpm-tcp-soft-errors-00 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.3. Changes from draft-gont-tcpm-tcp-soft-errors-02 A.4. Changes from draft-gont-tcpm-tcp-soft-errors-02
o Draft resubmitted as draft-ietf. o Draft resubmitted as draft-ietf.
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.4. Changes from draft-gont-tcpm-tcp-soft-errors-01 A.5. Changes from draft-gont-tcpm-tcp-soft-errors-01
o Changed wording to describe the mechanism, rather than proposing o Changed wording to describe the mechanism, rather than proposing
it it
o Miscellaneous editorial changes o Miscellaneous editorial changes
B.5. Changes from draft-gont-tcpm-tcp-soft-errors-00 A.6. Changes from draft-gont-tcpm-tcp-soft-errors-00
o Added reference to the Linux implementation in Section 4 o Added reference to the Linux implementation in Section 4
o Added Section 5
o Added Section 6 o Added Section 6
o Added Appendix A.1 o Added section on Higher-Level API
o Moved section "Asynchronous Application Notification" to o Added Section 5
Appendix A.2
o Added a Appendix A.3 o Moved section "Asynchronous Application Notification" to Appendix
o Added section on parallel connection requests
o Miscellaneous editorial changes o Miscellaneous editorial changes
Author's Address Author's Address
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 Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 62 change blocks. 
262 lines changed or deleted 205 lines changed or added

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