RFC 9647: A YANG Data Model for Babel
- M. Jethanandani,
- B. Stark
Abstract
This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
This document defines a data model for the Babel routing protocol [RFC8966]. The data model is defined using YANG 1.1 [RFC7950] and is compatible with Network Management Datastore Architecture (NMDA) [RFC8342]. It is based on the Babel information model [RFC9046]. The data model only includes data nodes that are useful for managing Babel over IPv6.¶
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
1.2. Tree Diagram Annotations
For a reference to the annotations used in tree diagrams included in this document, please see "YANG Tree Diagrams" [RFC8340].¶
2. Babel Module
This document defines a YANG 1.1 [RFC7950] data model for the configuration and management of Babel. The YANG module is based on the Babel information model [RFC9046].¶
2.1. Information Model
It's worth noting a few differences between the Babel information model and this data module. The information model mandates the definition of some of the attributes, e.g.,
"babel
2.2. Tree Diagram
The following diagram illustrates a top-level hierarchy of the model. In addition to the version implemented by this device, the model contains subtrees on "constants", "interfaces", "mac-key-set", "dtls", and "routes".¶
The "interfaces" subtree describes attributes such as the "interface" object that is being referenced; the type of link, e.g., wired, wireless, or tunnel, as enumerated by "metric
The "constants" subtree describes the UDP port used for sending and receiving Babel messages and the multicast group used to send and receive announcements on IPv6.¶
The "routes" subtree describes objects such as the prefix for which the route is advertised, a reference to the neighboring route, and the "next-hop" address.¶
Finally, for security, two subtrees are defined to contain Message Authentication Code (MAC) keys and DTLS certificates. The "mac-key-set" subtree contains keys used with the MAC security mechanism. The boolean flag "default-apply" indicates whether the set of MAC keys is automatically applied to new interfaces. The "dtls" subtree contains certificates used with the DTLS security mechanism. Similar to the MAC mechanism, the boolean flag "default-apply" indicates whether the set of DTLS certificates is automatically applied to new interfaces.¶
2.3. YANG Module
This YANG module augments the YANG routing management module [RFC8349] to provide a common framework for all routing subsystems. By augmenting the module, it provides a common building block for routes and Routing Information Bases (RIBs). It also has a reference to an interface defined by "A YANG Data Model for Interface Management" [RFC8343].¶
A router running the Babel routing protocol can sometimes determine the parameters it needs to use for an interface based on the interface name. For example, it can detect that eth0 is a wired interface and that wlan0 is a wireless interface. This is not true for a tunnel interface, where the link parameters need to be configured explicitly.¶
For a wired interface, it will assume "two
In addition to the modules used above, this module imports definitions from "Common YANG Data Types" [RFC6991] and references "HMAC: Keyed-Hashing for Message Authentication" [RFC2104], "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec" [RFC4868], "Textual Encodings of PKIX, PKCS, and CMS Structures" [RFC7468], "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)" [RFC7693], "Network Configuration Access Control Model" [RFC8341], "The Babel Routing Protocol" [RFC8966], "MAC Authentication for the Babel Routing Protocol" [RFC8967], "Babel Information Model" [RFC9046], "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3" [RFC9147], and "YANG Data Types and Groupings for Cryptography" [RFC9640].¶
3. IANA Considerations
3.1. URI Registration
IANA has registered the following URI in the "ns" registry of the "IETF XML Registry" [RFC3688].¶
3.2. YANG Module Name Registration
IANA has registered the following in the "YANG Module Names" registry [RFC6020].¶
4. Security Considerations
This section is modeled after the template defined in Section 3.7.1 of [RFC8407].¶
The "ietf-babel" YANG module defines a data model that is designed to be accessed via YANG-based management
protocols, such as NETCONF [RFC6241] and RESTCONF
[RFC8040]. These
protocols have mandatory
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content.¶
The security considerations outlined here are specific to the YANG data model and do not cover security considerations of the Babel protocol or its security mechanisms in "The Babel Routing Protocol" [RFC8966], "MAC Authentication for the Babel Routing Protocol" [RFC8967], and "Babel Routing Protocol over Datagram Transport Layer Security" [RFC8968]. Each of these has its own Security Considerations section for considerations that are specific to it.¶
There are a number of data nodes defined in the YANG module that are writable
- 'babel':
- This container includes an 'enable' parameter that can be used to enable or disable use of Babel on a router.¶
- 'babel
/constants' : - This container includes configuration parameters that can prevent reachability if misconfigured.¶
- 'babel
/interfaces' : - This leaf-list has configuration parameters that can enable/disable security mechanisms and change performance characteristics of the Babel protocol. For example, enabling logging of packets and giving unintended access to the log files gives an attacker detailed knowledge of the network and allows it to launch an attack on the traffic traversing the network device.¶
- 'babel/hmac' and 'babel/dtls':
- These contain security credentials that influence whether incoming packets are trusted and whether outgoing packets are produced in such a way that the receiver will treat them as trusted.¶
Some of the readable data or config false 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
- 'babel':
- Access to the information in the various nodes can disclose the network topology. Additionally, the routes used by a network device may be used to mount a subsequent attack on traffic traversing the network device.¶
- 'babel/hmac' and 'babel/dtls':
- These contain security credentials, including private credentials of the router; however, it is required that these values not be readable.¶
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
This model defines two actions. Resetting the statistics within an interface container would be visible to any monitoring processes, which should be designed to account for the possibility of such a reset. The "test" action allows for validation that a MAC key and MAC algorithm have been properly configured. The MAC key is a sensitive piece of information, and it is important to prevent an attacker that does not know the MAC key from being able to determine the MAC value by trying different input parameters. The "test" action has been designed to not reveal such information directly. Such information might also be revealed indirectly due to side channels such as the time it takes to produce a response to the action. Implementations SHOULD use a constant-time comparison between the input MAC and the locally generated MAC value for comparison in order to avoid such side channel leakage.¶
5. References
5.1. Normative References
- [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC4252]
-
Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10
.17487 , , <https:///RFC4252 www >..rfc -editor .org /info /rfc4252 - [RFC4868]
-
Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10
.17487 , , <https:///RFC4868 www >..rfc -editor .org /info /rfc4868 - [RFC6241]
-
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10
.17487 , , <https:///RFC6241 www >..rfc -editor .org /info /rfc6241 - [RFC6991]
-
Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10
.17487 , , <https:///RFC6991 www >..rfc -editor .org /info /rfc6991 - [RFC7693]
-
Saarinen, M., Ed. and J. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, DOI 10
.17487 , , <https:///RFC7693 www >..rfc -editor .org /info /rfc7693 - [RFC7950]
-
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10
.17487 , , <https:///RFC7950 www >..rfc -editor .org /info /rfc7950 - [RFC8040]
-
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10
.17487 , , <https:///RFC8040 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 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC8341]
-
Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10
.17487 , , <https:///RFC8341 www >..rfc -editor .org /info /rfc8341 - [RFC8343]
-
Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10
.17487 , , <https:///RFC8343 www >..rfc -editor .org /info /rfc8343 - [RFC8349]
-
Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10
.17487 , , <https:///RFC8349 www >..rfc -editor .org /info /rfc8349 - [RFC8446]
-
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10
.17487 , , <https:///RFC8446 www >..rfc -editor .org /info /rfc8446 - [RFC8966]
-
Chroboczek, J. and D. Schinazi, "The Babel Routing Protocol", RFC 8966, DOI 10
.17487 , , <https:///RFC8966 www >..rfc -editor .org /info /rfc8966 - [RFC8967]
-
Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC Authentication for the Babel Routing Protocol", RFC 8967, DOI 10
.17487 , , <https:///RFC8967 www >..rfc -editor .org /info /rfc8967 - [RFC8968]
-
Décimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", RFC 8968, DOI 10
.17487 , , <https:///RFC8968 www >..rfc -editor .org /info /rfc8968 - [RFC9000]
-
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10
.17487 , , <https:///RFC9000 www >..rfc -editor .org /info /rfc9000 - [RFC9046]
-
Stark, B. and M. Jethanandani, "Babel Information Model", RFC 9046, DOI 10
.17487 , , <https:///RFC9046 www >..rfc -editor .org /info /rfc9046 - [RFC9147]
-
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10
.17487 , , <https:///RFC9147 www >..rfc -editor .org /info /rfc9147 - [RFC9640]
-
Watsen, K., "YANG Data Types and Groupings for Cryptography", RFC 9640, DOI 10
.17487 , , <https:///RFC9640 www >..rfc -editor .org /info /rfc9640
5.2. Informative References
- [RFC2104]
-
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10
.17487 , , <https:///RFC2104 www >..rfc -editor .org /info /rfc2104 - [RFC3688]
-
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10
.17487 , , <https:///RFC3688 www >..rfc -editor .org /info /rfc3688 - [RFC6020]
-
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10
.17487 , , <https:///RFC6020 www >..rfc -editor .org /info /rfc6020 - [RFC7468]
-
Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10
.17487 , , <https:///RFC7468 www >..rfc -editor .org /info /rfc7468 - [RFC8340]
-
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10
.17487 , , <https:///RFC8340 www >..rfc -editor .org /info /rfc8340 - [RFC8342]
-
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10
.17487 , , <https:///RFC8342 www >..rfc -editor .org /info /rfc8342 - [RFC8407]
-
Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 8407, DOI 10
.17487 , , <https:///RFC8407 www >..rfc -editor .org /info /rfc8407 - [W3C
.REC -xml -20081126] -
Bray, T., Paoli, J., Sperberg
-Mc , Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation RECQueen, C. M. -xml , , <https://-20081126 www >..w3 .org /TR /xml /
Appendix A. Tree Diagram and Example Configurations
This section is devoted to including a complete tree diagram and examples that demonstrate how Babel can be configured.¶
Note that various examples are encoded using Extensible Markup
Language (XML) [W3C
A.1. Complete Tree Diagram
This section includes the complete tree diagram for the Babel YANG module.¶
A.2. Statistics Gathering Enabled
In this example, interface eth0 is being configured for routing protocol Babel, and statistics gathering is enabled. For security, HMAC-SHA256 is supported. Every sent Babel packet is signed with the key value provided, and every received Babel packet is verified with the same key value.¶
A.3. Automatic Detection of Properties
In this example, babeld is configured on two interfaces:¶
This says to run Babel on interfaces eth0 and wlan0. Babeld will automatically detect that eth0 is wired and wlan0 is wireless and will configure the right parameters automatically.¶
A.4. Override Default Properties
In this example, babeld is configured on three interfaces:¶
Here, interface eth1 is an Ethernet bridged to a wireless radio, so babeld's autodetection fails, and the interface type needs to be configured manually. Tunnels are not detected automatically, so this needs to be specified.¶
This is equivalent to the following:¶
A.5. Configuring Other Properties
In this example, two interfaces are configured for babeld:¶
Here, ppp0 is a metered 3G link used for fallback connectivity. It runs with much higher than default time constants in order to avoid control traffic as much as possible.¶
Acknowledgements
Juliusz Chroboczek provided most of the example configurations for babel that are shown in Appendix A.¶