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

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

Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-ioam-data-12: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please clarify what constitutes the edge or boundary of the IOAM domain. 
Consider:

(a) Section 4.
IOAM is a
   network domain focused feature, with "network domain" being a set of
   network devices or entities within a single administration.
…
Designers of
   protocol encapsulations for IOAM specify mechanisms to ensure that
   IOAM data stays within an IOAM domain.  In addition, the operator of
   such a domain is expected to put provisions in place to ensure that
   IOAM data does not leak beyond the edge of an IOAM domain.

(b) Section 5.3.
Namespace identifiers allow devices which are IOAM capable to
   determine: …
whether IOAM-Option-Type(s) has to be removed from the packet,
      e.g. at a domain edge or domain boundary.

(a) suggests that the filtering occurs on the basis of the single
administrative domain.  However, (b) suggests that namespace identifiers are
part of the filtering decision; which suggests that sub-domains can be created
in a given domain which should be partitioned from each other.

The Security Considerations should be clearer on who does the IOAM information
filtering, on what criteria and on what boundary.


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

Thank you to Shawn Emery for the SECDIR review.

I support Ben Kaduk’s DISCUSS position.

** Section 4.  Per the scope of “IOAM is a network domain focused feature, with
‘network domain’ being a set of network devices or entities within a single
administration” and the implicit trust model, the more precise text seems to be
a s/a set of network devices/a set of trusted network devices/.

** Section 10.  To the end of the first paragraph, “All nodes in the path of a
IOAM carrying packet can perform such an attack”.

** Section 10.  It is not clear why the "Direct Exporting" mode, a reference an
unadopted I-D, is being referenced here and then consideration for it is noted
as out of scope.

** Section 10
   At the management plane, attacks can be set up by misconfiguring or
   by maliciously configuring IOAM-enabled nodes in a way that enables
   other attacks.  Thus, IOAM configuration has to be secured in a way
   that authenticates authorized users and verifies the integrity of
   configuration procedures.

The link to authenticating authorized users isn’t clear.  Perhaps the intent of
the second sentence is that configurations should only managed by authorized
processes or users?

** Section 10.  Please note that IOAM fields could introduce the possibility of
a per-packet cover channel

** Editorial nits:
Section 4. Typo. s/using,for/using, for/

Section 10.  Editorial. s/Section Section 5.5/Section 5.5/