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

[Martin Duke <[e-mail]>]

I guess the question is whether the ops draft should be a normative
reference?

On Mon, Apr 26, 2021 at 8:38 AM Frank Brockners (fbrockne) <fbrockne=
[e-mail]> wrote:

> Hi Roman,
>
> Thanks a lot for your review - and sorry for the delay in responding.
> Please see inline ("..FB").
>
> > -----Original Message-----
> > From: Roman Danyliw via Datatracker <[e-mail]>
> > Sent: Mittwoch, 24. März 2021 16:06
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> [e-mail];
> > Al Morton <[e-mail]>; [e-mail]
> > Subject: Roman Danyliw's Discuss on draft-ietf-ippm-ioam-data-12: (with
> > DISCUSS and COMMENT)
> >
> > 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.
>
>
> ...FB: Eric already suggested in his review that we refer to RFC 8799 and
> an IOAM domain classifies as a "Limited Domain" per RFC 8799, which we plan
> to do for the next revision.
> And per your comment, namespaces can indeed be used for further
> segmentation of the single administrative domain.
>
> Given that draft-ietf-ippm-ioam-data is focused on the definition of
> data-fields, we created a "sister" document, which is to discuss all
> deployment related aspects of IOAM: draft-brockners-opsawg-ioam-deployment
> (we're working on an updated version as we speak). Domains and nodes are
> discussed in section 3, see
> https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-02#section-3.
> With regards to filtering at the edge of the administrative domain,
> draft-brockners-opsawg-ioam-deployment states the following
>
>    The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating
>    node is always performed within a specific IOAM-Namespace.  This
>    means that an IOAM node which is e.g. an IOAM-decapsulating node for
>    IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove
>    the IOAM-Option-Types for IOAM-Namespace "A" from the packet.  An
>    IOAM decapsulating node situated at the edge of an IOAM domain
>    removes all IOAM-Option-Types and associated encapsulation headers
>    for all IOAM-Namespaces from the packet.
>
> Does this clarify things? And if so, are you ok to keep "data fields
> definition" and "deployment aspects" separated in the two different
> documents? Otherwise, we would need to create redundancies between the
> documents, which are a bit hard to keep in synch.
>
> >
> >
> > ----------------------------------------------------------------------
> > 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/.
>
> ...FB: Thanks. We'll include the update in the next revision.
>
> >
> > ** Section 10.  To the end of the first paragraph, “All nodes in the
> path of a
> > IOAM carrying packet can perform such an attack”.
>
>
> ...FB: Thanks. We'll include this addition in the next revision.
>
> >
> > ** 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.
>
> ...FB: The reference to "direct exporting" draft is outdated. Sorry. The
> draft is already WG adopted in IPPM:
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-direct-export-03
>
> >
> > ** 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?
>
> ....FB: The sentence indeed sounds a bit confusing and is difficult to
> decode. It is to say exactly what you describe.
> Suggest that we update to "IOAM configurations should only managed by
> authorized processes or users" in the next revision.
>
> >
> > ** Section 10.  Please note that IOAM fields could introduce the
> possibility of a
> > per-packet cover channel[] .
>
> ...FB: Good point. We'll add this to the next revision.
>
> >
> > ** Editorial nits:
> > Section 4. Typo. s/using,for/using, for/
> >
> > Section 10.  Editorial. s/Section Section 5.5/Section 5.5/
> >
>
> ...FB: Thanks. Good catches.
>
> Thanks again for your review, Frank
>
>