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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 06 Oct 2021 07:46:47 -0700

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.

----------------------------------------------------------------------
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”?

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Oct 2021 09:22:16 -0700

> https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/

I have never seen text like the above paragraph in an RFC for a YANG module
before.
IMO it sets a bad precedent and should be removed.  The info reported in
this YANG module
is not critical to the operation of YANG Push.  I am curious why this
requirement is here at all,
let alone a MUST requirement.

Every other YANG monitoring module is expected to be retrievable from a
server
that advertises conformance to that module, without any requirements placed
on the vendor's WEB site contents (as if that is interoperable anyways).
I do not see any reason this YANG module needs additional requirements.

Andy

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 Oct 2021 17:26:32 +0000

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 <[email-masked]> 
Sent: 2021. október 6., szerda 16:47
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Kent Watsen <[email-masked]>; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-netconf-notification-capabilities-18: (with DISCUSS and COMMENT)

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.)

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.

** 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.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 10 Oct 2021 22:25:06 +0200

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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 14 Oct 2021 22:05:03 +0000

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 ...

> From: Balázs Lengyel <[email-masked]>
> Sent: Wednesday, October 6, 2021 1:27 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>; Benoit Claise
> <[email-masked]>
> Cc: [email-masked]; netconf-
> [email-masked]; [email-masked]; Kent Watsen <[email-masked]>
> 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
> 
> Cc: [email-masked]; netconf-
> [email-masked]; [email-masked]; Kent Watsen <[email-masked]>;
> [email-masked]
> Subject: Roman Danyliw's Discuss on draft-ietf-netconf-notification-
> capabilities-18: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> The text contains contradictions on how to handle implementation-time use
> case that might use the YANG file format.
> 
> (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”
> 
> (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.
> 
> 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.

> 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]

That works for me.

> ** 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
> 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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 15 Oct 2021 15:17:49 +0200

Thanks Roman.

Regards, Benoit