Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

[Balázs Lengyel <[e-mail]>]

From: Kent Watsen <[e-mail]> 
Sent: 2019. szeptember 30., hétfő 22:03
To: Balázs Lengyel <[e-mail]>
Cc: Eric Voit (evoit) <[e-mail]>; Mahesh Jethanandani
<[e-mail]>; Alexander Clemm <[e-mail]>; Benoit Claise
<[e-mail]>; [e-mail]
Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

 

 

In reviewing the draft, I don't see where the file format is defined.    I
understand the module defining a 'container' for protocol-accessible nodes,
but shouldn't it define an 'sx:structure' for the file format?  I suggest
moving the contents of the "datastore-subscription-capabilities" container
to a 'grouping' and then have both the container and an 'sx:structure' use
that grouping.

BALAZS2: This drafts does not want to define a file format. It intends to
use the "generic" file format defined in
draft-ietf-netmod-yang-instance-file-format. IMHO the whole aim of
draft-ietf-netmod-yang-instance-file-format is to avoid individual drafts
defining file formats.

 

On the below:





I suspect that you will need to do a security analysis per YANG object.
This has been done the other YANG push family.

BALAZS: The full module is readOnly and not sensitive or private in any
manner.  The security text for the readOnly parts of YangPush is the exact
same text: not very informative, but gives you the illusion of security
awareness.

 

I suspect that manipulating the reporting intervals could have some security
implications.   E.g., a hacker could push up the damping period or periodic
interval to a level where the information they are changing then becomes
invisible to a monitoring system.

BALAZS: The full YAM is read-only so manipulating the data is not a concern.

 

 

The draft should say something like:

 

1. All protocol-accessible are read-only and cannot be modified.  The nature
of the read-only data is not deemed to be sensitive in a way necessitating
access-control restrictions (e.g., NACM) beyond the client being
authenticated.

BALAZS2: OK,  Updated with first part, but Rob has asked for an extra
sentence about the dangers of revealing read-only data, I added that too.

"All protocol-accessible data are read-only and cannot be modified. 

        The data in this module is not security sensitive.

        Access control may be configured, to avoid exposing 

        the read-only data."

 

2. When a file format, the protection afforded by a mutually authenticated
transport protocol.  Protection of the data must be performed manually, so
as to ensure that the data is neither seen nor modified in transit.

Reword as needed.

BALAZS2: Agreed. This is part of normal file handling, transport. So I
reworded this to:

"When that data is in file format, data should be protected against 

        modification or unauthorized access using normal file handling and 

        secure and mutually authenticated file transport mechanisms."

 

Kent // contributor