Re: [ippm] Erik Kline's Discuss on draft-ietf-ippm-ioam-ipv6-options-09: (with DISCUSS and COMMENT)

[Erik Kline <[e-mail]>]

I reviewed what approach SRH took w.r.t. AH.  It might suffice if this
document added a section like RFC 8754 S7.5, but I'm not sure yet.
Something to think about, though...

On Wed, Nov 30, 2022 at 10:02 PM Erik Kline via Datatracker
<[e-mail]> wrote:
>
> Erik Kline has entered the following ballot position for
> draft-ietf-ippm-ioam-ipv6-options-09: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> # Internet AD comments for draft-ietf-ippm-ioam-ipv6-options-09
> CC @ekline
>
> * Thanks to 6MAN chairs Bob, Ole, and Jen for their last-minute
>   "IPv6 Directorate" reviews.  Some of their comments are reflected below.
>
> * There was kind of leaning toward concluding that the rewriting of a
>   Hop-by-Hop option's size was both against the spirit of RFC 8200 and
>   not actually against the letter.  I'm not sure that's actually the case
>   and so my biggest DISCUSS is this point (more below).
>
> ## Discuss
>
> ### S4
>
> * I don't think the Incremental Trace Option is something that can be
>   supported by current text in RFC 8200.  While is makes sense to have this
>   behavior described in RFC 9197, I don't think IPv6 HbH can support it.
>
>   My rationale for seeing this as a protocol violation is as follows.
>
>     - RFC 8200 S4.2 says this about the on-path mutability bit and the
>       expectations that result:
>
>       """
>       The third-highest-order bit of the Option Type specifies whether or
>       not the Option Data of that option can change en route to the
>       packet's final destination.  When an Authentication header is present
>       in the packet, for any option whose data may change en route, its
>       entire Option Data field must be treated as zero-valued octets when
>       computing or verifying the packet's authenticating value.
>       """
>
>     - Specifically, only the Option Data (not Option Length) is allowed to
>       change.  Any AH header, for example, would still have processed the
>       entire option with only the Data being zeroed -- the existence of the
>       option and the length of it would still have been part of the AH
>       computation.
>
>   Unless there's some misunderstanding here I think this option would need
>   removing from the document.
>
> * I think text needs to be added to make it clear that whatever options are
>   used they MUST be added, though not necessarily "filled in", by the
>   originator of the packet (the node bearing the interface assigned the
>   outermost Source Address).
>
>   The reasoning here again is the defined behavior of AH processing.  Any
>   options, even on-path mutable ones, MUST be present in the Hop-by-Hop
>   option when an AH is computed.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## Comments
>
> ### S5.1
>
> * In C2: "domain SHOULD ensure that the addition of OAM information does not
>   lead to fragmentation of the packet"
>
>   This should probably be rephrased to be more IPv6-compatible (as there is
>   no on-path fragmentation).  Perhaps:
>
>   "does not lead to an ICMP Packet To Big error message being sent to the
>   originator and the packet being dropped"
>
>   or something to that effect.
>
> * Also in C2: "exceeds the packet size beyond PTMU" in the domain, etc.
>
>   It may be worth noting that any single node can only know the configured
>   MTU of its outgoing links, and that this is why it MUST be a domain-managed
>   parameter.
>
> * C3 appears to create a requirement for some very deep packet inspection on
>   IOAM domain egress.
>
>   Also, if there's going to be talk of ICMPv6 you probably need to add a
>   reference to RFC 4443.
>
> * With respect to C4, I'd defer to the other IESG comments.
>
> * C5: this seems like it might be important for a Standards Track feature?
>
>   If it were Experimental, perhaps, then there could be text saying that
>   learning how this might best be done was an expected outcome of the
>   experiment?
>
>
>