Security Considerations Template for YANG Module Documents

Abstract

This document includes the template text agreed upon by the Operations Area and Security Area for inclusion in YANG documents. The best practices are updated as needed and will result in updates to this template for use to provide a consistent set of security considerations for authors, developers, and implementors.¶

1. Introduction

This document includes the template text agreed upon by the Operations Area and Security Area for inclusion in YANG documents. The best practices are updated as needed and will result in updates to this template for use to provide a consistent set of security considerations for authors, developers, and implementors.¶

Updates may be made through errata or a publication of an updated document for ease of use by the IETF and other standards organizations. The current version is maintained on a wiki.¶

2. YANG Security Considerations Template

The following template text, in addition to the guidance provided by the Security Area Directors in the Security Area wiki, must be included in the applicable IETF YANG publications. The text is provided as a template for use by other organizations with a requirement to reference it appropriately to this document.¶

---Template text BEGIN ---¶

Security Considerations¶

The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC 8446].¶

The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶

-- if you have any writable 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 that 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 subtrees and data nodes and their sensitivity/vulnerability:¶

<list subtrees and data nodes and 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 subtrees and data nodes and their sensitivity/vulnerability:¶

<list subtrees and data nodes and 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> Note: [RFC 8446], [RFC6241], [RFC6242], [RFC8341], and [RFC8040] must be "normative references".¶

---Template Text END ---¶

3. Security Considerations

This document defines a template to provide consistent YANG Security Considerations on publications by the IETF and other standards bodies and organizations.¶

4. IANA Considerations

This memo includes no request to IANA.¶

5. Contributors

Thank you to reviewers and contributors who helped to improve the security consdierations for YANG. The text has been developed and refined over many years on an Operations Area working group mailing list and to a Security Area wiki. Revisions have been made by IETF Security Area Directors and Operations Area Directors similar to the template for SNMP security considerations. Thank you to the following known contributors: Sean Turner, Stephen Farrell, Kathleen Moriarty, Beniot Claise, and Erik Rescorla.¶

6. References

Appendix A. Change Log

Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.¶

Appendix B. Open Issues

Note to RFC Editor: please remove this appendix before publication as an RFC.¶