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

["Frank Brockners (fbrockne)" <[e-mail]>]

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