Spring Appeal and [Errata Rejected] RFC8200 (6003)

Fernando Gont <fgont@si6networks.com> Fri, 15 May 2020 03:12 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3923A07C5; Thu, 14 May 2020 20:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YddZNy-kpGu2; Thu, 14 May 2020 20:12:13 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C73C3A07C2; Thu, 14 May 2020 20:12:12 -0700 (PDT)
Received: from [192.168.0.10] (unknown [181.45.84.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CC1A3283745; Fri, 15 May 2020 03:12:04 +0000 (UTC)
Subject: Spring Appeal and [Errata Rejected] RFC8200 (6003)
To: ek.ietf@gmail.com
Cc: bob.hinden@gmail.com, iesg@ietf.org, ipv6@ietf.org
References: <20200510184112.9643EF406D6@rfc-editor.org>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <030874d9-28f5-48da-befb-f0a210c51347@si6networks.com>
Date: Fri, 15 May 2020 00:11:54 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200510184112.9643EF406D6@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2CCuZ4t3scWE3bWMJI0rkT2lCqg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 03:12:19 -0000

On 10/5/20 15:41, RFC Errata System wrote:
[....]
> --VERIFIER NOTES-- Section
> 3 clearly highlights for the reader when the IPv6 Destination Address
> in the header might differ from the IPv6 address of the ultimate
> destination.
> 
> As such, all references in the document to "Destination Address"
> lacking further qualifying text should be read bearing this in mind.
> The text in section 4 is no exception.  The key text has remained
> unchanged since RFC 1883.

As noted by Jinmei in 
<https://mailarchive.ietf.org/arch/msg/ipv6/pB5dcr9FBV4vgziWop0kjGLseRU/>, 
this argument is incorrect.

Particularly in the light that it may also affect the discussion 
associated with an Appeal that is currently being processed by the IESG, 
I believe this should be revised.


Please let me elaborate on my claim:

IPv6 has always forbidden en-route insertion and removal of IPv6 EHs. 
RFC2460 contains this text (very similar to what's in its predecessor 
RFC1883):

    With one exception, extension headers are not examined or processed
    by any node along a packet's delivery path, until the packet reaches
    the node (or each of the set of nodes, in the case of multicast)
    identified in the Destination Address field of the IPv6 header.
    There, normal demultiplexing on the Next Header field of the IPv6
    header invokes the module to process the first extension header, or
    the upper-layer header if no extension header is present.  The
    contents and semantics of each extension header determine whether or
    not to proceed to the next header.
  [....]
    The exception referred to in the preceding paragraph is the Hop-by-
    Hop Options header, which carries information that must be examined
    and processed by every node along a packet's delivery path, including
    the source and destination nodes.

The text highlights that HBH options are processed by every node on the 
path, and that other EHs are only processed when the packet reaches the 
address in the "Destination Address" field. Indeed, RHs are processed 
when the packets get to such destination address, and other EHs and 
upper layer protocols are processed when the packet reaches the 
Destination Address. For packets that employ a RH, these later EHs and 
upper layer protocols will get processed by the node(s) identified in 
the Destination Address when Segments Left==0 -- that is, by the final 
destination.

In the same timeframe that the rfc2460bis effort (that eventually lead 
to RFC8200) was being pursued, an individual internet-draft 
(draft-previdi-6man-segment-routing-header) was proposing to perform 
en-route header insertion/removal. When this later draft appeared in the 
radar of 6man participants, there were many objections to such proposal, 
as it was violating existing standards.

The proponents of draft-previdi-6man-segment-routing-header argued that 
RFC2460 didn't explicitly forbid en-route EH-insertion/removal, and 
hence their proposal was not violating any specifications. Some of them 
claimed that the use of the term "processing" was ambiguous.

While it was clear to the vast majority of the 6man wg that the IPv6 
architecture and the ipv6 specification didn't allow for EH 
insertion/removal, participants felt that, since the rfc2460bis effort 
was ongoing, rfc2460bis should take the chance to be crystal clear on 
this point, to avoid possible future claims that such behavior was allowed.

While the document was still in the 6man wg, the proponents of 
draft-previdi-6man-segment-routing-header resisted any clarifications in 
this respect (please see 
<https://mailarchive.ietf.org/arch/msg/ietf/j1O11x4ICMUWGJmzlJfCx0y0-c8/>), 
and hence 6man shippoed for publication a version of the document that 
didn't spell out the prohibition of en-route EH insertion/removal.

During the IETF LC for the document, there was a strong push to have 
rfc2460bis be explicit about the prohibition of en-route 
insertion/removal of extension headers, and some subset of the 
participants crafted the text that eventually made it into RFC8200. 
Essentially, they spelled out all the prohibited actions, as explicitly 
sa possible, and added them along the existing text. The resulting text was:

    Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header.


While the intent was to be more explicit about the things that were 
prohibited, the addition of these extra terms alongside the existing 
text ended up introducing a bug in the specification since, af crafted, 
the text suggests that nodes that get to process EHs also get to e.g. 
insert and remove EHs.  This is why I consider this a bug, and why I've 
submitted Erratum 6003 on RFC8200.


RFC8200 contains, in Appendix B, a summary of the changes from RFC2460, 
and notes that:

    o  Clarified that extension headers (except for the Hop-by-Hop
       Options header) are not processed, inserted, or deleted by any
       node along a packet's delivery path.

This spells out the intent of the corresponding text. 
draft-ietf-6man-rfc2460bis-13 (the last internet-draft version of 
RFC8200), it spells out the intent of the specification with even more 
detail:

       01)  Added text that Extension headers must never be inserted by
            any node other than the source of the packet.

Finally, draft-ietf-6man-rfc2460bis-08, the document that was shipped by 
the 6man wg to the IESG for publication, was indeed very explicit about 
the serious problems with en-route insertion/removal of EHs:

    The insertion of Extension Headers by any node other than the source
    of the packet causes serious problems.  Two examples include breaking
    the integrity checks provided by the Authentication Header Integrity
    [RFC4302], and breaking Path MTU Discovery which can result in ICMP
    error messages being sent to the source of the packet that did not
    insert the header, rather than the node that inserted the header.

This very same problems are caused when the node inserting or removing 
EHs is a node listed in an RH.

It is also worth noting that RFC8200 elevated the status of IPv6 to 
"Internet Standard". Since RFC2460 by no means allows for en-route 
header insertion/removal/deletion, the incorporation of this "feature" 
in RFC8200 would have prevented the elevation of IPv6 to Internet 
Standard. This is yet another indication that Erratum 6003 refers to a 
bug in the specification, as opposed to an intended protocol behavior 
that would be a change from the preceding revision of the standard, RFC2460.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492