TCP Maintenance and Minor                                        F. Gont
Extensions (tcpm)                                                UTN/FRH
Internet-Draft                                             June 24, 2004
Expires: December 23, 2004


                     TCP's Reaction to Soft Errors
                 draft-gont-tcpm-tcp-soft-errors-00.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.  This document may not be modified, and derivative works of
   it may not be created, except to publish it as an RFC and to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 23, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document discusses problems that may arise due to TCP's reaction
   to soft errors.  In particular, it discusses the problem of long
   delays in connection establishment attempts that may arise when dual
   stack nodes that have IPv6 enabled by default are deployed in IPv4 or
   mixed IPv4 and IPv6 environments.  The purpose of this document is to
   discuss this potential problem, and analyze the ways in which it
   could be worked around.  It does not to try to specify whether IPv6



Gont                   Expires December 23, 2004                [Page 1]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   should be enabled by default or not.

1.  Introduction

   The handling of network failures can be separated into two different
   actions: fault isolation and fault recovery.  Fault isolation is the
   actions that hosts and routers take to determine that there is some
   network failure.  Fault recovery, on the other hand, is the actions
   that  hosts and routers will perform to isolate and survive a network
   failure.[8]

   In the Internet architecture, the Internet Control Message Protocol
   (ICMP) [1] is used to perform the fault isolation function, that is,
   to report network error conditions to the hosts sending datagrams
   over the network.

   When a host is signalled of a network error, there is still the issue
   of what to do to let communication survive, if possible, the network
   failure.  The fault recovery strategy may depend on the type of
   network failure taking place, and the time the error condition is
   detected.

   This document discusses the fault recovery policy of TCP [2], and the
   problems that may arise due to TCP's policy of reaction to soft
   errors.  In particular, it discusses the problems that arise in
   scenarios where dual stack nodes that have IPv6 enabled by default
   are deployed in IPv4 or mixed IPv4 and IPv6 environments.

   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 RFC 2119 [3].

2.  Error Handling in TCP

   Network errors can be divided into soft and hard errors.  Soft errors
   are considered to be transient network failures, which will hopefully
   be solved in the near term.  Hard errors, on the other hand, are
   considered to reflect permanent network conditions, which are
   unlikely to be solved in the near future.

   Therefore, it may make sense for the fault recovery action to be
   different depending on the type of error being detected.

   When there is a network failure that's not signalled to the sending
   host, such as a gateway corrupting packets, TCP's fault recovery
   action is to repeatedly retransmit the segment until either it gets
   acknowledged, or the connection times out.  In case the connection
   times out before the segment is acknowledged, TCP won't be able to



Gont                   Expires December 23, 2004                [Page 2]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   provide more information than the timeout condition.

   In case a host does receive an ICMP error message about a current TCP
   connection, the IP layer will pass this message up to TCP to raise
   awareness of the network failure.  [4]

   TCP's reaction will depend on the type of error being signalled.

2.1  Reaction to Hard Errors

   When receiving a segment with the RST bit set, or an ICMP error
   message indicating a hard error condition, TCP will simply abort the
   connection, regardless of the state the connection is in.

   The "Requirements for Internet Hosts RFC -- Communication Layers" RFC
   [4] states, in section 4.2.3.9., that TCP SHOULD abort connections
   when receiving ICMP errors that indicate hard errors.  This policy is
   based on the premise that, as hard errors indicate network conditions
   that won't change in the near term, it will not be possible for TCP
   to recover from this type of network failure.

2.2  Reaction to Soft Errors

   The "Requirements for Internet Hosts -- Communication Layers" RFC [4]
   states, in section 4.2.3.9, that TCP MUST NOT abort connections when
   receiving ICMP errors that indicate soft errors.

   If an ICMP error message is received that indicates a soft error, TCP
   will just record this information [9], and repeatedly retransmit the
   segment until either it gets acknowledged or the connection times
   out.  This policy is based on the premise that, as soft errors are
   transient network failures that will hopefully be solved in the near
   term, one of the retransmissions will succeed.

   In case the connection timer expires, and an ICMP error message had
   been received before the timeout, TCP will use this information to
   provide the user with a more specific error message.  [9]

   This handling of soft errors exploits the valuable feature of the
   Internet that for many network failures, the network can be
   dynamically reconstructed without any disruption of the endpoints.

3.  Problems arising from TCP's reaction to soft errors

3.1  General Discussion

   Even though TCP's fault recovery strategy in the presence of soft
   errors allows for TCP connections to survive transient network



Gont                   Expires December 23, 2004                [Page 3]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   failures, there are scenarios in which this policy may cause
   undesirable effects.

   For example, consider the case where an application on a local host
   is trying to communicate with a destination whose name resolves to
   several IP addresses.  The application on the local host will try to
   establish a connection with the destination host, cycling through the
   list of IP addresses, until one succeeds [5].  Suppose that some (but
   not all) of the addresses in the returned list are permanently
   unreachable.  If they are the first IP addresses in the list, the
   application will try to use these addresses first.

   As discussed in Section 2, this unreachability condition may or may
   not be signalled to the sending host.  If the local TCP is not
   signalled of the error condition, it will repeatedly retransmit the
   SYN segment, until the connection times out.  If unreachability is
   signalled by some intermediate router to the local TCP by means of an
   ICMP error message, the local TCP will just record the error message
   and will still repeatedly retransmit the SYN segment until the
   connection timer expires.  The "Requirements For Internet Hosts --
   Communication Layers" RFC [4] states that this timer MUST be large
   enough to provide retransmission of the SYN segment for at least 3
   minutes.  This would mean that the application on the local host
   would spend several minutes for each unreachable address it tries to
   use for a connection attempt.  These long delays in connection
   establishment attempts would be inappropriate for interactive
   applications such as the web.

3.2  Problems that arise with Dual Stack IPv6 on by Default

   A scenario in which this type of problem may occur is that where dual
   stack nodes that have IPv6 enabled by default are deployed in IPv4 or
   mixed IPv4 and IPv6 environments, and the IPv6 connectivity is
   non-existent [6].

   As discussed in [6], there are two possible variants of this
   scenario, which differ in whether the lack of connectivity is
   signalled to the sending node, or not.

   In cases where packets sent to a destination are silently dropped and
   no ICMPv6 [7] errors are generated, there is very little that can be
   done other than waiting for the existing connection timeout mechanism
   in TCP, or an aplication timeout, to be triggered.

   In cases where a node has no default routers and Neighbor
   Unreachability Detection (NUD) fails for destinations assumed to be
   on-link, or where firewalls or other systems that enforce scope
   boundaries send ICMPv6 errors, the sending node will be signalled of



Gont                   Expires December 23, 2004                [Page 4]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   the unreachability problem.  As discussed in Section 2.2, TCP
   implementations will not abort connections when receiving ICMP errors
   that indicate soft errors.  However, it would be desirable for TCP
   implementations to use this information to avoid the long delays in
   connection attempts described in Section 3.1.

   The following sections discuss some possible ways to solve this
   issue, and their potential drawbacks.

4.  Possible solutions to the problem

4.1  Changing TCP's reaction to soft errors

   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
   also on the time the error is reported.  For example, one could infer
   that when an error arrives in response to opening a new connection,
   it is probably caused by opening the connection improperly, rather
   than by a transient network failure.  [8]

   Thus, one solution is for TCP to abort a connection in the SYN-SENT
   or the SYN-RECEIVED states if it receives an ICMP "Destination
   Unreachable" message that indicates a soft error about that
   connection.

   The "Requirements for Internet Hosts -- Communication Layers" RFC [4]
   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 [4] was written, one could
   extrapolate the concept of soft errors to ICMPv6 Type 1 Codes 0 (no
   route to destination) and 3 (address unreachable).

   A tangential method of handling the problem in this way would be for
   applications to somehow notify the TCP layer of their preference in
   the matter.  An application could ask TCP to not abort a connection
   in the presence of such ICMP errors.  This would allow existing TCP
   implementations to maintain their status quo at the expense of
   increased application complexity, while maintaining the reaction to
   "soft errors" described in this section as the "default" action.

   There are drawbacks to this TCP behavior.  In case there's a
   transient network failure affecting all of the addresses returned by
   the name-to-address translation function, all destinations could be
   unreachable for some short period of time.  In such a situation, the
   application could quickly cycle through all the 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 problem could have



Gont                   Expires December 23, 2004                [Page 5]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   been mitigated.

4.2  Asynchronous Application Notification

   In section 4.2.4.1, [4] 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 require, in order to solve the potential problems
   described in Section 3, every application to implement this logic,
   which would not be acceptable.  Therefore, the solution described in
   Section 4.1 should be preferred over this one.

5.  Security Considerations

   This document proposes to make TCP abort a connection in the SYN-SENT
   or the SYN-RECEIVED states when it receives an ICMP "Destination
   Unreachable" message that indicates a "soft error" about that
   connection.  While this could be used to reset valid connections, it
   must be noted that this behaviour is specified only for connections
   in the SYN-SENT or the SYN-RECEIVED states, and thus the window of
   exposure is very short.  Furthermore, in order for this type to
   succeed, the attacker should be able to guess the four-tuple that
   identifies the target TCP connection.  A discussion on this issue can
   be found in [10].  To mitigate the impact of this attack, additional
   constraints could be imposed in order to reset a connection upon
   receipt of the ICMP error.  For example, the TCP sequence number of
   the contained in the payload of the ICMP error message could be
   required to be valid [2].

   In any case, it must be noted that an attacker wishing to reset valid
   connections could perform the attack by sending any of the ICMP error
   messages that indicate "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 security issues arising from the use of ICMPv6
   can be found in [7].

6.  Acknowledgements

   The author wishes to thank Michael Kerrisk, Mika Liljeberg, Pasi
   Sarolahti, and Pekka Savola, for contributing many valuable comments.

7.  Contributors

   Mika Liljeberg was the first to describe how their implementation
   treated soft errors.  Based on that, the solutions discussed in



Gont                   Expires December 23, 2004                [Page 6]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


   Section 4 were documented in [6] by Sebastien Roy, Alain Durand and
   James Paugh.

8.  References

8.1  Normative References

   [1]  Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        September 1981.

   [2]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

   [5]  Braden, R., "Requirements for Internet Hosts - Application and
        Support", STD 3, RFC 1123, October 1989.

   [6]  Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack IPv6
        on by Default", draft-ietf-v6ops-v6onbydefault-02 (work in
        progress), May 2004.

   [7]  Conta, A. and S. Deering, "Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6)
        Specification", RFC 2463, December 1998.

8.2  Informative References

   [8]   Clark, D., "Fault isolation and recovery", RFC 816, July 1982.

   [9]   "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley ,
         1994.

   [10]  "Slipping in the Window: TCP Reset Attacks", 2004 CanSecWest
         Conference , 2004.












Gont                   Expires December 23, 2004                [Page 7]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


Author's Address

   Fernando Gont
   Universidad Tecnologica Nacional
   Evaristo Carriego 2644
   Haedo, 1706, Provincia de Buenos Aires
   Argentina

   Phone: +54 11 4650 8472
   EMail: fernando@gont.com.ar









































Gont                   Expires December 23, 2004                [Page 8]


Internet-Draft       TCP's Reaction to Soft Errors             June 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Gont                   Expires December 23, 2004                [Page 9]