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

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Thu, 8 Jan 2015 15:56:39 +0000

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jan 2015 08:13:30 -0800

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

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.

> This idea is also expressed in http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines.

Andy

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