Subject: [netmod] 4th draft for yang module security considerations

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 27 Apr 2010 09:50:09 +0200

We had quite a few discussions on the 3rd revision.
>From my reading however, it seems we more or less agree that:

- security considerations must be listed in the SC section and
  not in a separtely tagged description clause with the nodes 
  themselves.
- we cannot do a blanket statement that basically ALL config data
  is sensitive
- it is OK toi list a container or node list if all the leaves have
  the sanme/similar secuirty considereations. 

Based on that, I think it is best to make that last point more explicit.
I basically had that, but I was still using the MIB term of "subtrees".
So the 4th revision (last??) of the template-text would be as
follows:

----

  Each specification that defines one or more YANG
  modules MUST contain a section that discusses
  security considerations relevant to those modules.
  This section MUST be patterned after the latest
  approved template (available at [ed: URL TBD]).

  In particular, writable data nodes that could
  be especially disruptive if abused MUST be
  explicitly listed by name and the associated
  security risks MUST be spelled out.
 
  Similarly, 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.

  Further, if new RPC operations have been defined,
  then it the security considerations of each new
  RPC operation MUST be explained.

  Note: it is best to list a container or list node if all the
  leaves in the container or list node share the same
  or similar security considerations.

X. Security Considerations
 
 -- if you have any writeable data nodes (those are all the
-- "config true" nodes, and remember, that is the default)
-- describe their specific sensitivity or vulnerability.

There are a number of data nodes defined in this YANG module
which are writable/creatable/deletable (i.e. config true, which
is the default).  These data nodes may be considered sensitive
or vulnerable in some network environments.  Write operations
(e.g. edit-config) to these data nodes without proper protection
can have a negative effect on network operations.  These are
the containers, list nodes and data nodes with their specific
sensitivity/vulnerability:

<list containers, list nodes or data nodes, state why they are sensitive>
 
-- for all YANG modules you must evaluate whether any readable data
-- nodes (those are all the "config false" nodes, but also all other
-- nodes, because they can also be read via operations like get or
-- get-config) are sensitive or vulnerable (for instance, if they
-- might reveal customer information or violate personal privacy
-- laws such as those of the European Union if exposed to
-- unauthorized parties)

Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g. via get,
get-config or notification) to these data nodes.  These are the
containers, list nodes and data nodes with their specific
sensitivity/vulnerability:

<list containers, list nodes or data nodes, state why they are sensitive>
 
-- if your YANG module has defined any rpc operations
-- describe their specific sensitivity or vulnerability.

Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control access to these operations.  These are the
operations and their sensitivity/vulnerability:

<list RPC operations and state why they are sensitive>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 27 Apr 2010 01:19:34 -0700

Bert Wijnen (IETF) wrote:
>  not in a separtely tagged description clause with the nodes  themselves.

This is fine, but there is no 'perfect' answer, no matter where
the text is placed.

Since YANG modules (like MIB modules) are often extracted
from RFCs, and the SC section is not part of the extracted module,
there is a risk operators will not see this text.

Andy

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Apr 2010 10:35:04 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman

> from RFCs, and the SC section is not part of the extracted 
> module, there is a risk operators will not see this text.
> 
> 
> Andy
> 
>

Indeed, but the same risk exists for MIB modules and is assumed by the
community for a number of years. 

I believe that this is acceptable. 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Apr 2010 10:35:22 +0200

This looks OK to me. 

Dan

> [mailto:[email-masked]] On Behalf Of Bert Wijnen (IETF)
> Sent: Tuesday, April 27, 2010 10:50 AM
> To: NETMOD Working Group
> Subject: [netmod] 4th draft for yang module security considerations
> 
> which are writable/creatable/deletable (i.e. config true, 
> which is the default).  These data nodes may be considered 
> sensitive or vulnerable in some network environments.  Write 
> operations (e.g. edit-config) to these data nodes without 
> proper protection can have a negative effect on network 
> operations.  These are the containers, list nodes and data 
> nodes with their specific
> get-config or notification) to these data nodes.  These are 
> Some of the RPC operations in this YANG module may be 
> considered sensitive or vulnerable in some network 
> environments.  It is thus important to control access to 
> these operations.  These are the operations and their

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 27 Apr 2010 11:07:27 +0200

+1

Mehmet

> [mailto:[email-masked]] On Behalf Of ext Romascanu, Dan (Dan)
> Sent: Tuesday, April 27, 2010 10:35 AM
> To: Bert Wijnen (IETF); NETMOD Working Group
> Subject: Re: [netmod] 4th draft for yang module security 
> considerations
> 
> This looks OK to me. 
> 
> Dan
>  
>

---

From: Mark Ellison <[email-masked]>
Date: Tue, 27 Apr 2010 13:27:12 -0400

Bert,

> RPC operation MUST be explained.

s/then it the/then the/

Regards,

Mark

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 27 Apr 2010 20:04:22 +0200

Yep. Thanks Mark.

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 27 Apr 2010 20:24:19 +0200

If there are no major issues I propose that we send this version to the
Security ADs for review (with nits fixed)

If there still are major issues please jump in in the next two days. 

Thanks and Regards,

Dan

> Sent: Tuesday, April 27, 2010 9:04 PM
> To: Mark Ellison
> Cc: NETMOD Working Group