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

[Martin Duke <[e-mail]>]

Ping

On Fri, Mar 17, 2023, 09:54 Martin Duke <[e-mail]> wrote:

> 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?
>> > >
>> > >
>> > >
>>
>