Re: [netconf] Roman Danyliw's Discuss on draft-ietf-netconf-notification-capabilities-18: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Balázs!

Thanks for the changes in -20 and your explanations below.  This new text addresses my concerns so I've cleared my ballot.  Minor comments inline ...

> -----Original Message-----
> From: Balázs Lengyel <[e-mail]>
> Sent: Wednesday, October 6, 2021 1:27 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; Benoit Claise
> <[e-mail]>
> Cc: [e-mail]; netconf-
> [e-mail]; [e-mail]; Kent Watsen <[e-mail]>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netconf-notification-
> capabilities-18: (with DISCUSS and COMMENT)
> 
> Hello Danyliw,
> Thank you for the review. We will use your comments to improve the draft, but
> I am not sure we understood some of your comments. See detailed answers
> below marked as BALAZS.
> Regards Balazs
> 
> -----Original Message-----
> From: Roman Danyliw via Datatracker <[e-mail]>
> Sent: 2021. október 6., szerda 16:47
> To: The IESG <[e-mail]>
> Cc: [e-mail]; netconf-
> [e-mail]; [e-mail]; Kent Watsen <[e-mail]>;
> [e-mail]
> Subject: Roman Danyliw's Discuss on draft-ietf-netconf-notification-
> capabilities-18: (with DISCUSS and COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-netconf-notification-capabilities-18: 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/blog/handling-iesg-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-netconf-notification-capabilities/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The text contains contradictions on how to handle implementation-time use
> case that might use the YANG file format.
> 
> (a) Section 2. “The file MUST be available already at implementation time,
> retrievable in a way that does not depend on a live network node.  E.g.,
> download from product website.”
> 
> (b) Section 2. “The YANG modules specified in this document define a schema
> for data that is designed to be accessed via network management protocols
> such as NETCONF [RFC6241] or RESTCONF [RFC8040].  … The Network
> Configuration Access Control Model (NACM) [RFC8341] provides the means to
> restrict access for particular NETCONF or RESTCONF users”
> 
> (c) Section 2.  “When that data is in file format, data should be protected
> against modification or unauthorized access using normal file handling
> mechanisms.”
> 
> (a) – (c) cannot all be satisfied at the same time.  (b) seems to only apply to the
> run-time use cases.  (a) and (b) seem to apply to the implementation time use
> cases.  Please make this clearer.
> 
> Per (c), it might be clearer to keep this text, but also noting that using the
> YANG file format inherits all of the security considerations of draft-ietf-netmod-
> yang-instance-file-format which has additional considerations about read
> protections; and distinguishes between data at rest and in motion.
> 
> BALAZS:
> About (a) – (c):  Why can't (a) and (c) be satisfied at the same time ? (a) states
> that the information should be available in a file. (c) states that the file must be
> protected. What is the problem? Please explain.

We are in agreement (a)+(c) are consistent; it's (a)+(c) vs. (b) that I meant specifically as you noted below.

> About (b) OK.  We will extend section 6 first sentence:
> The YANG modules specified in this document define a schema for data   that is
> designed to be accessed via network management protocols such as NETCONF
> [RFC6241] or RESTCONF [RFC8040]
> + or as YANG instance data.

That works for me.

> The modify section 6 last paragraph to:
> When that data is in file format, data should be protected against
>    modification or unauthorized access using normal file handling
> +   mechanisms.
> +  The data in file format also inherits all the security
> +  considerations of [draft-ietf-netmod-yang-instance-file-format] which
> +  has additional considerations about read protections; and distinguishes
> +  between data at rest and in motion.
> 
> (a) and (b) are included in a paragraphs that start with
> "For the implementation-time use case"
> "For the run-time use case"
> Please suggest some text, if needed.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you to Barry Lieba for the SECDIR review.
> 
> ** Section 6.  I’m surprised by the statement that “The data in these modules is
> not security sensitive” given that the specific YANG module that might be
> annotated is unknown.  Would it be possible for an attacker to glean any
> topology information by reviewing the notification properties of module?
> Could they poll this interface to inform real-time targeting since Section 1
> notes that “capabilities might change during run-time”?
> BALAZS: Topology information is not exposed by ietf-system-capabilities or ietf-
> notification-capabilities. Information could be gleaned about supported
> modules (and the schema tree) but not about the instance data stored
> according those modules. So, you may learn that there is a module listing
> interfaces, but you will not be able to learn what specific interfaces are present.
> The same information about supported modules available is already available
> from the mandatory module ietf-yang-library.yang.

Understood.  So worst case you could maybe fingerprint the type or class of device, but not its configurations.  Thanks for explaining it.

Thanks,
Roman