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

One minor correction: the Direct Export draft has, in fact, been adopted by
IPPM: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/

On Wed, Mar 24, 2021 at 8:06 AM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> 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/
>
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>