RFC 8431
A YANG Data Model for the Routing Information Base (RIB)
4. IANA Considerations
This document registers a URI in the "ns" registry within the "IETF XML Registry" [RFC3688]: ------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. ------------------------------------------------------------------- This document registers a YANG module in the "YANG Module Names" registry [RFC7950]: ------------------------------------------------------------------- name: ietf-i2rs-rib namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib prefix: iir reference: RFC 8431 -------------------------------------------------------------------5. 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 [RFC8446]. The NETCONF access control model [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. The YANG module defines information that can be configurable in certain instances, for example, a RIB, a route, a nexthop can be created or deleted by client applications; the YANG module also defines RPCs that can be used by client applications to add/delete RIBs, routes, and nexthops. In such cases, a malicious client could attempt to remove, add, or update a RIB, a route, or a nexthop by creating or deleting corresponding elements in the RIB, route, and
nexthop lists, respectively. Removing a RIB or a route could lead to
disruption or impact in performance of a service; updating a route
may lead to suboptimal path and degradation of service levels as well
as possibly disruption of service. For those reasons, it is
important that the NETCONF access control model is vigorously applied
to prevent misconfiguration by unauthorized clients.
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:
o RIB: A malicious client could attempt to remove a RIB from a
routing instance, for example, in order to sabotage the services
provided by the RIB or to add a RIB to a routing instance (hence,
to inject unauthorized traffic into the nexthop).
o route: A malicious client could attempt to remove or add a route
from/to a RIB, for example, in order to sabotage the services
provided by the RIB.
o nexthop: A malicious client could attempt to remove or add a
nexthop from/to RIB, which may lead to a suboptimal path, a
degradation of service levels, and a possible disruption of
service.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>. [RFC8430] Bahadur, N., Ed., Kini, S., Ed., and J. Medved, "RIB Information Model", RFC 8430, DOI 10.17487/RFC8430, September 2018, <http://www.rfc-editor.org/info/rfc8430>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.6.2. Informative References
[I2RS-REQS] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Work in Progress, draft-ietf-i2rs-usecase- reqs-summary-03, November 2016. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>. [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", RFC 7921, DOI 10.17487/RFC7921, June 2016, <https://www.rfc-editor.org/info/rfc7921>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.Acknowledgements
The authors would like to thank Chris Bowers, John Scudder, Tom Petch, Mike McBride, and Ebben Aries for their review, suggestions, and comments to this document.Contributors
The following individuals also contributed to this document. o Zekun He, Tencent Holdings Ltd. o Sujian Lu, Tencent Holdings Ltd. o Jeffery Zhang, Juniper Networks
Authors' Addresses
Lixing Wang Individual Email: wang_little_star@sina.com Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com Amit Dass Ericsson Email: dass.amit@gmail.com Hariharan Ananthakrishnan Netflix Email: hari@netflix.com Sriganesh Kini Individual Email: sriganeshkini@gmail.com Nitin Bahadur Uber Email: nitin_bahadur@yahoo.com