Babel routing protocol B. Stark
Internet-Draft AT&T
Intended status: Informational June 5, 2018
Expires: December 7, 2018

Babel Information Model
draft-ietf-babel-information-model-03

Abstract

This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as netconf) to report on its current state and may allow some limited configuration of protocol constants.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 7, 2018.

Copyright Notice

Copyright (c) 2018 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Babel is a loop-avoiding distance-vector routing protocol defined in draft-ietf-babel-rfc6126bis. draft-babel-7298bis defines a security mechanism that allows Babel messages to be cryptographically authenticated, and draft-babel-dtls defines a security mechanism that allows Babel messages to encrypted. This document describes an information model for Babel (including implementations using one of these security mechanisms) that can be used to created management protocol data models (such as a netconf [RFC6241] YANG data model).

Due to the simplicity of the Babel protocol, most of the information model is focused on reporting status of the Babel protocol, and very little of that is considered mandatory to implement (conditional 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.

1.1. Requirements Language

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 RFC 2119 and updated by RFC 8174 .

1.2. 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 values, and n is the maximum. The symbol * for n means no upper bound.

The object definitions use base types that are defined as follows:

base64
An opaque array of bytes.
boolean
A type representing a boolean value.
counter
A non-negative integer that monotonically increases. Counters may have discontinuities and they are not expected to persist across restarts.
credentials
An opaque type representing credentials needed by a cryptographic mechanism to secure communication. Data models must expand this opaque type as needed and required by the security protocols utilized.
datetime
A type representing a date and time using the Gregorian calendar. The datetime format MUST conform to RFC 3339 [RFC3339].
int
A type representing signed or unsigned integer numbers. This information model does not define a precision nor does it make a distinction between signed and unsigned number ranges.
ip-address
A type representing an IP address. This type supports both IPv4 and IPv6 addresses.
string
A type representing a human-readable string consisting of a (possibly restricted) subset of Unicode and ISO/IEC 10646 [ISO.10646] characters.
uri
A type representing a Uniform Resource Identifier as defined in STD 66 [RFC3986].

2. Overview

The Information Model is hierarchically structured as follows:

information object
   includes implementation version, router id, this node seqno, 
     enable flag parameters, supported security mechanisms
   constants object (exactly one per information object)
      includes UDP port and optional multicast group
        parameters
   interfaces object
      includes interface reference, Hello seqno and intervals, 
        update interval, link type, external cost parameters
      neighbors object
         includes neighbor IP address, Hello history, cost 
           parameters
      security object (per interface)
         includes enable flag, self credentials (credential 
           object), trusted credentials (credential object)
   security object (common to all interfaces)
      includes enable flag, self credentials (credential 
        object), trusted credentials (credential object)
   routes object
      includes route prefix, source router, reference to 
        advertising neighbor, metric, sequence number, whether 
        route is feasible, whether route is selected

Following is a list of the data elements that an implementation can choose to allow to be configurable:

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.

3. The Information Model

3.1. Definition of babel-information-obj

     object {
          string                babel-implementation-version;
          boolean               babel-enable;
          base64                babel-self-router-id;
          string                babel-supported-link-types<1..*>;
         [int                   babel-self-seqno;]
          string                babel-metric-comp-algorithms<1..*>;
          string                babel-security-supported<0..*>;
          babel-constants-obj   babel-constants;
          babel-interfaces-obj  babel-interfaces<0..*>;
          babel-routes-obj      babel-routes<0..*>;
          babel-security-obj    babel-security<0..*>;
      }babel-information-obj;

3.2. Definition of babel-constants-obj

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

3.3. Definition of babel-interfaces-obj

     object {
          string               babel-interface-reference;
         [boolean              babel-interface-enable;]
          int                  babel-link-type;
         [int                  babel-mcast-hello-seqno;]
         [int                  babel-ucast-hello-seqno;]
         [int                  babel-mcast-hello-interval;]
         [int                  babel-ucast-hello-interval;]
         [int                  babel-update-interval;]
         [int                  babel-external-cost;]
         [boolean              babel-message-log-enable;]
         [babel-log-obj        babel-message-log<0..*>;]
          babel-neighbors-obj  babel-neighbors<0..*>;
         [babel-security-obj   babel-interface-security<0..*>;]
      }babel-interfaces-obj;

3.4. Definition of babel-neighbors-obj

     object {
          ip-address           babel-neighbor-address;
         [string               babel-hello-mcast-history;]
         [string               babel-hello-ucast-history;]
          int                  babel-txcost;
          int                  babel-exp-mcast-hello-seqno;
          int                  babel-exp-ucast-hello-seqno;
          int                  babel-neighbor-ihu-interval;
         [int                  babel-rxcost]
         [int                  babel-cost]
      }babel-neighbors-obj;

3.5. Definition of babel-security-obj

     object {
          string                babel-security-mechanism
          boolean               babel-security-enable;
          babel-credential-obj  babel-security-self-cred<0..*>;
          babel-credential-obj  babel-security-trust<0..*>;
         [boolean               babel-credvalid-log-enable;]
         [babel-log-obj         babel-credvalid-log<0..*>;]    
      }babel-security-obj;

3.6. Definition of babel-routes-obj

     object {
          ip-address           babel-route-prefix;
          int                  babel-route-prefix-length;
          base64               babel-route-router-id;
          string               babel-route-neighbor;
         [int                  babel-route-received-metric;]
         [int                  babel-route-calculated-metric;]
          int                  babel-route-seqno;
          ip-address           babel-route-next-hop;
          boolean              babel-route-feasible;
          boolean              babel-route-selected;
      }babel-routes-obj;

4. Common Objects

4.1. Definition of babel-credential-obj

     object {
          credentials          babel-cred;
    }babel-credential-obj;

4.2. Definition of babel-log-obj

     object {
          datetime           babel-log-time;
          string             babel-log-entry;
    }babel-log-obj;

5. 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.

6. 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. Any mechanism or protocol that is used to transmit this information or allow for its configuration is also responsible for ensuring this is done so in a secure manner.

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 are not defined or identified in this model.

7. IANA Considerations

This document makes no IANA requests.

8. Acknowledgements

Juliusz Chroboczek, Toke Høiland-Jørgensen, and David Schinazi have been very helpful in refining this information model.

The language in the Notation section was mostly taken from RFC 8193.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[rfc6126bis] Chroboczek, J., "The Babel Routing Protocol", Work in Progress, draft-ietf-babel-rfc6126bis, October 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

9.2. Informative References

[BABEL-DTLS] Schinazi, D., "TBD", Work in Progress, rfc6347, March 2018.
[BABEL-HMAC] Ovsienko, D., "Babel HMAC Cryptographic Authentication", Work in Progress, draft-ovsienko-babel-rfc7298bis, March 2018.
[ISO.10646] International Organization for Standardization, "Information Technology - Universal Multiple-Octet Coded Character Set (UCS)", ISO Standard 10646:2014, 2014.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011.
[RFC8193] Burbridge, T., Eardley, P., Bagnulo, M. and J. Schoenwaelder, "Information Model for Large-Scale Measurement Platforms (LMAPs)", RFC 8193, DOI 10.17487/RFC8193, August 2017.

Appendix A. Open Issues

This draft must be reviewed against draft-ietf-babel-rfc6126bis. [I feel like this has been adequately done, but I could be wrong.]

Following are some issues where a conscious decision may be useful:

  1. 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.]
  2. 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.]
  3. 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.]
  4. 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?
  5. babel-external-cost may need more work. [if no comment, it will be left as is]
  6. 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?]
  7. 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.]
  8. Should babel link types have an IANA registry? [Right now, none is defined.]
  9. 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.]

Closed Issues:

Appendix B. Change Log

Individual Drafts:

Working group drafts:

Author's Address

Barbara Stark AT&T Atlanta, GA, US EMail: barbara.stark@att.com