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

[Martin Duke <[e-mail]>]

Erik, does the latest version of this draft address your DISCUSS?

On Fri, Dec 30, 2022 at 6:42 AM Frank Brockners (fbrockne) <fbrockne=
[e-mail]> wrote:

> Hi Erik,
>
> Thanks a lot for your review. Please see inline.
>
> > -----Original Message-----
> > From: Erik Kline <[e-mail]>
> > Sent: Thursday, 1 December 2022 07:36
> > To: Erik Kline <[e-mail]>
> > Cc: The IESG <[e-mail]>; [e-mail]
> ;
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Re: Erik Kline's Discuss on
> draft-ietf-ippm-ioam-ipv6-options-09: (with
> > DISCUSS and COMMENT)
> >
> > 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...
>
> ...FB: SRv6 and IOAM are indeed similar in their deployment focus. The
> both operate in limited domains (per RFC8799). And much like you, IMHO the
> approach would solve the issue with AH.
>
> Following your suggestion, we could add a section to
> draft-ietf-ippm-ioam-ipv6-options similar to RFC 8754 S7.5 that explains
> that due to IOAM's focus on limited domains only, IOAM only applies to
> deployments which do not use the Authentication Header. Operators who
> desire to protect the integrity of IOAM data, could leverage
> draft-ietf-ippm-ioam-data-integrity.
> Is this approach generally agreeable? If so we'll add it to the next
> revision.
>
> In addition, I fully agree to your note about clarifying that the IOAM
> encapsulating node MUST add the entire IPv6 option data - including fields
> that are supposed to be updated by other nodes.
>
> And a side note: Dropping support for the "incremental trace option" for
> IPv6 could be done of course, but would be really unfortunate, because we
> limit the applicability of IOAM. The option was created to help with
> efficient hardware implementations of IOAM. For hardware it is much easier
> to write to a fixed location in the packet (along with splitting and
> re-joining the parts) rather than do a pointer lookup of where to insert
> the data and then fill in the data. BTW - Below you state that
> "Specifically, only the Option Data (not Option Length) is allowed to
> change": Could you point me to the paragraph in  RFC 8200 that forbids the
> change in length? I did not find any text to that regard.
>
> Thanks, Frank
>
>
> >
> > 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-posi
> > > tions/ 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?
> > >
> > >
> > >
>