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

[Benoit Claise <[e-mail]>]

Hi Roman,

The proposed changes discussed below have been applied to the 
draft-ietf-netconf-notification-capabilities-20.
Please let us know what you think.

Regards, Benoit

On 10/6/2021 7:26 PM, Balázs Lengyel wrote:
> 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]; [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.
>
> 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.
>
> 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.
>