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

[Benoit Claise <[e-mail]>]

Thanks Roman.

Regards, Benoit

On 10/15/2021 12:05 AM, Roman Danyliw wrote:
> 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