Re: [ippm] Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)

[Tianran Zhou <[e-mail]>]

Hi Roman,
Thanks for your comments. Please see inline.

Best,
Tianran

-----Original Message-----
From: Roman Danyliw via Datatracker [mailto:[e-mail]] 
Sent: Tuesday, February 27, 2024 4:35 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Roman Danyliw's No Objection on draft-ietf-ippm-ioam-yang-11: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-ippm-ioam-yang-11: No Objection

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-yang/



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

Section 3.5.  Editorial
   The "pot-profile" contains
   the detailed information for the proof of transit data.

Wouldn’t it be more accurate to say “The ‘pot-profile is intended to contain
the detailed information …”.  As defined now, it contains no details.

ZTR> Agreed. Thanks.

** Section 5
   /ioam/ioam-profiles/ioam-profile

   The entries in the list above include the whole IOAM profile
   configurations which indirectly create or modify the device
   configurations.  Unexpected changes to these entries could lead to
   the mistake of the IOAM behavior for the corresponding flows.

Since this section is discussing Security Considerations, what are the security
consequences of “mistake[n] … IOAM behavior”?  Is any of the scope of the
Security Considerations of RFC9197 relevant?

ZTR> I just read about RFC9197. I think the security considerations cover the management attack.
Specifically, "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.  IOAM configuration should only be managed by
   authorized processes or users."
I can also add some content about the consequences of the mistake behavior.

**Section 5.  This text has no discussion of sensitivities to reading this YANG
modules?  Is there any risk in a completely readable version of this YANG
module?

ZTR> Yes. The readable information might give information about the underlying network as well as services deployed for the customers.  For instance, a customer might be given access to monitor their services status.  In that example, the customer access should be restricted to nodes representing their services so as not to divulge information about the underlying network structure or others customers services.