Babel Information Model
AT&T
Atlanta, GA
US
barbara.stark@att.com
VMware
California
US
mjethanandani@gmail.com
Routing
Babel routing protocol
Babel
This Babel Information Model provides structured data elements
for a Babel implementation reporting its current state and may
allow limited configuration of some such data elements.
This information model can be used as a basis for creating data
models under various data modeling regimes. This information
model only includes parameters and parameter values useful for
managing Babel over IPv6.
Introduction
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 both authenticated and encrypted.
This document describes an information model for Babel (including implementations
using one or both 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 for an implementation claiming
compliance with this information model. 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.
This information model only includes parameters and parameter values
useful for managing Babel over IPv6. This model has no parameters
or values specific to operating Babel over IPv4, even though
does define a multicast group for
sending and listening to multicast announcements on IPv4.
There is less likelihood of breakage due to inconsistent
configuration and increased implementation simplicity if
Babel is operated always and only over IPv6. Running Babel
over IPv6 requires IPv6 at the link layer and does not need
advertised prefixes, router advertisements or DHCPv6 to be
present in the network. Link-local IPv6 is widely supported
among devices where Babel is expected to be used. Note that
Babel over IPv6 can be used for configuration of both IPv4
and IPv6 routes.
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 BCP014 when, and only when, they
appear in all capitals, as shown here.
Notation
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:
-
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 RFC 3339 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 characters.
-
uint
-
A type representing an unsigned integer number. This information
model does not define a precision.
Overview
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 Babel
- create/delete Babel 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
The following parameters are required to return no value when read:
- MAC key values
- DTLS private keys
Note 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 Information Model
Definition of babel-information-obj
;
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:
-
The name and version of this implementation of the Babel protocol.
-
babel-enable:
-
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").
-
babel-self-router-id:
-
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.
-
babel-self-seqno:
-
The current sequence number included in route updates for routes
originated by this node. This is a 16-bit unsigned integer.
-
babel-metric-comp-algorithms:
-
List of supported cost computation algorithms. Possible
values include "2-out-of-3", and "ETX".
"2-out-of-3" is described in
, section A.2.1.
"ETX" is described in
, section A.2.2.
-
babel-security-supported:
-
List of supported security mechanisms. Possible values include
"MAC" to indicate support of and "DTLS"
to indicate support of .
-
babel-mac-algorithms:
-
List of supported MAC computation algorithms. Possible values
include "HMAC-SHA256", "BLAKE2s-128" to indicate support for
algorithms indicated in .
-
babel-dtls-cert-types:
-
List of supported DTLS certificate types. Possible values include
"X.509" and "RawPublicKey" to indicate support for types
indicated in .
-
babel-stats-enable:
-
Indicates whether statistics collection is enabled
(true) or disabled (false) on all interfaces. When
enabled, existing statistics values are not cleared
and will be incremented as new packets are counted.
-
babel-stats-reset:
-
An operation that resets all babel-if-stats
parameters to zero. This
operation has no input or output parameters.
-
babel-constants:
-
A babel-constants-obj object.
-
babel-interfaces:
-
A set of babel-interface-obj objects.
-
babel-routes:
-
A set of babel-route-obj objects. Contains the routes known to this
node.
-
babel-mac-key-sets:
-
A set of babel-mac-key-set-obj objects. If this
object is implemented, it
provides access to parameters related to the MAC security mechanism.
An implementation MAY choose
to expose this object as read-only ("ro").
-
babel-dtls-cert-sets:
-
A set of babel-dtls-cert-set-obj objects. 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").
Definition of babel-constants-obj
-
babel-udp-port:
-
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.
-
babel-mcast-group:
-
Multicast group for sending and listening to multicast
announcements on IPv6. Default is ff02::1:6.
An implementation MAY choose
to expose this parameter as read-only ("ro").
Definition of babel-interface-obj
;]
[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:
-
Reference to an interface object that can be used to send and
receive IPv6 packets, 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.
-
babel-interface-enable:
-
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").
-
babel-interface-metric-algorithm:
-
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.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-interface-split-horizon:
-
Indicates whether or not the split horizon optimization is used
when calculating metrics on this interface. A value of true
indicates split horizon optimization is used.
Split horizon optimization is described in
, section 3.7.4.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-mcast-hello-seqno:
-
The current sequence number in use for multicast
Hellos sent on this interface.
This is a 16-bit unsigned integer.
-
babel-mcast-hello-interval:
-
The current interval in use for multicast Hellos
sent on this interface. Units are centiseconds.
This is a 16-bit unsigned integer.
-
babel-update-interval:
-
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.
-
babel-mac-enable:
-
Indicates 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-keys-sets:
-
List of references to the babel-mac entries that apply to this
interface. When an interface instance is created, all babel-mac-key-sets
instances with babel-mac-default-apply "true" will be included
in this list.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-mac-verify
-
A Boolean flag indicating whether MACs 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 MAC.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-dtls-enable:
-
Indicates 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:
-
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").
-
babel-dtls-cached-info:
-
Indicates whether the cached_info extension
(see 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:
-
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 (see Appendix A)
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.
-
babel-packet-log-enable:
-
Indicates whether packet logging is enabled
(true) or disabled (false) on this interface.
-
babel-packet-log:
-
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.
Implementations will need to carefully manage and limit
memory used by packet logs.
-
babel-if-stats:
-
Statistics collection object for this interface.
-
babel-neighbors:
-
A set of babel-neighbor-obj objects.
Definition of babel-if-stats-obj
-
babel-sent-mcast-hello:
-
A count of the number of multicast Hello packets sent on this interface.
-
babel-sent-mcast-update:
-
A count of the number of multicast update packets sent on this interface.
-
babel-sent-ucast-hello:
-
A count of the number of unicast Hello packets sent on this interface.
-
babel-sent-ucast-update:
-
A count of the number of unicast update packets sent on this interface.
-
babel-sent-IHU:
-
A count of the number of IHU packets sent on this interface.
-
babel-received-packets:
-
A count of the number of Babel packets received on this interface.
Definition of babel-neighbor-obj
-
babel-neighbor-address:
-
IPv4 or IPv6 address the neighbor sends packets from.
-
babel-hello-mcast-history:
-
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.
-
babel-hello-ucast-history:
-
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.
-
babel-txcost:
-
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.
-
babel-exp-mcast-hello-seqno:
-
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 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:
-
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
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 are not 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. Units are centiseconds.
This is a 16-bit unsigned integer.
-
babel-rxcost:
-
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.
-
babel-cost:
-
The link cost, as 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.
Definition of babel-route-obj
-
babel-route-prefix:
-
Prefix (expressed in IP address format) for which this
route is advertised.
-
babel-route-prefix-length:
-
Length of the prefix for which this route is advertised.
-
babel-route-router-id:
-
The router-id of the router that originated this route.
-
babel-route-neighbor:
-
Reference to the babel-neighbors entry for the neighbor
that advertised this route.
-
babel-route-received-metric:
-
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
NULL 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-NULL.
Having both be non-NULL is expected for a route that is received and
subsequently 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-calculated-metric:
-
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-NULL.
Having both be non-NULL is expected for a route that is received and
subsequently 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 with which this route was advertised.
This is a 16-bit unsigned integer.
-
babel-route-next-hop:
-
The next-hop address of this route. This will be empty
if this route has no next-hop address.
-
babel-route-feasible:
-
A Boolean flag indicating whether this route is feasible,
as defined in Section 3.5.1 of ).
-
babel-route-selected:
-
A Boolean flag indicating whether this route is selected
(i.e., whether it is currently being used for forwarding and
is being advertised).
Definition of babel-mac-key-set-obj
;
} babel-mac-key-set-obj;
]]>
-
babel-mac-default-apply:
-
A Boolean flag indicating whether this object 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-if-mac-key-sets 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").
-
babel-mac-keys:
-
A set of babel-mac-key-obj objects.
Definition of babel-mac-key-obj
-
babel-mac-key-name:
-
A unique name for this MAC 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.
-
babel-mac-key-use-send:
-
Indicates whether this key value is used to compute a MAC
and include that MAC in the sent Babel
packet. A MAC for sent packets is computed using this key if the value
is "true". If the value is "false", this key is not used to
compute a MAC to include in sent Babel packets.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-mac-key-use-verify:
-
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 MAC is computed from this key for
comparing with the MAC in an incoming packet.
An implementation MAY choose
to expose this parameter as read-only ("ro").
-
babel-mac-key-value:
-
The value of the MAC key. An implementation MUST NOT allow
this parameter to be read. This can be done by always providing
an empty string when read, or through permissions, or other means.
This value MUST be provided when this
instance is created, and is not subsequently writable.
This value is of a length suitable for the associated
babel-mac-key-algorithm. If the algorithm is based on the HMAC
construction , the length MUST be between 0 and the
block size of the underlying hash inclusive (where "HMAC-SHA256"
block size is 64 bytes as described in ). If the
algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes
inclusive, as described in .
-
babel-mac-key-algorithm
-
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:
-
An operation that allows the MAC key and MAC algorithm to
be tested to see if they produce an expected outcome. Input
to this operation are a binary string and a calculated MAC
(also in the format of a binary string) for the binary 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. The
output of this operation is a Boolean indication that the
calculated MAC matched the input MAC (true) or
the MACs did not match (false).
Definition of babel-dtls-cert-set-obj
;
} babel-dtls-cert-set-obj;
]]>
-
babel-dtls-default-apply:
-
A Boolean flag indicating whether this object 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").
-
babel-dtls-certs:
-
A set of babel-dtls-cert-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.
Definition of babel-dtls-cert-obj
-
babel-cert-name:
-
A unique name for this 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.
-
babel-cert-value:
-
The certificate in PEM format .
This value MUST be provided when this
instance is created, and is not subsequently writable.
-
babel-cert-type:
-
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.
-
babel-cert-private-key:
-
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 when read, or through permissions, or other means.
This value can only be provided when this
instance is created, and is not subsequently writable.
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 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.
Security Considerations
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.
Misconfiguration (whether unintentional or malicious) can prevent reachability
or cause poor network performance (increased latency, jitter, etc.).
The information in this model discloses network topology, which can be used
to mount subsequent attacks on traffic traversing the network.
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
implementations use separate parameters to model the public
parts (including the public key) and the private key.
MAC keys are allowed to be as short as zero-length. This is
useful for testing. Network operators are RECOMMENDED to 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 section of
for additional considerations related to MAC keys.
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, the same set for one or more interfaces,
have a default set in case a new interface is instantiated and to
change keys and certificates as needed.
IANA Considerations
This document has no IANA actions.
Acknowledgements
Juliusz Chroboczek, Toke Hoeiland-Joergensen, David Schinazi,
Antonin Decimo,
Acee Lindem, and Carsten Bormann have been very helpful in
refining this information model.
The language in the Notation section was mostly taken from .
References
Normative References
HMAC: Keyed-Hashing for Message Authentication
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind
Key words for use in RFCs to Indicate Requirement Levels
In 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.
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]
Date and Time on the Internet: Timestamps
This 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.
Textual Encodings of PKIX, PKCS, and CMS Structures
This 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.
The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)
This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC).
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 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 Protocol
Babel 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.
Babel Routing Protocol over Datagram Transport Layer Security
The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS).
MAC authentication for the Babel routing protocol
This 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 Standardization
Libpcap File Format
Wireshark
Informative References
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 Language
YANG 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.
Device Data Model
Broadband Forum