Re: Errata #5933 for RFC8200

Hi Fernando, Suresh,

On Fri, 28 Feb 2020 at 07:08, Fernando Gont <fgont@si6networks.com> wrote:
>
> Suresh,
>
> Two months ago I filled an errata on RFC8200 regarding the processing of
> IPv6 extension headers. The errata is available here:
> https://www.rfc-editor.org/errata/eid5933
>
> While I believe that folks with a knowledge of Internet Protocols would
> be able to interpret what is in RFC8200, given recent discussions on the
> topic, and upon a re-read of the text, I believe a clarification is
> warranted, such that we allow all sorts of curious interpretations of
> the text.
>
> I send a heads-up on the 6man mailing list
> (https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c/),
> and the proposed text received the review of at least Brian Carpenter,
> Ron Bonica, and Mark Smith. Their reviews are available on such thread.
>
> In the light that some folks seem to be pretending to leverage "the lack
> of clarify" in RFC8200 (an Internet Standard) to violate it, I'd
> appreciate that the reported errata be processed.
>
> Processing the aforementioned errata is key to many of the discussions
> this and other WGs are having.
>

I think this text in the RH section also needs to be updated:

"The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   +*final* destination.  This function is very similar to IPv4's Loose Source
   and Record Route option."

I think this text may also further support which type of destination
is being referred to by the earlier EH text that Fernando is proposing
to clarify:

"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."

If this text is implicitly saying that an operation at all is
permitted on EHs when the packet is at the device holding the packet's
DA, intermediate or final in the case of a Routing Header, then I
think it is also saying, due to the "(or each of the set of nodes, in
the case of multicast)" text, that intermediate DAs in an RH can be
multicast addresses.

Would it ever be useful or valid to have an RH that is listing
multicast addresses as the intermediate DAs for the packet to visit?

I think that would also mean that at those intermediate multicast DAs,
if there are downstream interested listeners, the packet would be
duplicated per multicast operations. Are there any applications for
that sort of thing? I think it is a possible packet amplification
attack vector (two intermediate multicast node addresses that point
towards each other could create an amplification loop I think).

If we came to the conclusion that it is impossible or too dangerous
for RH intermediate node DAs to be multicast addresses, and that
intermediate node addresses must be unicast addresses, then I think
that then further clarifies and supports that the earlier EH text -
"Extension headers [...] are not processed, inserted, or deleted [...]
identified in the Destination Address field of the IPv6 header." - is
only referring to the final destination address, not intermediate ones
in an RH, because only final DAs can be multicast addresses.

It might sound a bit like clutching at straws, however the RH text is
unambiguous about intermediate verses final node DAs, and that clarity
helps clarify what type of DA is being referred to in the earlier EH
no insertion, deletion etc. text.

Regards,
Mark.

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------