idnits 2.17.1 draft-ietf-babel-information-model-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 229 has weird spacing: '...nts-obj ro ba...' == Line 232 has weird spacing: '...ity-obj ro b...' == Line 284 has weird spacing: '...address rw b...' == Line 308 has weird spacing: '...ors-obj ro ba...' == Line 309 has weird spacing: '...ity-obj ro b...' == (2 more instances...) -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-9a-fA-F' is mentioned on line 409, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-05 == Outdated reference: A later version (-10) exists of draft-ietf-babel-dtls-01 == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Babel routing protocol B. Stark 3 Internet-Draft AT&T 4 Intended status: Informational October 22, 2018 5 Expires: April 25, 2019 7 Babel Information Model 8 draft-ietf-babel-information-model-04 10 Abstract 12 This Babel Information Model can be used to create data models under 13 various data modeling regimes (e.g., YANG). It allows a Babel 14 implementation (via a management protocol such as NETCONF) to report 15 on its current state and may allow some limited configuration of 16 protocol constants. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. The Information Model . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Definition of babel-information-obj . . . . . . . . . . . 5 58 3.2. Definition of babel-constants-obj . . . . . . . . . . . . 6 59 3.3. Definition of babel-interfaces-obj . . . . . . . . . . . 7 60 3.4. Definition of babel-neighbors-obj . . . . . . . . . . . . 8 61 3.5. Definition of babel-security-obj . . . . . . . . . . . . 10 62 3.6. Definition of babel-routes-obj . . . . . . . . . . . . . 11 63 4. Common Objects . . . . . . . . . . . . . . . . . . . . . . . 12 64 4.1. Definition of babel-credential-obj . . . . . . . . . . . 12 65 4.2. Definition of babel-log-obj . . . . . . . . . . . . . . . 13 66 5. Extending the Information Model . . . . . . . . . . . . . . . 13 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 72 9.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 17 74 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 Babel is a loop-avoiding distance-vector routing protocol defined in 80 [I-D.ietf-babel-rfc6126bis]. [I-D.ietf-babel-hmac] defines a 81 security mechanism that allows Babel messages to be cryptographically 82 authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism 83 that allows Babel messages to be encrypted. This document describes 84 an information model for Babel (including implementations using one 85 of these security mechanisms) that can be used to create management 86 protocol data models (such as a NETCONF [RFC6241] YANG [RFC7950] data 87 model). 89 Due to the simplicity of the Babel protocol, most of the information 90 model is focused on reporting Babel protocol operational state, and 91 very little of that is considered mandatory to implement (contingent 92 on a management protocol with Babel support being implemented). Some 93 parameters may be configurable. However, it is up to the Babel 94 implementation whether to allow any of these to be configured within 95 its implementation. Where the implementation does not allow 96 configuration of these parameters, it may still choose to expose them 97 as read-only. 99 The Information Model is presented using a hierarchical structure. 100 This does not preclude a data model based on this Information Model 101 from using a referential or other structure. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119] and updated 108 by [RFC8174]. 110 1.2. Notation 112 This document uses a programming language-like notation to define the 113 properties of the objects of the information model. An optional 114 property is enclosed by square brackets, [ ], and a list property is 115 indicated by two numbers in angle brackets, , where m indicates 116 the minimal number of list elements, and n indicates the maximum 117 number of list elements. The symbol * for n means there are no 118 defined limits on the number of list elements. Each parameter and 119 object includes an indication of "ro" or "rw". "ro" means the 120 parameter or object is read-only. "rw" means it is read-write. For 121 an object, read-write means instances of the object can be created or 122 deleted. If an implementation is allowed to choose to implement a 123 "rw" parameter as read-only, this is noted in the parameter 124 description. 126 The object definitions use base types that are defined as follows: 128 binary A binary string (sequence of octets). 130 boolean A type representing a boolean value. 132 counter A non-negative integer that monotonically increases. 133 Counters may have discontinuities and they are not 134 expected to persist across restarts. 136 credentials An opaque type representing credentials needed by a 137 cryptographic mechanism to secure communication. Data 138 models must expand this opaque type as needed and 139 required by the security protocols utilized. 141 datetime A type representing a date and time using the Gregorian 142 calendar. The datetime format MUST conform to RFC 3339 143 [RFC3339]. 145 int A type representing signed or unsigned integer numbers. 146 This information model does not define a precision nor 147 does it make a distinction between signed and unsigned 148 number ranges. 150 ip-address A type representing an IP address. This type supports 151 both IPv4 and IPv6 addresses. 153 string A type representing a human-readable string consisting of 154 a (possibly restricted) subset of Unicode and ISO/IEC 155 10646 [ISO.10646] characters. 157 uri A type representing a Uniform Resource Identifier as 158 defined in STD 66 [RFC3986]. 160 2. Overview 162 The Information Model is hierarchically structured as follows: 164 information object 165 includes implementation version, router id, this node seqno, 166 enable flag parameters, supported security mechanisms 167 constants object (exactly one per information object) 168 includes UDP port and optional multicast group 169 parameters 170 interfaces object 171 includes interface reference, Hello seqno and intervals, 172 update interval, link type, metric computation parameters 173 neighbors object 174 includes neighbor IP address, Hello history, cost 175 parameters 176 security object (per interface) 177 includes enable flag, self credentials (credential 178 object), trusted credentials (credential object) 179 security object (common to all interfaces) 180 includes enable flag, self credentials (credential 181 object), trusted credentials (credential object) 182 routes object 183 includes route prefix, source router, reference to 184 advertising neighbor, metric, sequence number, whether 185 route is feasible, whether route is selected 187 Most parameters are read-only. Following is a list of the parameters 188 that are not required to be read-only: 190 o enable/disable Babel 192 o Constant: UDP port 194 o Constant: IPv6 multicast group 195 o Interface: Link type 197 o Interface: External cost (must be configurable if implemented, but 198 implementation is optional) 200 o Interface: enable/disable Babel on this interface 202 o Interface: enable/disable message log 204 o Security: enable/disable this security mechanism 206 o Security: self credentials 208 o Security: trusted credentials 210 o Security: enable/disable security log 212 Note that this overview is intended simply to be informative and is 213 not normative. If there is any discrepancy between this overview and 214 the detailed information model definitions in subsequent sections, 215 the error is in this overview. 217 3. The Information Model 219 3.1. Definition of babel-information-obj 221 object { 222 string ro babel-implementation-version; 223 boolean rw babel-enable; 224 binary ro babel-self-router-id; 225 string ro babel-supported-link-types<1..*>; 226 [int ro babel-self-seqno;] 227 string ro babel-metric-comp-algorithms<1..*>; 228 string ro babel-security-supported<0..*>; 229 babel-constants-obj ro babel-constants; 230 babel-interfaces-obj ro babel-interfaces<0..*>; 231 babel-routes-obj ro babel-routes<0..*>; 232 babel-security-obj ro babel-security<0..*>; 233 } babel-information-obj; 235 babel-implementation-version: The name and version of this 236 implementation of the Babel protocol. 238 babel-enable: When written, it configures whether the protocol shoud 239 be enabled (true) or disabled (false). A read from the running or 240 intended datastore indicates the configured administrative value 241 of whether the protocol is enabled (true) or not (false). A read 242 from the operational datastore indicates whether the protocol is 243 actually running (true) or not (i.e., it indicates the operational 244 state of the protocol). A data model that does not replicate 245 parameters for running and operational datastores can implement 246 this as two separate parameters. An implementation MAY choose to 247 expose this parameter as read-only ("ro"). 249 babel-self-router-id: The router-id used by this instance of the 250 Babel protocol to identify itself. [I-D.ietf-babel-rfc6126bis] 251 describes this as an arbitrary string of 8 octets. 253 babel-supported-link-types: Lists the set of link types supported by 254 this instance of Babel. Valid enumeration values are defined in 255 the Babel Link Types registry (see Section 7). 257 babel-self-seqno: The current sequence number included in route 258 updates for routes originated by this node. 260 babel-metric-comp-algorithms: List of supported cost computation 261 algorithms. Possible values include "k-out-of-j", and "ETX". 263 babel-security-supported: List of supported security mechanisms. As 264 Babel security mechanisms are defined, they will need to indicate 265 what enumeration value is to be used to represent them in this 266 parameter. 268 babel-constants: A babel-constants-obj object. 270 babel-interfaces: A set of babel-interface-obj objects. 272 babel-security: A babel-security-obj object that applies to all 273 interfaces. If this object is implemented, it allows a security 274 mechanism to be enabled or disabled in a manner that applies to 275 all Babel messages on all interfaces. 277 babel-routes: A set of babel-route-obj objects. Contains the routes 278 known to this node. 280 3.2. Definition of babel-constants-obj 282 object { 283 int rw babel-udp-port; 284 [ip-address rw babel-mcast-group;] 285 } babel-constants-obj; 287 babel-udp-port: UDP port for sending and listening for Babel 288 messages. Default is 6696. An implementation MAY choose to 289 expose this parameter as read-only ("ro"). 291 babel-mcast-group: Multicast group for sending and listening to 292 multicast announcements on IPv6. Default is ff02:0:0:0:0:0:1:6. 293 An implementation MAY choose to expose this parameter as read-only 294 ("ro"). 296 3.3. Definition of babel-interfaces-obj 298 object { 299 string ro babel-interface-reference; 300 [boolean rw babel-interface-enable;] 301 int rw babel-link-type; 302 string ro babel-interface-metric-algorithm; 303 [int ro babel-mcast-hello-seqno;] 304 [int ro babel-mcast-hello-interval;] 305 [int ro babel-update-interval;] 306 [boolean rw babel-message-log-enable;] 307 [babel-log-obj ro babel-message-log<0..*>;] 308 babel-neighbors-obj ro babel-neighbors<0..*>; 309 [babel-security-obj ro babel-interface-security<0..*>;] 310 } babel-interfaces-obj; 312 babel-interface-reference: Reference to an interface object as 313 defined by the data model (e.g., YANG [RFC7950], BBF [TR-181]). 314 Data model is assumed to allow for referencing of interface 315 objects which may be at any layer (physical, Ethernet MAC, IP, 316 tunneled IP, etc.). referencing syntax will be specific to the 317 data model. If there is no set of interface objects available, 318 this should be a string that indicates the interface name used by 319 the underlying operating system. 321 babel-interface-enable: When written, it configures whether the 322 protocol should be enabled (true) or disabled (false) on this 323 interface. A read from the running or intended datastore 324 indicates the configured administrative value of whether the 325 protocol is enabled (true) or not (false). A read from the 326 operational datastore indicates whether the protocol is actually 327 running (true) or not (i.e., it indicates the operational state of 328 the protocol). A data model that does not replicate parameters 329 for running and operational datastores can implement this as two 330 separate parameters. An implementation MAY choose to expose this 331 parameter as read-only ("ro"). 333 babel-link-type: Indicates the type of link. Valid enumeration 334 values are identified in Babel Link Types registry. An 335 implementation MAY choose to expose this parameter as read-only 336 ("ro"). 338 babel-interface-metric-algorithm: Indicates the metric computation 339 algorithm used on this interface. The value MUST be one of those 340 listed in the babel-information-obj babel-metric-comp-algorithms 341 parameter. 343 babel-mcast-hello-seqno: The current sequence number in use for 344 multicast hellos sent on this interface. 346 babel-mcast-hello-interval: The current interval in use for 347 multicast hellos sent on this interface. 349 babel-update-interval: The current interval in use for all updates 350 (multicast and unicast) sent on this interface. 352 babel-message-log-enable: When written, it configures whether 353 logging should be enabled (true) or disabled (false). A read from 354 the running or intended datastore indicates the configured 355 administrative value of whether logging is enabled (true) or not 356 (false). A read from the operational datastore indicates whether 357 logging is actually running (true) or not (i.e., it indicates the 358 operational state). A data model that does not replicate 359 parameters for running and operational datastores can implement 360 this as two separate parameters. An implementation MAY choose to 361 expose this parameter as read-only ("ro"). 363 babel-message-log: Log entries that have timestamp of a received 364 Babel message and the entire received Babel message (including 365 Ethernet frame and IP headers, if possible). An implementation 366 must restrict the size of this log, but how and what size is 367 implementation-specific. If this log is implemented, a mechanism 368 to clear it SHOULD be provided. 370 babel-neighbors: A set of babel-neighbors-obj objects. 372 babel-interface-security: A babel-security-obj object that applies 373 to this interface. If implemented, this allows security to be 374 enabled only on specific interfaces or allows different security 375 mechanisms to be enabled on different interfaces. 377 3.4. Definition of babel-neighbors-obj 378 object { 379 ip-address ro babel-neighbor-address; 380 [binary ro babel-hello-mcast-history;] 381 [binary ro babel-hello-ucast-history;] 382 int ro babel-txcost; 383 int ro babel-exp-mcast-hello-seqno; 384 int ro babel-exp-ucast-hello-seqno; 385 [int ro babel-ucast-hello-seqno;] 386 [int ro babel-ucast-hello-interval;] 387 [int ro babel-rxcost] 388 [int ro babel-cost] 389 } babel-neighbors-obj; 391 babel-neighbor-address: IPv4 or IPv6 address the neighbor sends 392 messages from 394 babel-hello-mcast-history: The multicast Hello history of whether or 395 not the multicast Hello messages prior to babel-exp-mcast-hello- 396 seqno were received. A binary sequence where the most recently 397 received Hello is expressed as a "1" placed in the left-most bit, 398 with prior bits shifted right (and "0" bits placed between prior 399 Hello bits and most recent Hello for any not-received Hellos). 400 This value should be displayed using hex digits ([0-9a-fA-F]). 401 See [I-D.ietf-babel-rfc6126bis], section A.1. 403 babel-hello-ucast-history: The unicast Hello history of whether or 404 not the unicast Hello messages prior to babel-exp-ucast-hello- 405 seqno were received. A binary sequence where the most recently 406 received Hello is expressed as a "1" placed in the left-most bit, 407 with prior bits shifted right (and "0" bits placed between prior 408 Hello bits and most recent Hello for any not-received Hellos). 409 This value should be displayed using hex digits ([0-9a-fA-F]). 410 See [I-D.ietf-babel-rfc6126bis], section A.1. 412 babel-txcost: Transmission cost value from the last IHU packet 413 received from this neighbor, or maximum value (infinity) to 414 indicate the IHU hold timer for this neighbor has expired. See 415 [I-D.ietf-babel-rfc6126bis], section 3.4.2. 417 babel-exp-mcast-hello-seqno: Expected multicast Hello sequence 418 number of next Hello to be received from this neighbor. If 419 multicast Hello messages are not expected, or processing of 420 multicast messages is not enabled, this MUST be 0. 422 babel-exp-ucast-hello-seqno: Expected unicast Hello sequence number 423 of next Hello to be received from this neighbor. If unicast Hello 424 messages are not expected, or processing of unicast messages is 425 not enabled, this MUST be 0. 427 babel-ucast-hello-seqno: The current sequence number in use for 428 unicast hellos sent to this neighbor. 430 babel-ucast-hello-interval: The current interval in use for unicast 431 hellos sent to this neighbor. 433 babel-rxcost: Reception cost calculated for this neighbor. This 434 value is usually derived from the Hello history, which may be 435 combined with other data, such as statistics maintained by the 436 link layer. The rxcost is sent to a neighbor in each IHU. See 437 [I-D.ietf-babel-rfc6126bis], section 3.4.3. 439 babel-cost: Link cost is computed from the values maintained in the 440 neighbor table: the statistics kept in the neighbor table about 441 the reception of Hellos, and the txcost computed from received IHU 442 packets. 444 3.5. Definition of babel-security-obj 446 object { 447 string ro babel-security-mechanism 448 boolean rw babel-security-enable; 449 babel-credential-obj ro babel-security-self-cred<0..*>; 450 babel-credential-obj ro babel-security-trust<0..*>; 451 [boolean rw babel-credvalid-log-enable;] 452 [babel-log-obj ro babel-credvalid-log<0..*>;] 453 } babel-security-obj; 455 babel-security-mechanism: The name of the security mechanism this 456 object instance is about. The value MUST be the same as one of 457 the enumerations listed in the babel-security-supported parameter. 459 babel-security-enable: When written, it configures whether this 460 security mechanism should be enabled (true) or disabled (false). 461 A read from the running or intended datastore indicates the 462 configured administrative value of whether this security mechanism 463 is enabled (true) or not (false). A read from the operational 464 datastore indicates whether this security mechanism is actually 465 running (true) or not (i.e., it indicates the operational state). 466 A data model that does not replicate parameters for running and 467 operational datastores can implement this as two separate 468 parameters. An implementation MAY choose to expose this parameter 469 as read-only ("ro"). 471 babel-security-self-cred: Credentials this router presents to 472 participate in the enabled security mechanism. Any private key 473 component of a credential MUST NOT be readable. Adding and 474 deleting credentials MAY be allowed. 476 babel-security-trust: A set of babel-credential-obj objects that 477 identify the credentials of routers whose Babel messages may be 478 trusted or of a certificate authority (CA) whose signing of a 479 router's credentials implies the router credentials can be 480 trusted, in the context of this security mechanism. How a 481 security mechanism interacts with this list is determined by the 482 mechanism. A security algorithm may do additional validation of 483 credentials, such as checking validity dates or revocation lists, 484 so presence in this list may not be sufficient to determine trust. 485 Adding and deleting credentials MAY be allowed. 487 babel-credvalid-log-enable: When written, it configures whether 488 logging should be enabled (true) or disabled (false). A read from 489 the running or intended datastore indicates the configured 490 administrative value of whether logging is enabled (true) or not 491 (false). A read from the operational datastore indicates whether 492 logging is actually running (true) or not (i.e., it indicates the 493 operational state). A data model that does not replicate 494 parameters for running and operational datastores can implement 495 this as two separate parameters. An implementation MAY choose to 496 expose this parameter as read-only ("ro"). 498 babel-credvalid-log: Log entries that have the timestamp a message 499 containing credentials used for peer authentication (e.g., DTLS 500 Server Hello) was received on a Babel port, and the entire 501 received message (including Ethernet frame and IP headers, if 502 possible). An implementation must restrict the size of this log, 503 but how and what size is implementation-specific. If this log is 504 implemented, a mechanism to clear it SHOULD be provided. 506 3.6. Definition of babel-routes-obj 508 object { 509 ip-address ro babel-route-prefix; 510 int ro babel-route-prefix-length; 511 binary ro babel-route-router-id; 512 string ro babel-route-neighbor; 513 [int ro babel-route-received-metric;] 514 [int ro babel-route-calculated-metric;] 515 int ro babel-route-seqno; 516 ip-address ro babel-route-next-hop; 517 boolean ro babel-route-feasible; 518 boolean ro babel-route-selected; 519 } babel-routes-obj; 521 babel-route-prefix: Prefix (expressed in IP address format) for 522 which this route is advertised. 524 babel-route-prefix-length: Length of the prefix for which this route 525 is advertised babel-route-router-id: router-id of the source 526 router for which this route is advertised. 528 babel-route-neighbor: Reference to the babel-neighbors entry for the 529 neighbor that advertised this route. 531 babel-route-received-metric: The metric with which this route was 532 advertised by the neighbor, or maximum value (infinity) to 533 indicate the route was recently retracted and is temporarily 534 unreachable (see Section 3.5.5 of [I-D.ietf-babel-rfc6126bis]). 535 This metric will be 0 (zero) if the route was not received from a 536 neighbor but was generated through other means. Either babel- 537 route-calculated-metric or babel-route-received-metric MUST be 538 provided. 540 babel-route-calculated-metric: A calculated metric for this route. 541 How the metric is calculated is implementation-specific. Maximum 542 value (infinity) indicates the route was recently retracted and is 543 temporarily unreachable (see Section 3.5.5 of 544 [I-D.ietf-babel-rfc6126bis]). Either babel-route-calculated- 545 metric or babel-route-received-metric MUST be provided. 547 babel-route-seqno: The sequence number with which this route was 548 advertised. 550 babel-route-next-hop: The next-hop address of this route. This will 551 be empty if this route has no next-hop address. 553 babel-route-feasible: A boolean flag indicating whether this route 554 is feasible, as defined in Section 3.5.1 of 555 [I-D.ietf-babel-rfc6126bis]). 557 babel-route-selected: A boolean flag indicating whether this route 558 is selected (i.e., whether it is currently being used for 559 forwarding and is being advertised). 561 4. Common Objects 563 4.1. Definition of babel-credential-obj 565 object { 566 credentials ro babel-cred; 567 } babel-credential-obj; 569 babel-cred: A credential, such as an X.509 certificate, a public 570 key, etc. used for signing and/or encrypting Babel messages. 572 4.2. Definition of babel-log-obj 574 object { 575 datetime ro babel-log-time; 576 string ro babel-log-entry; 577 } babel-log-obj; 579 babel-log-time: The date and time (according to the device internal 580 clock setting, which may be a time relative to boot time, acquired 581 from NTP, configured by the user, etc.) when this log entry was 582 created. 584 babel-log-entry: The logged message, as a string of utf-8 encoded 585 hex characters. 587 5. Extending the Information Model 589 Implementations MAY extend this information model with other 590 parameters or objects. For example, an implementation MAY choose to 591 expose Babel route filtering rules by adding a route filtering object 592 with parameters appropriate to how route filtering is done in that 593 implementation. The precise means used to extend the information 594 model would be specific to the data model the implementation uses to 595 expose this information. 597 6. Security Considerations 599 This document defines a set of information model objects and 600 parameters that may be exposed to be visible from other devices, and 601 some of which may be configured. Securing access to and ensuring the 602 integrity of this data is in scope of and the responsibility of any 603 data model derived from this information model. Specifically, any 604 YANG [RFC7950] data model is expected to define security exposure of 605 the various parameters, and a [TR-181] data model will be secured by 606 the mechanisms defined for the management protocol used to transport 607 it. 609 This information model defines objects that can allow credentials 610 (for this device, for trusted devices, and for trusted certificate 611 authorities) to be added and deleted. Public keys and shared secrets 612 may be exposed through this model. This model requires that private 613 keys never be exposed. The Babel security mechanisms that make use 614 of these credentials (e.g., [I-D.ietf-babel-dtls], 615 [I-D.ietf-babel-hmac]) are expected to define what credentials can be 616 used with those mechanisms. 618 7. IANA Considerations 620 This document defines a Babel Link Type registry for the values of 621 the babel-link-type and babel-supported-link-types parameters to be 622 listed under the Babel Routing Protocol registry. 624 Valid Babel Link Type names are normatively defined as 626 o MUST be at least 1 character and no more than 20 characters long 628 o MUST contain only US-ASCII [RFC0020] letters 'A' - 'Z' and 'a' - 629 'z', digits '0' - '9', and hyphens ('-', ASCII 0x2D or decimal 45) 631 o MUST contain at least one letter ('A' - 'Z' or 'a' - 'z') 633 o MUST NOT begin or end with a hyphen 635 o hyphens MUST NOT be adjacent to other hyphens 637 The rules for Link Type names, excepting the limit of 20 characters 638 maximum, are also expressed below (as a non-normative convenience) 639 using ABNF [RFC5234]. 641 SRVNAME = *(1*DIGIT [HYPHEN]) ALPHA *([HYPHEN] ALNUM) 642 ALNUM = ALPHA / DIGIT ; A-Z, a-z, 0-9 643 HYPHEN = %x2D ; "-" 644 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] 645 DIGIT = %x30-39 ; 0-9 [RFC5234] 647 The allocation policy of this registry is Specification Required 648 [RFC8126]. 650 The initial values in the "Babel Link Type" registry are: 652 +----------+-------------------------------------------+------------+ 653 | Name | Used for Links Defined By | Reference | 654 +----------+-------------------------------------------+------------+ 655 | ethernet | [IEEE-802.3-2018] | (this | 656 | | | document) | 657 | other | to be used when no link type information | (this | 658 | | available | document) | 659 | tunnel | to be used for a tunneled interface over | (this | 660 | | unknown physical link | document) | 661 | wireless | [IEEE-802.11-2016] | (this | 662 | | | document) | 663 | exp-* | Reserved for Experimental Use | (this | 664 | | | document) | 665 +----------+-------------------------------------------+------------+ 667 8. Acknowledgements 669 Juliusz Chroboczek, Toke Hoeiland-Joergensen, David Schinazi, Mahesh 670 Jethanandani, Acee Lindem, and Carsten Bormann have been very helpful 671 in refining this information model. 673 The language in the Notation section was mostly taken from [RFC8193]. 675 9. References 677 9.1. Normative References 679 [I-D.ietf-babel-rfc6126bis] 680 Chroboczek, J. and D. Schinazi, "The Babel Routing 681 Protocol", draft-ietf-babel-rfc6126bis-05 (work in 682 progress), May 2018. 684 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 685 RFC 20, DOI 10.17487/RFC0020, October 1969, 686 . 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 694 Writing an IANA Considerations Section in RFCs", BCP 26, 695 RFC 8126, DOI 10.17487/RFC8126, June 2017, 696 . 698 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 699 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 700 May 2017, . 702 9.2. Informative References 704 [I-D.ietf-babel-dtls] 705 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 706 Routing Protocol over Datagram Transport Layer Security", 707 draft-ietf-babel-dtls-01 (work in progress), October 2018. 709 [I-D.ietf-babel-hmac] 710 Do, C., Kolodziejak, W., and J. Chroboczek, "Babel 711 Cryptographic Authentification", draft-ietf-babel-hmac-00 712 (work in progress), August 2018. 714 [IEEE-802.11-2016] 715 "IEEE Standard 802.11-2016 - IEEE Standard for Information 716 Technology - Telecommunications and information exchange 717 between systems Local and metropolitan area networks - 718 Specific requirements - Part 11: Wireless LAN Medium 719 Access Control (MAC) and Physical Layer (PHY) 720 Specifications.". 722 [IEEE-802.3-2018] 723 "IEEE Standard 802.3-2018 - IEEE Approved Draft Standard 724 for Ethernet.". 726 [ISO.10646] 727 International Organization for Standardization, 728 "Information Technology - Universal Multiple-Octet Coded 729 Character Set (UCS)", ISO Standard 10646:2014, 2014. 731 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 732 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 733 . 735 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 736 Resource Identifier (URI): Generic Syntax", STD 66, 737 RFC 3986, DOI 10.17487/RFC3986, January 2005, 738 . 740 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 741 Specifications: ABNF", STD 68, RFC 5234, 742 DOI 10.17487/RFC5234, January 2008, 743 . 745 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 746 and A. Bierman, Ed., "Network Configuration Protocol 747 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 748 . 750 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 751 RFC 7950, DOI 10.17487/RFC7950, August 2016, 752 . 754 [RFC8193] Burbridge, T., Eardley, P., Bagnulo, M., and J. 755 Schoenwaelder, "Information Model for Large-Scale 756 Measurement Platforms (LMAPs)", RFC 8193, 757 DOI 10.17487/RFC8193, August 2017, 758 . 760 [TR-181] Broadband Forum, "Device Data Model", 761 . 763 Appendix A. Open Issues 765 1. I want to get rid of the security log, because all Babel messages 766 (which should be defined as all messages to/from the udp-port) 767 are be logged by message-log. I don't like message log as it is. 768 I think if logging is enabled it should just write to a text 769 file. This will mean there also needs to be a means of 770 downloading/reading the log file. 772 2. Consider the following statistics: under interface object: sent 773 multicast Hello, sent updates, received Babel messages; under 774 neighbor object: sent unicast Hello, sent updates, sent IHU, 775 received Hello, received updates, received IHUs. Would also need 776 to enable/disable stats and clear stats. 778 3. Security section needs furter review 780 4. Commands to add and delete credentials, and parameters that allow 781 credential to be identified without allowing access to private 782 credential info 784 5. Check description of enable parameters to make sure ok for YANG 785 and TR-181. Closed by updating description to be useful for YANG 786 and TR-181, using language consistent with YANG descriptions. 788 6. Distinguish signed and unsigned integers? 790 7. Review new IANA Considerations section. Should ABNF be 791 normative? 793 Closed Issues: 795 1. Datatype of the router-id: Closed by introducing binary datatype 796 and using that for router-id 798 2. babel-neighbor-address as IPv6-only: Closed by leaving as is 799 (IPv4 and IPv6) 801 3. babel-implementation-version includes the name of the 802 implementation: Closed by adding "name" to description 804 4. Delete external-cost?: Closed by deleting. 806 5. Would it be useful to define some parameters for reporting 807 statistics or logs? [2 logs are now included. If others are 808 needed they need to be proposed. See Open Issues for additional 809 thoughts on logs and statistics.] 811 6. Closed by defining base64 type and using it for all router IDs: 812 "babel-self-router-id: Should this be an opaque 64-bit value 813 instead of int?" 815 7. Closed as "No": Do we need a registry for the supported security 816 mechanisms? [Given the current limited set, and unlikelihood of 817 massive expansion, I don't think so. But we can if someone 818 wants it.] 820 8. This draft must be reviewed against draft-ietf-babel-rfc6126bis. 821 [I feel like this has been adequately done, but I could be 822 wrong.] 824 9. babel-interfaces-obj: Juliusz:"This needs further discussion, I 825 fear some of these are implementation details." [In the absence 826 of discussion, the current model stands. Note that all but 827 link-type and the neighbors sub-object are optional. If an 828 implementation does not have any of the optional elements then 829 it simply doesn't have them and that's fine.] 831 10. Would it be useful to define some parameters specifically for 832 security anomalies? [The 2 logs should be useful in identifying 833 security anomalies. If more is needed, someone needs to 834 propose.] 836 11. I created a basic security model. It's useful for single (or 837 no) active security mechanism (e.g., just HMAC, just DTLS, or 838 neither); but not multiple active (both HMAC and DTLS -- which 839 is not the same as HMAC of DTLS and would just mean that HMAC 840 would be used on all unencrypted messages -- but right now the 841 model doesn't allow for configuring HMAC of unencrypted messages 842 for routers without DTLS, while DTLS is used if possible). OK? 843 [No-one said otherwise.] 845 12. babel-external-cost may need more work. [if no comment, it will 846 be left as is] 848 13. babel-hello-[mu]cast-history: the Hello history is formated as 849 16 bits, per A.1 of 6126bis. Is that a too implementation 850 specific? [We also now have an optional-to-implement log of 851 received messages, and I made these optional. So maybe this is 852 ok?] 854 14. rxcost, txcost, cost: is it ok to model as integers, since 855 6126bis 2.1 says costs and metrics need not be integers. [I 856 have them as integers unless someone insists on something else.] 858 15. For the security log, should it also log whether the credentials 859 were considered ok? [Right now it doesn't and I think that's ok 860 because if you log Hellos it was ok and if you don't it wasn't.] 862 16. Should Babel link types have an IANA registry? [Agreed to do 863 this at IETF 102.] 865 Appendix B. Change Log 867 Individual Drafts: 869 v00 2016-07-07 EBD: Initial individual draft version 871 v01 2017-03-13: Addressed comments received in 2016-07-15 email from 872 J. Chroboczek 874 Working group drafts: 876 v00 2017-07-03: Addressed points noted with "oops" in 877 https://www.ietf.org/proceedings/98/slides/slides-98-babel-babel- 878 information-model-00.pdf 880 v01 2018-01-02: Removed item from issue list that was agreed (in 881 Prague) not to be an issue. Added description of data types under 882 Notation section, and used these in all data types. Added babel- 883 security and babel-trust. 885 v02 2018-04-05: 887 * changed babel-version description to babel-implementation- 888 version 890 * replace optional babel-interface-seqno with optional babel- 891 mcast-hello-seqno and babel-ucast-hello-seqno 893 * replace optional babel-interface-hello-interval with optional 894 babel-mcast-hello-interval and babel-ucast-hello-interval 896 * remove babel-request-trigger-ack 898 * remove "babel-router-id: router-id of the neighbor"; note that 899 parameter had previously been removed but description had 900 accidentally not been removed 902 * added an optional "babel-cost" field to babel-neighbors object, 903 since the spec does not define how exactly the cost is computed 904 from rxcost/txcost 906 * deleted babel-source-garbage-collection-time 908 * change babel-lossy-link to babel-link-type and make this an 909 enumeration; added at top level babel-supported-link-types so 910 which are supported by this implementation can be reported 912 * changes to babel-security-obj to allow self credentials to be 913 one or more instances of a credential object. Allowed trusted 914 credentials to include CA credentials; made some parameter name 915 changes 917 * updated references and Introduction 919 * added Overview section 921 * deleted babel-sources-obj 923 * added feasible Boolean to routes 925 * added section to briefly describe extending the information 926 model. 928 * deleted babel-route-neighbor 930 * tried to make definition of babel-interface-reference clearer 932 * added security and message logs 934 v03 2018-05-31: 936 * added reference to RFC 8174 (update to RFC 2119 on key words) 938 * applied edits to Introduction text per Juliusz email of 939 2018-04-06 941 * Deleted sentence in definition of "int" data type that said it 942 was also used for enumerations. Changed all enumerations to 943 strings. The only enumerations were for link types, which are 944 now "ethernet", "wireless", "tunnel", and "other". 946 * deleted [ip-address babel-mcast-group-ipv4;] 948 * babel-external-cost description changed 950 * babel-security-self-cred: Added "any private key component of a 951 credential MUST NOT be readable;" 953 * hello-history parameters put recent Hello in most significant 954 bit and length of parameter is not constrained. 956 * babel-hello-seqno in neighbors-obj changed to babel-exp-mcast- 957 hello-seqno and babel-exp-ucast-hello-seqno 959 * added babel-route-neighbor back again. It was mistakenly 960 deleted 962 * changed babel-route-metric and babel-route-announced-metric to 963 babel-route-received-metric and babel-route-calculated-metric 965 * changed model of security object to put list of supported 966 mechanisms at top level and separate security object per 967 mechanism. This caused some other changes to the security 968 object 970 v04 2018-10-15: 972 * changed babel-mcast-group-ipv6 to babel-mcast-group 974 * link type parameters changed to point to newly defined registry 976 * babel-ucast-hello-interval moved to neighbor object 978 * babel-ucast-hello-seqno moved to neighbor object 980 * babel-neighbor-ihu-interval deleted 982 * in log descriptions, included statement that there SHOULD be 983 ability to clear logs 985 * added IANA registry for link types 987 * added "ro" and "rw" to tables for read-write and read-only 989 * added metric computation parameter to interface 991 Author's Address 993 Barbara Stark 994 AT&T 995 Atlanta, GA 996 US 998 Email: barbara.stark@att.com