idnits 2.17.1 draft-ovsienko-babel-hmac-authentication-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6126, but the abstract doesn't seem to directly say this. It does mention RFC6126 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2013) is 4121 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6126 (ref. 'BABEL') (Obsoleted by RFC 8966) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 6506 (ref. 'OSPF3-AUTH') (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ovsienko 3 Internet-Draft Yandex 4 Updates: 6126 (if approved) January 10, 2013 5 Intended status: Experimental 6 Expires: July 14, 2013 8 Babel HMAC Cryptographic Authentication 9 draft-ovsienko-babel-hmac-authentication-01 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 Babel routing protocol, updating, but not superceding RFC 6126. The 15 mechanism allocates two new TLV types for the authentication data, 16 uses HMAC and is both optional and backward compatible. 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 http://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 July 14, 2013. 35 Copyright Notice 37 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 54 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Mandatory-to-Implement and Optional Hash Algorithms . . . 4 56 2.2. Padding Constant Specifics . . . . . . . . . . . . . . . . 5 57 2.3. Cryptographic Sequence Number Specifics . . . . . . . . . 6 58 2.4. Definition of HMAC . . . . . . . . . . . . . . . . . . . . 6 59 3. Updates to Protocol Data Structures . . . . . . . . . . . . . 8 60 3.1. RxAuthRequired . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2. LocalTS . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3. LocalPC . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. MaxDigestsIn . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. MaxDigestsOut . . . . . . . . . . . . . . . . . . . . . . 9 65 3.6. ANM Table . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.7. ANM Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.8. Configured Security Associations . . . . . . . . . . . . . 12 68 3.9. Effective Security Associations . . . . . . . . . . . . . 13 69 4. Updates to Protocol Encoding . . . . . . . . . . . . . . . . . 14 70 4.1. Justification . . . . . . . . . . . . . . . . . . . . . . 14 71 4.2. TS/PC TLV . . . . . . . . . . . . . . . . . . . . . . . . 16 72 4.3. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 5. Updates to Protocol Operation . . . . . . . . . . . . . . . . 18 74 5.1. Per-Interface TS/PC Number Updates . . . . . . . . . . . . 18 75 5.2. Deriving ESAs from CSAs . . . . . . . . . . . . . . . . . 20 76 5.3. Updates to Packet Sending . . . . . . . . . . . . . . . . 22 77 5.4. Updates to Packet Receiving . . . . . . . . . . . . . . . 24 78 5.5. Authentication-Specific Statistics Maintenance . . . . . . 26 79 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 27 80 6.1. IPv6 Source Address Selection for Sending . . . . . . . . 27 81 6.2. Output Buffer Management . . . . . . . . . . . . . . . . . 27 82 6.3. Optimizations of ESAs Deriving . . . . . . . . . . . . . . 28 83 6.4. CSA Implementation Specifics . . . . . . . . . . . . . . . 29 84 7. Network Management Aspects . . . . . . . . . . . . . . . . . . 30 85 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . . 30 86 7.2. Multi-Domain Authentication . . . . . . . . . . . . . . . 30 87 7.3. Migration to and from Authenticated Exchange . . . . . . . 32 88 7.4. Handling of Authentication Keys Exhaustion . . . . . . . . 32 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 95 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . . 39 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 98 1. Introduction 100 Comments are solicited and should be addressed to the author. 102 Authentication of routing protocol exchanges is a common mean of 103 securing computer networks. Use of protocol authentication 104 mechanisms helps in ascertaining, that only the intended routers 105 participate in routing information exchange, and that the exchanged 106 routing information is not modified by a third party. 108 [BABEL] ("the original specification") defines data structures, 109 encoding, and operation of a basic Babel routing protocol instance 110 ("instance of the original protocol"). This document ("this 111 specification") defines data structures, encoding, and operation of 112 an extension to Babel protocol, an authentication mechanism ("this 113 mechanism"). Both the instance of the original protocol and this 114 mechanism are mostly self-contained and interact only at coupling 115 points defined in this specification. 117 A major design goal of this mechanism is such a transparency to an 118 operator, that is not affected by implementation and configuration 119 specifics. A complying implementation makes all meaningful details 120 of authentication-specific processing clear to the operator, even 121 when some of the key parameters cannot be changed. 123 The currently established (see [RIP2-AUTH], [OSPF2-AUTH], 124 [OSPF3-AUTH], and [RFC6039]) approach to authentication mechanism 125 design for datagram-based routing protocols such as Babel relies on 126 two principal data items embedded into protocol packets, typically as 127 two integral parts of a single data structure: 129 o A fixed-length unsigned integer number, typically called a 130 cryptographic sequence number, used in replay attack protection. 132 o A variable-length sequence of octets, a result of the HMAC 133 construct (see [RFC2104]) computed on meaningful data items of the 134 packet (including the cryptographic sequence number) on one hand 135 and a secret key on another, used in proving that both the sender 136 and the receiver share the same secret key and that the meaningful 137 data was not changed in transmission. 139 Depending on the design specifics either all protocol packets are 140 authenticated or only those protecting the integrity of protocol 141 exchange. This mechanism authenticates all protocol packets. 143 This specification defines the use of the cryptographic sequence 144 number in details sufficient to make replay attack protection 145 strength predictable. That is, an operator can tell the strength 146 from the declared characteristics of an implementation and, whereas 147 the implementation allows changing relevant parameters, the effect of 148 a reconfiguration. 150 This mechanism explicitly allows for multiple HMAC results per an 151 authenticated packet. Since meaningful data items of a given packet 152 remain the same, each such HMAC result stands for a different secret 153 key and/or a different hash algorithm. This enables a simultaneous, 154 independent authentication within multiple domains. 156 An important concern addressed by this mechanism is limiting the 157 amount of HMAC computations done per an authenticated packet, 158 independently for sending and receiving. Without these limits the 159 number of computations per a packet could be as high as number of 160 configured authentication keys (in sending case) or as the number of 161 keys multiplied by the number of supplied HMAC results (in receiving 162 case). 164 These limits establish a basic competition between the configured 165 keys and (in receiving case) an additional competition between the 166 supplied HMAC results. This specification defines related data 167 structures and procedures in a way to make such competition 168 transparent and predictable for an operator. 170 1.1. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 2. Cryptographic Aspects 178 2.1. Mandatory-to-Implement and Optional Hash Algorithms 180 [RFC2104] defines HMAC as a construct that can use any cryptographic 181 hash algorithm with known digest length and internal block size. 182 This specification preserves this property of HMAC by defining data 183 processing that itself does not depend on any particular hash 184 algorithm either. However, since this mechanism is a protocol 185 extension case, there are relevant design considerations to take into 186 account. 188 Section 4.5 of [RFC6709] suggests selecting one hash algorithm as 189 mandatory-to-implement for the purpose of global interoperability 190 (Section 3.2 ibid.) and selecting another of distinct lineage as 191 recommended for implementation for the purpose of cryptographic 192 agility. This specification makes the latter property guaranteed, 193 rather than probable, through elevation of requirement level. There 194 are two hash algorithms mandatory-to-implement, unambiguously defined 195 and generally available in multiple implementations each. 197 An implementation of this mechanism MUST include support for two hash 198 algorithms: 200 o SHA-512 (SHA-2 family) 202 o Whirlpool (512-bit hash) 204 Besides that, an implementation of this mechanism MAY include support 205 for additional hash algorithms, provided those additional algorithms 206 are publicly and openly specified. Implementers SHOULD consider 207 strong, well-known hash algorithms as additional implementation 208 options and MUST NOT consider hash algorithms for that by the time of 209 implementation meaningful attacks exist or that are commonly viewed 210 as deprecated. For example, the following hash algorithms meet these 211 requirements at the time of this writing (in alphabetical order): 213 o GOST (256-bit hash) 215 o RIPEMD-160 217 o SHA-224 (SHA-2 family) 219 o SHA-256 (SHA-2 family) 221 o SHA-384 (SHA-2 family) 223 o Tiger (192-bit hash) 225 The set of hash algorithms available in an implementation MUST be 226 clearly stated. Whether known weak authentication keys exist for a 227 hash algorithm used in an implementation of this mechanism, the 228 implementation MUST deny a use of such keys. 230 2.2. Padding Constant Specifics 232 [RIP2-AUTH] established the reference method of HMAC construct 233 application housing the computed authentication data inside the 234 message being authenticated. This involves pre-allocating necessary 235 amount of message data space and pre-filling it with some data a 236 receiver can reproduce exactly, typically an arbitrary number known 237 as a padding constant. The padding constant used in [RIP2-AUTH] is 238 0x878FE1F3 four-octet value. 240 Subsequent works (including [OSPF2-AUTH] and [OSPF3-AUTH]) inherited 241 both the basic approach and the padding constant. In particular, 242 [OSPF3-AUTH] uses a source IPv6 address to set the first 16 octets of 243 the padded area and the padding constant to set any subsequent 244 octets. This mechanism makes the same use for the source IPv6 245 address, but the padding constant size and value are different. 247 Since any fixed arbitrary value of a padding constant does not affect 248 cryptographic characteristics of a hash algorithm and the HMAC 249 construct, and since single-octet padding is more straightforward to 250 implement, the padding constant used by this mechanism is 0x00 251 single-octet value. This is respectively addressed in sending 252 (Section 5.3 item 5) and receiving (Section 5.4 item 6) procedures. 254 2.3. Cryptographic Sequence Number Specifics 256 Operation of this mechanism may involve multiple local and multiple 257 remote cryptographic sequence numbers, each essentially being a 258 48-bit unsigned integer. This specification uses a term "TS/PC 259 number" to avoid confusion with the route's sequence number of the 260 original Babel specification (Section 2.5 of [BABEL]) and to stress 261 the fact, that there are two distinguished parts of this 48-bit 262 number, each handled in its specific way (see Section 5.1): 264 0 1 2 3 4 265 0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 266 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | TS // | PC | 268 +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 // 271 High-order 32 bits are called "timestamp" (TS) and low-order 16 bits 272 are called "packet counter" (PC). 274 This mechanism stores, updates, compares and encodes each TS/PC 275 number as two independent unsigned integers, TS and PC respectively. 276 Such comparison of TS/PC numbers performed in item 3 of Section 5.4 277 is algebraically equivalent to comparison of respective 48-bit 278 unsigned integers. Any byte order conversion, when required, is 279 performed on TS and PC parts independently. 281 2.4. Definition of HMAC 283 The algorithm description below uses the following nomenclature, 284 which is consistent with [FIPS-198]: 286 Text Is the data on which the HMAC is calculated (note item (b) of 287 Section 8). In this specification it is the contents of a 288 Babel packet ranging from the beginning of the Magic field of 289 the Babel packet header to the end of the last octet of the 290 Packet Body field, as defined in Section 4.2 of [BABEL]. 292 H Is the specific hash algorithm (see Section 2.1). 294 K Is a sequence of octets of an arbitrary, known length. 296 Ko Is the cryptographic key used with the hash algorithm. 298 B Is the block size of H, measured in octets rather than bits. 299 Note that B is the internal block size, not the digest length. 301 L Is the digest length of H, measured in octets rather than 302 bits. 304 XOR Is the exclusive-or operation. 306 Opad Is the hexadecimal value 0x5c repeated B times. 308 Ipad Is the hexadecimal value 0x36 repeated B times. 310 The algorithm below is the original, unmodified HMAC construct as 311 defined in both [RFC2104] and [FIPS-198], hence it is different from 312 the algorithms defined in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] 313 in exactly two regards: 315 o Algorithm below sets the size of Ko to B, not to L (L is not 316 greater than B). This resolves both ambiguity in XOR expressions 317 and incompatibility in handling of keys having length greater than 318 L but not greater than B. 320 o Algorithm below does not change value of Text before or after the 321 computation. Both padding of a Babel packet before the 322 computation and placing of the result inside the packet are 323 performed elsewhere. 325 The intent of this is to enable the most straightforward use of 326 cryptographic libraries by implementations of this specification. At 327 the time of this writing implementations of the original HMAC 328 construct coupled with hash algorithms of choice are generally 329 available. 331 Description of the algorithm: 333 1. Preparation of the Key 335 In this application, Ko is always B octets long. If K is B 336 octets long, then Ko is set to K. If K is more than B octets 337 long, then Ko is set to H(K) with zeroes appended to the end of 338 H(K), such that Ko is B octets long. If K is less than B octets 339 long, then Ko is set to K with zeroes appended to the end of K, 340 such that Ko is B octets long. 342 2. First-Hash 344 A First-Hash, also known as the inner hash, is computed as 345 follows: 347 First-Hash = H(Ko XOR Ipad || Text) 349 3. Second-Hash 351 A second hash, also known as the outer hash, is computed as 352 follows: 354 Second-Hash = H(Ko XOR Opad || First-Hash) 356 4. Result 358 The resulting Second-Hash becomes the authentication data that is 359 returned as the result of HMAC calculation. 361 3. Updates to Protocol Data Structures 363 3.1. RxAuthRequired 365 RxAuthRequired is a boolean parameter, its default value MUST be 366 TRUE. An implementation SHOULD make RxAuthRequired a per-interface 367 parameter, but MAY make it specific to the whole protocol instance. 368 The conceptual purpose of RxAuthRequired is to enable a smooth 369 migration from an unauthenticated to an authenticated Babel packet 370 exchange and back (see Section 7.3). Current value of RxAuthRequired 371 directly affects the receiving procedure defined in Section 5.4. An 372 implementation SHOULD allow the operator changing RxAuthRequired 373 value in runtime or by means of Babel speaker restart. An 374 implementation MUST allow the operator discovering the effective 375 value of RxAuthRequired in runtime or from the system documentation. 377 3.2. LocalTS 379 LocalTS is a 32-bit unsigned integer variable, it is the TS part of a 380 per-interface TS/PC number. LocalTS is a strictly per-interface 381 variable not intended to be changed by operator. Its initialization 382 is explained in Section 5.1. 384 3.3. LocalPC 386 LocalPC is a 16-bit unsigned integer variable, it is the PC part of a 387 per-interface TS/PC number. LocalPC is a strictly per-interface 388 variable not intended to be changed by operator. Its initialization 389 is explained in Section 5.1. 391 3.4. MaxDigestsIn 393 MaxDigestsIn is an unsigned integer parameter conceptually purposed 394 for limiting the amount of CPU time spent processing a received 395 authenticated packet. The receiving procedure performs the most CPU- 396 intensive operation, the HMAC computation, only at most MaxDigestsIn 397 (Section 5.4 item 7) times for a given packet. 399 MaxDigestsIn value MUST be at least 2. An implementation SHOULD make 400 MaxDigestsIn a per-interface parameter, but MAY make it specific to 401 the whole protocol instance. An implementation SHOULD allow the 402 operator changing the value of MaxDigestsIn in runtime or by means of 403 Babel speaker restart. An implementation MUST allow the operator 404 discovering the effective value of MaxDigestsIn in runtime or from 405 the system documentation. 407 3.5. MaxDigestsOut 409 MaxDigestsOut is an unsigned integer parameter conceptually purposed 410 for limiting the amount of a sent authenticated packet's space spent 411 on authentication data. The sending procedure adds at most 412 MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet, 413 concurring with the output buffer management explained in 414 Section 6.2. 416 MaxDigestsOut value MUST be at least 2. An implementation SHOULD 417 make MaxDigestsOut a per-interface parameter, but MAY make it 418 specific to the whole protocol instance. An implementation SHOULD 419 allow the operator changing the value of MaxDigestsOut in runtime or 420 by means of Babel speaker restart, in a safe range. The maximum safe 421 value of MaxDigestsOut is implementation-specific (see Section 6.2). 422 An implementation MUST allow the operator discovering the effective 423 value of MaxDigestsOut in runtime or from the system documentation. 425 3.6. ANM Table 427 The ANM (Authentic Neighbours Memory) table resembles the neighbour 428 table defined in Section 3.2.3 of [BABEL]. Note that the term 429 "neighbour table" means the neighbour table of the original Babel 430 specification, and term "ANM table" means the table defined herein. 431 Indexing of the ANM table is done in exactly the same way as indexing 432 of the neighbour table, but purpose, field set and associated 433 procedures are different. 435 Conceptual purpose of the ANM table is to provide a longer term 436 replay attack protection, than it would be possible using the 437 neighbour table. Expiry of an inactive entry in the neighbour table 438 depends on the last received Hello Interval of the neighbour and 439 typically stands for tens to hundreds of seconds (see Appendix A and 440 Appendix B of [BABEL]). Expiry of an inactive entry in the ANM table 441 depends only on the local speaker's configuration. The ANM table 442 retains (for at least the amount of seconds set by ANM timeout 443 parameter defined in Section 3.7) a copy of TS/PC number advertised 444 in authentic packets by each remote Babel speaker. 446 The ANM table is indexed by pairs of the form (Interface, Source). 447 Every table entry consists of the following fields: 449 o Interface 451 An implementation specific reference to the local node's interface 452 that the authentic packet was received through. 454 o Source 456 IPv6 source address of the Babel speaker that the authentic packet 457 was received from. 459 o LastTS 461 A 32-bit unsigned integer, the TS part of a remote TS/PC number. 463 o LastPC 465 A 16-bit unsigned integer, the PC part of a remote TS/PC number. 467 Each ANM table entry has an associated aging timer, which is reset by 468 the receiving procedure (Section 5.4 item 8). If the timer expires, 469 the entry is deleted from the ANM table. 471 An implementation SHOULD use a persistent memory (NVRAM) to retain 472 the contents of ANM table across restarts of the Babel speaker, but 473 only as long as both the Interface field reference and expiry of the 474 aging timer remain correct. An implementation MUST make it clear, if 475 and how persistent memory is used for ANM table. An implementation 476 SHOULD allow retrieving the current contents of ANM table in runtime 477 through common management interfaces such as CLI and SNMP. An 478 implementation SHOULD provide a mean to remove some or all ANM table 479 entries in runtime or by means of Babel speaker restart. 481 3.7. ANM Timeout 483 ANM timeout is an unsigned integer parameter. An implementation 484 SHOULD make ANM timeout a per-interface parameter, but MAY make it 485 specific to the whole protocol instance. ANM timeout is conceptually 486 purposed for limiting the maximum age (in seconds) of entries in the 487 ANM table standing for inactive Babel speakers. The maximum age is 488 immediately related to replay attack protection strength. The 489 strongest protection is achieved with the maximum possible value of 490 ANM timeout set, but it may provide not the best overall result for 491 specific network segments and implementations of this mechanism. 493 In the first turn, implementations unable to maintain local TS/PC 494 number strictly increasing across Babel speaker restarts will reuse 495 advertised TS/PC numbers after each restart (see Section 5.1). The 496 neighbouring speakers will treat the new packets as replayed and 497 discard them until the aging timer of respective ANM table entry 498 expires or the new TS/PC number exceeds the one stored in the entry. 500 Another possible, but less probable case could be an environment 501 involving physical moves of network interfaces hardware between 502 routers. Even performed without restarting Babel speakers, these 503 would cause random drops of the TS/PC number advertised for a given 504 (Interface, Source) index, as viewed by neighbouring speakers, since 505 IPv6 link-local addresses are typically derived from interface 506 hardware addresses. 508 Assuming, that in such cases the operators would prefer using a lower 509 ANM timeout value to let the entries expire on their own rather than 510 having to manually remove them from ANM table each time, an 511 implementation SHOULD set the default value of ANM timeout to a value 512 between 30 and 300 seconds. 514 At the same time, network segments may exist with every Babel speaker 515 having its advertised TS/PC number strictly increasing over the 516 deployed lifetime. Assuming, that in such cases the operators would 517 prefer using a much higher ANM timeout value, an implementation 518 SHOULD allow the operator changing the value of ANM timeout in 519 runtime or by means of Babel speaker restart. An implementation MUST 520 allow the operator discovering the effective value of ANM timeout in 521 runtime or from the system documentation. 523 3.8. Configured Security Associations 525 A Configured Security Association (CSA) is a data structure 526 conceptually purposed for associating authentication keys and hash 527 algorithms with Babel interfaces. All CSAs are managed in ordered 528 lists, one list per each interface. Each interface's list of CSAs is 529 an integral part of the Babel speaker configuration. The default 530 state of an interface's list of CSAs is empty, which has a special 531 meaning of no authentication configured for the interface. The 532 sending (Section 5.3 item 1) and the receiving (Section 5.4 item 1) 533 procedures address this convention accordingly. 535 A single CSA structure consists of the following fields: 537 o HashAlgo 539 An implementation specific reference to one of the hash algorithms 540 supported by this implementation (see Section 2.1). 542 o KeyChain 544 An ordered list of items representing authentication keys, each 545 item being a structure consisting of the following fields: 547 * LocalKeyID 549 An unsigned integer. 551 * AuthKeyOctets 553 A sequence of octets of an arbitrary, known length to be used 554 as the authentication key. 556 * KeyStartAccept 558 The time that this Babel speaker will begin considering this 559 authentication key for accepting packets with authentication 560 data. 562 * KeyStartGenerate 564 The time that this Babel speaker will begin considering this 565 authentication key for generating packet authentication data. 567 * KeyStopGenerate 568 The time that this Babel speaker will stop considering this 569 authentication key for generating packet authentication data. 571 * KeyStopAccept 573 The time that this Babel speaker will stop considering this 574 authentication key for accepting packets with authentication 575 data. 577 It is possible for the KeyChain list to be empty, although this is 578 not the intended way of CSAs use. 580 Since there is no limit imposed on number of CSAs per an interface, 581 but number of HMAC computations per a sent/received packet is limited 582 (through MaxDigestsOut and MaxDigestsIn respectively), only a 583 fraction of the associated keys and hash algorithms may appear used 584 in the process. Ordering of items within a list of CSAs and within a 585 KeyChain list is important to make association selection process 586 deterministic and transparent. Once this ordering is deterministic 587 at Babel interface level, the intermediate data derived by the 588 procedure defined in Section 5.2 will be deterministically ordered as 589 well. 591 An implementation SHOULD allow an operator to set any arbitrary order 592 of items within a given interface's list of CSAs and within the 593 KeyChain list of a given CSA. Regardless if this requirement is or 594 isn't met, the implementation MUST provide a mean to discover the 595 actual item order used. Whichever order is used by an 596 implementation, it MUST be preserved across Babel speaker restarts. 598 Note that none of the CSA structure fields is constrained to contain 599 unique values. Section 6.4 explains this in more details. 601 3.9. Effective Security Associations 603 An Effective Security Association (ESA) is a data structure 604 immediately used in sending (Section 5.3) and receiving (Section 5.4) 605 procedures. Its conceptual purpose is to establish a runtime 606 interface between those procedures and the deriving procedure defined 607 in Section 5.2. All ESAs are managed in ordered, temporary lists, 608 which are not intended for any persistent storage. Item ordering 609 within a temporary list of ESAs MUST be preserved as long as the list 610 exists. 612 A single ESA structure consists of the following fields: 614 o HashAlgo 615 An implementation specific reference to one of the hash algorithms 616 supported by this implementation (see Section 2.1). 618 o KeyID 620 A 16-bit unsigned integer. 622 o AuthKeyOctets 624 A sequence of octets of an arbitrary, known length to be used as 625 the authentication key. 627 Note that among the protocol data structures introduced by this 628 mechanism ESA is the only one not directly interfaced with the system 629 operator (see Figure 1) and it is not immediately present in the 630 protocol encoding either. However, ESA is not just a possible 631 implementation technique, but an integral part of this specification: 632 the deriving (Section 5.2), the sending (Section 5.3), and the 633 receiving (Section 5.4) procedures are defined in terms of the ESA 634 structure and its semantics provided herein. ESA is as meaningful 635 for a correct implementation as the other protocol data structures. 637 4. Updates to Protocol Encoding 639 4.1. Justification 641 Choice of encoding is very important in the long term. Protocol 642 encoding defines possible options of authentication mechanism design 643 and encoding, which in turn define options of future developments of 644 the protocol. 646 Considering existing implementations of Babel protocol instance 647 itself and related modules of packet analysers, current encoding of 648 Babel allows for compact and robust decoders. At the same time, this 649 encoding allows for future extensions of Babel by three (not 650 excluding each other) principal means defined by Section 4.2 and 651 Section 4.3 of [BABEL]: 653 a. A Babel packet consists of a four-octet header followed by a 654 packet body, that is, a sequence of TLVs (see Figure 2). Besides 655 the header and the sequence, an actual Babel datagram may have an 656 arbitrary amount of trailing data between the end of the packet 657 body and the end of the datagram. An instance of the original 658 protocol silently ignores such trailing data. 660 b. The sequence of TLVs uses a binary format allowing for 256 TLV 661 types and imposing no requirements on TLV ordering or number of 662 TLVs of a given type in a packet. Only TLV length matters within 663 the sequence, TLV body contents is to be interpreted elsewhere. 664 This makes an iteration over the sequence possible without a 665 knowledge of body structure of each TLV (with the only 666 distinction between a Pad1 TLV and any other TLVs). The original 667 specification allocates TLV types 0 through 10 (see Table 1) and 668 defines TLV body structure for each. An instance of the original 669 protocol silently ignores any unknown TLV types. 671 c. Within each TLV of the sequence there may be some "extra data" 672 after the "expected length" of the TLV body. An instance of the 673 original protocol silently ignores any such extra data. Note 674 that any TLV types without the expected length defined (such as 675 PadN TLV) cannot be extended with the extra data. 677 Considering each principal extension mean for the specific purpose of 678 adding authentication data items to each protocol packet, the 679 following arguments can be made: 681 o Use of the TLV extra data of some existing TLV type would not be a 682 solution, since no particular TLV type is guaranteed to be present 683 in a Babel packet. 685 o Use of the TLV extra data could also conflict with future 686 developments of the protocol encoding. 688 o Since the packet trailing data is currently unstructured, using it 689 would involve defining an encoding structure and associated 690 procedures, adding to the complexity of both specification and 691 implementation and increasing the exposure to protocol attacks 692 such as fuzzing. 694 o A naive use of the packet trailing data would make it unavailable 695 to any future extension of Babel. Since this mechanism is 696 possibly not the last extension and since some other extensions 697 may allow no other embedding means except the packet trailing 698 data, the defined encoding structure would have to enable 699 multiplexing of data items belonging to different extensions. 700 Such a definition is out of scope of this work. 702 o Deprecating an extension (or only its protocol encoding) that uses 703 purely purpose-allocated TLVs is as simple as deprecating the 704 TLVs. 706 o Use of purpose-allocated TLVs is transparent to both the original 707 protocol and any its future extensions, regardless of the 708 embedding mean(s) used by the latter. 710 Considering all of the above, this mechanism neither uses the packet 711 trailing data nor uses the TLV extra data, but uses two new TLV 712 types: type 11 for a TS/PC number and type 12 for a HMAC result (see 713 Table 1). 715 +-------+-------------------------+---------------+ 716 | Value | Code | Reference | 717 +-------+-------------------------+---------------+ 718 | 0 | Pad1 | [BABEL] | 719 | 1 | PadN | [BABEL] | 720 | 2 | Acknowledgement Request | [BABEL] | 721 | 3 | Acknowledgement | [BABEL] | 722 | 4 | Hello | [BABEL] | 723 | 5 | IHU | [BABEL] | 724 | 6 | Router-Id | [BABEL] | 725 | 7 | Next Hop | [BABEL] | 726 | 8 | Update | [BABEL] | 727 | 9 | Route Request | [BABEL] | 728 | 10 | Seqno Request | [BABEL] | 729 | 11 | TS/PC | this document | 730 | 12 | HMAC | this document | 731 +-------+-------------------------+---------------+ 733 Table 1: Babel TLV types namespace 735 4.2. TS/PC TLV 737 The purpose of a TS/PC TLV is to store a single TS/PC number. There 738 is normally exactly one TS/PC TLV in an authenticated Babel packet. 739 Any occurences of this TLV except the first are ignored. 741 0 1 2 3 742 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Type = 11 | Length | PacketCounter | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Timestamp | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Fields: 751 Type Set to 11 to indicate a TS/PC TLV. 753 Length The length of the body, exclusive of the Type and 754 Length fields. 756 PacketCounter A 16-bit unsigned integer in network byte order, the 757 PC part of a TS/PC number stored in this TLV. 759 Timestamp A 32-bit unsigned integer in network byte order, the 760 TS part of a TS/PC number stored in this TLV. 762 Note that ordering of PacketCounter and Timestamp in TLV structure is 763 opposite to the ordering of TS and PC in "TS/PC" term and the 48-bit 764 equivalent. 766 Considering the "expected length" and the "extra data" in the 767 definition of Section 4.2 of [BABEL], the expected length of a TS/PC 768 TLV body is unambiguously defined as 6 octets. The receiving 769 procedure correctly processes any TS/PC TLV with body length not less 770 than the expected, ignoring any extra data (Section 5.4 items 3 and 771 9). The sending procedure produces a TS/PC TLV with body length 772 equal to the expected and Length field set respectively (Section 5.3 773 item 3). 775 Future Babel extensions (such as sub-TLVs) MAY modify the sending 776 procedure to include the extra data after the fixed-size TS/PC TLV 777 body defined herein, making necessary adjustments to Length TLV 778 field, "Body length" packet header field and output buffer management 779 explained in Section 6.2. 781 4.3. HMAC TLV 783 The purpose of a HMAC TLV is to store a single HMAC result. To 784 assist a receiver in reproducing the HMAC computation, LocalKeyID 785 modulo 2^16 of the authentication key is also provided in the TLV. 786 There is normally at least one HMAC TLV in an authenticated Babel 787 packet. 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type = 12 | Length | KeyID | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Digest... 795 +-+-+-+-+-+-+-+-+-+-+-+- 797 Fields: 799 Type Set to 12 to indicate a HMAC TLV. 801 Length The length of the body, exclusive of the Type and 802 Length fields. 804 KeyID A 16-bit unsigned integer in network byte order. 806 Digest A variable-length sequence of octets, that MUST be at 807 least 16 octets long. 809 Considering the "expected length" and the "extra data" in the 810 definition of Section 4.2 of [BABEL], the expected length of a HMAC 811 TLV body is not defined. The receiving procedure processes every 812 octet of the Digest field, deriving the field boundary from the 813 Length field value (Section 5.4 item 6). The sending procedure 814 produces HMAC TLVs with Length field precisely sizing the Digest 815 field to match digest length of the hash algorithm used (Section 5.3 816 items 5 and 8). 818 HMAC TLV structure defined herein is final, future Babel extensions 819 MUST NOT extend it with any extra data. 821 5. Updates to Protocol Operation 823 5.1. Per-Interface TS/PC Number Updates 825 LocalTS and LocalPC interface-specific variables constitute the TS/PC 826 number of a Babel interface. This number is advertised in the TS/PC 827 TLV of authenticated Babel packets sent from that interface. There 828 is only one property mandatory for the advertised TS/PC number: its 829 48-bit equivalent MUST be strictly increasing within the scope of a 830 given interface of a Babel speaker as long as the speaker is 831 continuously operating. This property combined with ANM tables of 832 neighbouring Babel speakers provides them with the most basic replay 833 attack protection. 835 Initialization and increment are two principal updates performed on 836 an interface TS/PC number. The initialization is performed when a 837 new interface becomes a part of a Babel protocol instance. The 838 increment is performed by the sending procedure (Section 5.3 item 2) 839 before advertising the TS/PC number in a TS/PC TLV. 841 Depending on particular implementation method of these two updates 842 the advertised TS/PC number may possess additional properties 843 improving the replay attack protection strength. This includes, but 844 is not limited to the methods below. 846 a. The most straightforward implementation would use LocalTS as a 847 plain wrap counter, defining the updates as follows: 849 initialization Set LocalPC to 0, set LocalTS to 0. 851 increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF 852 + 1 = 0x0000), increment LocalTS by 1. 854 In this case advertised TS/PC numbers would be reused after each 855 Babel speaker restart, making neighbouring speakers reject 856 authenticated packets until respective ANM table entries expire 857 or the new TS/PC number exceeds the old (see Section 3.6 and 858 Section 3.7). 860 b. A more advanced implementation could make a use of any 32-bit 861 unsigned integer timestamp (number of time units since an 862 arbitrary epoch) such as the UNIX timestamp, whereas the 863 timestamp itself spans a reasonable time range and is guaranteed 864 against a decrease (such as one resulting from network time use). 865 The updates would be defined as follows: 867 initialization Set LocalPC to 0, set LocalTS to 0. 869 increment If the current timestamp is greater than LocalTS, 870 set LocalTS to the current timestamp and LocalPC 871 to 0, then consider the update complete. 872 Otherwise increment LocalPC by 1 and, if LocalPC 873 wraps, increment LocalTS by 1. 875 In this case the advertised TS/PC number would remain unique 876 across speaker's deployed lifetime without the need for any 877 persistent storage. However, a suitable timestamp source is not 878 available in every implementation case. 880 c. Another advanced implementation could use LocalTS in a way 881 similar to the "wrap/boot counter" suggested in Section 4.1.1 of 882 [OSPF3-AUTH], defining the updates as follows: 884 initialization Set LocalPC to 0. Whether there is a TS value 885 stored in NVRAM for the current interface, set 886 LocalTS to the stored TS value, then increment 887 the stored TS value by 1. Otherwise set LocalTS 888 to 0 and set the stored TS value to 1. 890 increment Increment LocalPC by 1. If LocalPC wraps, set 891 LocalTS to the TS value stored in NVRAM for the 892 current interface, then increment the stored TS 893 value by 1. 895 In this case the advertised TS/PC number would also remain unique 896 across speaker's deployed lifetime, relying on NVRAM for storing 897 multiple TS numbers, one per each interface. 899 As long as the TS/PC number retains its mandatory property stated 900 above, an implementer is free to decide, which TS/PC updates 901 implementation methods are available to an operator and whether the 902 method can be configured per-interface and/or in runtime. To enable 903 the optimal (see Section 3.7) management of ANM timeout in a network 904 segment, an implementation MUST allow the operator discovering exact 905 matter of the TS/PC update method effective for any interface, either 906 in runtime or from the system documentation. 908 Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is 909 unlikely, but possible, causing the advertised TS/PC number to be 910 reused. Resolving this situation requires replacing of all 911 authentication keys of the involved interface. In addition to that, 912 if the wrap was caused by a timestamp reaching its end of epoch, 913 using this mechanism will be impossible for the involved interface 914 until some different timestamp or update implementation method is 915 used. 917 5.2. Deriving ESAs from CSAs 919 Neither receiving nor sending procedures work with the contents of 920 interface's list of CSAs directly, both (Section 5.4 item 4 and 921 Section 5.3 item 4 respectively) derive a list of ESAs from the list 922 of CSAs and use the derived list (see Figure 1). There are two main 923 goals achieved through this indirection: 925 o Filtering of expired and duplicate security associations. This is 926 done earliest possible to keep subsequent procedures focused on 927 their respective tasks. 929 o Maintenance of particular sort order in the derived list of ESAs. 930 The sort order deterministically depends on the sort order of 931 interface's list of CSAs and sort order of KeyChain items of each 932 CSA. Particular correlation maintained by this procedure 933 implements a concept of fair (independent of number of keys used 934 by each) competition between CSAs. 936 The deriving procedure uses the following input arguments: 938 o input list of CSAs 940 o direction (sending or receiving) 942 o current time (CT) 944 Processing of input arguments begins with an empty ordered output 945 list of ESAs and consists of the following steps: 947 1. Make a temporary copy of the input list of CSAs. 949 2. Remove all expired keys from the copy, that is, any keys such 950 that: 952 * for receiving: KeyStartAccept is greater than CT or 953 KeyStopAccept is less than CT 955 * for sending: KeyStartGenerate is greater than CT or 956 KeyStopGenerate is less than CT 958 Note well, that there are no special exceptions. Remove all 959 expired keys, even if there are no keys left after that (see 960 Section 7.4). 962 3. Remove all duplicate keys from the copy. A duplicate key (Kd) 963 within a list of CSAs is a key, for that another key (Ka) exists 964 within the same list of CSAs such that every statement below is 965 true: 967 * HashAlgo of the CSA containing Kd is equal to HashAlgo of the 968 CSA containing Ka. 970 * LocalKeyID modulo 2^16 of Kd is equal to LocalKeyID modulo 971 2^16 of Ka 973 * AuthKeyOctets of Kd is equal to AuthKeyOctets of Ka 975 4. Use the copy to populate the output list of ESAs as follows: 977 1. Whether the KeyChain list of the first CSA contains at least 978 one key, use its first key to produce an ESA with fields set 979 as follows: 981 HashAlgo Set to HashAlgo of the current CSA. 983 KeyID Set to LocalKeyID modulo 2^16 of the current 984 key of the current CSA. 986 AuthKeyOctets Set to AuthKeyOctets of the current key of the 987 current CSA. 989 Append this ESA to the end of the output list. 991 2. Whether the KeyChain list of the second CSA contains at least 992 one key, use its first key the same way and so forth until 993 all first keys of the copy are processed. 995 3. Whether the KeyChain list of the first CSA contains at least 996 two keys, use its second key the same way. 998 4. Whether the KeyChain list of the second CSA contains at least 999 two keys, use its second key the same way and so forth until 1000 all second keys of the copy are processed. 1002 5. And so forth until all keys of all CSAs of the copy are 1003 processed, exactly one time each. 1005 The resulting list will contain zero or more unique ESAs, ordered in 1006 a way deterministically correlated with sort order of CSAs within the 1007 original input list of CSAs and sort orders of keys within each 1008 KeyChain list. This ordering maximizes the probability of having 1009 equal amount of keys per original CSA in any N first items of the 1010 resulting list. Possible optimizations of this deriving procedure 1011 are outlined in Section 6.3. 1013 5.3. Updates to Packet Sending 1015 Perform the following authentication-specific processing after the 1016 instance of the original protocol considers an outgoing Babel packet 1017 ready for sending, but before the packet is actually sent (see 1018 Figure 1). After that send the packet regardless if the 1019 authentication-specific processing modified the outgoing packet or 1020 left it intact. 1022 1. If the current outgoing interface's list of CSAs is empty, finish 1023 authentication-specific processing and consider the packet ready 1024 for sending. 1026 2. Increment TS/PC number of the current outgoing interface as 1027 explained in Section 5.1. 1029 3. Append a TS/PC TLV to the packet's sequence of TLVs with fields 1030 set as follows: 1032 Type Set to 11. 1034 Length Set to 6. 1036 PacketCounter Set to the current value of LocalPC variable of 1037 the current outgoing interface. 1039 Timestamp Set to the current value of LocalTS variable of 1040 the current outgoing interface. 1042 Note that the current step may involve byte order conversion. 1044 4. Derive a list of ESAs using procedure defined in Section 5.2 with 1045 the current interface's list of CSAs as the input list of CSAs, 1046 current time as CT and "sending" as the direction. Note that 1047 both the input list of CSAs and the derived list of ESAs are 1048 sorted. Proceed to the next step even if the derived list is 1049 empty. 1051 5. Iterate over the derived list using its sort order. For each ESA 1052 append a HMAC TLV to the end of the packet's sequence of TLVs 1053 with fields set as follows: 1055 Type Set to 12. 1057 Length Set to 2 plus digest length of HashAlgo of the current 1058 ESA. 1060 KeyID Set to KeyID of the current ESA. 1062 Digest Size exactly to the digest length of HashAlgo of the 1063 current ESA. Set the first 16 octets to the source IPv6 1064 address of the current packet (see Section 6.1) and any 1065 subsequent octets to 0x00 (see Figure 3). 1067 As soon as there are MaxDigestsOut HMAC TLVs appended to the 1068 current packet, immediately proceed to the next step. 1070 Note that the current step may involve byte order conversion. 1072 6. Update "Body length" field of the current packet header to 1073 include the total length of TS/PC and HMAC TLVs added to the 1074 current packet so far. 1076 Note that the current step may involve byte order conversion. 1078 7. Make a temporary copy of the current packet. 1080 8. Iterate over the derived list again, using the same very order 1081 and amount of items. For each ESA (and respectively for each 1082 HMAC TLV recently added to the current packet) compute a HMAC 1083 result (see Section 2.4) using the temporary copy (not the 1084 original packet) as Text, HashAlgo of the current ESA as H, and 1085 AuthKeyOctets of the current ESA as K. Write the HMAC result to 1086 the Digest field of the current HMAC TLV (see Figure 4) of the 1087 current packet (not the copy). 1089 9. Since this point, allow no more changes to the current packet and 1090 consider it ready for sending. 1092 Note that even if the derived list of ESAs is empty, the packet is 1093 sent anyway with only a TS/PC TLV appended to its sequence of TLVs. 1094 Although such a packet is not authenticated, presence of a sole TS/PC 1095 TLV indicates authentication keys exhaustion to operators of 1096 neighbouring Babel speakers. See also Section 7.4. 1098 5.4. Updates to Packet Receiving 1100 Perform the following authentication-specific processing after an 1101 incoming Babel packet is received from local IPv6 stack, but before 1102 it is processed by the Babel protocol instance (see Figure 1). The 1103 final action conceptually depends not only upon the result of the 1104 authentication-specific processing, but also on the current value of 1105 RxAuthRequired parameter. Immediately after any processing step 1106 below accepts or refuses the packet, either deliver the packet to the 1107 instance of the original protocol (when the packet is accepted or 1108 RxAuthRequired is FALSE) or discard it (when the packet is refused 1109 and RxAuthRequired is TRUE). 1111 1. If the current incoming interface's list of CSAs is empty, 1112 accept the packet. 1114 2. If the current packet does not contain a TS/PC TLV, refuse it. 1116 3. Perform a lookup in the ANM table for an entry having Interface 1117 equal to the current incoming interface and Source equal to the 1118 source address of the current packet. If such an entry does not 1119 exist, immediately proceed to the next step. Otherwise, compare 1120 the entry's LastTS and LastPC field values with Timestamp and 1121 PacketCounter values respectively of the first TS/PC TLV of the 1122 packet. That is, refuse the packet, if at least one of the 1123 following two conditions is true: 1125 * Timestamp is less than LastTS 1127 * Timestamp is equal to LastTS and PacketCounter is not greater 1128 than LastPC 1130 Note that the current step may involve byte order conversion. 1132 4. Derive a list of ESAs using procedure defined in Section 5.2 1133 with the current interface's list of CSAs as the input list of 1134 CSAs, current time as CT and "receiving" as the direction. If 1135 the derived list is empty, refuse the packet. 1137 5. Make a temporary copy of the current packet. 1139 6. For every HMAC TLV present in the temporary copy (not the 1140 original packet) pad all octets of its Digest field using the 1141 source IPv6 address of the current packet to set the first 16 1142 octets and 0x00 to set any subsequent octets (see Figure 3). 1144 7. Iterate over all HMAC TLVs of the original input packet (not the 1145 copy) using their order of appearance in the packet. For each 1146 HMAC TLV look up all ESAs in the derived list such that 2 plus 1147 digest length of HashAlgo of the ESA is equal to Length of the 1148 TLV and KeyID of the ESA is equal to value of KeyID of the TLV. 1149 Iterate over these ESAs in the order of their appearance on the 1150 full list of ESAs. Note that nesting the iterations the 1151 opposite way (over ESAs, then over HMAC TLVs) is wrong. 1153 For each of these ESAs compute a HMAC result (see Section 2.4) 1154 using the temporary copy (not the original packet) as Text, 1155 HashAlgo of the current ESA as H, and AuthKeyOctets of the 1156 current ESA as K. If the current HMAC result exactly matches the 1157 contents of Digest field of the current HMAC TLV, immediately 1158 proceed to the next step. Otherwise, if number of HMAC 1159 computations done for the current packet is equal to 1160 MaxDigestsIn, immediately proceed to the next step. Otherwise 1161 follow the normal order of iterations. 1163 Note that the current step may involve byte order conversion. 1165 8. If none of the HMAC results computed during the previous step 1166 matched, refuse the input packet. 1168 9. Modify the ANM table, using the same index as for the entry 1169 lookup above, to contain an entry with LastTS set to the value 1170 of Timestamp and LastPC set to the value of PacketCounter fields 1171 of the first TS/PC TLV of the current packet. That is, either 1172 add a new ANM table entry or update the existing one, according 1173 to the result of the entry lookup above. Reset the entry's 1174 aging timer to the current value of ANM timeout. 1176 Note that the current step may involve byte order conversion. 1178 10. Accept the input packet. 1180 Note that RxAuthRequired affects only the final action, but not the 1181 defined flow of authentication-specific processing. The purpose of 1182 this is to preserve authentication-specific processing feedback (such 1183 as log messages and event counters updates) even with RxAuthRequired 1184 set to FALSE. This allows an operator to predict the effect of 1185 changing RxAuthRequired from FALSE to TRUE during a migration 1186 scenario (Section 7.3) implementation. 1188 5.5. Authentication-Specific Statistics Maintenance 1190 A Babel speaker implementing this mechanism SHOULD maintain a set of 1191 counters for the following events, per protocol instance and per each 1192 interface: 1194 o Sending of an unauthenticated Babel packet through an interface 1195 having an empty list of CSAs. 1197 o Sending of an unauthenticated Babel packet with a TS/PC TLV but 1198 without any HMAC TLVs due to an empty list of ESAs. 1200 o Sending of an authenticated Babel packet containing both TS/PC and 1201 HMAC TLVs. 1203 o Accepting of a Babel packet received through an interface having 1204 an empty list of CSAs. 1206 o Refusing of a received Babel packet due to an empty list of ESAs. 1208 o Refusing of a received Babel packet missing any TS/PC TLVs. 1210 o Refusing of a received Babel packet due to the first TS/PC TLV 1211 failing the ANM table check. 1213 o Refusing of a received Babel packet missing any HMAC TLVs. 1215 o Refusing of a received Babel packet due to none of the processed 1216 HMAC TLVs passing the ESA check. 1218 o Accepting of a received Babel packet having both TS/PC and HMAC 1219 TLVs. 1221 o Delivery of a refused packet to the instance of the original 1222 protocol due to RxAuthRequired parameter set to FALSE. 1224 Note that terms "accepting" and "refusing" are used in the sense of 1225 the receiving procedure, that is, "accepting" does not mean a packet 1226 delivered to the instance of the original protocol purely because of 1227 RxAuthRequired parameter set to FALSE. Event counters readings 1228 SHOULD be available in runtime through common management interfaces 1229 such as CLI and SNMP. 1231 6. Implementation Notes 1233 6.1. IPv6 Source Address Selection for Sending 1235 Section 3.1 of [BABEL] defines, that Babel datagrams are exchanged 1236 using IPv6 link-local address as source address. This implies having 1237 at least one such address assigned to an interface participating in 1238 the exchange. When the interface has more than one link-local 1239 addresses assigned, selection of one particular link-local address as 1240 packet source address is left up to the local IPv6 stack, since this 1241 choice is not meaningful in the scope of the original protocol. 1242 However, the sending procedure defined in Section 5.3 requires exact 1243 knowledge of packet source address for proper padding of HMAC TLVs. 1245 As long as a Babel interface has more than one IPv6 link-local 1246 addresses assigned, the Babel speaker SHOULD internally choose one 1247 particular link-local address for Babel packet sending purposes and 1248 make this choice to both the sending procedure and local IPv6 stack 1249 (see Figure 1). Wherever this requirement cannot be met, this 1250 limitation MUST be clearly stated in the system documentation to 1251 allow an operator to plan IPv6 address management accordingly. 1253 6.2. Output Buffer Management 1255 An instance of the original protocol buffers produced TLVs until the 1256 buffer becomes full or a delay timer has expired or an urgent TLV is 1257 produced. This is performed independently for each Babel interface 1258 with each buffer sized according to the interface MTU (see Sections 1259 3.1 and 4 of [BABEL]). 1261 Since TS/PC and HMAC TLVs and any other TLVs, in the first place 1262 those of the original protocol, share the same packet space (see 1263 Figure 2) and respectively the same buffer space, a particular 1264 portion of each interface buffer needs to be reserved for 1 TS/PC TLV 1265 and up to MaxDigestsOut HMAC TLVs. Amount (R) of this reserved 1266 buffer space is calculated as follows: 1268 R = St + MaxDigestsOut * Sh = 1269 = 8 + MaxDigestsOut * (4 + Lmax) 1271 St Is the size of a TS/PC TLV. 1273 Sh Is the size of a HMAC TLV. 1275 Lmax Is the maximum digest length in octets possible for a 1276 particular interface. It SHOULD be calculated based on 1277 particular interface's list of CSAs, but MAY be taken as the 1278 maximum digest length supported by particular implementation. 1280 An implementation allowing for per-interface value of MaxDigestsOut 1281 parameter has to account for different value of R across different 1282 interfaces, even having the same MTU. An implementation allowing for 1283 runtime change of MaxDigestsOut parameter value has to take care of 1284 the TLVs already buffered by the time of the change, especially when 1285 the change increases the value of R. 1287 The maximum safe value of MaxDigestsOut parameter depends on 1288 interface MTU and maximum digest length used. In general, at least 1289 200-300 octets of a Babel packet should be always available to data 1290 other than TS/PC and HMAC TLVs. An implementation following the 1291 requirements of Section 4 of [BABEL] would send packets sized 512 1292 octets or larger. If, for example, the maximum digest length is 64 1293 octets and MaxDigestsOut value is 4, the value of R would be 280, 1294 leaving less than a half of a 512-octet packet for any other TLVs. 1295 As long as interface MTU is larger or digest length is smaller, 1296 higher values of MaxDigestsOut can be used safely. 1298 6.3. Optimizations of ESAs Deriving 1300 The following optimizations of the ESAs deriving procedure can reduce 1301 amount of CPU time consumed by authentication-specific processing, 1302 preserving implementation's effective behaviour. 1304 a. The most straightforward implementation would treat the deriving 1305 procedure as a per-packet action. But since the procedure is 1306 deterministic (its output depends on its input only), it is 1307 possible to significantly reduce the number of times the 1308 procedure is performed. 1310 The procedure would obviously return the same result for the same 1311 input arguments (list of CSAs, direction, CT) values. However, 1312 it is possible to predict, when the result will remain the same 1313 even for a different input. That is, when the input list of CSAs 1314 and the direction both remain the same but CT changes, the result 1315 will remain the same as long as CT's order on the time axis 1316 (relative to all critical points of the list of CSAs) remains 1317 unchanged. Here, the critical points are KeyStartAccept and 1318 KeyStopAccept (for the "receiving" direction) and 1319 KeyStartGenerate and KeyStopGenerate (for the "sending" 1320 direction) of all keys of all CSAs of the input list. In other 1321 words, in this case the result will remain the same as long as 1322 both none of the active keys expire and none of the inactive keys 1323 enter into operation. 1325 An implementation optimized this way would perform the full 1326 deriving procedure for a given (interface, direction) pair only 1327 after an operator's change to the interface's list of CSAs or 1328 after reaching one of the critical points mentioned above. 1330 b. Considering, that the sending procedure iterates over at most 1331 MaxDigestsOut items of the ordered list of derived ESAs 1332 (Section 5.3 item 5), there is little sense in the case of 1333 "sending" direction in appending ESA items to the end of the 1334 output list once the list already contains MaxDigestsOut number 1335 of items. Note that a similar optimization is impossible in the 1336 case of "receiving" direction, since number of ESAs actually used 1337 in examining a particular packet cannot be determined in advance. 1339 6.4. CSA Implementation Specifics 1341 The KeyChain list of the CSA structure is a direct equivalent of the 1342 "key chain" syntax item of some existing router configuration 1343 languages. Whereas an implementation already implements this syntax 1344 item, it is suggested to reuse it, that is, to implement a CSA syntax 1345 item referring to a key chain item instead of reimplementing the 1346 latter in full. 1348 No CSA structure field (including HashAlgo, LocalKeyID, and 1349 AuthKeyOctets) value has to be unique within a given CSA, or within a 1350 given list of CSAs, or within all lists of CSAs of a Babel speaker. 1351 Respectively, for any two authentication keys their one field 1352 (in)equality would not imply their another field (in)equality. In 1353 particular, in the CSA space defined this way it is acceptable to 1354 have more than one authentication key with the same LocalKeyID or the 1355 same AuthKeyOctets or both at a time. It is a conscious design 1356 decision, that CSA semantics allow for duplication of contained data 1357 items. 1359 One of the intents of this is to define the security association 1360 management in a way to allow addressing some specifics of Babel as a 1361 mesh routing protocol. For example, a system operator configuring a 1362 Babel speaker to participate in more than one administrative domain 1363 could find each domain using its own authentication key 1364 (AuthKeyOctets) under the same LocalKeyID value, e.g., a "well-known" 1365 value like 0 or 1. Since reconfiguring the domains to use distinct 1366 LocalKeyID values isn't always feasible, the multi-domain Babel 1367 speaker using several distinct authentication keys under the same 1368 LocalKeyID would make a valid use case for such duplication. 1370 Likewise, if in such a situation the operator decided to change 1371 LocalKeyID of a domain to a different value in a seamless way, 1372 respective Babel speakers would use the same authentication key 1373 (AuthKeyOctets) under two different LocalKeyID values for the time of 1374 the transition (see also item (e) of Section 8). This would make a 1375 similar use case. 1377 Another intent is to set authentication key management and security 1378 association management as two interfaced, but otherwise independent 1379 processes. This way an implementation can include arbitrary 1380 authentication key management process(es) and at the same time 1381 conform to the CSA management constraints defined in Section 3.8. 1382 This is also the reason why LocalKeyID field has a bit length in ESA, 1383 but not in CSA. 1385 7. Network Management Aspects 1387 7.1. Backward Compatibility 1389 Support of this mechanism is optional, it does not change the default 1390 behaviour of a Babel speaker and causes no compatibility issues with 1391 speakers properly implementing the original Babel specification. 1392 Given two Babel speakers, one implementing this mechanism and 1393 configured for authenticated exchange (A) and another not not 1394 implementing it (B), these would not distribute routing information 1395 uni-directionally or form a routing loop or experience other protocol 1396 logic issues specific purely to the use of this mechanism. 1398 Babel design requires a bi-directional neighbour reachability 1399 condition between two given speakers for a successful exchange of 1400 routing information. Apparently, in the case above neighbour 1401 reachability would be uni-directional. Presence of TS/PC and HMAC 1402 TLVs in Babel packets sent by A would be transparent to B. But lack 1403 of authentication data in Babel packets send by B would make them 1404 effectively invisible to the instance of the original protocol of A. 1405 Uni-directional links are not specific to use of this mechanism, they 1406 naturally exist on their own and are properly detected and avoided by 1407 the original protocol (see Section 3.4.2 of [BABEL]). 1409 7.2. Multi-Domain Authentication 1411 The receiving procedure treats a packet as authentic as soon as one 1412 of its HMAC TLVs passes the check against the list of ESAs. This 1413 allows for packet exchange authenticated with multiple (hash 1414 algorithm, authentication key) pairs simultaneously, in combinations 1415 as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut. 1417 For example, consider three Babel speakers with one interface each, 1418 configured with the following CSAs: 1420 o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key 1421 SK2) 1423 o speaker B: (hash algorithm H1; key SK1) 1425 o speaker C: (hash algorithm H1; key SK2) 1427 Packets sent by A would contain 2 HMAC TLVs each, packets sent by B 1428 and C would contain 1 HMAC TLV each. A and B would authenticate the 1429 exchange between themselves using H1 and SK1; A and C would use H1 1430 and SK2; B and C would discard each other's packets. 1432 Consider a similar set of speakers configured with different CSAs: 1434 o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key 1435 SK4) 1437 o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys 1438 SK5 and SK6) 1440 o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm 1441 H5, key SK8) 1443 Packets sent by D would contain 2 HMAC TLVs each, packets sent by E 1444 and F would contain 3 HMAC TLVs each. D and E would authenticate the 1445 exchange between themselves using H2 and SK3; D and F would use H3 1446 and SK4; E and F would discard each other's packets. The 1447 simultaneous use of H4, SK5, and SK6 by E, as well as use of SK7, H5, 1448 and SK8 by F (for their own purposes) would remain insignificant to 1449 A. 1451 An operator implementing a multi-domain authentication should keep in 1452 mind, that values of MaxDigestsIn and MaxDigestsOut may be different 1453 both within the same Babel speaker and across different speakers. 1454 Since the minimum value of both parameters is 2 (see Section 3.4 and 1455 Section 3.5), when more than 2 authentication domains are configured 1456 simultaneously, it is advised to confirm that every involved speaker 1457 can handle sufficient number of HMAC results for both sending and 1458 receiving. 1460 The recommended method of Babel speaker configuration for multi- 1461 domain authentication is not only using a different authentication 1462 key for each domain, but also using a separate CSA for each domain, 1463 even when hash algorithms are the same. This allows for fair 1464 competition between CSAs and sometimes limits consequences of a 1465 possible misconfiguration to the scope of one CSA. See also item (e) 1466 of Section 8. 1468 7.3. Migration to and from Authenticated Exchange 1470 It is common in practice to consider a migration to authenticated 1471 exchange of routing information only after the network has already 1472 been deployed and put to an active use. Performing the migration in 1473 a way without regular traffic interruption is typically demanded, and 1474 this specification allows for such a smooth migration using the 1475 RxAuthRequired interface parameter defined in Section 3.1. This 1476 measure is similar to the "transition mode" suggested in Section 5 of 1477 [OSPF3-AUTH]. 1479 An operator performing the migration needs to arrange configuration 1480 changes as follows: 1482 1. Decide on particular hash algorithm(s) and key(s) to be used. 1484 2. Identify all speakers and their involved interfaces that need to 1485 be migrated to authenticated exchange. 1487 3. For each of the speakers and the interfaces to be reconfigured 1488 first set RxAuthRequired parameter to FALSE, then configure 1489 necessary CSA(s). 1491 4. Examine the speakers to confirm, that Babel packets are 1492 successfully authenticated according to the configuration 1493 (supposedly, through examining ANM table entries and 1494 authentication-specific statistics, see Figure 1), and address 1495 any discrepancies before proceeding further. 1497 5. For each of the speakers and the reconfigured interfaces set 1498 RxAuthRequired parameter to TRUE. 1500 Likewise, temporarily setting RxAuthRequired to FALSE can be used to 1501 migrate smoothly from authenticated packet exchange back to 1502 unauthenticated one. 1504 7.4. Handling of Authentication Keys Exhaustion 1506 This specification employs a common concept of multiple authenticaion 1507 keys co-existing for a given interface, with two independent lifetime 1508 ranges associated with each key (one for sending and another for 1509 receiving). It is typically recommended to configure the keys using 1510 finite lifetimes, adding new keys before the old keys expire. 1511 However, it is obviously possible for all keys to expire for a given 1512 interface (for sending or receiving or both). Possible ways of 1513 addressing this situation raise their own concerns: 1515 o Automatic switching to unauthenticated protocol exchange. This 1516 behaviour invalidates the initial purposes of authentication and 1517 is commonly viewed as "unacceptable" ([RIP2-AUTH] Section 5.1, 1518 [OSPF2-AUTH] Section 3.2, [OSPF3-AUTH] Section 3). 1520 o Stopping routing information exchange over the interface. This 1521 behaviour is likely to impact regular traffic routing and is 1522 commonly viewed as "not advisable" (ibid.). 1524 o Use of the "most recently expired" key over its intended lifetime 1525 range. This behaviour is commonly recommended for implementation 1526 (ibid.), although it may become a problem due to an offline 1527 cryptographic attack (see item (e) of Section 8) or a compromise 1528 of the key. In addition, telling a recently expired key from a 1529 key never ever been in a use may be impossible after a router 1530 restart. 1532 Design of this mechanism prevents the automatic switching to 1533 unauthenticated exchange and is consistent with similar 1534 authentication mechanisms in this regard. But since the best choice 1535 between two other options depends on local site policy, this decision 1536 is left up to the operator rather than the implementer (in a way 1537 resembling the "fail secure" configuration knob described in Section 1538 5.1 of [RIP2-AUTH]). 1540 Although the deriving procedure does not allow for any exceptions in 1541 expired keys filtering (Section 5.2 item 2), the operator can 1542 trivially enforce one of the two remaining behaviour options through 1543 local key management procedures. In particular, when using the key 1544 over its intended lifetime is more preferred than regular traffic 1545 disruption, the operator would explicitly leave the old key expiry 1546 time open until the new key is added to the router configuration. In 1547 the opposite case the operator would always configure the old key 1548 with a finite lifetime and bear associated risks. 1550 8. Security Considerations 1552 Use of this mechanism implies requirements common to a use of shared 1553 authentication keys, including, but not limited to: 1555 o holding the keys secret, 1557 o including sufficient amount of random bits into each key, 1559 o rekeying on a regular basis, and 1560 o never reusing a used key for a different purpose 1562 That said, proper design and implementation of a key management 1563 policy is out of scope of this work. Many publications on this 1564 subject exist and should be used for this purpose. 1566 Considering particular attacks being in-scope or out of scope on one 1567 hand and measures taken to protect against particular in-scope 1568 attacks on the other, the original Babel protocol and this 1569 authentication mechanism are in line with similar datagram-based 1570 routing protocols and their respective mechanisms. In particular, 1571 the primary concerns addressed are: 1573 a. Peer Entity Authentication 1575 Babel speaker authentication mechanism defined herein is believed 1576 to be as strong as is the class itself that it belongs to. This 1577 specification is built on the fundamental concepts implemented 1578 for authentication of similar routing protocols: per-packet 1579 authentication, use of HMAC construct, use of shared keys. 1580 Although this design approach does not address all possible 1581 concerns, it is so far known to be sufficient for most practical 1582 cases. 1584 b. Data Integrity 1586 Meaningful parts of a Babel datagram are the contents of the 1587 Babel packet (in the definition of Section 4.2 of [BABEL]) and 1588 IPv6 source address of the datagram (Section 3.5.3 ibid.). This 1589 mechanism authenticates both parts using a HMAC construct, so 1590 that making any meaningful change to an authenticated packet 1591 after it has been emitted by the sender should be as hard as 1592 attacking the hash algorithm itself or successfully recovering 1593 the authentication key. 1595 Note well, that any trailing data of the Babel datagram is not 1596 meaningful in the scope of the original specification and does 1597 not belong to the Babel packet. Integrity of the trailing data 1598 is respectively not protected by this mechanism. At the same 1599 time, although any TLV extra data is also not meaningful in the 1600 same scope, its integrity is protected, since this extra data is 1601 a part of the Babel packet (see Figure 2). 1603 c. Replay Attacks 1605 This specification establishes a basic replay protection measure 1606 (see Section 3.6), defines a timeout parameter affecting its 1607 strength (see Section 3.7), and outlines implementation methods 1608 also affecting protection strength in several ways (see 1609 Section 5.1). Implementer's choice of the timeout value and 1610 particular implementation methods may be suboptimal due to, for 1611 example, insufficient hardware resources of the Babel speaker. 1612 Furthermore, it may be possible, that an operator configures the 1613 timeout and the methods to address particular local specifics and 1614 this further weakens the protection. An operator concerned about 1615 replay attack protection strength should understand these factors 1616 and their meaning in a given network segment. 1618 d. Denial of Service 1620 Proper deploy of this mechanism in a Babel network significantly 1621 increases the efforts required for an attacker to feed arbitrary 1622 Babel PDUs into protocol exchange (with an intent of attacking a 1623 particular Babel speaker or disrupting exchange of regular 1624 traffic in a routing domain). It also protects the neighbour 1625 table from being flooded with forged speaker entries. 1627 At the same time, this protection comes for a price of CPU time 1628 being spent on HMAC computations. This may be a concern for low- 1629 performance CPUs combined with high-speed interfaces, as 1630 sometimes is seen in embedded systems and hardware routers. The 1631 MaxDigestsIn parameter, which is purposed to limit the maximum 1632 amount of CPU time spent on a single received Babel packet, 1633 addresses this concern to some extent. 1635 The following in-scope concerns are not addressed: 1637 e. Offline Cryptographic Attacks 1639 This mechanism is an obvious subject to offline cryptographic 1640 attacks. As soon as an attacker has obtained a copy of an 1641 authenticated Babel packet of interest (which gets easier to do 1642 in wireless networks), he has got all the parameters of the 1643 authentication-specific processing performed by the sender, 1644 except authentication key(s) and choice of particular hash 1645 algorithm(s). Since digest lengths of common hash algorithms are 1646 well-known and can be matched with those seen in the packet, 1647 complexity of this attack is essentially that of the 1648 authentication key attack. 1650 Viewing cryptographic strength of particular hash algorithms as a 1651 concern of its own, the main practical means of resisting offline 1652 cryptographic attacks on this mechanism are periodic rekeying and 1653 use of strong keys with sufficient amount of random bits. 1655 It is important to understand, that in the case of multiple keys 1656 being used within single interface (for a multi-domain 1657 authentication or during a key rollover) strength of the combined 1658 configuration would be that of the weakest key, since only one 1659 successful HMAC test is required for an authentic packet. 1660 Operators concerned about offline cryptographic attacks should 1661 enforce the same strength policy for all keys used for a given 1662 interface. 1664 Note that a special pathological case is possible with this 1665 mechanism. Whenever two or more authentication keys are 1666 configured for a given interface such that all keys share the 1667 same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 1668 2^16 is different for each key, these keys will not be treated as 1669 duplicate (Section 5.2 item 3), but a HMAC result computed for a 1670 given packet will be the same for each of these keys. In the 1671 case of sending procedure this can produce multiple HMAC TLVs 1672 with exactly the same value of the Digest field, but different 1673 value of KeyID field. In this case the attacker will see that 1674 the keys are the same, even without the knowledge of the key 1675 itself. Reuse of authentication keys is not the intended use 1676 case of this mechanism and should be strongly avoided. 1678 f. Non-repudiation 1680 This specification relies on a use of shared keys. There is no 1681 timestamp infrastructure and no key revocation mechanism defined 1682 to address a shared key compromise. Establishing the time that a 1683 particular authentic Babel packet was generated is thus not 1684 possible. Proving, that a particular Babel speaker had actually 1685 sent a given authentic packet is also impossible as soon as the 1686 shared key is claimed compromised. Even with the shared key not 1687 being compromised, reliably identifying the speaker that had 1688 actually sent a given authentic Babel packet is not possible any 1689 better than proving the speaker to belong to the group sharing 1690 the key (any of the speakers sharing a key can impose any other 1691 speaker sharing the same key). 1693 g. Confidentiality Violations 1695 The original Babel protocol does not encrypt any of the 1696 information contained in its packets. Contents of a Babel packet 1697 is trivial to decode, revealing network topology details. This 1698 mechanism does not improve this situation in any way. Since 1699 routing protocol messages are not the only kind of information 1700 subject to confidentiality concerns, a complete solution to this 1701 problem is likely to include measures based on the channel 1702 security model, such as IPSec and WPA2 at the time of this 1703 writing. 1705 h. Key Management 1707 Any authentication key exchange/distribution concerns are left 1708 out of scope. However, the internal representation of 1709 authentication keys (see Section 3.8) allows for diverse key 1710 management means, manual configuration in the first place. 1712 i. Message Deletion 1714 Any message deletion attacks are left out of scope. Since a 1715 datagram deleted by an attacker cannot be distinguished from a 1716 datagram naturally lost in transmission and since datagram-based 1717 routing protocols are designed to withstand a certain loss of 1718 packets, the currently established practice is treating 1719 authentication purely as a per-packet function without any added 1720 detection of lost packets. 1722 9. IANA Considerations 1724 [RFC Editor: please do not remove this section.] 1726 At the time of this publication Babel TLV Types namespace did not 1727 have an IANA registry. TLV types 11 and 12 were assigned (see 1728 Table 1) to the TS/PC and HMAC TLV types by Juliusz Chroboczek, 1729 designer of the original Babel protocol. Therefore, this document 1730 has no IANA actions. 1732 10. Acknowledgements 1734 Thanks to Ran Atkinson and Matthew Fanto for their comprehensive work 1735 on [RIP2-AUTH] that initiated a series of publications on routing 1736 protocols authentication, including this one. This specification 1737 adopts many concepts belonging to the whole series. 1739 Thanks to Juliusz Chroboczek for his works on mesh networking in 1740 general and Babel routing protocol in particular, and also for 1741 feedback on early revisions of this document. This work would not be 1742 possible without prior works on Babel. 1744 Thanks to Jim Gettys and Dave Taht for developing CeroWrt wireless 1745 router project and collaborating on many integration issues. A 1746 practical need for Babel authentication emerged during a research 1747 based on CeroWrt that eventually became the very first use case of 1748 this mechanism. 1750 Thanks to Kunihiro Ishiguro and Paul Jakma for establishing GNU Zebra 1751 and Quagga routing software projects respectively. Thanks to Werner 1752 Koch, the author of Libgcrypt. The very first implementation of this 1753 mechanism was made on base of Quagga and Libgcrypt. 1755 This document was produced using the xml2rfc ([RFC2629]) authoring 1756 tool. 1758 11. References 1760 11.1. Normative References 1762 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1763 Hashing for Message Authentication", RFC 2104, 1764 February 1997. 1766 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1767 Requirement Levels", BCP 14, RFC 2119, March 1997. 1769 [FIPS-198] 1770 US National Institute of Standards & Technology, "The 1771 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 1772 198 , March 2002. 1774 [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1775 April 2011. 1777 11.2. Informative References 1779 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1780 June 1999. 1782 [RIP2-AUTH] 1783 Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1784 Authentication", RFC 4822, February 2007. 1786 [OSPF2-AUTH] 1787 Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 1788 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 1789 Authentication", RFC 5709, October 2009. 1791 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 1792 with Existing Cryptographic Protection Methods for Routing 1793 Protocols", RFC 6039, October 2010. 1795 [OSPF3-AUTH] 1796 Bhatia, M., Manral, V., and A. Lindem, "Supporting 1797 Authentication Trailer for OSPFv3", RFC 6506, 1798 February 2012. 1800 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 1801 Considerations for Protocol Extensions", RFC 6709, 1802 September 2012. 1804 Appendix A. Figures 1805 +-------------------------------------------------------------+ 1806 | authentication-specific statistics | 1807 +-------------------------------------------------------------+ 1808 ^ | ^ 1809 | v | 1810 | +-----------------------------------------------+ | 1811 | | system operator | | 1812 | +-----------------------------------------------+ | 1813 | ^ | ^ | ^ | ^ | ^ | | 1814 | | v | | | | | | | v | 1815 +---+ +---------+ | | | | | | +---------+ +---+ 1816 | |->| ANM | | | | | | | | LocalTS |->| | 1817 | R |<-| table | | | | | | | | LocalPC |<-| T | 1818 | x | +---------+ | v | v | v +---------+ | x | 1819 | | +----------------+ +---------+ +----------------+ | | 1820 | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | 1821 | r |<-| ANM timeout | | CSAs | | |->| r | 1822 | o | | RxAuthRequired | | | | | | o | 1823 | c | +----------------+ +---------+ +----------------+ | c | 1824 | e | +-------------+ | | +-------------+ | e | 1825 | s | | Rx ESAs | | | | Tx ESAs | | s | 1826 | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | 1827 | i | +-------------+ +-------------+ | i | 1828 | n | +------------------------------+----------------+ | n | 1829 | g | | instance of | output buffers |=>| g | 1830 | |=>| the original +----------------+ | | 1831 | | | protocol | source address |->| | 1832 +---+ +------------------------------+----------------+ +---+ 1833 /\ | || 1834 || v \/ 1835 +-------------------------------------------------------------+ 1836 | IPv6 stack | 1837 +-------------------------------------------------------------+ 1838 /\ || /\ || /\ || /\ || 1839 || \/ || \/ || \/ || \/ 1840 +---------+ +---------+ +---------+ +---------+ 1841 | speaker | | speaker | ... | speaker | | speaker | 1842 +---------+ +---------+ +---------+ +---------+ 1844 Flow of Babel datagrams: ===> Flow of control data: ---> 1846 Figure 1: Interaction Diagram 1848 The diagram below depicts structure of two Babel datagrams. The left 1849 datagram contains an unauthenticated Babel packet and an optional 1850 trailing data block. The right datagram, besides these, contains 1851 authentication-specific TLVs in the Babel packet body. 1853 +-------------------+ ------- ------- +-------------------+ 1854 | Babel packet | ^ ^ | Babel packet | 1855 | header | | | | header | 1856 +-------------------+ -- | | -- +-------------------+ 1857 | some TLV | ^ | | ^ | some TLV | 1858 +-------------------+ | | | | +-------------------+ 1859 | some TLV | | | P | | | some TLV | 1860 +-------------------+ | | | | +-------------------+ 1861 | (...) | | B | | | | (...) | 1862 +-------------------+ | | | | +-------------------+ 1863 | some TLV | | | P | | | some TLV | 1864 +-------------------+ | | | | +-------------------+ 1865 | some TLV | v v | B | | some TLV | 1866 +-------------------+ ------- | | +-------------------+ 1867 | optional trailing | | | | TS/PC TLV | 1868 | data block | | | +-------------------+ 1869 +-------------------+ | | | HMAC TLV | 1870 | | +-------------------+ 1871 | | | (...) | 1872 | | +-------------------+ 1873 P: Babel packet v v | HMAC TLV | 1874 B: Babel packet body ------- +-------------------+ 1875 | optional trailing | 1876 | data block | 1877 +-------------------+ 1879 Figure 2: Babel Datagram Structure 1881 The diagram below depicts a sample HMAC TLV corresponding to a hash 1882 algorithm with digest length of 20 octets (such as RIPEMD-160). Its 1883 Digest field is fully padded using IPv6 address 1884 fe80::0a11:96ff:fe1c:10c8 for the first 16 octets and 0x00 for the 1885 subsequent octets. 1887 0 1 2 3 1888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Type = 12 | Length = 22 | KeyID = 12345 | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | Digest = 0xFE 80 00 00 | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | 00 00 00 00 | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | 0A 11 96 FF | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | FE 1C 10 C8 | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | 00 00 00 00 | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 Figure 3: A Padded HMAC TLV 1905 The diagram below depicts the same HMAC TLV with all 20 octets of a 1906 sample HMAC result written to the Digest field. 1908 0 1 2 3 1909 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 | Type = 12 | Length = 22 | KeyID = 12345 | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | Digest = 0x4F C8 C8 9D | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | 57 83 91 9B | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | 81 B0 90 47 | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | B4 2F E3 37 | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | A7 BE 93 83 | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 Figure 4: A HMAC TLV with a HMAC Result 1926 Author's Address 1928 Denis Ovsienko 1929 Yandex 1930 16, Leo Tolstoy St. 1931 Moscow, 119021 1932 Russia 1934 Email: infrastation@yandex.ru