idnits 2.17.1 draft-ovsienko-babel-hmac-authentication-00.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 (August 20, 2012) is 4268 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) August 20, 2012 5 Intended status: Experimental 6 Expires: February 21, 2013 8 Babel HMAC Cryptographic Authentication 9 draft-ovsienko-babel-hmac-authentication-00 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 February 21, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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. Neutral Use of 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.3. LocalPC . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. MaxDigestsIn . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. MaxDigestsOut . . . . . . . . . . . . . . . . . . . . . . 9 65 3.6. ANM Table . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.7. ANM Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.8. Configured Security Associations . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 17 74 5.1. Per-interface TS/PC Number Updates . . . . . . . . . . . . 17 75 5.2. Deriving ESAs from CSAs . . . . . . . . . . . . . . . . . 19 76 5.3. Updates to Packet Sending . . . . . . . . . . . . . . . . 21 77 5.4. Updates to Packet Receiving . . . . . . . . . . . . . . . 23 78 5.5. Authentication-specific Statistics Maintenance . . . . . . 25 79 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 26 80 6.1. IPv6 Source Address Selection for Sending . . . . . . . . 26 81 6.2. Output Buffer Management . . . . . . . . . . . . . . . . . 26 82 6.3. Optimizations of ESAs Deriving . . . . . . . . . . . . . . 27 83 6.4. Internal Representation of CSAs . . . . . . . . . . . . . 28 84 7. Network Management Aspects . . . . . . . . . . . . . . . . . . 28 85 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . . 28 86 7.2. Multi-Domain Authentication . . . . . . . . . . . . . . . 29 87 7.3. Migration . . . . . . . . . . . . . . . . . . . . . . . . 30 88 7.4. Handling of Authentication Keys Exhaustion . . . . . . . . 31 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 37 95 Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . . 38 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41 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 The HMAC construct can be combined with any cryptographic hash 151 algorithm, although the primary focus of [RIP2-AUTH], [OSPF2-AUTH], 152 and [OSPF3-AUTH] is either SHA-1 hash algorithm or SHA-2 family of 153 hash algorithms, or both. This specification does not mandate or 154 suggest a use of any particular hash algorithms. This mechanism can 155 be deployed using any appropriate hash algorithms, as long as Babel 156 speakers participating in the authenticated exchange are implemented 157 and configured consistently. 159 This mechanism explicitly allows for multiple HMAC results per an 160 authenticated packet. Since meaningful data items of a given packet 161 remain the same, each such HMAC result stands for a different secret 162 key and/or a different hash algorithm. This enables a simultaneous, 163 independent authentication within multiple domains. 165 An important concern addressed by this mechanism is limiting the 166 amount of HMAC computations done per an authenticated packet, 167 independently for sending and receiving. Without these limits the 168 number of computations per a packet could be as high as number of 169 configured authentication keys (in sending case) or as the number of 170 keys multiplied by the number of supplied HMAC results (in receiving 171 case). 173 These limits establish a basic competition between the configured 174 keys and (in receiving case) an additional competition between the 175 supplied HMAC results. This specification defines related data 176 structures and procedures in a way to make such competition 177 transparent and predictable for an operator. 179 1.1. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in RFC 2119 [RFC2119]. 185 2. Cryptographic Aspects 187 2.1. Neutral Use of Hash Algorithms 189 The only hash algorithm characteristics meaningful within the scope 190 of processing defined herein are digest length and internal block 191 size, there is no pre- or post-processing specific to a particular 192 hash algorithm. The following generic requirements affect only the 193 set of options available for an implementation. 195 A set of hash algorithms available in an implementation MUST be 196 clearly stated, MUST include at least one option and SHOULD include 197 multiple options. Implementers SHOULD consider strong, well-known 198 hash algorithms as implementation options and MUST NOT consider hash 199 algorithms for that by the time of implementation meaningful attacks 200 exist or that are commonly viewed as deprecated. 202 For example, the following hash algorithms meet these requirements at 203 the time of this writing: 205 o GOST (256-bit hash) 207 o RIPEMD-160 209 o SHA-224 211 o SHA-256 213 o SHA-384 215 o SHA-512 217 o Tiger (192-bit hash) 219 o Whirlpool (512-bit hash) 221 The final choice of particular hash algorithm(s) is left up to the 222 implementer. Whether known weak authentication keys exist for a hash 223 algorithm used in an implementation of this mechanism, the 224 implementation MUST deny a use of such keys. 226 2.2. Padding Constant Specifics 228 [RIP2-AUTH] established the reference method of HMAC construct 229 application housing the computed authentication data inside the 230 message being authenticated. This involves pre-allocating necessary 231 amount of message data space and pre-filling it with some data a 232 receiver can reproduce exactly, typically an arbitrary number known 233 as a padding constant. The padding constant used in [RIP2-AUTH] is 234 0x878FE1F3 four-octet value. 236 Subsequent works (including [OSPF2-AUTH] and [OSPF3-AUTH]) inherited 237 both the basic approach and the padding constant. In particular, 238 [OSPF3-AUTH] uses a source IPv6 address to set the first 16 octets of 239 the padded area and the padding constant to set any subsequent 240 octets. This mechanism makes the same use for the source IPv6 241 address, but the padding constant size and value are different. 243 Since any fixed arbitrary value of a padding constant does not affect 244 cryptographic characteristics of a hash algorithm and the HMAC 245 construct, and since single-octet padding is more straightforward to 246 implement, the padding constant used by this mechanism is 0x00 247 single-octet value. This is respectively addressed in sending 248 (Section 5.3 item 5) and receiving (Section 5.4 item 6) procedures. 250 2.3. Cryptographic Sequence Number Specifics 252 Operation of this mechanism may involve multiple local and multiple 253 remote cryptographic sequence numbers, each essentially being a 254 48-bit unsigned integer. This specification uses a term "TS/PC 255 number" to avoid confusion with the route's sequence number of the 256 original Babel specification (Section 2.5 of [BABEL]) and to stress 257 the fact, that there are two distinguished parts of this 48-bit 258 number, each handled in its specific way (see Section 5.1): 260 0 1 2 3 4 261 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 262 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | TS // | PC | 264 +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 // 267 High-order 32 bits are called "timestamp" (TS) and low-order 16 bits 268 are called "packet counter" (PC). 270 This mechanism stores, updates, compares and encodes each TS/PC 271 number as two independent unsigned integers, TS and PC respectively. 272 Such comparison of TS/PC numbers performed in item 3 of Section 5.4 273 is algebraically equivalent to comparison of respective 48-bit 274 unsigned integers. Any byte order conversion, when required, is 275 performed on TS and PC parts independently. 277 2.4. Definition of HMAC 279 The algorithm description below uses the following nomenclature, 280 which is consistent with [FIPS-198]: 282 Text Is the data on which the HMAC is calculated (note item (b) of 283 Section 8). In this specification it is the contents of a 284 Babel packet ranging from the beginning of the Magic field of 285 the Babel packet header to the end of the last octet of the 286 Packet Body field, as defined in Section 4.2 of [BABEL]. 288 H Is the specific hash algorithm (see Section 2.1). 290 K Is a sequence of octets of an arbitrary, known length. 292 Ko Is the cryptographic key used with the hash algorithm. 294 B Is the block size of H, measured in octets rather than bits. 295 Note that B is the internal block size, not the digest length. 297 L Is the digest length of H, measured in octets rather than 298 bits. 300 XOR Is the exclusive-or operation. 302 Opad Is the hexadecimal value 0x5c repeated B times. 304 Ipad Is the hexadecimal value 0x36 repeated B times. 306 The algorithm below is the original, unmodified HMAC construct as 307 defined in both [RFC2104] and [FIPS-198], hence it is different from 308 the algorithms defined in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] 309 in exactly two regards: 311 o Algorithm below sets the size of Ko to B, not to L (L is not 312 greater than B). This resolves both ambiguity in XOR expressions 313 and incompatibility in handling of keys having length greater than 314 L but not greater than B. 316 o Algorithm below does not change value of Text before or after the 317 computation. Both padding of a Babel packet before the 318 computation and placing of the result inside the packet are 319 performed elsewhere. 321 The intent of this is to enable the most straightforward use of 322 cryptographic libraries by implementations of this specification. At 323 the time of this writing implementations of the original HMAC 324 construct coupled with hash algorithms of choice are generally 325 available. 327 Description of the algorithm: 329 1. Preparation of the Key 331 In this application, Ko is always B octets long. If K is B 332 octets long, then Ko is set to K. If K is more than B octets 333 long, then Ko is set to H(K) with zeroes appended to the end of 334 H(K), such that Ko is B octets long. If K is less than B octets 335 long, then Ko is set to K with zeroes appended to the end of K, 336 such that Ko is B octets long. 338 2. First-Hash 340 A First-Hash, also known as the inner hash, is computed as 341 follows: 343 First-Hash = H(Ko XOR Ipad || Text) 345 3. Second-Hash 347 A second hash, also known as the outer hash, is computed as 348 follows: 350 Second-Hash = H(Ko XOR Opad || First-Hash) 352 4. Result 354 The resulting Second-Hash becomes the authentication data that is 355 returned as the result of HMAC calculation. 357 3. Updates to Protocol Data Structures 359 3.1. RxAuthRequired 361 RxAuthRequired is a boolean parameter, its default value MUST be 362 TRUE. An implementation SHOULD make RxAuthRequired a per-interface 363 parameter, but MAY make it specific to the whole protocol instance. 364 The conceptual purpose of RxAuthRequired is to enable a smooth 365 migration from an unauthenticated to an authenticated Babel packet 366 exchange and back (see Section 7.3). Current value of RxAuthRequired 367 directly affects the receiving procedure defined in Section 5.4. An 368 implementation SHOULD allow the operator changing RxAuthRequired 369 value in runtime or by means of Babel speaker restart. An 370 implementation MUST allow the operator discovering the effective 371 value of RxAuthRequired in runtime or from the system documentation. 373 3.2. LocalTS 375 LocalTS is a 32-bit unsigned integer variable, it is the TS part of a 376 per-interface TS/PC number. LocalTS is a strictly per-interface 377 variable not intended to be changed by operator. Its initialization 378 is explained in Section 5.1. 380 3.3. LocalPC 382 LocalPC is a 16-bit unsigned integer variable, it is the PC part of a 383 per-interface TS/PC number. LocalPC is a strictly per-interface 384 variable not intended to be changed by operator. Its initialization 385 is explained in Section 5.1. 387 3.4. MaxDigestsIn 389 MaxDigestsIn is an unsigned integer parameter conceptually purposed 390 for limiting the amount of CPU time spent processing a received 391 authenticated packet. The receiving procedure performs the most CPU- 392 intensive operation, the HMAC computation, only at most MaxDigestsIn 393 (Section 5.4 item 7) times for a given packet. 395 MaxDigestsIn value MUST be at least 2. An implementation SHOULD make 396 MaxDigestsIn a per-interface parameter, but MAY make it specific to 397 the whole protocol instance. An implementation SHOULD allow the 398 operator changing the value of MaxDigestsIn in runtime or by means of 399 Babel speaker restart. An implementation MUST allow the operator 400 discovering the effective value of MaxDigestsIn in runtime or from 401 the system documentation. 403 3.5. MaxDigestsOut 405 MaxDigestsOut is an unsigned integer parameter conceptually purposed 406 for limiting the amount of a sent authenticated packet's space spent 407 on authentication data. The sending procedure adds at most 408 MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet, 409 concurring with the output buffer management explained in 410 Section 6.2. 412 MaxDigestsOut value MUST be at least 2. An implementation SHOULD 413 make MaxDigestsOut a per-interface parameter, but MAY make it 414 specific to the whole protocol instance. An implementation SHOULD 415 allow the operator changing the value of MaxDigestsOut in runtime or 416 by means of Babel speaker restart, in a safe range. The maximum safe 417 value of MaxDigestsOut is implementation-specific (see Section 6.2). 418 An implementation MUST allow the operator discovering the effective 419 value of MaxDigestsOut in runtime or from the system documentation. 421 3.6. ANM Table 423 The ANM (Authentic Neighbours Memory) table resembles the neighbour 424 table defined in Section 3.2.3 of [BABEL]. Note that the term 425 "neighbour table" means the neighbour table of the original Babel 426 specification, and term "ANM table" means the table defined herein. 427 Indexing of the ANM table is done in exactly the same way as indexing 428 of the neighbour table, but purpose, field set and associated 429 procedures are different. 431 Conceptual purpose of the ANM table is to provide a longer term 432 replay attack protection, than it would be possible using the 433 neighbour table. Expiry of an inactive entry in the neighbour table 434 depends on the last received Hello Interval of the neighbour and 435 typically stands for tens to hundreds of seconds (see Appendix A and 436 Appendix B of [BABEL]). Expiry of an inactive entry in the ANM table 437 depends only on the local speaker's configuration. The ANM table 438 retains (for at least the amount of seconds set by ANM timeout 439 parameter defined in Section 3.7) a copy of TS/PC number advertised 440 in authentic packets by each remote Babel speaker. 442 The ANM table is indexed by pairs of the form (Interface, Source). 443 Every table entry consists of the following fields: 445 o Interface 447 An implementation specific reference to the local node's interface 448 that the authentic packet was received through. 450 o Source 452 IPv6 source address of the Babel speaker that the authentic packet 453 was received from. 455 o LastTS 457 A 32-bit unsigned integer, the TS part of a remote TS/PC number. 459 o LastPC 461 A 16-bit unsigned integer, the PC part of a remote TS/PC number. 463 Each ANM table entry has an associated aging timer, which is reset by 464 the receiving procedure (Section 5.4 item 8). If the timer expires, 465 the entry is deleted from the ANM table. 467 An implementation SHOULD use a persistent memory (NVRAM) to retain 468 the contents of ANM table across restarts of the Babel speaker, but 469 only as long as both the Interface field reference and expiry of the 470 aging timer remain correct. An implementation MUST make it clear, if 471 and how persistent memory is used for ANM table. An implementation 472 SHOULD allow retrieving the current contents of ANM table in runtime 473 through common management interfaces such as CLI and SNMP. An 474 implementation SHOULD provide a mean to remove some or all ANM table 475 entries in runtime or by means of Babel speaker restart. 477 3.7. ANM Timeout 479 ANM timeout is an unsigned integer parameter. An implementation 480 SHOULD make ANM timeout a per-interface parameter, but MAY make it 481 specific to the whole protocol instance. ANM timeout is conceptually 482 purposed for limiting the maximum age (in seconds) of entries in the 483 ANM table standing for inactive Babel speakers. The maximum age is 484 immediately related to replay attack protection strength. The 485 strongest protection is achieved with the maximum possible value of 486 ANM timeout set, but it may provide not the best overall result for 487 specific network segments and implementations of this mechanism. 489 In the first turn, implementations unable to maintain local TS/PC 490 number strictly increasing across Babel speaker restarts will reuse 491 advertised TS/PC numbers after each restart (see Section 5.1). The 492 neighbouring speakers will treat the new packets as replayed and 493 discard them until the aging timer of respective ANM table entry 494 expires or the new TS/PC number exceeds the one stored in the entry. 496 Another possible, but less probable case could be an environment 497 involving physical moves of network interfaces hardware between 498 routers. Even performed without restarting Babel speakers, these 499 would cause random drops of the TS/PC number advertised for a given 500 (Interface, Source) index, as viewed by neighbouring speakers, since 501 IPv6 link-local addresses are typically derived from interface 502 hardware addresses. 504 Assuming, that in such cases the operators would prefer using a lower 505 ANM timeout value to let the entries expire on their own rather than 506 having to manually remove them from ANM table each time, an 507 implementation SHOULD set the default value of ANM timeout to a value 508 between 30 and 300 seconds. 510 At the same time, network segments may exist with every Babel speaker 511 having its advertised TS/PC number strictly increasing over the 512 deployed lifetime. Assuming, that in such cases the operators would 513 prefer using a much higher ANM timeout value, an implementation 514 SHOULD allow the operator changing the value of ANM timeout in 515 runtime or by means of Babel speaker restart. An implementation MUST 516 allow the operator discovering the effective value of ANM timeout in 517 runtime or from the system documentation. 519 3.8. Configured Security Associations 521 A Configured Security Association (CSA) is a data structure 522 conceptually purposed for associating authentication keys and hash 523 algorithms with Babel interfaces. All CSAs are managed in ordered 524 lists, one list per each interface. Each interface's list of CSAs is 525 an integral part of the Babel speaker configuration. The default 526 state of an interface's list of CSAs is empty, which has a special 527 meaning of no authentication configured for the interface. The 528 sending (Section 5.3 item 1) and the receiving (Section 5.4 item 1) 529 procedures address this convention accordingly. 531 A single CSA structure consists of the following fields: 533 o HashAlgo 535 An implementation specific reference to one of the hash algorithms 536 supported by this implementation (see Section 2.1). 538 o KeyChain 540 An ordered list of items representing authentication keys, each 541 item being a structure consisting of the following fields: 543 * LocalKeyID 545 An unsigned integer. 547 * AuthKeyOctets 549 A sequence of octets of an arbitrary, known length to be used 550 as the authentication key. 552 * KeyStartAccept 554 The time that this Babel speaker will begin considering this 555 authentication key for accepting packets with authentication 556 data. 558 * KeyStartGenerate 560 The time that this Babel speaker will begin considering this 561 authentication key for generating packet authentication data. 563 * KeyStopGenerate 565 The time that this Babel speaker will stop considering this 566 authentication key for generating packet authentication data. 568 * KeyStopAccept 570 The time that this Babel speaker will stop considering this 571 authentication key for accepting packets with authentication 572 data. 574 It is possible for the KeyChain list to be empty, although this is 575 not the intended way of CSAs use. 577 Since there is no limit imposed on number of CSAs per an interface, 578 but number of HMAC computations per a sent/received packet is limited 579 (through MaxDigestsOut and MaxDigestsIn respectively), only a 580 fraction of the associated keys and hash algorithms may appear used 581 in the process. Ordering of items within a list of CSAs and within a 582 KeyChain list is important to make association selection process 583 deterministic and transparent. Once this ordering is deterministic 584 at Babel interface level, the intermediate data derived by the 585 procedure defined in Section 5.2 will be deterministically ordered as 586 well. 588 An implementation SHOULD allow an operator to set any arbitrary order 589 of items within a given interface's list of CSAs and within the 590 KeyChain list of a given CSA. Whenever this requirement cannot be 591 met, the implementation MUST provide a mean to discover the actual 592 item order used. Whichever order is used by an implementation, it 593 MUST be preserved across Babel speaker restarts. 595 3.9. Effective Security Associations 597 An Effective Security Association (ESA) is a data structure 598 immediately used in sending (Section 5.3) and receiving (Section 5.4) 599 procedures. Its conceptual purpose is to establish a runtime 600 interface between those procedures and the deriving procedure defined 601 in Section 5.2. All ESAs are managed in ordered, temporary lists, 602 which are not intended for any persistent storage. Item ordering 603 within a temporary list of ESAs MUST be preserved as long as the list 604 exists. 606 A single ESA structure consists of the following fields: 608 o HashAlgo 610 An implementation specific reference to one of the hash algorithms 611 supported by this implementation (see Section 2.1). 613 o KeyID 615 A 16-bit unsigned integer. 617 o AuthKeyOctets 619 A sequence of octets of an arbitrary, known length to be used as 620 the authentication key. 622 4. Updates to Protocol Encoding 624 4.1. Justification 626 Choice of encoding is very important in the long term. Protocol 627 encoding defines possible options of authentication mechanism design 628 and encoding, which in turn define options of future developments of 629 the protocol. 631 Considering existing implementations of Babel protocol instance 632 itself and related modules of packet analysers, current encoding of 633 Babel allows for compact and robust decoders. At the same time, this 634 encoding allows for future extensions of Babel by three (not 635 excluding each other) principal means defined by Section 4.2 and 636 Section 4.3 of [BABEL]: 638 a. A Babel packet consists of a four-octet header followed by a 639 packet body, that is, a sequence of TLVs (see Figure 2). Besides 640 the header and the sequence, an actual Babel datagram may have an 641 arbitrary amount of trailing data between the end of the packet 642 body and the end of the datagram. An instance of the original 643 protocol silently ignores such trailing data. 645 b. The sequence of TLVs uses a binary format allowing for 256 TLV 646 types and imposing no requirements on TLV ordering or number of 647 TLVs of a given type in a packet. Only TLV length matters within 648 the sequence, TLV body contents is to be interpreted elsewhere. 649 This makes an iteration over the sequence possible without a 650 knowledge of body structure of each TLV (with the only 651 distinction between a Pad1 TLV and any other TLVs). The original 652 specification allocates TLV types 0 through 10 and defines TLV 653 body structure for each. An instance of the original protocol 654 silently ignores any unknown TLV types. 656 c. Within each TLV of the sequence there may be some "extra data" 657 after the "expected length" of the TLV body. An instance of the 658 original protocol silently ignores any such extra data. Note 659 that any TLV types without the expected length defined (such as 660 PadN TLV) cannot be extended with the extra data. 662 Considering each principal extension mean for the specific purpose of 663 adding authentication data items to each protocol packet, the 664 following arguments can be made: 666 o Use of the TLV extra data of some existing TLV type would not be a 667 solution, since no particular TLV type is guaranteed to be present 668 in a Babel packet. 670 o Use of the TLV extra data could also conflict with future 671 developments of the protocol encoding. 673 o Since the packet trailing data is currently unstructured, using it 674 would involve defining an encoding structure and associated 675 procedures, adding to the complexity of both specification and 676 implementation and increasing the exposure to protocol attacks 677 such as fuzzing. 679 o A naive use of the packet trailing data would make it unavailable 680 to any future extension of Babel. Since this mechanism is 681 possibly not the last extension and since some other extensions 682 may allow no other embedding means except the packet trailing 683 data, the defined encoding structure would have to enable 684 multiplexing of data items belonging to different extensions. 685 Such a definition is out of scope of this work. 687 o Deprecating an extension (or only its protocol encoding) that uses 688 purely purpose-allocated TLVs is as simple as deprecating the 689 TLVs. 691 o Use of purpose-allocated TLVs is transparent to both the original 692 protocol and any its future extensions, regardless of the 693 embedding mean(s) used by the latter. 695 Considering all of the above, this mechanism neither uses the packet 696 trailing data nor uses the TLV extra data, but uses two new TLV 697 types: type 11 for a TS/PC number and type 12 for a HMAC result. 699 With these additional two types the Babel TLV types namespace appears 700 as follows: 702 +-------+-------------------------+---------------+ 703 | Value | Code | Reference | 704 +-------+-------------------------+---------------+ 705 | 0 | Pad1 | [BABEL] | 706 | 1 | PadN | [BABEL] | 707 | 2 | Acknowledgement Request | [BABEL] | 708 | 3 | Acknowledgement | [BABEL] | 709 | 4 | Hello | [BABEL] | 710 | 5 | IHU | [BABEL] | 711 | 6 | Router-Id | [BABEL] | 712 | 7 | Next Hop | [BABEL] | 713 | 8 | Update | [BABEL] | 714 | 9 | Route Request | [BABEL] | 715 | 10 | Seqno Request | [BABEL] | 716 | 11 | TS/PC | this document | 717 | 12 | HMAC | this document | 718 +-------+-------------------------+---------------+ 720 4.2. TS/PC TLV 722 The purpose of a TS/PC TLV is to store a single TS/PC number. There 723 is normally exactly one TS/PC TLV in an authenticated Babel packet. 724 Any occurences of this TLV except the first are ignored. 726 0 1 2 3 727 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 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Type = 11 | Length | PacketCounter | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Timestamp | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Fields: 736 Type Set to 11 to indicate a TS/PC TLV. 738 Length The length of the body, exclusive of the Type and 739 Length fields. 741 PacketCounter A 16-bit unsigned integer in network byte order, the 742 PC part of a TS/PC number stored in this TLV. 744 Timestamp A 32-bit unsigned integer in network byte order, the 745 TS part of a TS/PC number stored in this TLV. 747 Note that ordering of PacketCounter and Timestamp in TLV structure is 748 opposite to the ordering of TS and PC in "TS/PC" term and the 48-bit 749 equivalent. 751 Considering the "expected length" and the "extra data" in the 752 definition of Section 4.2 of [BABEL], the expected length of a TS/PC 753 TLV body is unambiguously defined as 6 octets. The receiving 754 procedure correctly processes any TS/PC TLV with body length not less 755 than the expected, ignoring any extra data (Section 5.4 items 3 and 756 9). The sending procedure produces a TS/PC TLV with body length 757 equal to the expected and Length field set respectively (Section 5.3 758 item 3). 760 Future Babel extensions (such as sub-TLVs) MAY modify the sending 761 procedure to include the extra data after the fixed-size TS/PC TLV 762 body defined herein, making necessary adjustments to Length TLV 763 field, "Body length" packet header field and output buffer management 764 explained in Section 6.2. 766 4.3. HMAC TLV 768 The purpose of a HMAC TLV is to store a single HMAC result. To 769 assist a receiver in reproducing the HMAC computation, LocalKeyID 770 modulo 2^16 of the authentication key is also provided in the TLV. 771 There is normally at least one HMAC TLV in an authenticated Babel 772 packet. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type = 12 | Length | KeyID | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Digest... 780 +-+-+-+-+-+-+-+-+-+-+-+- 782 Fields: 784 Type Set to 12 to indicate a HMAC TLV. 786 Length The length of the body, exclusive of the Type and 787 Length fields. 789 KeyID A 16-bit unsigned integer in network byte order. 791 Digest A variable-length sequence of octets, that MUST be at 792 least 16 octets long. 794 Considering the "expected length" and the "extra data" in the 795 definition of Section 4.2 of [BABEL], the expected length of a HMAC 796 TLV body is not defined. The receiving procedure processes every 797 octet of the Digest field, deriving the field boundary from the 798 Length field value (Section 5.4 item 6). The sending procedure 799 produces HMAC TLVs with Length field precisely sizing the Digest 800 field to match digest length of the hash algorithm used (Section 5.3 801 items 5 and 8). 803 HMAC TLV structure defined herein is final, future Babel extensions 804 MUST NOT extend it with any extra data. 806 5. Updates to Protocol Operation 808 5.1. Per-interface TS/PC Number Updates 810 LocalTS and LocalPC interface-specific variables constitute the TS/PC 811 number of a Babel interface. This number is advertised in the TS/PC 812 TLV of authenticated Babel packets sent from that interface. There 813 is only one property mandatory for the advertised TS/PC number: its 814 48-bit equivalent MUST be strictly increasing within the scope of a 815 given interface of a Babel speaker as long as the speaker is 816 continuously operating. This property combined with ANM tables of 817 neighbouring Babel speakers provides them with the most basic replay 818 attack protection. 820 Initialization and increment are two principal updates performed on 821 an interface TS/PC number. The initialization is performed when a 822 new interface becomes a part of a Babel protocol instance. The 823 increment is performed by the sending procedure (Section 5.3 item 2) 824 before advertising the TS/PC number in a TS/PC TLV. 826 Depending on particular implementation method of these two updates 827 the advertised TS/PC number may possess additional properties 828 improving the replay attack protection strength. This includes, but 829 is not limited to the methods below. 831 a. The most straightforward implementation would use LocalTS as a 832 plain wrap counter, defining the updates as follows: 834 initialization Set LocalPC to 0, set LocalTS to 0. 836 increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF 837 + 1 = 0x0000), increment LocalTS by 1. 839 In this case advertised TS/PC numbers would be reused after each 840 Babel speaker restart, making neighbouring speakers reject 841 authenticated packets until respective ANM table entries expire 842 or the new TS/PC number exceeds the old (see Section 3.6 and 843 Section 3.7). 845 b. A more advanced implementation could make a use of any 32-bit 846 unsigned integer timestamp (number of time units since an 847 arbitrary epoch) such as the UNIX timestamp, whereas the 848 timestamp itself spans a reasonable time range and is guaranteed 849 against a decrease (such as one resulting from network time use). 850 The updates would be defined as follows: 852 initialization Set LocalPC to 0, set LocalTS to 0. 854 increment If the current timestamp is greater than LocalTS, 855 set LocalTS to the current timestamp and LocalPC 856 to 0, then consider the update complete. 857 Otherwise increment LocalPC by 1 and, if LocalPC 858 wraps, increment LocalTS by 1. 860 In this case the advertised TS/PC number would remain unique 861 across speaker's deployed lifetime without the need for any 862 persistent storage. However, a suitable timestamp source is not 863 available in every implementation case. 865 c. Another advanced implementation could use LocalTS in a way 866 similar to the "wrap/boot counter" suggested in Section 4.1.1 of 867 [OSPF3-AUTH], defining the updates as follows: 869 initialization Set LocalPC to 0. Whether there is a TS value 870 stored in NVRAM for the current interface, set 871 LocalTS to that TS value, then increment the 872 stored TS value by 1. Otherwise set LocalTS to 0 873 and set the stored TS value to 1. 875 increment Increment LocalPC by 1. If LocalPC wraps, set 876 LocalTS to the TS value stored in NVRAM for the 877 current interface, then increment the stored TS 878 value by 1. 880 In this case the advertised TS/PC number would also remain unique 881 across speaker's deployed lifetime, relying on NVRAM for storing 882 multiple TS numbers, one per each interface. 884 As long as the TS/PC number retains its mandatory property stated 885 above, an implementer is free to decide, which TS/PC updates 886 implementation methods are available to an operator and whether the 887 method can be configured per-interface and/or in runtime. To enable 888 the optimal (see Section 3.7) management of ANM timeout in a network 889 segment, an implementation MUST allow the operator discovering exact 890 matter of the TS/PC update method effective for any interface, either 891 in runtime or from the system documentation. 893 Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is 894 unlikely, but possible, causing the advertised TS/PC number to be 895 reused. Resolving this situation requires replacing of all 896 authentication keys of the involved interface. In addition to that, 897 if the wrap was caused by a timestamp reaching its end of epoch, 898 using this mechanism will be impossible for the involved interface 899 until some different timestamp or update implementation method is 900 used. 902 5.2. Deriving ESAs from CSAs 904 Neither receiving nor sending procedures work with the contents of 905 interface's list of CSAs directly, both (Section 5.4 item 4 and 906 Section 5.3 item 4 respectively) derive a list of ESAs from the list 907 of CSAs and use the derived list (see Figure 1). There are two main 908 goals achieved through this indirection: 910 o Filtering of expired and duplicate security associations. This is 911 done earliest possible to keep subsequent procedures focused on 912 their respective tasks. 914 o Maintenance of particular sort order in the derived list of ESAs. 915 The sort order deterministically depends on the sort order of 916 interface's list of CSAs and sort order of KeyChain items of each 917 CSA. Particular correlation maintained by this procedure 918 implements a concept of fair (independent of number of keys used 919 by each) competition between CSAs. 921 The deriving procedure uses the following input arguments: 923 o input list of CSAs 925 o direction (sending or receiving) 927 o current time (CT) 929 Processing of input arguments begins with an empty ordered output 930 list of ESAs and consists of the following steps: 932 1. Make a temporary copy of the input list of CSAs. 934 2. Remove all expired keys from the copy, that is, any keys such 935 that: 937 * for receiving: KeyStartAccept is greater than CT or 938 KeyStopAccept is less than CT 940 * for sending: KeyStartGenerate is greater than CT or 941 KeyStopGenerate is less than CT 943 Note well, that there are no special exceptions. Remove all 944 expired keys, even if there are no keys left after that (see 945 Section 7.4). 947 3. Remove all duplicate keys from the copy. A duplicate key (Kd) 948 within a list of CSAs is a key, for that another key (Ka) exists 949 within the same list of CSAs such that every statement below is 950 true: 952 * HashAlgo of the CSA containing Kd is equal to HashAlgo of the 953 CSA containing Ka. 955 * LocalKeyID modulo 2^16 of Kd is equal to LocalKeyID modulo 956 2^16 of Ka 958 * AuthKeyOctets of Kd is equal to AuthKeyOctets of Ka 960 4. Use the copy to populate the output list of ESAs as follows: 962 1. Whether the KeyChain list of the first CSA contains at least 963 one key, use its first key to produce an ESA with fields set 964 as follows: 966 HashAlgo Set to HashAlgo of the current CSA. 968 KeyID Set to LocalKeyID modulo 2^16 of the current 969 key of the current CSA. 971 AuthKeyOctets Set to AuthKeyOctets of the current key of the 972 current CSA. 974 Append this ESA to the end of the output list. 976 2. Whether the KeyChain list of the second CSA contains at least 977 one key, use its first key the same way and so forth until 978 all first keys of the copy are processed. 980 3. Whether the KeyChain list of the first CSA contains at least 981 two keys, use its second key the same way. 983 4. Whether the KeyChain list of the second CSA contains at least 984 two keys, use its second key the same way and so forth until 985 all second keys of the copy are processed. 987 5. And so forth until all keys of all CSAs of the copy are 988 processed, exactly one time each. 990 The resulting list will contain zero or more unique ESAs, ordered in 991 a way deterministically correlated with sort order of CSAs within the 992 original input list of CSAs and sort orders of keys within each 993 KeyChain list. This ordering maximizes the probability of having 994 equal amount of keys per original CSA in any N first items of the 995 resulting list. Possible optimizations of this deriving procedure 996 are outlined in Section 6.3. 998 5.3. Updates to Packet Sending 1000 Perform the following authentication-specific processing after the 1001 instance of the original protocol considers an outgoing Babel packet 1002 ready for sending, but before the packet is actually sent (see 1003 Figure 1). After that send the packet regardless if the 1004 authentication-specific processing modified the outgoing packet or 1005 left it intact. 1007 1. If the current outgoing interface's list of CSAs is empty, finish 1008 authentication-specific processing and consider the packet ready 1009 for sending. 1011 2. Increment TS/PC number of the current outgoing interface as 1012 explained in Section 5.1. 1014 3. Append a TS/PC TLV to the packet's sequence of TLVs with fields 1015 set as follows: 1017 Type Set to 11. 1019 Length Set to 6. 1021 PacketCounter Set to the current value of LocalPC variable of 1022 the current outgoing interface. 1024 Timestamp Set to the current value of LocalTS variable of 1025 the current outgoing interface. 1027 Note that the current step may involve byte order conversion. 1029 4. Derive a list of ESAs using procedure defined in Section 5.2 with 1030 the current interface's list of CSAs as the input list of CSAs, 1031 current time as CT and "sending" as the direction. Note that 1032 both the input list of CSAs and the derived list of ESAs are 1033 sorted. Proceed to the next step even if the derived list is 1034 empty. 1036 5. Iterate over the derived list using its sort order. For each ESA 1037 append a HMAC TLV to the end of the packet's sequence of TLVs 1038 with fields set as follows: 1040 Type Set to 12. 1042 Length Set to 2 plus digest length of HashAlgo of the current 1043 ESA. 1045 KeyID Set to KeyID of the current ESA. 1047 Digest Size exactly to the digest length of HashAlgo of the 1048 current ESA. Set the first 16 octets to the source IPv6 1049 address of the current packet (see Section 6.1) and any 1050 subsequent octets to 0x00 (see Figure 3). 1052 As soon as there are MaxDigestsOut HMAC TLVs appended to the 1053 current packet, immediately proceed to the next step. 1055 Note that the current step may involve byte order conversion. 1057 6. Update "Body length" field of the current packet header to 1058 include the total length of TS/PC and HMAC TLVs added to the 1059 current packet so far. 1061 Note that the current step may involve byte order conversion. 1063 7. Make a temporary copy of the current packet. 1065 8. Iterate over the derived list again, using the same very order 1066 and amount of items. For each ESA (and respectively for each 1067 HMAC TLV recently added to the current packet) compute a HMAC 1068 result (see Section 2.4) using the temporary copy (not the 1069 original packet) as Text, HashAlgo of the current ESA as H, and 1070 AuthKeyOctets of the current ESA as K. Write the HMAC result to 1071 the Digest field of the current HMAC TLV (see Figure 4) of the 1072 current packet (not the copy). 1074 9. Since this point, allow no more changes to the current packet and 1075 consider it ready for sending. 1077 Note that even if the derived list of ESAs is empty, the packet is 1078 sent anyway with only a TS/PC TLV appended to its sequence of TLVs. 1079 Although such a packet is not authenticated, presence of a sole TS/PC 1080 TLV indicates authentication keys exhaustion to operators of 1081 neighbouring Babel speakers. See also Section 7.4. 1083 5.4. Updates to Packet Receiving 1085 Perform the following authentication-specific processing after an 1086 incoming Babel packet is received from local IPv6 stack, but before 1087 it is processed by the Babel protocol instance (see Figure 1). The 1088 final action conceptually depends not only upon the result of the 1089 authentication-specific processing, but also on the current value of 1090 RxAuthRequired parameter. Immediately after any processing step 1091 below accepts or refuses the packet, either deliver the packet to the 1092 instance of the original protocol (when the packet is accepted or 1093 RxAuthRequired is FALSE) or discard it (when the packet is refused 1094 and RxAuthRequired is TRUE). 1096 1. If the current incoming interface's list of CSAs is empty, 1097 accept the packet. 1099 2. If the current packet does not contain a TS/PC TLV, refuse it. 1101 3. Perform a lookup in the ANM table for an entry having Interface 1102 equal to the current incoming interface and Source equal to the 1103 source address of the current packet. If such an entry exists, 1104 compare its LastTS and LastPC field values with Timestamp and 1105 PacketCounter values respectively of the first TS/PC TLV of the 1106 packet. That is, refuse the packet, if at least one of the 1107 following two conditions is true: 1109 * Timestamp is less than LastTS 1111 * Timestamp is equal to LastTS and PacketCounter is not greater 1112 than LastPC 1114 Note that the current step may involve byte order conversion. 1116 4. Derive a list of ESAs using procedure defined in Section 5.2 1117 with the current interface's list of CSAs as the input list of 1118 CSAs, current time as CT and "receiving" as the direction. If 1119 the derived list is empty, refuse the packet. 1121 5. Make a temporary copy of the current packet. 1123 6. For every HMAC TLV present in the temporary copy (not the 1124 original packet) pad all octets of its Digest field using the 1125 source IPv6 address of the current packet to set the first 16 1126 octets and 0x00 to set any subsequent octets (see Figure 3). 1128 7. Iterate over all HMAC TLVs of the original input packet (not the 1129 copy) using their order of appearance in the packet. For each 1130 HMAC TLV look up all ESAs in the derived list such that 2 plus 1131 digest length of HashAlgo of the ESA is equal to Length of the 1132 TLV and KeyID of the ESA is equal to value of KeyID of the TLV. 1133 Iterate over these ESAs in the order of their appearance on the 1134 full list of ESAs. Note that nesting the iterations the 1135 opposite way (over ESAs, then over HMAC TLVs) is wrong. 1137 For each of these ESAs compute a HMAC result (see Section 2.4) 1138 using the temporary copy (not the original packet) as Text, 1139 HashAlgo of the current ESA as H, and AuthKeyOctets of the 1140 current ESA as K. If the current HMAC result exactly matches the 1141 contents of Digest field of the current HMAC TLV, immediately 1142 proceed to the next step. Otherwise, if number of HMAC 1143 computations done for the current packet is equal to 1144 MaxDigestsIn, immediately proceed to the next step. Otherwise 1145 follow the normal order of iterations. 1147 Note that the current step may involve byte order conversion. 1149 8. If none of the HMAC results computed during the previous step 1150 matched, refuse the input packet. 1152 9. Modify the ANM table, using the same index as for the entry 1153 lookup above, to contain an entry with LastTS set to the value 1154 of Timestamp and LastPC set to the value of PacketCounter fields 1155 of the first TS/PC TLV of the current packet. That is, either 1156 add a new ANM table entry or update the existing one, according 1157 to the result of the entry lookup above. Reset the entry's 1158 aging timer to the current value of ANM timeout. 1160 Note that the current step may involve byte order conversion. 1162 10. Accept the input packet. 1164 Note that RxAuthRequired affects only the final action, but not the 1165 defined flow of authentication-specific processing. The purpose of 1166 this is to preserve authentication-specific processing feedback (such 1167 as log messages and event counters updates) even with RxAuthRequired 1168 set to FALSE. This allows an operator to predict the effect of 1169 changing RxAuthRequired from FALSE to TRUE during a migration 1170 scenario (Section 7.3) implementation. 1172 5.5. Authentication-specific Statistics Maintenance 1174 A Babel speaker implementing this mechanism SHOULD maintain a set of 1175 counters for the following events, per protocol instance and per each 1176 interface: 1178 o Sending of an unauthenticated Babel packet through an interface 1179 having an empty list of CSAs. 1181 o Sending of an unauthenticated Babel packet with a TS/PC TLV but 1182 without any HMAC TLVs due to an empty list of ESAs. 1184 o Sending of an authenticated Babel packet containing both TS/PC and 1185 HMAC TLVs. 1187 o Accepting of a Babel packet received through an interface having 1188 an empty list of CSAs. 1190 o Refusing of a received Babel packet due to an empty list of ESAs. 1192 o Refusing of a received Babel packet missing any TS/PC TLVs. 1194 o Refusing of a received Babel packet due to the first TS/PC TLV 1195 failing the ANM table check. 1197 o Refusing of a received Babel packet missing any HMAC TLVs. 1199 o Refusing of a received Babel packet due to none of the processed 1200 HMAC TLVs passing the ESA check. 1202 o Accepting of a received Babel packet having both TS/PC and HMAC 1203 TLVs. 1205 o Delivery of a refused packet to the instance of the original 1206 protocol due to RxAuthRequired parameter set to FALSE. 1208 Note that terms "accepting" and "refusing" are used in the sense of 1209 the receiving procedure, that is, "accepting" does not mean a packet 1210 delivered to the instance of the original protocol purely because of 1211 RxAuthRequired parameter set to FALSE. Event counters readings 1212 SHOULD be available in runtime through common management interfaces 1213 such as CLI and SNMP. 1215 6. Implementation Notes 1217 6.1. IPv6 Source Address Selection for Sending 1219 Section 3.1 of [BABEL] defines, that Babel datagrams are exchanged 1220 using IPv6 link-local address as source address. This implies having 1221 at least one such address assigned to an interface participating in 1222 the exchange. When the interface has more than one link-local 1223 addresses assigned, selection of one particular link-local address as 1224 packet source address is left up to the local IPv6 stack, since this 1225 choice is not meaningful in the scope of the original protocol. 1226 However, the sending procedure defined in Section 5.3 requires exact 1227 knowledge of packet source address for proper padding of HMAC TLVs. 1229 As long as a Babel interface has more than one IPv6 link-local 1230 addresses assigned, the Babel speaker SHOULD internally choose one 1231 particular link-local address for Babel packet sending purposes and 1232 make this choice to both the sending procedure and local IPv6 stack 1233 (see Figure 1). Wherever this requirement cannot be met, this 1234 limitation MUST be clearly stated in the system documentation to 1235 allow an operator to plan IPv6 address management accordingly. 1237 6.2. Output Buffer Management 1239 An instance of the original protocol buffers produced TLVs until the 1240 buffer becomes full or a delay timer has expired or an urgent TLV is 1241 produced. This is performed independently for each Babel interface 1242 with each buffer sized according to the interface MTU (see Sections 1243 3.1 and 4 of [BABEL]). 1245 Since TS/PC and HMAC TLVs and any other TLVs, in the first place 1246 those of the original protocol, share the same packet space (see 1247 Figure 2) and respectively the same buffer space, a particular 1248 portion of each interface buffer needs to be reserved for 1 TS/PC TLV 1249 and up to MaxDigestsOut HMAC TLVs. Amount (R) of this reserved 1250 buffer space is calculated as follows: 1252 R = St + MaxDigestsOut * Sh = 1253 = 8 + MaxDigestsOut * (4 + Lmax) 1255 St Is the size of a TS/PC TLV. 1257 Sh Is the size of a HMAC TLV. 1259 Lmax Is the maximum digest length in octets possible for a 1260 particular interface. It SHOULD be calculated based on 1261 particular interface's list of CSAs, but MAY be taken as the 1262 maximum digest length supported by particular implementation. 1264 An implementation allowing for per-interface value of MaxDigestsOut 1265 parameter has to account for different value of R across different 1266 interfaces, even having the same MTU. An implementation allowing for 1267 runtime change of MaxDigestsOut parameter value has to take care of 1268 the TLVs already buffered by the time of the change, especially when 1269 the change increases the value of R. 1271 The maximum safe value of MaxDigestsOut parameter depends on 1272 interface MTU and maximum digest length used. In general, at least 1273 200-300 octets of a Babel packet should be always available to data 1274 other than TS/PC and HMAC TLVs. An implementation following the 1275 requirements of Section 4 of [BABEL] would send packets sized 512 1276 octets or larger. If, for example, the maximum digest length is 64 1277 octets and MaxDigestsOut value is 4, the value of R would be 280, 1278 leaving less than a half of a 512-octet packet for any other TLVs. 1279 As long as interface MTU is larger or digest length is smaller, 1280 higher values of MaxDigestsOut can be used safely. 1282 6.3. Optimizations of ESAs Deriving 1284 The following optimizations of the ESAs deriving procedure can reduce 1285 amount of CPU time consumed by authentication-specific processing, 1286 preserving implementation's effective behaviour. 1288 a. The most straightforward implementation would treat the deriving 1289 procedure as a per-packet action. But since the procedure is 1290 deterministic (its output depends on its input only), it is 1291 possible to significantly reduce the number of times the 1292 procedure is performed. 1294 The procedure would obviously return the same result for the same 1295 input arguments (list of CSAs, direction, CT) values. However, 1296 it is possible to predict, when the result will remain the same 1297 even for a different input. That is, when the input list of CSAs 1298 and the direction both remain the same but CT changes, the result 1299 will remain the same as long as CT's order on the time axis 1300 (relative to all critical points of the list of CSAs) remains 1301 unchanged. Here, the critical points are KeyStartAccept and 1302 KeyStopAccept (for the "receiving" direction) and 1303 KeyStartGenerate and KeyStopGenerate (for the "sending" 1304 direction) of all keys of all CSAs of the input list. In other 1305 words, in this case the result will remain the same as long as 1306 both none of the active keys expire and none of the inactive keys 1307 enter into operation. 1309 An implementation optimized this way would perform the full 1310 deriving procedure for a given (interface, direction) pair only 1311 after an operator's change to the interface's list of CSAs or 1312 after reaching one of the critical points mentioned above. 1314 b. Considering, that the sending procedure iterates over at most 1315 MaxDigestsOut items of the ordered list of derived ESAs 1316 (Section 5.3 item 5), there is little sense in the case of 1317 "sending" direction in appending ESA items to the end of the 1318 output list once the list already contains MaxDigestsOut number 1319 of items. Note that a similar optimization is impossible in the 1320 case of "receiving" direction, since number of ESAs actually used 1321 in examining a particular packet cannot be determined in advance. 1323 6.4. Internal Representation of CSAs 1325 Note that the KeyChain list of the CSA structure is a direct 1326 equivalent of the "key chain" syntax item of some existing router 1327 configuration languages. Whereas an implementation already 1328 implements this syntax item, it is suggested to reuse it, that is, to 1329 implement a CSA syntax item referring to a key chain item instead of 1330 reimplementing the latter in full. 1332 7. Network Management Aspects 1334 7.1. Backward Compatibility 1336 Support of this mechanism is optional, it does not change the default 1337 behaviour of a Babel speaker and causes no compatibility issues with 1338 speakers properly implementing the original Babel specification. 1339 Given two Babel speakers, one implementing this mechanism and 1340 configured for authenticated exchange (A) and another not not 1341 implementing it (B), these would not distribute routing information 1342 uni-directionally or form a routing loop or experience other protocol 1343 logic issues specific purely to the use of this mechanism. 1345 Babel design requires a bi-directional neighbour reachability 1346 condition between two given speakers for a successful exchange of 1347 routing information. Apparently, in the case above neighbour 1348 reachability would be uni-directional. Presence of TS/PC and HMAC 1349 TLVs in Babel packets sent by A would be transparent to B. But lack 1350 of authentication data in Babel packets send by B would make them 1351 effectively invisible to the instance of the original protocol of A. 1352 Uni-directional links are not specific to use of this mechanism, they 1353 naturally exist on their own and are properly detected and avoided by 1354 the original protocol (see Section 3.4.2 of [BABEL]). 1356 7.2. Multi-Domain Authentication 1358 The receiving procedure treats a packet as authentic as soon as one 1359 of its HMAC TLVs passes the check against the list of ESAs. This 1360 allows for packet exchange authenticated with multiple (hash 1361 algorithm, authentication key) pairs simultaneously, in combinations 1362 as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut. 1364 For example, consider three Babel speakers with one interface each, 1365 configured with the following CSAs: 1367 o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key 1368 SK2) 1370 o speaker B: (hash algorithm H1; key SK1) 1372 o speaker C: (hash algorithm H1; key SK2) 1374 Packets sent by A would contain 2 HMAC TLVs each, packets sent by B 1375 and C would contain 1 HMAC TLV each. A and B would authenticate the 1376 exchange between themselves using H1 and SK1; A and C would use H1 1377 and SK2; B and C would discard each other's packets. 1379 Consider a similar set of speakers configured with different CSAs: 1381 o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key 1382 SK4) 1384 o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys 1385 SK5 and SK6) 1387 o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm 1388 H5, key SK8) 1390 Packets sent by D would contain 2 HMAC TLVs each, packets sent by E 1391 and F would contain 3 HMAC TLVs each. D and E would authenticate the 1392 exchange between themselves using H2 and SK3; D and F would use H3 1393 and SK4; E and F would discard each other's packets. The 1394 simultaneous use of H4, SK5, and SK6 by E, as well as use of SK7, H5, 1395 and SK8 by F (for their own purposes) would remain insignificant to 1396 A. 1398 An operator implementing a multi-domain authentication should keep in 1399 mind, that values of MaxDigestsIn and MaxDigestsOut may be different 1400 both within the same Babel speaker and across different speakers. 1401 Since the minimum value of both parameters is 2 (see Section 3.4 and 1402 Section 3.5), when more than 2 authentication domains are configured 1403 simultaneously, it is advised to confirm that every involved speaker 1404 can handle sufficient number of HMAC results for both sending and 1405 receiving. 1407 The recommended method of Babel speaker configuration for multi- 1408 domain authentication is not only using a different authentication 1409 key for each domain, but also using a separate CSA for each domain, 1410 even when hash algorithms are the same. This allows for fair 1411 competition between CSAs and sometimes limits consequences of a 1412 possible misconfiguration to the scope of one CSA. See also item (e) 1413 of Section 8. 1415 7.3. Migration 1417 It is common in practice to consider a migration to authenticated 1418 exchange of routing information only after the network has already 1419 been deployed and put to an active use. Performing the migration in 1420 a way without regular traffic interruption is typically demanded, and 1421 this specification allows for such a smooth migration using the 1422 RxAuthRequired interface parameter defined in Section 3.1. This 1423 measure is similar to the "transition mode" suggested in Section 5 of 1424 [OSPF3-AUTH]. 1426 An operator performing the migration needs to arrange configuration 1427 changes as follows: 1429 1. Decide on particular hash algorithm(s) and key(s) to be used. 1431 2. Identify all speakers and their involved interfaces that need to 1432 be migrated to authenticated exchange. 1434 3. For each of the speakers and the interfaces to be reconfigured 1435 first set RxAuthRequired parameter to FALSE, then configure 1436 necessary CSA(s). 1438 4. Examine the speakers to confirm, that Babel packets are 1439 successfully authenticated according to the configuration 1440 (supposedly, through examining ANM table entries and 1441 authentication-specific statistics, see Figure 1)), and address 1442 any discrepancies before proceeding further. 1444 5. For each of the speakers and the reconfigured interfaces set 1445 RxAuthRequired parameter to TRUE. 1447 Likewise, temporarily setting RxAuthRequired to FALSE can be used to 1448 migrate smoothly from authenticated packet exchange back to 1449 unauthenticated one. 1451 7.4. Handling of Authentication Keys Exhaustion 1453 This specification employs a common concept of multiple authenticaion 1454 keys co-existing for a given interface, with two independent lifetime 1455 ranges associated with each key (one for sending and another for 1456 receiving). It is typically recommended to configure the keys using 1457 finite lifetimes, adding new keys before the old keys expire. 1458 However, it is obviously possible for all keys to expire for a given 1459 interface (for sending or receiving or both). Possible ways of 1460 addressing this situation raise their own concerns: 1462 o Automatic switching to unauthenticated protocol exchange. This 1463 behaviour invalidates the initial purposes of authentication and 1464 is commonly viewed as "unacceptable" ([RIP2-AUTH] Section 5.1, 1465 [OSPF2-AUTH] Section 3.2, [OSPF3-AUTH] Section 3). 1467 o Stopping routing information exchange over the interface. This 1468 behaviour is likely to impact regular traffic routing and is 1469 commonly viewed as "not advisable" (ibid.). 1471 o Use of the "most recently expired" key over its intended lifetime 1472 range. This behaviour is commonly recommended for implementation 1473 (ibid.), although it may become a problem due to an offline 1474 cryptographic attack (see item (e) of Section 8) or a compromise 1475 of the key. In addition, telling a recently expired key from a 1476 key never ever been in a use may be impossible after a router 1477 restart. 1479 Design of this mechanism prevents the automatic switching to 1480 unauthenticated exchange and is consistent with similar 1481 authentication mechanisms in this regard. But since the best choice 1482 between two other options depends on local site policy, this decision 1483 is left up to the operator rather than the implementer (in a way 1484 resembling the "fail secure" configuration knob described in Section 1485 5.1 of [RIP2-AUTH]). 1487 Although the deriving procedure does not allow for any exceptions in 1488 expired keys filtering (Section 5.2 item 2), the operator can 1489 trivially enforce one of the two remaining behaviour options through 1490 local key management procedures. In particular, when using the key 1491 over its intended lifetime is more preferred than regular traffic 1492 disruption, the operator would explicitly leave the old key expiry 1493 time open until the new key is added to the router configuration. In 1494 the opposite case the operator would always configure the old key 1495 with a finite lifetime and bear associated risks. 1497 8. Security Considerations 1499 Use of this mechanism implies requirements common to a use of shared 1500 authentication keys, including, but not limited to: 1502 o holding the keys secret, 1504 o including sufficient amount of random bits into each key, 1506 o rekeying on a regular basis, and 1508 o never reusing a used key for a different purpose 1510 That said, proper design and implementation of a key management 1511 policy is out of scope of this work. Many publications on this 1512 subject exist and should be used for this purpose. 1514 Considering particular attacks being in-scope or out of scope on one 1515 hand and measures taken to protect against particular in-scope 1516 attacks on the other, the original Babel protocol and this 1517 authentication mechanism are in line with similar datagram-based 1518 routing protocols and their respective mechanisms. In particular, 1519 the primary concerns addressed are: 1521 a. Peer Entity Authentication 1523 Babel speaker authentication mechanism defined herein is believed 1524 to be as strong as is the class itself that it belongs to. This 1525 specification is built on the fundamental concepts implemented 1526 for authentication of similar routing protocols: per-packet 1527 authentication, use of HMAC construct, use of shared keys. 1528 Although this design approach does not address all possible 1529 concerns, it is so far known to be sufficient for most practical 1530 cases. 1532 b. Data Integrity 1534 Meaningful parts of a Babel datagram are the contents of the 1535 Babel packet (in the definition of Section 4.2 of [BABEL]) and 1536 IPv6 source address of the datagram (ibid. Section 3.5.3). This 1537 mechanism authenticates both parts using a HMAC construct, so 1538 that making any meaningful change to an authenticated packet 1539 after it has been emitted by the sender should be as hard as 1540 attacking the hash algorithm itself or successfully recovering 1541 the authentication key. 1543 Note well, that any trailing data of the Babel datagram is not 1544 meaningful in the scope of the original specification and does 1545 not belong to the Babel packet. Integrity of the trailing data 1546 is respectively not protected by this mechanism. At the same 1547 time, although any TLV extra data is also not meaningful in the 1548 same scope, its integrity is protected, since this extra data is 1549 a part of the Babel packet (see Figure 2). 1551 c. Replay Attacks 1553 This specification establishes a basic replay protection measure 1554 (see Section 3.6), defines a timeout parameter affecting its 1555 strength (see Section 3.7), and outlines implementation methods 1556 also affecting protection strength in several ways (see 1557 Section 5.1). Implementer's choice of the timeout value and 1558 particular implementation methods may be suboptimal due to, for 1559 example, insufficient hardware resources of the Babel speaker. 1560 Furthermore, it may be possible, that an operator configures the 1561 timeout and the methods to address particular local specifics and 1562 this further weakens the protection. An operator concerned about 1563 replay attack protection strength should understand these factors 1564 and their meaning in a given network segment. 1566 d. Denial of Service 1568 Proper deploy of this mechanism in a Babel network significantly 1569 increases the efforts required for an attacker to feed arbitrary 1570 Babel PDUs into protocol exchange (with an intent of attacking a 1571 particular Babel speaker or disrupting exchange of regular 1572 traffic in a routing domain). It also protects the neighbour 1573 table from being flooded with forged speaker entries. 1575 At the same time, this protection comes for a price of CPU time 1576 being spent on HMAC computations. This may be a concern for low- 1577 performance CPUs combined with high-speed interfaces, as 1578 sometimes is seen in embedded systems and hardware routers. The 1579 MaxDigestsIn parameter, which is purposed to limit the maximum 1580 amount of CPU time spent on a single received Babel packet, 1581 addresses this concern to some extent. 1583 The following in-scope concerns are not addressed: 1585 e. Offline Cryptographic Attacks 1587 This mechanism is an obvious subject to offline cryptographic 1588 attacks. As soon as an attacker has obtained a copy of an 1589 authenticated Babel packet of interest (which gets easier to do 1590 in wireless networks), he has got all the parameters of the 1591 authentication-specific processing performed by the sender, 1592 except authentication key(s) and choice of particular hash 1593 algorithm(s). Since digest lengths of common hash algorithms are 1594 well-known and can be matched with those seen in the packet, 1595 complexity of this attack is essentially that of the 1596 authentication key attack. 1598 Viewing cryptographic strength of particular hash algorithms as a 1599 concern of its own, the main practical means of resisting offline 1600 cryptographic attacks on this mechanism are periodic rekeying and 1601 use of strong keys with sufficient amount of random bits. 1603 It is important to understand, that in the case of multiple keys 1604 being used within single interface (for a multi-domain 1605 authentication or during a key rollover) strength of the combined 1606 configuration would be that of the weakest key, since only one 1607 successful HMAC test is required for an authentic packet. 1608 Operators concerned about offline cryptographic attacks should 1609 enforce the same strength policy for all keys used for a given 1610 interface. 1612 Note that a special pathological case is possible with this 1613 mechanism. Whenever two or more authentication keys are 1614 configured for a given interface such that all keys share the 1615 same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 1616 2^16 is different for each key, these keys will not be treated as 1617 duplicate (Section 5.2 item 3), but a HMAC result computed for a 1618 given packet will be the same for each of these keys. In the 1619 case of sending procedure this can produce multiple HMAC TLVs 1620 with exactly the same value of the Digest field, but different 1621 value of KeyID field. In this case the attacker will see that 1622 the keys are the same, even without the knowledge of the key 1623 itself. Reuse of authentication keys is not the intended use 1624 case of this mechanism and should be strongly avoided. 1626 f. Non-repudiation 1628 This specification relies on a use of shared keys. There is no 1629 timestamp infrastructure and no key revocation mechanism defined 1630 to address a shared key compromise. Establishing the time that a 1631 particular authentic Babel packet was generated is thus not 1632 possible. Proving, that a particular Babel speaker had actually 1633 sent a given authentic packet is also impossible as soon as the 1634 shared key is claimed compromised. Even with the shared key not 1635 being compromised, reliably identifying the speaker that had 1636 actually sent a given authentic Babel packet is not possible any 1637 better than proving the speaker to belong to the group sharing 1638 the key (any of the speakers sharing a key can impose any other 1639 speaker sharing the same key). 1641 g. Confidentiality Violations 1643 The original Babel protocol does not encrypt any of the 1644 information contained in its packets. Contents of a Babel packet 1645 is trivial to decode, revealing network topology details. This 1646 mechanism does not improve this situation in any way. Since 1647 routing protocol messages are not the only kind of information 1648 subject to confidentiality concerns, a complete solution to this 1649 problem is likely to include measures based on the channel 1650 security model, such as IPSec and WPA2 at the time of this 1651 writing. 1653 h. Key Management 1655 Any authentication key exchange/distribution concerns are left 1656 out of scope. However, the internal representation of 1657 authentication keys (see Section 3.8) allows for diverse key 1658 management means, manual configuration in the first place. 1660 i. Message Deletion 1662 Any message deletion attacks are left out of scope. Since a 1663 datagram deleted by an attacker cannot be distinguished from a 1664 datagram naturally lost in transmission and since datagram-based 1665 routing protocols are designed to withstand a certain loss of 1666 packets, the currently established practice is treating 1667 authentication purely as a per-packet function without any added 1668 detection of lost packets. 1670 9. IANA Considerations 1672 [RFC Editor: please do not remove this section.] 1674 At the time of this publication Babel TLV Types namespace did not 1675 have an IANA registry. TLV types 11 and 12 were assigned to the 1676 TS/PC and HMAC TLV types by Juliusz Chroboczek, designer of the 1677 original Babel protocol. Therefore, this document has no IANA 1678 actions. 1680 10. Acknowledgements 1682 Thanks to Ran Atkinson and Matthew Fanto for their comprehensive work 1683 on [RIP2-AUTH] that initiated a series of publications on routing 1684 protocols authentication, including this one. This specification 1685 adopts many concepts belonging to the whole series. 1687 Thanks to Juliusz Chroboczek for his works on mesh networking in 1688 general and Babel routing protocol in particular, and also for 1689 feedback on early revisions of this document. This work would not be 1690 possible without prior works on Babel. 1692 Thank to Jim Gettys and Dave Taht for developing CeroWrt wireless 1693 router project and collaborating on many integration issues. A 1694 practical need for Babel authentication emerged during a research 1695 based on CeroWrt that eventually became the very first use case of 1696 this mechanism. 1698 Thanks to Kunihiro Ishiguro and Paul Jakma for establishing GNU Zebra 1699 and Quagga routing software projects respectively. Thanks to Werner 1700 Koch, the author of Libgcrypt. The very first implementation of this 1701 mechanism was made on base of Quagga and Libgcrypt. 1703 This document was produced using the xml2rfc ([RFC2629]) authoring 1704 tool. 1706 11. References 1708 11.1. Normative References 1710 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1711 Hashing for Message Authentication", RFC 2104, 1712 February 1997. 1714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1715 Requirement Levels", BCP 14, RFC 2119, March 1997. 1717 [FIPS-198] 1718 US National Institute of Standards & Technology, "The 1719 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 1720 198 , March 2002. 1722 [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1723 April 2011. 1725 11.2. Informative References 1727 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1728 June 1999. 1730 [RIP2-AUTH] 1731 Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1732 Authentication", RFC 4822, February 2007. 1734 [OSPF2-AUTH] 1735 Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 1736 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 1737 Authentication", RFC 5709, October 2009. 1739 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 1740 with Existing Cryptographic Protection Methods for Routing 1741 Protocols", RFC 6039, October 2010. 1743 [OSPF3-AUTH] 1744 Bhatia, M., Manral, V., and A. Lindem, "Supporting 1745 Authentication Trailer for OSPFv3", RFC 6506, 1746 February 2012. 1748 Appendix A. Figures 1750 +-------------------------------------------------------------+ 1751 | authentication-specific statistics | 1752 +-------------------------------------------------------------+ 1753 ^ | ^ 1754 | v | 1755 | +-----------------------------------------------+ | 1756 | | system operator | | 1757 | +-----------------------------------------------+ | 1758 | ^ | ^ | ^ | | 1759 | | v | v | v | 1760 +---+ +----------------+ +---------+ +----------------+ +---+ 1761 | | | MaxDigestsIn | | | | MaxDigestsOut | | | 1762 | |<-| ANM timeout | | CSAs | | |->| | 1763 | R | | RxAuthRequired | | | | | | T | 1764 | x | +----------------+ +---------+ +----------------+ | x | 1765 | | | | | | 1766 | p | v v | p | 1767 | r | +---------------------+ +---------------------+ | r | 1768 | o |<-| Rx ESAs (temporary) | | Tx ESAs (temporary) |->| o | 1769 | c | +---------------------+ +---------------------+ | c | 1770 | e | +---------------------+ +---------------------+ | e | 1771 | s |->| ANM | | LocalTS |->| s | 1772 | s |<-| table | | LocalPC |<-| s | 1773 | i | +---------------------+ +---------------------+ | i | 1774 | n | +------------------------------+----------------+ | n | 1775 | g | | instance of | output buffers |=>| g | 1776 | |=>| the original +----------------+ | | 1777 | | | protocol | source address |->| | 1778 +---+ +------------------------------+----------------+ +---+ 1779 /\ | || 1780 || v \/ 1781 +-------------------------------------------------------------+ 1782 | IPv6 stack | 1783 +-------------------------------------------------------------+ 1784 /\ || /\ || /\ || /\ || 1785 || \/ || \/ || \/ || \/ 1786 +---------+ +---------+ +---------+ +---------+ 1787 | speaker | | speaker | ... | speaker | | speaker | 1788 +---------+ +---------+ +---------+ +---------+ 1790 Flow of Babel datagrams: ===> Flow of contol data: ---> 1792 Figure 1: Interaction Diagram 1794 The diagram below depicts structure of two Babel datagrams. The left 1795 datagram contains an unauthenticated Babel packet and an optional 1796 trailing data block. The right datagram, besides these, contains 1797 authentication-specific TLVs in the Babel packet body. 1799 +-------------------+ ------- ------- +-------------------+ 1800 | Babel packet | ^ ^ | Babel packet | 1801 | header | | | | header | 1802 +-------------------+ -- | | -- +-------------------+ 1803 | other TLV | ^ | | ^ | other TLV | 1804 +-------------------+ | | | | +-------------------+ 1805 | other TLV | | | P | | | other TLV | 1806 +-------------------+ | | | | +-------------------+ 1807 | (...) | | B | | | | (...) | 1808 +-------------------+ | | | | +-------------------+ 1809 | other TLV | | | P | | | other TLV | 1810 +-------------------+ | | | | +-------------------+ 1811 | other TLV | v v | B | | other TLV | 1812 +-------------------+ ------- | | +-------------------+ 1813 | optional trailing | | | | TS/PC TLV | 1814 | data block | | | +-------------------+ 1815 +-------------------+ | | | HMAC TLV | 1816 | | +-------------------+ 1817 | | | (...) | 1818 | | +-------------------+ 1819 P: Babel packet v v | HMAC TLV | 1820 B: Babel packet body ------- +-------------------+ 1821 | optional trailing | 1822 | data block | 1823 +-------------------+ 1825 Figure 2: Babel Datagram Structure 1827 The diagram below depicts a sample HMAC TLV corresponding to a hash 1828 algorithm with digest length of 20 octets (such as RIPEMD-160). Its 1829 Digest field is fully padded using IPv6 address 1830 fe80::0a11:96ff:fe1c:10c8 for the first 16 octets and 0x00 for the 1831 subsequent octets. 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Type = 12 | Length = 22 | KeyID = 12345 | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Digest = 0xFE 80 00 00 | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | 00 00 00 00 | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | 0A 11 96 FF | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | FE 1C 10 C8 | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | 00 00 00 00 | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 Figure 3: A Padded HMAC TLV 1851 The diagram below depicts the same HMAC TLV with all 20 octets of a 1852 sample HMAC result written to the Digest field. 1854 0 1 2 3 1855 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 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Type = 12 | Length = 22 | KeyID = 12345 | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Digest = 0x4F C8 C8 9D | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | 57 83 91 9B | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | 81 B0 90 47 | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | B4 2F E3 37 | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | A7 BE 93 83 | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 Figure 4: A HMAC TLV with a HMAC Result 1872 Author's Address 1874 Denis Ovsienko 1875 Yandex 1876 16, Leo Tolstoy St. 1877 Moscow, 119021 1878 Russia 1880 Email: infrastation@yandex.ru