Re: [netmod] Identifying "sensitive" or "security" data nodes (RFC6087bis-01, RFC6536)

On Thu, Jan 8, 2015 at 7:56 AM, Sterne, Jason (Jason)
<jason.sterne@alcatel-lucent.com> wrote:
> Hi guys,
>
> I made a verbal comment back in IETF91 for RFC6087bis-01 (and a few others) and someone recommended at the meeting that it would be useful if I could post them on the list.   Finally getting to that - sorry for the delay.
>
> I'm wondering whether it is really possible to adhere to the bullets in section 4.6 of RFC6087bis-01:
>
>    o  Writable data nodes that could be especially disruptive if abused
>       MUST be explicitly listed by name and the associated security
>       risks MUST be explained.
>
>    o  Readable data nodes that contain especially sensitive information
>       or that raise significant privacy concerns MUST be explicitly
>       listed by name and the reasons for the sensitivity/privacy
>       concerns MUST be explained.
>
>    o  Operations (i.e., YANG 'rpc' statements) that are potentially
>       harmful to system behavior or that raise significant privacy
>       concerns MUST be explicitly listed by name and the reasons for the
>       sensitivity/privacy concerns MUST be explained.
>
> Would we really get agreement across more than 3 people of which data nodes are "especially disruptive" and which data nodes are not ?  There are dozens/hundreds of knobs in most systems that can disrupt service (probably *most* nodes), cause a NE to be unmanageable, etc.   If you combined the requests of 10 vendors/operators (to make a superset) you'd end up with a large number of knobs being labeled "disruptive" (we each have our own pet peeves, or have seen human error in different areas cause service impacts).   As we start to accept more and more nodes as "disruptive" it is a slippery slope and where do you draw the line ?
>
> I can see this causing annoying arguments and requests for changes & churn on modules (or just not being used/useful).  It should at least be changed to "SHOULD" instead of "MUST".
>
> Other opinions ?  Is it advantageous enough to have "disruptive" labeling "mostly right" (by the opinion of the author(s)) in modules or should we leave it as an exercise for the user of the module to determine what they consider dangerous (and then use things like NACM to manage it) ?
>

I don't think the IESG would agree with your logic.
The wiggle-room is in the WG decision that a specific node
could be especially disruptive.

> Similar text is found in RFC6536 section 3.7.3:
>
>    Designers need to clearly identify any sensitive data, notifications,
>    or protocol operations defined within a YANG module.  For such
>    definitions, a "nacm:default-deny-write" or "nacm:default-deny-all"
>    statement ought to be present, in addition to a clear description of
>    the security risks.
>
> This idea is also expressed in http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines.
>
> Jason

Andy

>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod