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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

Section 4 and RFC9197 seem clear that IOAM traffic cannot leave the IOAM
domain.  However, this document seems to be suggesting behavior that violates
this guidance.  Specifically, in Section 5.1, it allows for the possibility of
leaks per (a) and explicitly describe a use case where leaks are intentional
(b).

(a) Section 5.1.  C3.
      IOAM domains MUST
      provide a mechanism to prevent data leaks or be able to ensure
      that if a leak occurs, network elements outside the domain are not
      affected (i.e., they continue to process other valid packets).

(b) Section 5.1. C5.
      An Autonomous System (AS) that inserts and leaks the IOAM data
      needs to be easy to identify for the purpose of troubleshooting,...

Furthermore, per (a), why are “IOAM domains … provid[ing] a mechanism” which
suggests a feature rather than a required to explicitly prevent this behavior.


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

** Section 4.
   As
   additional security, IOAM domains MUST provide a mechanism to prevent
   unauthorized injections at ingress or leaks at egress.

No disagreement.  To clarify, is this a new requirement? I thought this
configuration was the mandatory architecture of IOAM.  Per RFC9197:

   Notably, IOAM is expected to be deployed in limited domains, thus
   confining the potential attack vectors to within the limited domain.
   A limited administrative domain provides the operator with the means
   to select, monitor, and control the access of all the network
   devices, making these devices trusted by the operator.  Indeed, in
   order to limit the scope of threats mentioned above to within the
   current limited domain, the network operator is expected to enforce
   policies that prevent IOAM traffic from leaking outside of the IOAM-
   Domain and prevent IOAM data from outside the domain to be processed
   and used within the domain.

** Section 4.  Please be explicit on where the Option Data is specified.  I
believe it is:

-- For the “Pre-allocated Traction Option” and “Incremental Trace Option”,
Section 4.4 of RFC9197

-- For the “Proof of Transition Option”, Section 4.5 of RFC9197

-- For the “Edge to Edge Option”, Section 4.6 of RFC9197

-- For the “Direct Export Option” Section 3.2 of RFC9326

** Section 5.1.  C3.
      Packets with IOAM data or associated ICMP errors, should not
      arrive at destinations that have no knowledge of IOAM.  For
      example, if IOAM is used in in transit devices, misleading ICMP
      errors due to addition and/or presence of OAM data in a packet
      could confuse the host that sent the packet if it did not insert
      the OAM information.

Is the expectation that any entity which adds IOAM headers (either at the
source or in transit) will know if a destination in the IOAM domain supports
these headers?  If so, is that realistic (not knowing where this is currently,
or anticipated to be, fielded)?.

** Section 5.1.  C3.

      The entities that communicate the errors to
      devices outside of the IOAM domain MUST remove any IOAM data from
      the packet included in the error message.

The completeness of this guidance seems to depend on how one reads “the
entities that communicate the error” – is it the IOAM hosts or also the network
devices at the edge of the IOAM domain.  I took it to mean hosts per the
deployment model defined in Section 5.2. (IOAM domains bounded by hosts) which
would be insufficient.  Could this text please be made clearer to cover the
deployment models described in 5.2 and 5.3.

Editorial

** Section 4.  Typo. s/inSection 7/in Section 7/