Babel Information ModelAT&TAtlanta, GAUSbarbara.stark@att.comVMwareCaliforniaUSmjethanandani@gmail.com
Routing
Babel routing protocolBabelThis Babel Information Model can be used to create data models under various
data modeling regimes. It allows a Babel implementation (via
a management protocol or interface) to report on its current state and
may allow some limited configuration of protocol constants.Babel is a loop-avoiding distance-vector routing protocol defined in . defines a security mechanism that allows Babel packets to be cryptographically
authenticated, and defines a security mechanism that allows Babel packets to be encrypted.
This document describes an information model for Babel (including implementations
using one of these security mechanisms) that can be used to create management
protocol data models (such as a NETCONF YANG data model).Due to the simplicity of the Babel protocol, most of the information model
is focused on reporting Babel protocol operational state, and very little of
that is considered mandatory to implement (contingent on a management protocol
with Babel support being implemented). Some parameters may be configurable.
However, it is up to the Babel implementation whether to allow any of these
to be configured within its implementation. Where the implementation does
not allow configuration of these parameters, it may still choose to expose
them as read-only.The Information Model is presented using a hierarchical structure. This does
not preclude a data model based on this Information Model from using a referential
or other structure.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in and updated by .This document uses a programming language-like notation to define the properties
of the objects of the information model. An optional property is enclosed
by square brackets, [ ], and a list property is indicated by two numbers
in angle brackets, <m..n>, where m indicates the minimal number
of list elements,
and n indicates the maximum number of list elements. The symbol * for n means there are no defined limits on the number of list elements. Each parameter
and object includes an indication of “ro” or “rw”. “ro” means the parameter
or object is read-only. “rw” means it is read-write. For an object, read-write
means instances of the object can be created or deleted.
If an implementation is allowed to choose
to implement a “rw” parameter as read-only, this is noted in the parameter
description.The object definitions use base types that are defined as follows:
A binary string (sequence of octets).
A type representing a Boolean value.
A non-negative integer that monotonically increases. Counters may have discontinuities
and they are not expected to persist across restarts.
A type representing a date and time using the Gregorian calendar. The datetime
format MUST conform to RFC 3339 .
A type representing an IP address. This type supports both IPv4 and IPv6
addresses.
A type representing a remote procedure call or other action that can be used
to manipulate data elements or system behaviors.
A type representing a reference to another information or data model element
or to some other device resource.
A type representing a human-readable string consisting of a (possibly restricted)
subset of Unicode and ISO/IEC 10646 characters.
A type representing an unsigned integer number. This information
model does not define a precision.The Information Model is hierarchically structured as follows:Most parameters are read-only. Following is a descriptive list of the parameters that are not required to be read-only:enable/disable Babelcreate/delete babel-hmac objectscreate/delete babel-dtls objectsenable/disable statistics collectionConstant: UDP portConstant: IPv6 multicast groupInterface: Link typeInterface: enable/disable Babel on this interfaceInterface: sets of HMAC keysInterface: HMAC algorithmInterface: verify received HMAC packetsInterface: set of DTLS certificatesInterface: use cached info extensionsInterface: preferred order of certificate typesInterface: enable/disable packet logHMAC-keys: create/delete entriesHMAC-keys: use to sign packetsHMAC-keys: use to verify packetsDTLS-certs: create/delete entriesThe following parameters are required to return no value when read:HMAC key valuesDTLS certificate valuesNote that this overview is intended simply to be informative and is not normative.
If there is any discrepancy between this overview and the detailed information
model definitions in subsequent sections, the error is in this overview.
The name and version of this implementation of the Babel protocol.
When written, it configures whether the protocol should be enabled
(true) or disabled (false).
A read from the running or intended datastore indicates the
configured administrative value of whether the protocol is enabled
(true) or not (false). A read from the operational datastore indicates whether
the protocol is actually running (true) or not (i.e., it indicates the
operational state of the protocol).
A data model that does not replicate parameters for running and operational
datastores can implement this as two separate parameters.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
The router-id used by this instance of the Babel protocol
to identify itself.
describes this as an arbitrary string of 8 octets.
The router-id value MUST NOT consist of all zeroes or all ones.
Lists the collections of link properties supported by this instance of Babel.
Valid enumeration values are
defined in the Babel Link Properties registry (see ).
The current sequence number included in route updates for routes
originated by this node. This is a 16-bit unsigned integer.
List of supported cost computation algorithms. Possible
values include “k-out-of-j”, and “ETX”.
List of supported security mechanisms. Possible values include
“HMAC” and “DTLS”.
List of supported HMAC computation algorithms. Possible values
include “HMAC-SHA256”, “BLAKE2s”.
List of supported DTLS certificate types. Possible values include
“X.509” and “RawPublicKey”.
Indicates whether statistics collection is enabled
(true) or disabled (false) on all interfaces, including
neighbor-specific statistics (babel-nbr-stats).
An operation that resets all babel-if-stats and babel-nbr-stats
parameters to zero. This
operation has no input or output parameters.
A babel-constants-obj object.
A set of babel-interface-obj objects.
A set of babel-route-obj objects. Contains the routes known to this
node.
A babel-hmac-obj object. If this
object is implemented, it
provides access to parameters related to the HMAC security mechanism.
An implementation MAY choose
to expose this object as read-only (“ro”).
A babel-dtls-obj object. If this
object is implemented, it
provides access to parameters related to the DTLS security mechanism.
An implementation MAY choose
to expose this object as read-only (“ro”).
UDP port for sending and listening for Babel packets. Default
is 6696. An implementation MAY choose
to expose this parameter as read-only (“ro”).
This is a 16-bit unsigned integer.
Multicast group for sending and listening to multicast
announcements on IPv6. Default is ff02:0:0:0:0:0:1:6.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Reference to an IPv6 interface object as defined by
the data model (e.g., YANG , BBF ).
Referencing syntax will be specific to the data model. If there is
no set of interface objects available, this should be a string that indicates
the interface name used by the underlying operating system.
When written, it configures whether the protocol should be enabled
(true) or disabled (false) on this interface.
A read from the running or intended datastore indicates the
configured administrative value of whether the protocol is enabled
(true) or not (false). A read from the operational datastore indicates whether
the protocol is actually running (true) or not (i.e., it indicates the
operational state of the protocol).
A data model that does not replicate parameters for running and operational
datastores can implement this as two separate parameters.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Indicates the properties of the link. The value MUST be one of those listed in the
babel-supported-link-properties parameter. Valid enumeration values are
identified in Babel Link Properties registry.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Indicates the metric computation algorithm used on this interface.
The value MUST be one of those listed in the babel-information-obj babel-metric-comp-algorithms
parameter.
The current sequence number in use for multicast
Hellos sent on this interface.
This is a 16-bit unsigned integer.
The current interval in use for multicast Hellos
sent on this interface. Units are centiseconds.
This is a 16-bit unsigned integer.
The current interval in use for all updates (multicast
and unicast) sent on this interface. Units are centiseconds.
This is a 16-bit unsigned integer.
Indicates whether the HMAC security mechanism is enabled
(true) or disabled (false).
An implementation MAY choose
to expose this parameter as read-only (“ro”).
List of references to the babel-hmac entries that apply to this
interface. When an interface instance is created, all babel-hmac-key-sets
instances with babel-hmac-default-apply “true” will be included
in this list.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
The name of the HMAC algorithm used on this interface.
The value MUST be the same as one of the enumerations
listed in the babel-hmac-algorithms parameter.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
A Boolean flag indicating whether HMAC hashes in incoming Babel packets
are required to be present and are verified. If this parameter is “true”,
incoming packets are required to have a valid HMAC hash.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Indicates whether the DTLS security mechanism is enabled
(true) or disabled (false).
An implementation MAY choose
to expose this parameter as read-only (“ro”).
List of references to the babel-dtls-cert-sets entries that apply to this
interface. When an interface instance is created, all babel-dtls-cert-sets
instances with babel-dtls-default-apply “true” will be included
in this list.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Indicates whether the cached_info extension 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”).
List of supported certificate types, in order of preference.
The values MUST be among those
listed in the babel-dtls-cert-types parameter.
This list is used to populate the server_certificate_type
extension in a Client Hello. Values that are present 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 will be used to populate
the client_certificate_type extension in a Client Hello.
Indicates whether packet logging is enabled
(true) or disabled (false) on this interface.
A reference or url link to a file that contains a timestamped log
of packets received and sent on babel-udp-port on this interface.
The file format with .pcap file extension SHOULD be supported for
packet log files. Logging is
enabled / disabled by babel-packet-log-enable.
Statistics collection object for this interface.
A set of babel-neighbors-obj objects.
A count of the number of multicast Hello packets sent on this interface.
A count of the number of multicast update packets sent on this interface.
A count of the number of Babel packets received on this interface.
IPv4 or IPv6 address the neighbor sends packets from.
The multicast Hello history of whether or not
the multicast Hello packets prior to babel-exp-mcast-hello-seqno
were received.
A binary sequence where the most recently received Hello
is expressed as a “1” placed in the left-most bit, with prior bits shifted
right (and “0” bits placed between prior Hello bits and most recent Hello
for any not-received Hellos). This value should be displayed using
hex digits ([0-9a-fA-F]). See , section A.1.
The unicast Hello history of whether or not the
unicast Hello packets prior to babel-exp-ucast-hello-seqno were received.
A binary sequence where the most recently received Hello
is expressed as a “1” placed in the left-most bit, with prior bits shifted
right (and “0” bits placed between prior Hello bits and most recent Hello
for any not-received Hellos). This value should be displayed using
hex digits ([0-9a-fA-F]). See , section A.1.
Transmission cost value from the last IHU packet received from
this neighbor, or maximum value to indicate the IHU hold timer
for this neighbor has expired. See , section 3.4.2.
This is a 16-bit unsigned integer.
Expected multicast Hello sequence number of
next Hello to be received from this neighbor. If multicast Hello packets
are not expected, or processing of multicast packets is not enabled, this
MUST be 0.
This is a 16-bit unsigned integer.
Expected unicast Hello sequence number of next
Hello to be received from this neighbor. If unicast Hello packets are not
expected, or processing of unicast packets is not enabled, this MUST be
0.
This is a 16-bit unsigned integer.
The current sequence number in use for unicast Hellos
sent to this neighbor.
This is a 16-bit unsigned integer.
The current interval in use for unicast Hellos
sent to this neighbor. Units are centiseconds.
This is a 16-bit unsigned integer.
Reception cost calculated for this neighbor. This value is
usually derived from the Hello history, which may be combined with other
data, such as statistics maintained by the link layer. The rxcost is sent
to a neighbor in each IHU. See , section 3.4.3.
This is a 16-bit unsigned integer.
Link cost is computed from the values
maintained in the neighbor table: the statistics kept in the
neighbor table about the reception of Hellos, and the txcost
computed from received IHU packets.
This is a 16-bit unsigned integer.
Statistics collection object for this neighbor.
A count of the number of unicast Hello packets sent to this neighbor.
A count of the number of unicast update packets sent to this neighbor.
A count of the number of IHU packets sent to this neighbor.
A count of the number of Hello packets received from this neighbor.
A count of the number of update packets received from this neighbor.
A count of the number of IHU packets received from this neighbor.
Prefix (expressed in IP address format) for which this
route is advertised.
Length of the prefix for which this route is advertised.
router-id of the source router for which this route
is advertised.
Reference to the babel-neighbors entry for the neighbor
that advertised this route.
The metric with which this route was advertised
by the neighbor, or maximum value to indicate the route was
recently retracted and is temporarily unreachable (see Section 3.5.5
of ). This metric will be
0 (zero) if the route was not received from a neighbor
but was generated through other means. At least one of
babel-route-calculated-metric
and babel-route-received-metric MUST be non-zero.
Having both be non-zero is expected for a route that is received and
subsequently advertised.
This is a 16-bit unsigned integer.
A calculated metric for this route. How the
metric is calculated is implementation-specific. Maximum value
indicates the route was recently retracted and is temporarily unreachable
(see Section 3.5.5 of ).
At least one of babel-route-calculated-metric and
babel-route-received-metric MUST be non-zero.
Having both be non-zero is expected for a route that is received and
subsequently advertised.
This is a 16-bit unsigned integer.
The sequence number with which this route was advertised.
This is a 16-bit unsigned integer.
The next-hop address of this route. This will be empty
if this route has no next-hop address.
A Boolean flag indicating whether this route is feasible,
as defined in Section 3.5.1 of ).
A Boolean flag indicating whether this route is selected
(i.e., whether it is currently being used for forwarding and
is being advertised).
A Boolean flag indicating whether this babel-hmac instance is
applied to all new babel-interface instances, by default.
If “true”, this instance is applied to
new babel-interfaces instances at the time they are created, by including
it in the babel-interface-hmac-keys list.
If “false”, this instance is not applied to new babel-interfaces
instances when they are created.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
A set of babel-hmac-keys-obj objects.
A unique name for this HMAC key that can be used to identify
the key in this object instance, since the key value is not
allowed to be read. This value MUST NOT be empty and can only be provided when this
instance is created (i.e., it is not subsequently writable).
The value MAY be auto-generated if not explicitly supplied when the instance is created.
Indicates whether this key value is used to sign sent Babel
packets. Sent packets are signed using this key if the value
is “true”. If the value is “false”, this key is not used to
sign sent Babel packets.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
Indicates whether this key value is used to verify
incoming Babel packets. This key is used to verify
incoming packets if the value is “true”. If the value
is “false”, no HMAC is computed from this key for
comparing an incoming packet.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
The value of the HMAC key. An implementation MUST NOT allow
this parameter to be read. This can be done by always providing
an empty string, or through permissions, or other means.
This value MUST be provided when this
instance is created, and is not subsequently writable.
An operation that allows the HMAC key and hash algorithm to
be tested to see if they produce an expected outcome. Input
to this operation MUST be a non-empty binary string. The implementation is
expected to create a hash of this string using the
babel-hmac-key-value and the babel-hmac-algorithm. The
output of this operation is the resulting hash,
as a binary string.
A Boolean flag indicating whether this babel-dtls instance is
applied to all new babel-interface instances, by default.
If “true”, this instance is applied to
new babel-interfaces instances at the time they are created, by including
it in the babel-interface-dtls-certs list.
If “false”, this instance is not applied to new babel-interfaces
instances when they are created.
An implementation MAY choose
to expose this parameter as read-only (“ro”).
A set of babel-dtls-keys-obj objects. This contains both certificates
for this implementation to present for authentication, and to accept
from others. Certificates with a non-empty babel-cert-private-key can
be presented by this implementation for authentication.
A unique name for this DTLS certificate that can be used to identify
the certificate in this object instance, since the value is too long
to be useful for identification. This value MUST NOT be empty and can
only be provided when this instance is created (i.e., it is not
subsequently writable). The value MAY be auto-generated if not
explicitly supplied when the instance is created.
The DTLS certificate in PEM format .
This value MUST be provided when this
instance is created, and is not subsequently writable.
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 this
instance is created, and is not subsequently writable.
The value of the private key. If this is 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. This can be done by always providing
an empty string, or through permissions, or other means.
This value can only be provided when this
instance is created, and is not subsequently writable.
An operation that allows a hash of the provided input string
to be created using the certificate public key and the
SHA-256 hash algorithm. Input
to this operation MUST be a non-empty binary string. The
output of this operation is the resulting hash, as a
binary string.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 appropriate
to 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.This document defines a set of information model objects and parameters that
may be exposed to be visible from other devices, and some of which may be
configured. Securing access to and ensuring the integrity of this data
is in scope of and the responsibility of any data model derived from this
information model. Specifically, any YANG data model is expected
to define security exposure of the various parameters, and a data model
will be secured by the mechanisms defined for the management protocol used to
transport it.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 and shared secrets may be exposed through
this model. This model requires that private keys never be exposed. The Babel
security mechanisms that make use of these credentials
(e.g., , ) are expected to
define what credentials can be used with those mechanisms.This document defines a Babel Link Properties registry for the values of the babel-link-properties
and babel-supported-link-properties parameters to be listed under the Babel Routing
Protocol registry.Valid Babel Link Properties names are normatively defined asMUST be at least 1 character and no more than 20 characters longMUST contain only US-ASCII letters ‘A’ - ‘Z’ and ‘a’ -
‘z’, digits ‘0’ - ‘9’, and hyphens (‘-‘, ASCII 0x2D or decimal 45)MUST contain at least one letter (‘A’ - ‘Z’ or ‘a’ - ‘z’)MUST NOT begin or end with a hyphenhyphens MUST NOT be adjacent to other hyphensThe rules for Link Properties names, excepting the limit of 20 characters maximum,
are also expressed below (as a non-normative convenience) using ABNF .The allocation policy of this registry is Specification Required .The initial values in the “Babel Link Properties” registry are:NameLinks PropertiesReferenceotherimplementation-specific default properties used(this document)tunnel2-out-of-3, split horizon, RTT(this document)wired2-out-of-3, split horizon, no RTT(this document)wirelessETX, no split horizon, no RTT(this document)exp-*Reserved for Experimental Use(this document)The link properties listed are expected to include the metric computation algorithm that will be used for the link and whether split horizon optimization is used. If round trip time is used in metric computation, this should also be noted (any link property that does not mention RTT will be assumed not to use it).Juliusz Chroboczek, Toke Høiland-Jørgensen, David Schinazi, Acee Lindem, and Carsten Bormann have been very helpful in refining this information model.The language in the Notation section was mostly taken from .ASCII format for network interchangeKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Textual Encodings of PKIX, PKCS, and CMS StructuresThis document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Babel Routing ProtocolBabel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557.Libpcap File FormatWiresharkDate and Time on the Internet: TimestampsThis document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Information Model for Large-Scale Measurement Platforms (LMAPs)This Information Model applies to the Measurement Agent within an LMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols.Babel Routing Protocol over Datagram Transport Layer SecurityThe Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS).HMAC authentication for the Babel routing protocolThis document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298.Information Technology - Universal Multiple-Octet Coded Character Set (UCS)International Organization for StandardizationDevice Data ModelBroadband ForumAll open issues have been closed.Closed Issues:See minutes of IETF 104 for discussion of issues that led to changes noted for 2019-07-08HMAC spec adds other parameters to neighbor table. Check these to see if any need to be readable or writable. / None were identified.Actions to add and delete HMAC and DTLS credentials, and parameters that allow credential to be identified without allowing access to private credential info. Will have separate sub-tables for HMAC and DTLS credentials. / Instead, there is a normative statement that the parameter values must never be supplied when read.Consider the following statistics: under interface object: sent multicast Hello, sent updates, received Babel messages; under neighbor object: sent unicast Hello, sent updates, sent IHU, received Hello, received updates, received IHUs. Would also need to enable/disable stats and clear stats.Message log (optional to implement) is still in. Support for the libpcap file format is “SHOULD”.Single security table with (optional) reference to interfaces that security mechanism applies to. / This actually became separate objects for DTLS and HMAC.Should ABNF be normative in IANA Considerations section? Decision was to leave it as is.I want to get rid of the security log, because all Babel messages (which should be defined as all messages to/from the udp-port) are be logged by message-log. I don’t like message log as it is. I think if logging is enabled it should just write to a text file. This will mean there also needs to be a means of downloading/reading the log file. Closed by having single log for all messages to/from udp port and log is represented by a string that can be reference to filename or some other part of the overall data model (depends on data model).Check description of enable parameters to make sure ok for YANG and TR-181. Closed by updating description to be useful for YANG and TR-181, using language consistent with YANG descriptions. Done.Distinguish signed and unsigned integers? All integers are unsigned and size is mentioned in description of each uint parameter.Datatype of the router-id: Closed by introducing binary datatype and using that for router-idbabel-neighbor-address as IPv6-only: Closed by leaving as is (IPv4 and IPv6)babel-implementation-version includes the name of the implementation: Closed by adding “name” to descriptionDelete external-cost?: Closed by deleting.Would it be useful to define some parameters for reporting statistics or
logs? [2 logs are now included. If others are needed they need to be proposed. See Open Issues for additional thoughts on logs and statistics.]Closed by defining base64 type and using it for all router IDs: “babel-self-router-id:
Should this be an opaque 64-bit value instead of int?”Closed as “No”: Do we need a registry for the supported security mechanisms?
[Given the current limited set, and unlikelihood of massive expansion, I
don’t think so. But we can if someone wants it.]This draft must be reviewed against draft-ietf-babel-rfc6126bis. [I feel
like this has been adequately done, but I could be wrong.]babel-interfaces-obj: Juliusz:”This needs further discussion, I fear some
of these are implementation details.” [In the absence of discussion, the
current model stands. Note that all but link-type and the neighbors sub-object
are optional. If an implementation does not have any of the optional elements
then it simply doesn’t have them and that’s fine.]Would it be useful to define some parameters specifically for security anomalies?
[The 2 logs should be useful in identifying security anomalies. If more is
needed, someone needs to propose.]I created a basic security model. It’s useful for single (or no) active security
mechanism (e.g., just HMAC, just DTLS, or neither); but not multiple active
(both HMAC and DTLS — which is not the same as HMAC of DTLS and would just
mean that HMAC would be used on all unencrypted messages — but right now
the model doesn’t allow for configuring HMAC of unencrypted messages for
routers without DTLS, while DTLS is used if possible). OK? [No-one said otherwise.]babel-external-cost may need more work. [if no comment, it will be left as
is]babel-hello-[mu]cast-history: the Hello history is formated as 16 bits, per
A.1 of 6126bis. Is that a too implementation specific? [We also now have
an optional-to-implement log of received messages, and I made these optional.
So maybe this is ok?]rxcost, txcost, cost: is it ok to model as integers, since 6126bis 2.1 says
costs and metrics need not be integers. [I have them as integers unless someone
insists on something else.]For the security log, should it also log whether the credentials were considered
ok? [Right now it doesn’t and I think that’s ok because if you log Hellos
it was ok and if you don’t it wasn’t.]Should Babel link types have an IANA registry? [Agreed to do this at IETF
102.]Individual Drafts:
Initial individual draft version
Addressed comments received in 2016-07-15 email from J. ChroboczekWorking group drafts:
Addressed points noted with “oops” in https://www.ietf.org/proceedings/98/slides/slides-98-babel-babel-information-model-00.pdf
Removed item from issue list that was agreed (in Prague)
not to be an issue. Added description of data types under Notation section,
and used these in all data types. Added babel-security and babel-trust.changed babel-version description to babel-implementation-versionreplace optional babel-interface-seqno with optional babel-mcast-hello-seqno
and babel-ucast-hello-seqnoreplace optional babel-interface-hello-interval with optional babel-mcast-hello-interval
and babel-ucast-hello-intervalremove babel-request-trigger-ackremove “babel-router-id: router-id of the neighbor”; note that parameter
had previously been removed but description had accidentally not been removedadded an optional “babel-cost” field to babel-neighbors object, since the
spec does not define how exactly the cost is computed from rxcost/txcostdeleted babel-source-garbage-collection-timechange babel-lossy-link to babel-link-type and make this an enumeration;
added at top level babel-supported-link-types so which are supported by this
implementation can be reportedchanges to babel-security-obj to allow self credentials to be one or more
instances of a credential object. Allowed trusted credentials to include
CA credentials; made some parameter name changesupdated references and Introductionadded Overview sectiondeleted babel-sources-objadded feasible Boolean to routesadded section to briefly describe extending the information model.deleted babel-route-neighbortried to make definition of babel-interface-reference cleareradded security and message logsadded reference to RFC 8174 (update to RFC 2119 on key words)applied edits to Introduction text per Juliusz email of 2018-04-06Deleted sentence in definition of “int” data type that said it was also
used for enumerations. Changed all enumerations to strings. The only enumerations
were for link types, which are now “ethernet”, “wireless”, “tunnel”, and
“other”.deleted [ip-address babel-mcast-group-ipv4;]babel-external-cost description changedbabel-security-self-cred: Added “any private key component of a credential
MUST NOT be readable;”hello-history parameters put recent Hello in most significant bit and length
of parameter is not constrained.babel-hello-seqno in neighbors-obj changed to babel-exp-mcast-hello-seqno
and babel-exp-ucast-hello-seqnoadded babel-route-neighbor back again. It was mistakenly deletedchanged babel-route-metric and babel-route-announced-metric to babel-route-received-metric
and babel-route-calculated-metricchanged model of security object to put list of supported mechanisms at
top level and separate security object per mechanism. This caused some other
changes to the security objectchanged babel-mcast-group-ipv6 to babel-mcast-grouplink type parameters changed to point to newly defined registrybabel-ucast-hello-interval moved to neighbor objectbabel-ucast-hello-seqno moved to neighbor objectbabel-neighbor-ihu-interval deletedin log descriptions, included statement that there SHOULD be ability to
clear logsadded IANA registry for link typesadded “ro” and “rw” to tables for read-write and read-onlyadded metric computation parameter to interfacesecurity modeled with single table under information-obj and
references to interfaces that instance applies tochanged int to uint because all integers in model were unsigned; added
size of integer to description of each uint parameterdeleted log object and made single message log that points to file or
other data model object used to maintain logsdeleted babel-credentials; there are no more “common” objects; hmac keys
and DTLS certificates are more explicitly modeledchanged definition of babel-security-supportedadded parameters for HMAC and DTLSadded statisticschanged all instances of “message” to “packet”changed Link Type registry in IANA considerations to Lik Property Typeschanged direction of reference for HMAC and DTLS objects to be
from interface to these objectsprovided DTLS certificate objects with a unique namechanged received and calculated metric descriptions to make
clear that it is ok to have bothconstrained interface reference to only IPv6 interfacesbabel-dtls-enable and babel-hmac-enable moved to interfaces and made rwrenamed babel-dtls and babel-hmac to babel-dtls-cert-sets and babel-hmac-key-sets and references to them from interfaces are babel-if-dtls-cert-sets and babel-if-hmac-key-setshttps://github.com/bhstark2/babel-information-model/issues/16 with nitshttps://github.com/bhstark2/babel-information-model/issues/14 addressing parameters not allowed to be empty/nullhttps://github.com/bhstark2/babel-information-model/issues/18 on IANA link properties table