[ippm] Warren Kumari's Abstain on draft-ietf-ippm-ioam-ipv6-options-09: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-ippm-ioam-ipv6-options-09: Abstain

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I spent a while oscillating between DISCUSS and NoObjection when balloting on
this document, before finally settling on Abstain (a non-blocking position).

Like others, I have concerns about what happens when IOAM EH packets invariably
leak outside the IOAM domain. My views align very strongly with John Scudder's,
but seeing as he is already carrying the DISCUSS, I'm going to cowardly abstain
and hide behind him.

The document feels like it is creating something very similar to a "limited
domain"; the reason that I'm not balloting DISCUSS is that the document "feels"
like it is trying to minimize the damage when IOAM packets do leak. This
includes "failing closed" ('IOAM MUST be explicitly enabled per interface on
every node within the IOAM domain'). I am, however, quite troubled by the "As
additional security, IOAM domains MUST provide a mechanism to prevent
unauthorized injections at ingress or leaks at egress." without actually
stating how this would be performed.

The fact that the IOAM data is information (it doesn't obfuscate the source of
the traffic, nor (hopefully!) change routing / forwarding) also helps push this
from DISCUSS to Abstain for me - when a domain *does* leak packets with IOAM
info, they will either exceed the MTU and so be dropped, or will "just" be
leaking traffic stats from that domain, and should otherwise be forwarded OK.

There are some Considerations in Sec 5 which I think are unrealistic, but not
harmful - for example: * I suspect that in some cases adding IOAM will change
ECMP hashing (C1); * they *will* leak (C3), but this shouldn't break things; *
they *will* leak (C4), but I suspect that external devices will simply ignore
the EH header;

I have a horrible feeling that I'm being inconsistent with my balloting:
normally I would ballot DISCUSS on documents which either add information to an
in-flight packet, or which create any sort of closed domain, but in this case I
feel that the document has sufficiently attempted to mitigate the (external)
consequences of leaks that I'm choosing Abstain instead.