TCP's Reaction to Soft Errors
RFC 5461

[Ballot comment]
Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Update Aug 2008: the IETF specs are still saying this, even
if implementations are not. Suggesting that the authors consider
stating some of the actual reality as well.

[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice quite important --
this problem is perhaps more important than any other problem for IPv6
deployment -- and hence requires careful review.

I have a few issues with the document, however.

First, I was unable to find any evidence of review from the 6MAN or V6OPS
communities. No request for review has been posted to the lists, at least.
Has there been such review, and if not, can we ensure it happens now?
Normally, in general and in particularly for Informational documents IETF
Last Call suffices, but as I outlined above, this specification is
important enough to warrant that we get it right.

Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Update Aug 2008: the IETF specs are still saying this, even
if implementations are not. Suggesting that the authors consider
stating some of the actual reality as well.

[Ballot discuss]
This is a welcome document, and a very useful spec to publish. Even
if this is Informational, I believe it is in practice quite important --
this problem is perhaps more important than any other problem for IPv6
deployment -- and hence requires careful review.

I have a few issues with the document, however.

First, I was unable to find any evidence of review from the 6MAN or V6OPS
communities. No request for review has been posted to the lists, at least.
Has there been such review, and if not, can we ensure it happens now?
Normally, in general and in particularly for Informational documents IETF
Last Call suffices, but as I outlined above, this specification is
important enough to warrant that we get it right.

Section 2.1 says:

  When receiving an ICMP error message that indicates a hard error
  condition, TCP will simply abort the corresponding connection,
  regardless of the connection state.

Question. I was under the impression that recent specifications have
started to say to not blindly believe ICMP errors due to denial-
of-service concerns? If this is not the case, then no problem.

Section 3.2 says:

  In scenarios where a node has no default routers and Neighbor
  Unreachability Detection (NUD) [RFC4861] 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
  signaled of the unreachability problem.  However, as discussed in
  Section 2.2, standard TCP implementations will not abort connections
  when receiving ICMP error messages that indicate soft errors.

Clarity. This is somewhat misleading. When the node has no default
routers it also has no prefixes, no global addresses and it will not
even try to use IPv6 towards other global addresses. That is not a soft
error situation as described by this document.

[Ballot discuss]
I have not seen a response to the comments in the SecDir Review
  by Sandy Murphy posted on 15-07-2007.  The comments deserve a
  response, even if the discussion does not result in any changes
  to the document.

draft-ietf-tcpm-tcp-soft-errors-08.txt
>
>>  (1.a)  Who is the Document Shepherd for this document?  Has the
>>          Document Shepherd personally reviewed this version of
>>          the document and, in particular, does he or she believe
>>          this version is ready for forwarding to the IESG for
>>          publication?
>
> Mark Allman (mallman@icir.org) (TCPM co-chair)
>
> I have read the document and believe it is ready for publication.
>
>>  (1.b)  Has the document had adequate review both from key WG 
>> members
>>          and from key non-WG members?  Does the Document Shepherd 
>> have
>>          any concerns about the depth or breadth of the reviews that
>>          have been performed?
>
> The document has enjoyed much review from the TCPM WG.
>
>>  (1.c)  Does the Document Shepherd have concerns that the document
>>          needs more review from a particular or broader perspective,
>>          e.g., security, operational complexity, someone familiar 
>> with
>>          AAA, internationalization or XML?
>
> No concerns.
>
>>  (1.d)  Does the Document Shepherd have any specific concerns or
>>          issues with this document that the Responsible Area Director
>>          and/or the IESG should be aware of?  For example, perhaps he
>>          or she is uncomfortable with certain parts of the 
>> document, or
>>          has concerns whether there really is a need for it.  In any
>>          event, if the WG has discussed those issues and has 
>> indicated
>>          that it still wishes to advance the document, detail those
>>          concerns here.  Has an IPR disclosure related to this 
>> document
>>          been filed?  If so, please include a reference to the
>>          disclosure and summarize the WG discussion and conclusion on
>>          this issue.
>
> This document involves no IPR disclosure.
>
> The document shepherd has no specific concerns about the document.
>
>>  (1.e)  How solid is the WG consensus behind this document?  Does it
>>          represent the strong concurrence of a few individuals, with
>>          others being silent, or does the WG as a whole understand 
>> and
>>          agree with it?
>
> The WG consensus on this document is broad and solid.
>
>>  (1.f)  Has anyone threatened an appeal or otherwise indicated 
>> extreme
>>          discontent?  If so, please summarise the areas of conflict 
>> in
>>          separate email messages to the Responsible Area Director. 
>> (It
>>          should be in a separate email because this questionnaire is
>>          entered into the ID Tracker.)
>
> We are aware of no reasons this document would be appealed or anyone
> who is overly unhappy with it.
>
> The biggest bone of contention about this draft was that, while
> aiming for informational status, initially was quite prescriptive in
> its language.  The language now is not prescriptive, but rather
> simply documents the behavior of some popular TCP stacks.
>
>>  (1.g)  Has the Document Shepherd personally verified that the
>>          document satisfies all ID nits?  (See
>>          http://www.ietf.org/ID-Checklist.html and
>>          http://tools.ietf.org/tools/idnits/).  Boilerplate checks 
>> are
>>          not enough; this check needs to be thorough.  Has the 
>> document
>>          met all formal review criteria it needs to, such as the MIB
>>          Doctor, media type and URI type reviews?
>
> This document does not need MIB or URI reviews.
>
> The document passes 'idnits'.
>
>>  (1.h)  Has the document split its references into normative and
>>          informative?  Are there normative references to documents 
>> that
>>          are not ready for advancement or are otherwise in an unclear
>>          state?  If such normative references exist, what is the
>>          strategy for their completion?  Are there normative 
>> references
>>          that are downward references, as described in [RFC3967]?  If
>>          so, list these downward references to support the Area
>>          Director in the Last Call procedure for them [RFC3967].
>
> The references have been split into 'normative' and 'non-normative'.
>
> The normative references are all published RFCs.
>
>>  (1.i)  Has the Document Shepherd verified that the document IANA
>>          consideration section exists and is consistent with the body
>>          of the document?  If the document specifies protocol
>>          extensions, are reservations requested in appropriate IANA
>>          registries?  Are the IANA registries clearly identified?  If
>>          the document creates a new registry, does it define the
>>          proposed initial contents of the registry and an allocation
>>          procedure for future registrations?  Does it suggest a
>>          reasonable name for the new registry?  See [RFC2434].  If 
>> the
>>          document describes an Expert Review process has Shepherd
>>          conferred with the Responsible Area Director so that the 
>> IESG
>>          can appoint the needed Expert during the IESG Evaluation?
>
> The document has an IANA considerations section that correctly notes
> that no IANA work is needed.
>
>>  (1.j)  Has the Document Shepherd verified that sections of the
>>          document that are written in a formal language, such as XML
>>          code, BNF rules, MIB definitions, etc., validate correctly 
>> in
>>          an automated checker?
>
> N/A
>
>>  (1.k)  The IESG approval announcement includes a Document
>>          Announcement Write-Up.  Please provide such a Document
>>          Announcement Write-Up?  Recent examples can be found in the
>>          "Action" announcements for approved documents.  The approval
>>          announcement contains the following sections:
>>
>>          Technical Summary
>>            Relevant content can frequently be found in the abstract
>>            and/or introduction of the document.  If not, this may be
>>            an indication that there are deficiencies in the abstract
>>            or introduction.
>>
>>          Working Group Summary
>>            Was there anything in WG process that is worth noting? 
>> For
>>            example, was there controversy about particular points or
>>            were there decisions where the consensus was particularly
>>            rough?
>>
>>          Document Quality
>>            Are there existing implementations of the protocol? 
>> Have a
>>            significant number of vendors indicated their plan to
>>            implement the specification?  Are there any reviewers 
>> that
>>            merit special mention as having done a thorough review,
>>            e.g., one that resulted in important changes or a
>>            conclusion that the document had no substantive 
>> issues?  If
>>            there was a MIB Doctor, Media Type or other expert 
>> review,
>>            what was its course (briefly)?  In the case of a Media 
>> Type
>>            review, on what date was the request posted?
>
> Technical Summary:
>
>    The TCP specification calls for calls for ICMP soft errors to be
>    treated as transient and therefore TCP connections will not
>    abort in response to such messages.  A widely implemented
>    departure from the specification has TCP stacks treating such
>    soft errors as hard errors and aborting connections during
>    connection establishment.
>
> Working Group Summary
>
>    The WG could not arrive at consensus for changing the TCP
>    specification to allow ICMP soft errors to be treated as hard
>    errors during connection establishment.  However, this change is
>    widely implemented.  This document describes the change in an
>    informational way.
>
> Document Quality
>
>    The document was reviewed for quality by a large number of TCPM
>    WG members.