Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Fernando Gont <[e-mail]>]

On 23/9/20 21:22, Erik Kline wrote:
>     (5) This point is for the IESG to discuss.
> 
>     §4.16.1.2 <http://4.16.1.2>:
> 
>            The End, End.X and End.T behaviors with PSP do not contravene
>            Section 4 of [RFC8200] because the destination address of the
>            incoming packet is the address of the node executing the
>     behavior.
> 
>     The spring WG's interpretation of rfc8200 was a central point in the
>     appeal
>     presented against the WG consensus on this document.  The text above, I
>     believe, reflects that consensus.
> 
>     However, given that the document relies on the spring WG's
>     interpretation of
>     rfc8200, I think it would be better if the text is explicit.
> 
>     Suggestion: to add at the end of the paragraph>
> 
>         This conclusion represents the consensus interpretation of the
>     spring WG.
> 
> 
> This seems like an important -- and entirely reasonable -- thing to note.

FWIW, one would expect that, if anything, if a matter is subject to 
interpretation, it would be for the group that published the spec or the 
IETF as a whole to discuss the topic.

I did my share of reading on how the text in RFC8200 ended up being what 
it currently is and, if anything, one may say the text is far from 
perfect -- but the interpretation that this document is making seems to 
go against the IPv6 architecture, and even contradict the text from 
previous revisions of the IPv6 specification (before we made the 
relevant text sloppy in RFC8200).

Namely:

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, as 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.


As per the above, it would seem to me that before a Spring documents 
makes any arbitrary interpretation of RFC8200 that happens to represent 
a change to the IPv6 Architecture, 6man should clarify the topic, and if 
the IPv6 architecture is to be changed, the IETF as a whole should be 
involved (since that would probably be even out of the scope of 6man).

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1