< draft-ietf-tcpm-tcp-soft-errors-08.txt   draft-ietf-tcpm-tcp-soft-errors-09.txt >
TCP Maintenance and Minor F. Gont TCP Maintenance and Minor F. Gont
Extensions (tcpm) UTN/FRH Extensions (tcpm) UTN/FRH
Internet-Draft April 23, 2008 Internet-Draft November 30, 2008
Intended status: Informational Intended status: Informational
Expires: October 25, 2008 Expires: June 3, 2009
TCP's Reaction to Soft Errors TCP's Reaction to Soft Errors
draft-ietf-tcpm-tcp-soft-errors-08.txt draft-ietf-tcpm-tcp-soft-errors-09.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 October 25, 2008. This Internet-Draft will expire on June 3, 2009.
Abstract Abstract
This document describes a non-standard, but widely implemented, This document describes a non-standard, but widely implemented,
modification to TCP's handling of ICMP soft error messages, that modification to TCP's handling of ICMP soft error messages, that
rejects pending connection-requests when those error messages are rejects pending connection-requests when those error messages are
received. This behavior reduces the likelihood of long delays received. This behavior reduces the likelihood of long delays
between connection establishment attempts that may arise in a number between connection establishment attempts that may arise in a number
of scenarios, including one in which dual stack nodes that have IPv6 of scenarios, including one in which dual stack nodes that have IPv6
enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 Default . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployed workarounds for long delays between 4. Deployed workarounds for long delays between
connection-establishment attempts . . . . . . . . . . . . . . 7 connection-establishment attempts . . . . . . . . . . . . . . 7
4.1. Context-sensitive ICMP/TCP interaction . . . . . . . . . . 7 4.1. Context-sensitive ICMP/TCP interaction . . . . . . . . . . 7
4.2. Context-sensitive ICMP/TCP interaction with repeated 4.2. Context-sensitive ICMP/TCP interaction with repeated
confirmation . . . . . . . . . . . . . . . . . . . . . . . 8 confirmation . . . . . . . . . . . . . . . . . . . . . . . 8
5. Possible drawbacks of changing ICMP semantics . . . . . . . . 9 5. Possible drawbacks of changing ICMP semantics . . . . . . . . 9
5.1. Non-deterministic transient network failures . . . . . . . 9 5.1. Non-deterministic transient network failures . . . . . . . 9
5.2. Deterministic transient network failures . . . . . . . . . 9 5.2. Deterministic transient network failures . . . . . . . . . 10
5.3. Non-compliant Network Address Translators (NATs) . . . . . 10 5.3. Non-compliant Network Address Translators (NATs) . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Change log (to be removed before publication of Appendix A. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 13 the document as an RFC) . . . . . . . . . . . . . . . 13
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-07 . . . . . 13 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-08 . . . . . 13
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-06 . . . . . 13 A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-07 . . . . . 14
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-05 . . . . . 13 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-06 . . . . . 14
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 13 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-05 . . . . . 14
A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 13 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-04 . . . . . 15
A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 14 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-03 . . . . . 15
A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 14 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-02 . . . . . 15
A.8. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 14 A.8. Changes from draft-ietf-tcpm-tcp-soft-errors-01 . . . . . 15
A.9. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 14 A.9. Changes from draft-ietf-tcpm-tcp-soft-errors-00 . . . . . 15
A.10. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 14 A.10. Changes from draft-gont-tcpm-tcp-soft-errors-02 . . . . . 15
A.11. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 14 A.11. Changes from draft-gont-tcpm-tcp-soft-errors-01 . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.12. Changes from draft-gont-tcpm-tcp-soft-errors-00 . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
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 in an attempt consists of the actions that hosts and routers perform in an attempt
to survive a 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 one fault isolation technique to report network (ICMP) [RFC0792] is one fault isolation technique to report network
error conditions to the hosts sending datagrams over the network. error conditions to the hosts sending datagrams over the network.
When a host is notified of a network error, its network stack will When a host is notified of a network error, its network stack will
attempt to continue communications, if possible, in the presence of attempt to continue communications, if possible, in the presence of
the network failure. The fault recovery strategy may depend on the the network failure. The fault recovery strategy may depend on the
type of network failure taking place, and the time the error type of network failure taking place, and the time the error
condition is detected. condition is detected.
This document analyzes the fault recovery strategy of TCP [RFC0793], This document analyzes the problems that may arise due to TCP's fault
and the problems that may arise due to TCP's reaction to ICMP soft recovery reactions to ICMP soft errors. It analyzes the problems
errors. It analyzes the problems that may arise when a host tries to that may arise when a host tries to establish a TCP connection with a
establish a TCP connection with a multihomed host for which some of multihomed host for which some of its addresses are unreachable.
its addresses are unreachable. Additionally, it analyzes the Additionally, it analyzes the problems that may arise in the specific
problems that may arise in the specific scenario where dual stack scenario where dual stack nodes that have IPv6 enabled by default are
nodes that have IPv6 enabled by default are deployed in IPv4 or mixed deployed in IPv4 or mixed IPv4 and IPv6 environments.
IPv4 and IPv6 environments.
Finally, we document a modification to TCP's reaction to ICMP Finally, we document a modification to TCP's reaction to ICMP
messages indicating soft errors during connection startup, that has messages indicating soft errors during connection startup, that has
been implemented in a variety of TCP/IP stacks to help overcome the been implemented in a variety of TCP/IP stacks to help overcome the
problems outlined below. We stress that this modification runs problems outlined below. We stress that this modification runs
contrary to the standard behavior and this document unambiguously contrary to the standard behavior and this document unambiguously
does not change the standard reaction. does not change the standard reaction.
[Gont] describes alternative approaches for dealing with the problem
of long delays between connection-establishment attempts in TCP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 network error conditions that are unlikely to considered to reflect network error conditions that are unlikely to
skipping to change at page 4, line 47 skipping to change at page 4, line 48
In the case that a host does receive an ICMP error message referring In the case that a host does receive an ICMP error message referring
to an ongoing TCP connection, the IP layer will pass this message up to an ongoing TCP connection, the IP layer will pass this message up
to the corresponding TCP instance to raise awareness of the network to the corresponding TCP instance to raise awareness of the network
failure [RFC1122]. TCP's reaction to ICMP messages will depend on failure [RFC1122]. TCP's reaction to ICMP messages will depend on
the type of error being signaled. the type of error 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, compliant TCP implementations will simply abort the
regardless of the connection state. corresponding connection, regardless of the connection state.
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
TCP SHOULD abort connections when receiving ICMP error messages that TCP SHOULD abort connections when receiving ICMP error messages that
indicate hard errors. This policy is based on the premise that, as indicate hard errors. This policy is based on the premise that, as
hard errors indicate network error conditions that will not change in hard errors indicate network error conditions that will not change in
the near term, it will not be possible for TCP to usefully recover the near term, it will not be possible for TCP to usefully recover
from this type of network failure. from this type of network failure.
It should be noted that virtually all current TCP implementations do
not follow the advice in [RFC1122], and do not abort the
corresponding connection when an ICMP hard error is received for
connection that is in any of the synchronized states
[I-D.ietf-tcpm-icmp-attacks].
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 repeatedly retransmit the segment until it either gets will repeatedly retransmit the segment until it either gets
acknowledged or the connection times out. In addition, the TCP acknowledged or the connection times out. In addition, the TCP
sender may record the information for possible later use [Stevens] sender may record the information for possible later use [Stevens]
(pp. 317-319). (pp. 317-319).
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that
TCP MUST NOT abort connections when receiving ICMP error messages TCP MUST NOT abort connections when receiving ICMP error messages
skipping to change at page 6, line 39 skipping to change at page 6, line 46
not the only possible approach. For example, applications could try not the only possible approach. For example, applications could try
multiple addresses in parallel until one succeeds, possibly avoiding multiple addresses in parallel until one succeeds, possibly avoiding
the problem of long delays between connection establishment attempts the problem of long delays between connection establishment attempts
described in this document. described in this document.
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
A particular scenario in which the above sketched type of problem may A particular scenario in which the above sketched type of problem may
occur regularly is that where dual stack nodes that have IPv6 enabled occur regularly is that where dual stack nodes that have IPv6 enabled
by default are deployed in IPv4 or mixed IPv4 and IPv6 environments, by default are deployed in IPv4 or mixed IPv4 and IPv6 environments,
and the IPv6 connectivity is non-existent and the IPv6 connectivity is non-existent [RFC4943].
[I-D.ietf-v6ops-v6onbydefault].
As discussed in [I-D.ietf-v6ops-v6onbydefault], there are two As discussed in [RFC4943], there are two possible variants of this
possible variants of this scenario, which differ in whether the lack scenario, which differ in whether the lack of connectivity is
of connectivity is signaled to the sending node, or not. signaled to the sending node, or not.
In those scenarios in which packets sent to a destination are In those scenarios in which packets sent to a destination are
silently dropped and no ICMPv6 [RFC4443] errors are generated, there silently dropped and no ICMPv6 [RFC4443] errors are generated, there
is little that can be done other than waiting for the existing is little that can be done other than waiting for the existing
connection timeout mechanism in TCP, or an application timeout, to be connection timeout mechanism in TCP, or an application timeout, to be
triggered. triggered.
In scenarios where a node has no default routers and Neighbor In scenarios where a legacy node has no default routers and Neighbor
Unreachability Detection (NUD) [RFC4861] fails for destinations Unreachability Detection (NUD) [RFC4861] fails for destinations
assumed to be on-link, or where firewalls or other systems that assumed to be on-link, or where firewalls or other systems that
enforce scope boundaries send ICMPv6 errors, the sending node will be enforce scope boundaries send ICMPv6 errors, the sending node will be
signaled of the unreachability problem. However, as discussed in signaled of the unreachability problem. However, as discussed in
Section 2.2, standard TCP implementations will not abort connections Section 2.2, standard TCP implementations will not abort connections
when receiving ICMP error messages that indicate soft errors. when receiving ICMP error messages that indicate soft errors.
4. Deployed workarounds for long delays between connection- 4. Deployed workarounds for long delays between connection-
establishment attempts establishment attempts
The following subsections describe a number of workarounds for the The following subsections describe a number of workarounds for the
problem of long delays between connection-establishment attempts that problem of long delays between connection-establishment attempts that
have been implemented in a variety of TCP/IP stacks. We note that have been implemented in a variety of TCP/IP stacks. We note that
treating soft errors as hard errors during connection establishment, treating soft errors as hard errors during connection establishment,
while widespread, is not part of standard TCP behavior and this while widespread, is not part of standard TCP behavior and this
document does not change that state of affairs. The TCPM WG document does not change that state of affairs. The TCPM WG (TCP
consensus was to document this widespread implementation of Maintenance and Minor Extensions Working Group) consensus was to
nonstandard TCP behavior, but to not change the TCP standard. document this widespread implementation of nonstandard TCP behavior,
but to not change the TCP standard.
4.1. Context-sensitive ICMP/TCP interaction 4.1. Context-sensitive ICMP/TCP interaction
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 number of TCP implementations have modified their reaction to soft A number of TCP implementations have modified their reaction to all
errors, to treat the errors as hard errors in the SYN-SENT or SYN- ICMP soft errors, to treat them as hard errors when they are received
RECEIVED states. For example, this workaround has been implemented, for connections in the SYN-SENT or SYN-RECEIVED states. For example,
for example, in the Linux kernel since version 2.0.0 (released in this workaround has been implemented in the Linux kernel since
1996) [Linux]. However, it should be noted that this change violates version 2.0.0 (released in 1996) [Linux]. However, it should be
section 4.2.3.9 of [RFC1122], which states that these Unreachable noted that this change violates section 4.2.3.9 of [RFC1122], which
messages indicate soft error conditions and therefore TCP MUST NOT states that these ICMP error messages indicate soft error conditions
abort the corresponding connection. and therefore TCP MUST NOT abort the corresponding connection.
[RFC3168] states that a host that receives a RST in response to the [RFC3168] states that a host that receives a RST in response to the
transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and
ECE cleared. This is meant to deal with faulty middle-boxes that ECE cleared. This is meant to deal with faulty middle-boxes that
reject connections when a SYN segment has the ECE and CWR bits set. reject connections when a SYN segment has the ECE and CWR bits set.
Given that this section describes a modification that processes ICMP Some faulty middle-boxes (e.g., firewalls) may reject connections
error messages as hard errors when they are received for a connection with an ICMP soft error of type 3 (Destination Unreachable), code 0
in any of the non-synchronized states, systems implementing this (net unreachable) or 1 (host unreachable), instead of an RST.
behavior could resend the SYN segment with the ECE and CWR bits Therefore a system that processes ICMP error messages as hard errors
cleared when an ICMP error message is received in response to a SYN when they are received for a connection in any of the non-
segment that had these bits set. synchronized states could resend the SYN segment with the ECE and CWR
bits cleared when an ICMP "net unreachable" (type 3, code 0) or "host
unreachable" (type 3, code 1) error message is received in response
to a SYN segment that had these bits set.
Section 4.2 discusses a more conservative approach than that sketched Section 4.2 discusses a more conservative approach than that sketched
above, that is implemented in FreeBSD. above, that is implemented in FreeBSD.
4.2. Context-sensitive ICMP/TCP interaction with repeated confirmation 4.2. Context-sensitive ICMP/TCP interaction with repeated confirmation
A more conservative approach than simply treating soft errors as hard A more conservative approach than simply treating soft errors as hard
errors as described above would be to abort a connection in the SYN- errors as described above would be to abort a connection in the SYN-
SENT or SYN-RECEIVED states only after an ICMP Destination SENT or SYN-RECEIVED states only after an ICMP soft error has been
Unreachable has been received a specified number of times, and the received a specified number of times, and the SYN segment has been
SYN segment has been retransmitted more than some specified number of retransmitted more than some specified number of times.
times.
Two new parameters would have to be introduced to TCP, to be used Two new parameters would have to be introduced to TCP, to be used
only during the connection-establishment phase: MAXSYNREXMIT and only during the connection-establishment phase: MAXSYNREXMIT and
MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN
segment would have to be retransmitted before a connection is segment would have to be retransmitted before a connection is
aborted. MAXSOFTERROR would specify the number of ICMP messages aborted. MAXSOFTERROR would specify the number of ICMP messages
indicating soft errors that would have to be received before a indicating soft errors that would have to be received before a
connection is aborted. connection is aborted.
Two additional state variables would need to be introduced to store Two additional state variables would need to be introduced to store
skipping to change at page 9, line 26 skipping to change at page 9, line 36
arising from the use of the non-standard modifications to TCP's arising from the use of the non-standard modifications to TCP's
reaction to soft errors described in Section 4.1 and Section 4.2. reaction to soft errors described in Section 4.1 and Section 4.2.
5.1. Non-deterministic transient network failures 5.1. Non-deterministic transient network failures
In scenarios where a transient network failure affects all of the In scenarios where a transient network failure affects all of the
addresses returned by the name-to-address translation function, all addresses returned by the name-to-address translation function, all
destinations could be unreachable for some short period of time. For destinations could be unreachable for some short period of time. For
example, a mobile system consisting of a cell and a repeater may pass example, a mobile system consisting of a cell and a repeater may pass
through a tunnel, leading to a loss of connectivity at the repeater, through a tunnel, leading to a loss of connectivity at the repeater,
with the repeater sending ICMP soft errors back to the cell. In such with the repeater sending ICMP soft errors back to the cell. Also,
transient routing problem might lead some intervening router to drop
a SYN segment that was meaning to establish a TCP connection and send
an ICMP soft error back to the host. Finally, a SYN segment carrying
data might get fragmented and some of the resulting fragments might
get lost, with the destination host timing out the reassembly process
and sending an ICMP soft error back to the sending host (although
this particular scenario is unlikely because, while the [RFC0793]
allows SYN segments to carry data, in practice they do not). In such
scenarios, the application could quickly cycle through all the IP scenarios, the application could quickly cycle through all the IP
addresses in the list and return an error, when it could have let TCP addresses in the list and return an error, when it could have let TCP
retry a destination a few seconds later, when the transient problem retry a destination a few seconds later, when the transient problem
could have disappeared. In this case, the modifications described could have disappeared. In this case, the modifications described
here make TCP less robust than a standards-compliant implementation. here make TCP less robust than a standards-compliant implementation.
Additionally, in many cases a domain name maps to a single IP Additionally, in many cases a domain name maps to a single IP
address. In such a case, it might be better to try that address address. In such a case, it might be better to try that address
persistently according to normal TCP rules, instead of just aborting persistently according to normal TCP rules, instead of just aborting
the pending connection upon receipt of an ICMP soft error. the pending connection upon receipt of an ICMP soft error.
skipping to change at page 10, line 14 skipping to change at page 10, line 31
5.3. Non-compliant Network Address Translators (NATs) 5.3. Non-compliant Network Address Translators (NATs)
Some NATs respond to an unsolicited inbound SYN segment with an ICMP Some NATs respond to an unsolicited inbound SYN segment with an ICMP
soft error message. If the system sending the unsolicited SYN soft error message. If the system sending the unsolicited SYN
segment implements the workaround described in this document, it will segment implements the workaround described in this document, it will
abort the connection upon receipt of the ICMP error message, thus abort the connection upon receipt of the ICMP error message, thus
probably preventing TCP's simultaneous open through the NAT from probably preventing TCP's simultaneous open through the NAT from
succeeding. However, it must be stressed that those NATs described succeeding. However, it must be stressed that those NATs described
in this section are not BEHAVE-compliant, and therefore should in this section are not BEHAVE-compliant, and therefore should
implement REQ-4 of [I-D.ietf-behave-tcp] instead. implement REQ-4 of [RFC5382] instead.
In those scenarios in which such a non-BEHAVE-compliant NAT is
deployed, TCP simultaneous open could fail. While undesirable, this
is tolerable in many situations. For instance, a number of host
implementations of TCP do not support TCP simultaneous opens
[Zuquete].
6. Security Considerations 6. Security Considerations
This document describes a non-standard modification to TCP's reaction This document describes a non-standard modification to TCP's reaction
to soft errors that has been implemented in a variety of TCP to soft errors that has been implemented in a variety of TCP
implementations. This modification makes TCP abort a connection in implementations. This modification makes TCP abort a connection in
the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP
"Destination Unreachable" message that indicates a soft error. error message that indicates a soft error. Therefore, the
Therefore, the modification could be exploited to reset valid modification could be exploited to reset valid connections during the
connections during the connection-establishment phase. connection-establishment phase.
The non-standard workaround described in this document makes TCP more The non-standard workaround described in this document makes TCP more
vulnerable to attack, even if only slightly. However, we note that vulnerable to attack, even if only slightly. However, we note that
an attacker wishing to reset ongoing TCP connections could send any an attacker wishing to reset ongoing TCP connections could send any
of the ICMP hard error messages in any connection state. of the ICMP hard error messages in any connection state.
Generally, TCP backs off its retransmission timer each time it Generally, TCP backs off its retransmission timer each time it
retransmits the SYN segment for the same connection. If a TCP retransmits the SYN segment for the same connection. If a TCP
implements the modification described in this document, that is, implements the modification described in this document, that is,
tries the next address in the list upon receipt of an ICMP error tries the next address in the list upon receipt of an ICMP error
skipping to change at page 11, line 11 skipping to change at page 11, line 31
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].
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Acknowledgements 8. Acknowledgements
The author wishes to thank Mark Allman, Ron Bonica, Ted Faber, Gorry The author wishes to thank Mark Allman, Jari Arkko, David Black, Ron
Fairhurst, Sally Floyd, Tomohiro Fujisaki, Guillermo Gont, Saikat Bonica, Ted Faber, Gorry Fairhurst, Sally Floyd, Tomohiro Fujisaki,
Guha, Alfred Hoenes, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Guillermo Gont, Saikat Guha, Alfred Hoenes, Michael Kerrisk, Eddie
Arifumi Matsumoto, Carlos Pignataro, Pasi Sarolahti, Pekka Savola, Kohler, Mika Liljeberg, Arifumi Matsumoto, Sandy Murphy, Carlos
Pyda Srisuresh, and Joe Touch, for contributing many valuable Pignataro, Pasi Sarolahti, Pekka Savola, Pyda Srisuresh, Jinmei
comments on earlier versions of this document. Tatuya, and Joe Touch, for contributing many valuable comments on
earlier versions of this document.
The author wishes to express deep and heartfelt gratitude to Jorge The author wishes to thank Secretaria de Extension Universitaria at
Oscar Gont and Nelida Garcia, for their precious motivation and Universidad Tecnologica Nacional, and Universidad Tecnologica
Nacional/Facultad Regional Haedo, for their support in this work.
Finally, the author wishes to express deep and heartfelt gratitude to
Jorge Oscar Gont and Nelida Garcia, for their precious motivation and
guidance. guidance.
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.1 was documented in [I-D.ietf-v6ops-v6onbydefault] by Section 4.1 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 12, line 16 skipping to change at page 12, line 45
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
10.2. Informative References 10.2. Informative References
[I-D.ietf-behave-tcp] [Gont] Gont, F., "On the problem of long delays between
Guha, S., "NAT Behavioral Requirements for TCP", connection-establishment attempts in TCP", http://
draft-ietf-behave-tcp-07 (work in progress), April 2007. www.gont.com.ar/papers/connection-delays/
fgont-alt-solutions-connection-delays.pdf , 2008.
[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-03 (work in progress), draft-ietf-tcpm-icmp-attacks-04 (work in progress),
March 2008. October 2008.
[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.
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
Discovery On-Link Assumption Considered Harmful",
RFC 4943, September 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[Shneiderman] [Shneiderman]
Shneiderman, B., "Response Time and Display Rate in Human Shneiderman, B., "Response Time and Display Rate in Human
Performance with Computers", ACM Computing Surveys , 1984. Performance with Computers", ACM Computing Surveys , 1984.
[Stevens] Stevens, W., "TCP/IP Illustrated, Volume 1: The [Stevens] Stevens, W., "TCP/IP Illustrated, Volume 1: The
Protocols", Addison-Wesley , 1994. Protocols", Addison-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.
[Zuquete] Zuquete, A., "Improving the functionality of SYN cookies",
6th IFIP Communications and Multimedia Security Conference
(CMS 2002) , 2002.
Appendix A. Change log (to be removed before publication of the Appendix A. Change log (to be removed before publication of the
document as an RFC) document as an RFC)
A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-07 A.1. Changes from draft-ietf-tcpm-tcp-soft-errors-08
o Addresses Last Call feedback from David Black: Minor tweaks in the
Section 1, Section 5.3, and Section 4.1 (ECN).
o Addresses Last Call feedback from Jinmei Tatuya: (on-link
assumption has been deprecated)
o Addresses Last Call feedback from Sandy Murphy: clarifies that
reaction to ICMP soft errors applies to all ICMP soft errors,
expands Section 5.1, and clarifies Section 4.1 (ECN).
o Minor editorial changes
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-07
o Fixes id nits. o Fixes id nits.
A.2. Changes from draft-ietf-tcpm-tcp-soft-errors-06 A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-06
o Added a paragraph (in Section 4.1) about the interaction of the o Added a paragraph (in Section 4.1) about the interaction of the
described modification with ECN-enabled connections described modification with ECN-enabled connections
o Added a paragraph (in Section 6) about the possible scenario in o Added a paragraph (in Section 6) about the possible scenario in
which a host injects SYN segments into the network at a high rate, which a host injects SYN segments into the network at a high rate,
in response to ICMP soft errors. in response to ICMP soft errors.
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.3. Changes from draft-ietf-tcpm-tcp-soft-errors-05 A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-05
o Miscellaneous edits, clarifications, and reorganization of both o Miscellaneous edits, clarifications, and reorganization of both
workarounds into a single top-level section, as suggested by Pasi workarounds into a single top-level section, as suggested by Pasi
Sarolahti. Sarolahti.
o Added note on non-compliant NATs, as suggested by Ted Faber and o Added note on non-compliant NATs, as suggested by Ted Faber and
Saikat Guha Saikat Guha
o Miscellaneous edits suggested by Gorry Fairhurst o Miscellaneous edits suggested by Gorry Fairhurst
o Added a table to clarify how to extrapolate the concept of ICMPv4 o Added a table to clarify how to extrapolate the concept of ICMPv4
"soft errors" to ICMPv6 (as suggested by Arifumi Matsumoto and "soft errors" to ICMPv6 (as suggested by Arifumi Matsumoto and
Gorry Fairhurst). Gorry Fairhurst).
o Miscellaneous edits, clarification on alternative approach by o Miscellaneous edits, clarification on alternative approach by
sending connection requests in parallel, example of mobile system sending connection requests in parallel, example of mobile system
(for non-deterministic errors), and note on the possible impact of (for non-deterministic errors), and note on the possible impact of
the workarounds on TCP's robusteness (as suggested by Joe Touch) the workarounds on TCP's robusteness (as suggested by Joe Touch)
A.4. Changes from draft-ietf-tcpm-tcp-soft-errors-04 A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-04
o Addresses feedback sent by Carlos Pignataro (adds missing error o Addresses feedback sent by Carlos Pignataro (adds missing error
codes in Section 2, and fixes a number of typos/writeos). codes in Section 2, and fixes a number of typos/writeos).
A.5. Changes from draft-ietf-tcpm-tcp-soft-errors-03 A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-03
o Addresses feedback sent by Ted Faber and Gorry Fairhurst o Addresses feedback sent by Ted Faber and Gorry Fairhurst
(miscellaneous editorial changes). (miscellaneous editorial changes).
A.6. Changes from draft-ietf-tcpm-tcp-soft-errors-02 A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-02
o Moved appendix on FreeBSD's approach to the body of the draft. o Moved appendix on FreeBSD's approach to the body of the draft.
o Removed rest of the appendix, as suggested by Ron Bonica and Mark o Removed rest of the appendix, as suggested by Ron Bonica and Mark
Allman. Allman.
o Reworded some parts of the document to make the text more neutral. o Reworded some parts of the document to make the text more neutral.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
A.7. Changes from draft-ietf-tcpm-tcp-soft-errors-01 A.8. 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)
A.8. Changes from draft-ietf-tcpm-tcp-soft-errors-00 A.9. Changes from draft-ietf-tcpm-tcp-soft-errors-00
o Miscellaneous editorial changes o Miscellaneous editorial changes
A.9. Changes from draft-gont-tcpm-tcp-soft-errors-02 A.10. 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
A.10. Changes from draft-gont-tcpm-tcp-soft-errors-01 A.11. 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
A.11. Changes from draft-gont-tcpm-tcp-soft-errors-00 A.12. Changes from draft-gont-tcpm-tcp-soft-errors-00
o Added reference to the Linux implementation in Section 4.1 o Added reference to the Linux implementation in Section 4.1
o Added Section 5 o Added Section 5
o Added section on Higher-Level API o Added section on Higher-Level API
o Added Section 4.2 o Added Section 4.2
o Moved section "Asynchronous Application Notification" to Appendix o Moved section "Asynchronous Application Notification" to Appendix
o Added section on parallel connection requests 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
 End of changes. 40 change blocks. 
88 lines changed or deleted 145 lines changed or added

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