RFC 9046

Babel Information Model

๐Ÿ“… published June 2021, from ietf

RFC 9046: Babel Information Model โœจ

Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's an Informational doc ๐ŸŽ€. It's not a standards-track spec, it's just published so people can see it. The authors are B. Stark (AT&T) and M. Jethanandani (Kloud Services), and it came out in June 2021. It's on the ISSN 2070-1721 series. The title block doesn't list any RFCs that it obsoletes or updates, so it's not replacing or patching anything else ๐Ÿฆ‹

Abstract

Okay so the Babel information model gives you structured data elements for a Babel implementation to report its current state ๐Ÿ“Š It may also allow limited configuration of some of those elements ๐Ÿ”ง The model can be used as the base for building data models under different data modeling regimes ๐Ÿ’… And it only includes the parameters and values that are actually useful for managing Babel over IPv6 ๐ŸŒ That's the whole vibe โœจ

Status of This Memo

Babel info is not an Internet Standards Track spec, it's published purely for information ๐Ÿงš

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community ๐Ÿซถ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 for the details ๐Ÿค“

For the latest status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9046 ๐Ÿ’Œ

Copyright (c) 2021 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://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they explain what you can and can't do with this doc ๐Ÿ“œ Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ๐ŸŒธ

Table of Contents

1.  Introduction
  1.1.  Requirements Language
  1.2.  Notation
2.  Overview
3.  The Information Model
  3.1.  Definition of babel-information-obj
  3.2.  Definition of babel-constants-obj
  3.3.  Definition of babel-interface-obj
  3.4.  Definition of babel-if-stats-obj
  3.5.  Definition of babel-neighbor-obj
  3.6.  Definition of babel-route-obj
  3.7.  Definition of babel-mac-key-set-obj
  3.8.  Definition of babel-mac-key-obj
  3.9.  Definition of babel-dtls-cert-set-obj
  3.10. Definition of babel-dtls-cert-obj
4.  Extending the Information Model
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ๐ŸŒท

Babel is a loop-avoiding, distance-vector routing protocol, and it's defined in [RFC8966] ๐Ÿฆ‹ [RFC8967] defines a security mechanism that lets Babel packets be cryptographically authenticated, and [RFC8968] defines a security mechanism that lets Babel packets be both authenticated and encrypted ๐Ÿ” This doc describes an information model for Babel, covering implementations that use one or both of those security mechanisms ๐Ÿ’– The model can be used to build management protocol data models, like a NETCONF [RFC6241] YANG [RFC7950] data model ๐ŸŽ€

Okay so because Babel is so simple, most of this model is about reporting the protocol's operational state ๐Ÿ“Š Very little of it counts as mandatory to implement if you want to claim compliance with this information model ๐Ÿ™ˆ Some parameters may be configurable, but it's up to each Babel implementation whether it lets you configure any of them ๐Ÿ”ง If an implementation doesn't allow configuration of a parameter, it MAY still choose to expose that parameter as read-only ๐Ÿ‘€

The model uses a hierarchical structure ๐ŸŒณ That doesn't stop a data model built on top of it from using a referential or some other structure instead ๐Ÿ’…

This model only covers parameters and values that are useful for managing Babel over IPv6 ๐ŸŒ It has nothing specific to running Babel over IPv4, even though [RFC8966] does define a multicast group for sending and listening to multicast announcements on IPv4 ๐Ÿ™ƒ Running Babel always and only over IPv6 means there's less chance of breakage from inconsistent configuration, and the implementation is simpler too ๐Ÿงš Running Babel over IPv6 needs IPv6 at the link layer, but it doesn't need advertised prefixes, router advertisements, or DHCPv6 to be present in the network โœจ Link-local IPv6 is widely supported on the devices where Babel is expected to be used ๐Ÿ’œ And Babel over IPv6 can be used to configure both IPv4 and IPv6 routes, so it's giving versatile ๐ŸŒˆ

1.1. Requirements Language

Here's the key-word part, and it matters so listen up ๐Ÿ‘‘ 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. Notation

Okay so this doc uses a programming-language-style notation to define the properties of the objects in the information model ๐Ÿง‘โ€๐Ÿ’ป An optional property is wrapped in square brackets, [ ]. A list property is shown with two numbers in angle brackets, <m..n>, where m is the minimum number of list elements and n is the maximum number. A * for n means there's no defined limit on how many list elements there can be ๐ŸŒธ

Every parameter and object has an indication of either "ro" or "rw". "ro" means read-only. "rw" means read-write. For an object, read-write means you can create or delete instances of it ๐Ÿ’– If an implementation is allowed to implement a "rw" parameter as read-only, the parameter description will say so ๐Ÿ”ฅ

The object definitions use these base types:

binary:       A binary string (sequence of octets).

boolean:      A type representing a Boolean (true or false) value.

datetime:     A type representing a date and time using the Gregorian
              calendar.  The datetime format MUST conform to
              [RFC3339], Section 5.6.

ip-address:   A type representing an IP address.  This type supports
              both IPv4 and IPv6 addresses.

operation:    A type representing a remote procedure call or other
              action that can be used to manipulate data elements or
              system behaviors.

reference:    A type representing a reference to another information
              or data model element or to some other device resource.

string:       A type representing a human-readable string consisting
              of a (possibly restricted) subset of Unicode and ISO/
              IEC 10646 [ISO.10646] characters.

uint:         A type representing an unsigned integer number.  This
              information model does not define a precision.

2. Overview ๐Ÿ—บ๏ธ

Okay so here's the big picture, the whole info model laid out as a hierarchy ๐ŸŒณโœจ

+-- babel-information
   +-- babel-implementation-version
   +-- babel-enable
   +-- router-id
   +-- self-seqno
   +-- babel-metric-comp-algorithms
   +-- babel-security-supported
   +-- babel-mac-algorithms
   +-- babel-dtls-cert-types
   +-- babel-stats-enable
   +-- babel-stats-reset
   +-- babel-constants
   |  +-- babel-udp-port
   |  +-- babel-mcast-group
   +-- babel-interfaces
   |  +-- babel-interface-reference
   |  +-- babel-interface-enable
   |  +-- babel-interface-metric-algorithm
   |  +-- babel-interface-split-horizon
   |  +-- babel-mcast-hello-seqno
   |  +-- babel-mcast-hello-interval
   |  +-- babel-update-interval
   |  +-- babel-mac-enable
   |  +-- babel-if-mac-key-sets
   |  +-- babel-mac-verify
   |  +-- babel-dtls-enable
   |  +-- babel-if-dtls-cert-sets
   |  +-- babel-dtls-cached-info
   |  +-- babel-dtls-cert-prefer
   |  +-- babel-packet-log-enable
   |  +-- babel-packet-log
   |  +-- babel-if-stats
   |  |  +-- babel-sent-mcast-hello
   |  |  +-- babel-sent-mcast-update
   |  |  +-- babel-sent-ucast-hello
   |  |  +-- babel-sent-ucast-update
   |  |  +-- babel-sent-IHU
   |  |  +-- babel-received-packets
   |  +-- babel-neighbors
   |     +-- babel-neighbor-address
   |     +-- babel-hello-mcast-history
   |     +-- babel-hello-ucast-history
   |     +-- babel-txcost
   |     +-- babel-exp-mcast-hello-seqno
   |     +-- babel-exp-ucast-hello-seqno
   |     +-- babel-ucast-hello-seqno
   |     +-- babel-ucast-hello-interval
   |     +-- babel-rxcost
   |     +-- babel-cost
   +-- babel-routes
   |  +-- babel-route-prefix
   |  +-- babel-route-prefix-length
   |  +-- babel-route-router-id
   |  +-- babel-route-neighbor
   |  +-- babel-route-received-metric
   |  +-- babel-route-calculated-metric
   |  +-- babel-route-seqno
   |  +-- babel-route-next-hop
   |  +-- babel-route-feasible
   |  +-- babel-route-selected
   +-- babel-mac-key-sets
   |  +-- babel-mac-default-apply
   |  +-- babel-mac-keys
   |     +-- babel-mac-key-name
   |     +-- babel-mac-key-use-send
   |     +-- babel-mac-key-use-verify
   |     +-- babel-mac-key-value
   |     +-- babel-mac-key-algorithm
   |     +-- babel-mac-key-test
   +-- babel-dtls-cert-sets
      +-- babel-dtls-default-apply
      +-- babel-dtls-certs
         +-- babel-cert-name
         +-- babel-cert-value
         +-- babel-cert-type
         +-- babel-cert-private-key

Most parameters are read-only ๐Ÿ”’ But there's a list of the ones that aren't required to be read-only, and it's a bunch of good stuff ๐ŸŽ€

  • enable/disable Babel
  • create/delete Babel Message Authentication Code (MAC) Key sets
  • create/delete Babel Certificate sets
  • enable/disable statistics collection
  • Constant: UDP port
  • Constant: IPv6 multicast group
  • Interface: enable/disable Babel on this interface
  • Interface: metric algorithm
  • Interface: split horizon
  • Interface: sets of MAC keys
  • Interface: verify received MAC packets
  • Interface: set of certificates for use with DTLS
  • Interface: use cached info extensions
  • Interface: preferred order of certificate types
  • Interface: enable/disable packet log
  • MAC-keys: create/delete entries
  • MAC-keys: key used for sent packets
  • MAC-keys: key used to verify packets
  • DTLS-certs: create/delete entries

Some parameters are required to return no value when read, so they're basically secret ๐Ÿคซ

  • MAC key values
  • DTLS private keys

Okay real talk: this overview is just there to be informative, it's not normative ๐Ÿงš If it ever disagrees with the detailed definitions in the later sections, the mistake is in the overview, not the detailed part ๐Ÿ’…


3. The Information Model โœจ

Okay, this is where it gets real ๐Ÿ’– The detailed definitions of every object live here, and they're coming up next ๐Ÿฆ‹

3.1. Definition of babel-information-obj

okay bestie, let's start with the big boss object ๐Ÿ‘‘ Every babel-information-obj is a bundle of read-only and read-write parameters, plus a few operations and some lists. Here's the whole shape:

   object {
        string                    ro babel-implementation-version;
        boolean                   rw babel-enable;
        binary                    ro babel-self-router-id;
       [uint                      ro babel-self-seqno;]
        string                    ro babel-metric-comp-algorithms<1..*>;
        string                    ro babel-security-supported<0..*>;
       [string                    ro babel-mac-algorithms<1..*>;]
       [string                    ro babel-dtls-cert-types<1..*>;]
       [boolean                   rw babel-stats-enable;]
       [operation                    babel-stats-reset;]
        babel-constants-obj       ro babel-constants;
        babel-interface-obj       ro babel-interfaces<0..*>;
        babel-route-obj           ro babel-routes<0..*>;
       [babel-mac-key-set-obj     rw babel-mac-key-sets<0..*>;]
       [babel-dtls-cert-set-obj   rw babel-dtls-cert-sets<0..*>;]
   } babel-information-obj;

babel-implementation-version is the name and version of this implementation of the Babel protocol. Basically the "who am I" card for the software ๐Ÿชช

babel-enable is the on/off switch ๐Ÿ’… When you write it, it decides whether the protocol gets turned on (true) or off (false). When you read it from the running or intended datastore, you get the administrative setting, aka what somebody asked for. When you read it from the operational datastore, you get what's actually happening right now, so running (true) or not running (false). A data model that doesn't keep running and operational values separate can just use two separate parameters instead. An implementation MAY choose to expose this parameter as read-only ("ro").

babel-self-router-id is the router-id this instance of Babel uses to identify itself. [RFC8966] describes it as an arbitrary string of 8 octets. Very mysterious, very iconic ๐Ÿ”ฎ

babel-self-seqno is the current sequence number that shows up in route updates for routes this node originated. It's a 16-bit unsigned integer ๐Ÿ”ข

babel-metric-comp-algorithms is the list of cost computation algorithms this node supports. The possible values include "2-out-of-3", which is described in [RFC8966], Appendix A.2.1, and "ETX", which is described in [RFC8966], Appendix A.2.2.

babel-security-supported is the list of security mechanisms this node supports. The possible values include "MAC", which means support for [RFC8967], and "DTLS", which means support for [RFC8968]. Security list energy ๐Ÿ”

babel-mac-algorithms is the list of MAC computation algorithms that are supported. The possible values include "HMAC-SHA256" and "BLAKE2s-128", which indicate support for the algorithms mentioned in [RFC8967].

babel-dtls-cert-types is the list of supported certificate types. The possible values include "X.509" and "RawPublicKey", which indicate support for the types mentioned in [RFC8968] ๐ŸŽ€

babel-stats-enable tells you whether statistics collection is enabled (true) or disabled (false) on all interfaces. When it's enabled, the existing stats values don't get cleared, and they keep going up as new packets get counted ๐Ÿ“ˆ

babel-stats-reset is an operation that resets all of the babel-if-stats parameters back to zero. It has no input or output parameters, so it's a pure "poof, start over" button ๐Ÿงน

babel-constants is a babel-constants-obj object.

babel-interfaces is a set of babel-interface-obj objects.

babel-routes is a set of babel-route-obj objects, and it holds the routes this node knows about ๐Ÿ—บ๏ธ

babel-mac-key-sets is a set of babel-mac-key-set-obj objects. If this object is implemented, it gives you access to the parameters for the MAC security mechanism. An implementation MAY choose to expose this object as read-only ("ro").

babel-dtls-cert-sets is a set of babel-dtls-cert-set-obj objects. If this object is implemented, it gives you access to the parameters for the DTLS security mechanism. An implementation MAY choose to expose this object as read-only ("ro") ๐Ÿซถ


3.2. Definition of babel-constants-obj

Next up, the constants object, which is smaller but still important, bestie โœจ

   object {
        uint         rw babel-udp-port;
       [ip-address   rw babel-mcast-group;]
   } babel-constants-obj;

babel-udp-port is the UDP port used for sending and listening for Babel packets. The default is 6696. An implementation MAY choose to expose this parameter as read-only ("ro"). It's a 16-bit unsigned integer ๐Ÿฆ‹

babel-mcast-group is the multicast group used for sending and listening to multicast announcements on IPv6. The default is ff02::1:6. An implementation MAY choose to expose this parameter as read-only ("ro") ๐ŸŒธ


3.3. Definition of babel-interface-obj

Now we're getting into the interface object, and honestly this is where the drama lives ๐Ÿ’– Here's the full layout:

   object {
        reference            ro babel-interface-reference;
       [boolean              rw babel-interface-enable;]
        string               rw babel-interface-metric-algorithm;
       [boolean              rw babel-interface-split-horizon;]
       [uint                 ro babel-mcast-hello-seqno;]
       [uint                 ro babel-mcast-hello-interval;]
       [uint                 ro babel-update-interval;]
       [boolean              rw babel-mac-enable;]
       [reference            rw babel-if-mac-key-sets<0..*>;]
       [boolean              rw babel-mac-verify;]
       [boolean              rw babel-dtls-enable;]
       [reference            rw babel-if-dtls-cert-sets<0..*>;]
       [boolean              rw babel-dtls-cached-info;]
       [string               rw babel-dtls-cert-prefer<0..*>;]
       [boolean              rw babel-packet-log-enable;]
       [reference            ro babel-packet-log;]
       [babel-if-stats-obj   ro babel-if-stats;]
        babel-neighbor-obj   ro babel-neighbors<0..*>;
   } babel-interface-obj;

babel-interface-reference is a reference to an interface object that can be used to send and receive IPv6 packets. This is defined by the data model, for example YANG [RFC7950] and Broadband Forum (BBF) [TR-181]. The referencing syntax depends on the data model. If there's no set of interface objects available, this should be a string that names the interface the underlying operating system uses ๐Ÿ”Œ

babel-interface-enable is the on/off switch for this particular interface ๐Ÿ’… When you write it, it decides whether the protocol gets enabled (true) or disabled (false) on this interface. Reading from the running or intended datastore gives you the administrative value, and reading from the operational datastore tells you whether the protocol is actually running (true) or not (false). Same deal as before: a data model that doesn't replicate running and operational parameters can implement this as two separate parameters. An implementation MAY choose to expose this parameter as read-only ("ro").

babel-interface-metric-algorithm shows which metric computation algorithm is used on this interface. The value MUST be one of the ones listed in the babel-metric-comp-algorithms parameter. An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿงฎ

babel-interface-split-horizon shows whether or not the split-horizon optimization is used when calculating metrics on this interface. A value of "true" means split-horizon optimization is used. It's described in [RFC8966], Section 3.7.4. An implementation MAY choose to expose this parameter as read-only ("ro") ๐ŸŒˆ

babel-mcast-hello-seqno is the current sequence number in use for multicast Hellos sent on this interface. It's a 16-bit unsigned integer ๐Ÿ”ข

babel-mcast-hello-interval is the current interval in use for multicast Hellos sent on this interface. The units are centiseconds โฑ๏ธ and it's a 16-bit unsigned integer.

babel-update-interval is the current interval in use for all updates, both multicast and unicast, sent on this interface. The units are centiseconds, and it's a 16-bit unsigned integer โฑ๏ธ

babel-mac-enable shows whether the MAC security mechanism is enabled (true) or disabled (false). An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿ”

babel-if-mac-key-sets is a list of references to the babel-mac-key-sets entries that apply to this interface. When an interface instance gets created, every babel-mac-key-sets instance with babel-mac-default-apply "true" gets included in this list. An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿ—๏ธ

babel-mac-verify is a Boolean flag that says whether MACs in incoming Babel packets are required to be present and verified. If this parameter is "true", incoming packets are required to have a valid MAC. An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿ›ก๏ธ

babel-dtls-enable shows whether the DTLS security mechanism is enabled (true) or disabled (false). An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿ”’

babel-if-dtls-cert-sets is a list of references to the babel-dtls-cert-sets entries that apply to this interface. When an interface instance gets created, every babel-dtls-cert-sets instance with babel-dtls-default-apply "true" gets included in this list. An implementation MAY choose to expose this parameter as read-only ("ro") ๐ŸŽ€

babel-dtls-cached-info shows whether the cached_info extension (see [RFC8968], Appendix A) is included in ClientHello and ServerHello packets. The extension is included if the value is "true". An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿง

babel-dtls-cert-prefer is a list of supported certificate types, in order of preference. The values MUST be among the ones listed in the babel-dtls-cert-types parameter. This list is used to fill in the server_certificate_type extension (see [RFC8968], Appendix A) in a ClientHello. Values that show up in at least one instance in the babel-dtls-certs object of a referenced babel-dtls instance, and that have a non-empty babel-cert-private-key, get used to fill in the client_certificate_type extension in a ClientHello ๐Ÿซง

babel-packet-log-enable shows whether packet logging is enabled (true) or disabled (false) on this interface ๐Ÿ“

babel-packet-log is a reference or URL link to a file holding a timestamped log of packets received and sent on babel-udp-port on this interface. The [libpcap] file format, with a .pcap file extension, SHOULD be supported for packet log files. Logging is turned on or off by babel-packet-log-enable. Implementations will need to carefully manage and limit the memory that packet logs use, so keep an eye on that one ๐Ÿ‘€

babel-if-stats is the statistics collection object for this interface ๐Ÿ“Š

babel-neighbors is a set of babel-neighbor-obj objects ๐Ÿค

3.4. Definition of babel-if-stats-obj โœจ๐Ÿ“Š

okay bestie, this one's the interface's scoreboard ๐Ÿ€ it keeps count of every Hello, update, and IHU that goes out, plus every Babel packet that comes in ๐Ÿ’…

   object {
        uint   ro babel-sent-mcast-hello;
        uint   ro babel-sent-mcast-update;
        uint   ro babel-sent-ucast-hello;
        uint   ro babel-sent-ucast-update;
        uint   ro babel-sent-IHU;
        uint   ro babel-received-packets;
   } babel-if-stats-obj;

babel-sent-mcast-hello: a count of how many multicast Hello packets were sent on this interface ๐Ÿ“จ

babel-sent-mcast-update: a count of how many multicast update packets were sent on this interface ๐Ÿ”

babel-sent-ucast-hello: a count of how many unicast Hello packets were sent on this interface ๐Ÿ’Œ

babel-sent-ucast-update: a count of how many unicast update packets were sent on this interface ๐Ÿ“ฌ

babel-sent-IHU: a count of how many "I Heard You" (IHU) packets were sent on this interface ๐Ÿซถ

babel-received-packets: a count of how many Babel packets were received on this interface ๐Ÿ“ฅ

3.5. Definition of babel-neighbor-obj ๐Ÿค๐ŸŒธ

this is your neighbor's whole profile, bestie ๐Ÿ‘€ who they are, how their Hellos have been landing, and what costs they've got ๐Ÿ’…

   object {
        ip-address   ro babel-neighbor-address;
       [binary       ro babel-hello-mcast-history;]
       [binary       ro babel-hello-ucast-history;]
        uint         ro babel-txcost;
        uint         ro babel-exp-mcast-hello-seqno;
        uint         ro babel-exp-ucast-hello-seqno;
       [uint         ro babel-ucast-hello-seqno;]
       [uint         ro babel-ucast-hello-interval;]
       [uint         ro babel-rxcost;]
       [uint         ro babel-cost;]
   } babel-neighbor-obj;

babel-neighbor-address: the IPv4 or IPv6 address the neighbor sends packets from ๐Ÿ“

babel-hello-mcast-history: the multicast Hello history, meaning whether or not the multicast Hello packets before babel-exp-mcast-hello-seqno got received ๐Ÿงพ it's a binary sequence where the newest Hello is a "1" in the leftmost bit, older bits slide right, and "0" bits fill in the gaps for any Hellos that never showed up ๐Ÿซ  this value should be displayed using hex digits ([0-9a-fA-F]). See [RFC8966], Appendix A.1.

babel-hello-ucast-history: the unicast Hello history, meaning whether or not the unicast Hello packets before babel-exp-ucast-hello-seqno got received ๐Ÿ“œ same vibe as the multicast one: the newest Hello is a "1" in the leftmost bit, older bits shift right, and "0" bits sit between prior Hello bits and the most recent Hello for any not-received Hellos. This value should be displayed using hex digits ([0-9a-fA-F]). See [RFC8966], Appendix A.1.

babel-txcost: the transmission cost value from the last IHU packet received from this neighbor, or the maximum value if the IHU hold timer for this neighbor has expired โณ See [RFC8966], Section 3.4.2. This is a 16-bit unsigned integer.

babel-exp-mcast-hello-seqno: the expected multicast Hello sequence number of the next Hello to be received from this neighbor ๐Ÿ”ข if multicast Hello packets aren't expected, or processing of multicast packets isn't enabled, this MUST be NULL ๐Ÿšซ This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model MAY use a different data type that allows differentiation between zero (0) and NULL.

babel-exp-ucast-hello-seqno: the expected unicast Hello sequence number of the next Hello to be received from this neighbor ๐Ÿ”ข if unicast Hello packets aren't expected, or processing of unicast packets isn't enabled, this MUST be NULL ๐Ÿšซ This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model MAY use a different data type that allows differentiation between zero (0) and NULL.

babel-ucast-hello-seqno: the current sequence number in use for unicast Hellos sent to this neighbor ๐Ÿ“ฎ if unicast Hellos aren't being sent, this MUST be NULL ๐Ÿšซ This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model MAY use a different data type that allows differentiation between zero (0) and NULL.

babel-ucast-hello-interval: the current interval in use for unicast Hellos sent to this neighbor โฑ๏ธ the units are centiseconds. This is a 16-bit unsigned integer.

babel-rxcost: the reception cost calculated for this neighbor ๐Ÿ“ก this value is usually derived from the Hello history, and it can be combined with other data, like statistics kept by the link layer. The rxcost is sent to a neighbor in each IHU. See [RFC8966], Section 3.4.3. This is a 16-bit unsigned integer.

babel-cost: the link cost, computed from the values in the neighbor table ๐Ÿ’ธ that means the statistics kept there about receiving Hellos, plus the txcost from received IHU packets. This is a 16-bit unsigned integer.

3.6. Definition of babel-route-obj ๐Ÿ›ฃ๏ธ๐Ÿ’–

every route gets its own little profile here ๐Ÿ—บ๏ธ where it's going, who sent it, how good it is, and whether it's the one actually being used โœจ

   object {
        ip-address   ro babel-route-prefix;
        uint         ro babel-route-prefix-length;
        binary       ro babel-route-router-id;
        reference    ro babel-route-neighbor;
        uint         ro babel-route-received-metric;
        uint         ro babel-route-calculated-metric;
        uint         ro babel-route-seqno;
        ip-address   ro babel-route-next-hop;
        boolean      ro babel-route-feasible;
        boolean      ro babel-route-selected;
   } babel-route-obj;

babel-route-prefix: the prefix, expressed in IP address format, that this route is advertised for ๐ŸŽฏ

babel-route-prefix-length: the length of the prefix this route is advertised for ๐Ÿ“

babel-route-router-id: the router-id of the router that originated this route ๐Ÿชช

babel-route-neighbor: a reference to the babel-neighbors entry for the neighbor that advertised this route ๐Ÿ”—

babel-route-received-metric: the metric this route was advertised with by the neighbor, or the maximum value to show the route was recently retracted and is temporarily unreachable (see Section 3.5.4 of [RFC8966]) ๐Ÿ™ˆ this metric will be NULL if the route wasn't received from a neighbor but got generated some other way. At least one of the following MUST be non-NULL: babel-route-calculated-metric or babel-route-received-metric ๐Ÿ’ฏ having both be non-NULL is expected for a route that's received and then advertised onward. This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model MAY use a different data type that allows differentiation between zero (0) and NULL.

babel-route-calculated-metric: a calculated metric for this route ๐Ÿงฎ how it's calculated is implementation specific. The maximum value shows the route was recently retracted and is temporarily unreachable (see Section 3.5.4 of [RFC8966]). At least one of the following MUST be non-NULL: babel-route-calculated-metric or babel-route-received-metric ๐Ÿ’ฏ having both be non-NULL is expected for a route that's received and then advertised. This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model MAY use a different data type that allows differentiation between zero (0) and NULL.

babel-route-seqno: the sequence number this route was advertised with ๐Ÿท๏ธ This is a 16-bit unsigned integer.

babel-route-next-hop: the next-hop address of this route ๐Ÿ‘ฃ this will be empty if the route doesn't have a next-hop address.

babel-route-feasible: a Boolean flag saying whether this route is feasible, as defined in Section 3.5.1 of [RFC8966]). โœ…

babel-route-selected: a Boolean flag saying whether this route is selected, meaning it's currently being used for forwarding and being advertised ๐Ÿ‘‘

3.7. Definition of babel-mac-key-set-obj ๐Ÿ”๐ŸŽ€

this is the MAC key set bundle ๐ŸŽ€ it holds a default-apply switch plus the list of keys themselves ๐Ÿ—๏ธ

   object {
        boolean             rw babel-mac-default-apply;
        babel-mac-key-obj   rw babel-mac-keys<0..*>;
   } babel-mac-key-set-obj;

babel-mac-default-apply: a Boolean flag saying whether this object instance is applied to all new babel-interfaces instances by default ๐ŸŒˆ if "true", the instance gets applied to new babel-interfaces instances when they're created by being included in the babel-if-mac-key-sets list. If "false", the instance isn't applied to new babel-interfaces instances when they're created. An implementation MAY choose to expose this parameter as read-only ("ro") ๐Ÿ™ˆ

babel-mac-keys: a set of babel-mac-key-obj objects ๐Ÿ’–

3.8. Definition of babel-mac-key-obj โœจ

object {
        string      rw babel-mac-key-name;
        boolean     rw babel-mac-key-use-send;
        boolean     rw babel-mac-key-use-verify;
        binary      -- babel-mac-key-value;
        string      rw babel-mac-key-algorithm;
       [operation      babel-mac-key-test;]
} babel-mac-key-obj;

babel-mac-key-name ๐Ÿ”‘ okay so this is the unique name for the MAC key. The key value is never allowed to be read, so the name is how you point at that key inside this object, bestie. The value MUST NOT be empty, and it can only be set when the instance is created (no editing it later, sorry ๐Ÿ™ˆ). The value MAY be auto-generated if you don't supply one when the instance is created.

babel-mac-key-use-send ๐Ÿ“ค tells you whether this key gets used to compute a MAC that goes into the Babel packets you send. If the value is "true", a MAC for sent packets is computed with this key. If it's "false", this key is not used to compute a MAC for sent Babel packets. An implementation MAY choose to expose this parameter as read-only ("ro").

babel-mac-key-use-verify ๐Ÿ“ฅ is the incoming side of things. This key is used to verify incoming Babel packets if the value is "true". If it's "false", no MAC is computed from this key for comparison with the MAC in an incoming packet. An implementation MAY choose to expose this parameter as read-only ("ro") too ๐Ÿ’….

babel-mac-key-value ๐Ÿคซ this is the actual MAC key, and it's top secret. An implementation MUST NOT allow this parameter to be read. You can make that happen by always giving back an empty string when someone reads it, through permissions, or by some other means. This value MUST be provided when the instance is created and is not subsequently writable. Its length has to suit the babel-mac-key-algorithm. If the algorithm is based on the Hashed Message Authentication Code (HMAC) construction [RFC2104], the length MUST be between 0 and an upper limit that is at least the size of the output length (where the "HMAC-SHA256" output length is 32 octets as described in [RFC4868]). Longer lengths MAY be supported but are not necessary if the management system can generate a suitably random value (e.g., by randomly generating a value or by using a key derivation technique as recommended in the security considerations in Section 7 of [RFC8967]). If the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes inclusive as specified by [RFC7693]. Literally so many rules for one little key ๐Ÿ˜ญ๐Ÿ”ฅ.

babel-mac-key-algorithm ๐Ÿงฎ is the name of the MAC algorithm used with this key. The value MUST be the same as one of the enumerations listed in the babel-mac-algorithms parameter. An implementation MAY choose to expose this parameter as read-only ("ro").

babel-mac-key-test ๐Ÿงช is an operation that checks whether the MAC key and MAC algorithm give you the outcome you expect. You feed it a binary string plus a calculated MAC (also a binary string) for that string. The implementation is expected to create a MAC over the binary string using the babel-mac-key-value and the babel-mac-key-algorithm. What you get back is a Boolean: true if the calculated MAC matched the input MAC, or false if they didn't match. Iconic test energy โœจ.

3.9. Definition of babel-dtls-cert-set-obj ๐ŸŽ€

object {
        boolean               rw babel-dtls-default-apply;
        babel-dtls-cert-obj   rw babel-dtls-certs<0..*>;
} babel-dtls-cert-set-obj;

babel-dtls-default-apply ๐Ÿช„ is a Boolean flag for whether this object instance gets applied to all new babel-interfaces instances by default. If it's "true", this instance is applied to new babel-interfaces instances at the time they're created, by including it in the babel-interface-dtls-certs list. If it's "false", this instance is not applied to new babel-interfaces instances when they're created. An implementation MAY choose to expose this parameter as read-only ("ro").

babel-dtls-certs ๐Ÿ“œ is a set of babel-dtls-cert-obj objects. It holds both the certificates this implementation presents for authentication and the ones it accepts from others. Certificates with a non-empty babel-cert-private-key can be presented by this implementation for authentication. The vibe is very organised bestie energy ๐Ÿ’œ.

3.10. Definition of babel-dtls-cert-obj ๐Ÿ”

object {
        string      rw babel-cert-name;
        string      rw babel-cert-value;
        string      rw babel-cert-type;
        binary      -- babel-cert-private-key;
} babel-dtls-cert-obj;

babel-cert-name ๐Ÿท๏ธ is a unique name for this certificate. You use it to identify the certificate in this object instance, because the value itself is way too long to be useful for identification ๐Ÿ™„. This value MUST NOT be empty and can only be provided when the instance is created (so it's not writable after that). The value MAY be auto-generated if you don't explicitly supply one when the instance is created.

babel-cert-value ๐Ÿ“„ is the certificate in Privacy-Enhanced Mail (PEM) format [RFC7468]. This value MUST be provided when the instance is created and is not subsequently writable.

babel-cert-type ๐Ÿ—‚๏ธ is the name of the certificate type of this object instance. The value MUST be the same as one of the enumerations listed in the babel-dtls-cert-types parameter. This value can only be provided when the instance is created and is not subsequently writable.

babel-cert-private-key ๐Ÿ—๏ธ is the value of the private key. If it's non-empty, this certificate can be used by this implementation to provide a certificate during DTLS handshaking. An implementation MUST NOT allow this parameter to be read. You can do that by always providing an empty string when it's read, through permissions, or by other means. This value can only be provided when the instance is created and is not subsequently writable. Guard this one with your life, babe ๐Ÿซถ.

4. Extending the Information Model โœจ

Implementations MAY extend this information model with other parameters or objects. For example, an implementation MAY choose to expose Babel route filtering rules by adding a route filtering object with parameters that fit how route filtering is done in that implementation. The precise means used to extend the information model would be specific to the data model the implementation uses to expose this information. Choose your own adventure, bestie ๐Ÿ—บ๏ธ๐ŸŒˆ.

5. Security Considerations ๐Ÿ›ก๏ธ

This document defines a set of information model objects and parameters that may be exposed and visible from other devices. Some of these objects and parameters may be configured. Securing access to this data and making sure it has integrity is in scope, and it's the responsibility of any data model derived from this information model. Specifically, any YANG [RFC7950] data model is expected to define the security exposure of the various parameters, and a [TR-181] data model will be secured by the mechanisms defined for the management protocol used to transport it. Okay this part is serious, no cap ๐Ÿ”’.

Misconfiguration (whether unintentional or malicious) can prevent reachability or cause poor network performance (increased latency, jitter, etc.). Misconfiguration of security credentials can cause a denial-of-service condition for the Babel routing protocol. The information in this model discloses network topology, which can be used to mount subsequent attacks on traffic traversing the network. ๐Ÿ’€ this is the dramatic part, so pay attention.

This information model defines objects that can allow credentials (for this device, for trusted devices, and for trusted certificate authorities) to be added and deleted. Public keys may be exposed through this model. This model requires that private keys and MAC keys never be exposed. Certificates used by [RFC8968] implementations use separate parameters to model the public parts (including the public key) and the private key. Private stuff stays private, periodt ๐Ÿคซ.

MAC keys are allowed to be as short as zero length. This is useful for testing. It is RECOMMENDED that network operators follow current best practices for key length and generation of keys related to the MAC algorithm associated with the key. Short (and zero-length) keys are highly susceptible to brute-force attacks and therefore SHOULD NOT be used. See the security considerations as described in Section 7 of [RFC8967] for additional considerations related to MAC keys. Note that there are some specific key value recommendations in the fifth paragraph. It says that if it is necessary to derive keys from a human-readable passphrase, "only the derived keys should be communicated to the routers" and "the original passphrase itself should be kept on the host used to perform the key generation" (which would be the management system in the case of a remote management protocol). It also recommends that keys "should have a length of 32 octets (both for HMAC-SHA256 and BLAKE2s), and be chosen randomly". Short keys are a no-go, fr fr ๐Ÿ™…โ€โ™€๏ธ๐Ÿ’–.

This information model uses key sets and certification sets to provide a means of grouping keys and certificates. This makes it easy to use a different set per interface, use the same set for one or more interfaces, have a default set in case a new interface is instantiated, and change keys and certificates as needed. Organised, iconic, a whole main character moment ๐Ÿ‘‘โœจ.

6. IANA Considerations ๐Ÿ“‹

This document has no IANA actions. Nothing to file with IANA this time, so we're free and clear ๐Ÿฆ‹.

7. References ๐Ÿ“š

7.1. Normative References ๐Ÿ’–

Okay, these are the references the spec needs you to read. No skipping! ๐Ÿ“š

7.2. Informative References ๐Ÿฆ‹

These ones are just extra reading, lowkey helpful for the vibe check. โœจ

Acknowledgements ๐Ÿซถ

Huge thank-yous to Juliusz Chroboczek, Toke Hรธiland-Jรธrgensen, David Schinazi, Antonin Dรฉcimo, Roman Danyliw, Benjamin Kaduk, Valery Smyslov, Alvaro Retana, Donald Eastlake, Martin Vigoureux, Acee Lindem, and Carsten Bormann, who were super helpful in refining this information model. You're all iconic! ๐Ÿ‘‘

Most of the wording in the "Notation" section was borrowed from [RFC8193] ๐Ÿ’….

Authors' Addresses ๐ŸŽ€

Barbara Stark
AT&T
TX
United States of America

Email: barbara.stark@att.com


Mahesh Jethanandani
Kloud Services
CA
United States of America

Email: mjethanandani@gmail.com
๐Ÿ“ฆ where this page comes from