idnits 2.17.1 draft-ovsienko-babel-hmac-authentication-09.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 18, 2014) is 3632 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TLV' is mentioned on line 2363, but not defined ** 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 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6506 (ref. 'OSPF3-AUTH') (Obsoleted by RFC 7166) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-04) exists of draft-chroboczek-babel-extension-mechanism-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 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) April 18, 2014 5 Intended status: Experimental 6 Expires: October 20, 2014 8 Babel HMAC Cryptographic Authentication 9 draft-ovsienko-babel-hmac-authentication-09 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 Babel routing protocol, updating, but not superseding 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 October 20, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 54 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 6 55 2.1. Mandatory-to-Implement and Optional Hash Algorithms . . . 6 56 2.2. Definition of Padding . . . . . . . . . . . . . . . . . . 7 57 2.3. Cryptographic Sequence Number Specifics . . . . . . . . . 9 58 2.4. Definition of HMAC . . . . . . . . . . . . . . . . . . . . 9 59 3. Updates to Protocol Data Structures . . . . . . . . . . . . . 11 60 3.1. RxAuthRequired . . . . . . . . . . . . . . . . . . . . . . 11 61 3.2. LocalTS . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 3.3. LocalPC . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 3.4. MaxDigestsIn . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.5. MaxDigestsOut . . . . . . . . . . . . . . . . . . . . . . 12 65 3.6. ANM Table . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.7. ANM Timeout . . . . . . . . . . . . . . . . . . . . . . . 14 67 3.8. Configured Security Associations . . . . . . . . . . . . . 15 68 3.9. Effective Security Associations . . . . . . . . . . . . . 16 69 4. Updates to Protocol Encoding . . . . . . . . . . . . . . . . . 17 70 4.1. Justification . . . . . . . . . . . . . . . . . . . . . . 17 71 4.2. TS/PC TLV . . . . . . . . . . . . . . . . . . . . . . . . 19 72 4.3. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 20 73 5. Updates to Protocol Operation . . . . . . . . . . . . . . . . 21 74 5.1. Per-Interface TS/PC Number Updates . . . . . . . . . . . . 21 75 5.2. Deriving ESAs from CSAs . . . . . . . . . . . . . . . . . 23 76 5.3. Updates to Packet Sending . . . . . . . . . . . . . . . . 25 77 5.4. Updates to Packet Receiving . . . . . . . . . . . . . . . 27 78 5.5. Authentication-Specific Statistics Maintenance . . . . . . 29 79 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 30 80 6.1. Source Address Selection for Sending . . . . . . . . . . . 30 81 6.2. Output Buffer Management . . . . . . . . . . . . . . . . . 31 82 6.3. Optimizations of ESAs Deriving . . . . . . . . . . . . . . 32 83 6.4. Security Associations Duplication . . . . . . . . . . . . 32 84 7. Network Management Aspects . . . . . . . . . . . . . . . . . . 34 85 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . . 34 86 7.2. Multi-Domain Authentication . . . . . . . . . . . . . . . 34 87 7.3. Migration to and from Authenticated Exchange . . . . . . . 35 88 7.4. Handling of Authentication Keys Exhaustion . . . . . . . . 36 89 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 45 96 Appendix A. Figures and Tables . . . . . . . . . . . . . . . . . 48 97 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 52 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 100 1. Introduction 102 [RFC Editor: before publication please remove the sentence below.] 103 Comments are solicited and should be addressed to the author. 105 Authentication of routing protocol exchanges is a common mean of 106 securing computer networks. Use of protocol authentication 107 mechanisms helps in ascertaining that only the intended routers 108 participate in routing information exchange, and that the exchanged 109 routing information is not modified by a third party. 111 [BABEL] ("the original specification") defines data structures, 112 encoding, and the operation of a basic Babel routing protocol 113 instance ("instance of the original protocol"). This document ("this 114 specification") defines data structures, encoding, and the operation 115 of an extension to the Babel protocol, an authentication mechanism 116 ("this mechanism"). Both the instance of the original protocol and 117 this mechanism are mostly self-contained and interact only at 118 coupling points defined in this specification. 120 A major design goal of this mechanism is transparency to operators 121 that is not affected by implementation and configuration specifics. 122 A complying implementation makes all meaningful details of 123 authentication-specific processing clear to the operator, even when 124 some of the operational parameters cannot be changed. 126 The currently established (see [RIP2-AUTH], [OSPF2-AUTH], 127 [OSPF3-AUTH], [ISIS-AUTH-A], and [RFC6039]) approach to 128 authentication mechanism design for datagram-based routing protocols 129 such as Babel relies on two principal data items embedded into 130 protocol packets, typically as two integral parts of a single data 131 structure: 133 o A fixed-length unsigned integer, typically called a cryptographic 134 sequence number, used in replay attack protection. 136 o A variable-length sequence of octets, a result of the HMAC 137 construct (see [RFC2104]) computed on meaningful data items of the 138 packet (including the cryptographic sequence number) on one hand 139 and a secret key on the other, used in proving that both the 140 sender and the receiver share the same secret key and that the 141 meaningful data was not changed in transmission. 143 Depending on the design specifics either all protocol packets are 144 authenticated or only those protecting the integrity of protocol 145 exchange. This mechanism authenticates all protocol packets. 147 Although the HMAC construct is just one of many possible approaches 148 to cryptographic authentication of packets, this mechanism makes use 149 of relevant prior experience by using HMAC too and its solution space 150 correlates with the solution spaces of the mechanisms above. At the 151 same time, it allows for a future extension that treats HMAC as a 152 particular case of a more generic mechanism. Practical experience 153 with the mechanism defined herein should be useful in designing such 154 future extension. 156 This specification defines the use of the cryptographic sequence 157 number in details sufficient to make replay attack protection 158 strength predictable. That is, an operator can tell the strength 159 from the declared characteristics of an implementation and, whereas 160 the implementation allows to change relevant parameters, the effect 161 of a reconfiguration. 163 This mechanism explicitly allows for multiple HMAC results per 164 authenticated packet. Since meaningful data items of a given packet 165 remain the same, each such HMAC result stands for a different secret 166 key and/or a different hash algorithm. This enables a simultaneous, 167 independent authentication within multiple domains. This 168 specification is not novel in this regard, e.g., L2TPv3 allows for 1 169 or 2 ([RFC3931] Section 5.4.1) and MANET protocols allow for several 170 ([RFC7183] Section 6.1) results per authenticated packet. 172 An important concern addressed by this mechanism is limiting the 173 amount of HMAC computations done per authenticated packet, 174 independently for sending and receiving. Without these limits the 175 number of computations per packet could be as high as the number of 176 configured authentication keys (in the sending case) or as the number 177 of keys multiplied by the number of supplied HMAC results (in the 178 receiving case). 180 These limits establish a basic competition between the configured 181 keys and (in the receiving case) an additional competition between 182 the supplied HMAC results. This specification defines related data 183 structures and procedures in a way to make such competition 184 transparent and predictable for an operator. 186 Wherever this specification mentions the operator reading or changing 187 a particular data structure, variable, parameter, or event counter 188 "at runtime", it is up to the implementor how this is to be done. 189 For example, the implementation can employ an interactive CLI, or a 190 management protocol such as SNMP, or an inter-process communication 191 mean such as a local socket, or a combination of these. 193 1.1. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in BCP 14 [RFC2119]. 199 2. Cryptographic Aspects 201 2.1. Mandatory-to-Implement and Optional Hash Algorithms 203 [RFC2104] defines HMAC as a construct that can use any cryptographic 204 hash algorithm with a known digest length and internal block size. 205 This specification preserves this property of HMAC by defining data 206 processing that itself does not depend on any particular hash 207 algorithm either. However, since this mechanism is a protocol 208 extension case, there are relevant design considerations to take into 209 account. 211 Section 4.5 of [RFC6709] suggests selecting one hash algorithm as 212 mandatory-to-implement for the purpose of global interoperability 213 (Section 3.2 ibid.) and selecting another of distinct lineage as 214 recommended for implementation for the purpose of cryptographic 215 agility. This specification makes the latter property guaranteed, 216 rather than probable, through an elevation of the requirement level. 217 There are two hash algorithms mandatory-to-implement, unambiguously 218 defined and generally available in multiple implementations each. 220 An implementation of this mechanism MUST include support for two hash 221 algorithms: 223 o RIPEMD-160 (160-bit digest) 225 o SHA-1 (160-bit digest) 227 Besides that, an implementation of this mechanism MAY include support 228 for additional hash algorithms, provided each such algorithm is 229 publicly and openly specified and its digest length is 128 bits or 230 more (to meet the constraint implied in Section 2.2). Implementors 231 SHOULD consider strong, well-known hash algorithms as additional 232 implementation options and MUST NOT consider hash algorithms for that 233 by the time of implementation meaningful attacks exist or that are 234 commonly viewed as deprecated. 236 In the latter case it is important to take into account 237 considerations both common (such as those made in [RFC4270]) and 238 specific to the HMAC application of the hash algorithm. E.g., 239 [RFC6151] considers MD5 collisions and concludes that new protocol 240 designs should not use HMAC-MD5, while [RFC6194] includes a 241 comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the 242 same purpose. 244 For example, the following hash algorithms meet these requirements at 245 the time of this writing (in alphabetical order): 247 o GOST R 34.11-94 (256-bit digest) 249 o SHA-224 (224-bit digest, SHA-2 family) 251 o SHA-256 (256-bit digest, SHA-2 family) 253 o SHA-384 (384-bit digest, SHA-2 family) 255 o SHA-512 (512-bit digest, SHA-2 family) 257 o Tiger (192-bit digest) 259 o Whirlpool (512-bit digest, 2nd rev., 2003) 261 The set of hash algorithms available in an implementation MUST be 262 clearly stated. When known weak authentication keys exist for a hash 263 algorithm used in the HMAC construct, an implementation MUST deny a 264 use of such keys. 266 2.2. Definition of Padding 268 Many practical applications of HMAC for authentication of datagram- 269 based network protocols (including routing protocols) involve the 270 padding procedure, a design-specific conditioning of the message that 271 both the sender and the receiver perform before the HMAC computation. 272 Specific padding procedure of this mechanism addresses the following 273 needs: 275 o Data Initialization 277 A design that places the HMAC result(s) computed for a message 278 inside the same message after the computation has to allocate in 279 the message some data unit(s) purposed for the result(s) (in this 280 mechanism it is the HMAC TLV(s), see Section 4.3). The padding 281 procedure sets respective octets of the data unit(s), in the 282 simplest case to a fixed value known as the padding constant. 284 Particular value of the constant is specific to each design. For 285 instance, in [RIP2-AUTH] as well as works derived from it 286 ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH]) the value is 287 0x878FE1F3. In many other designs (for instance, [RFC3315], 289 [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]) the 290 value is 0x00. 292 However, the HMAC construct is defined on the base of a 293 cryptographic hash algorithm, that is, an algorithm meeting 294 particular set of requirements made for any input message. Thus 295 any padding constant values, whether single- or multiple-octet, as 296 well as any other message conditioning methods, don't affect 297 cryptographic characteristics of the hash algorithm and the HMAC 298 construct respectively. 300 o Source Address Protection 302 In the specific case of datagram-based routing protocols the 303 protocol packet (that is, the message being authenticated) often 304 does not include network layer addresses, although the source and 305 (to a lesser extent) the destination address of the datagram may 306 be meaningful in the scope of the protocol instance. 308 In Babel the source address may be used as a prefix hext hop (see 309 Section 3.5.3 of [BABEL]). A well-known (see Section 2.3 of 310 [OSPF3-AUTH]) solution to the source address protection problem is 311 to set the first respective octets of the data unit(s) above to 312 the source address (yet setting the rest of the octets to the 313 padding constant). This procedure adapts this solution to the 314 specifics of Babel, which allows for exchange of protocol packets 315 using both IPv4 and IPv6 datagrams (see Section 4 of [BABEL]). 316 Even though in the case of IPv6 exchange a Babel speaker currently 317 uses only link-local source addresses (Section 3.1 ibid.), this 318 procedure protects all octets of an arbitrary given source address 319 for the reasons of future extensibility. The procedure implies 320 that future Babel extensions will never use an IPv4-mapped IPv6 321 address as a packet source address. 323 This procedure does not protect the destination address, which is 324 currently considered meaningless (ibid.) in the same scope. A 325 future extension that looks to add such protection would likely 326 use a new TLV or sub-TLV to include the destination address into 327 the protocol packet (see Section 4.1). 329 Description of the padding procedure: 331 1. Set the first 16 octets of the Digest field of the given HMAC TLV 332 to: 334 * the given source address, if it is an IPv6 address, or 335 * the IPv4-mapped IPv6 address (per Section 2.5.5.2 of 336 [RFC4291]) holding the given source address, if it is an IPv4 337 address. 339 2. Set the remaining (TLV Length - 18) octets of the Digest field of 340 the given HMAC TLV to 0x00. 342 For an example of a Babel packet with padded HMAC TLVs see Table 3. 344 2.3. Cryptographic Sequence Number Specifics 346 Operation of this mechanism may involve multiple local and multiple 347 remote cryptographic sequence numbers, each essentially being a 348 48-bit unsigned integer. This specification uses a term "TS/PC 349 number" to avoid confusion with the route's (Section 2.5 of [BABEL]) 350 or node's (Section 3.2.1 ibid.) sequence numbers of the original 351 Babel specification and to stress the fact that there are two 352 distinguished parts of this 48-bit number, each handled in its 353 specific way (see Section 5.1): 355 0 1 2 3 4 356 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 357 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | TS // | PC | 359 +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 // 362 The high-order 32 bits are called "timestamp" (TS) and the low-order 363 16 bits are called "packet counter" (PC). 365 This mechanism stores, updates, compares, and encodes each TS/PC 366 number as two independent unsigned integers, TS and PC respectively. 367 Such comparison of TS/PC numbers performed in item 3 of Section 5.4 368 is algebraically equivalent to comparison of respective 48-bit 369 unsigned integers. Any byte order conversion, when required, is 370 performed on TS and PC parts independently. 372 2.4. Definition of HMAC 374 The algorithm description below uses the following nomenclature, 375 which is consistent with [FIPS-198]: 377 Text Is the data on which the HMAC is calculated (note item (b) of 378 Section 9). In this specification it is the contents of a 379 Babel packet ranging from the beginning of the Magic field of 380 the Babel packet header to the end of the last octet of the 381 Packet Body field, as defined in Section 4.2 of [BABEL] (see 382 Figure 2). 384 H Is the specific hash algorithm (see Section 2.1). 386 K Is a sequence of octets of an arbitrary, known length. 388 Ko Is the cryptographic key used with the hash algorithm. 390 B Is the block size of H, measured in octets rather than bits. 391 Note that B is the internal block size, not the digest length. 393 L Is the digest length of H, measured in octets rather than 394 bits. 396 XOR Is the bitwise exclusive-or operation. 398 Opad Is the hexadecimal value 0x5C repeated B times. 400 Ipad Is the hexadecimal value 0x36 repeated B times. 402 The algorithm below is the original, unmodified HMAC construct as 403 defined in both [RFC2104] and [FIPS-198], hence it is different from 404 the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], 405 and [OSPF3-AUTH] in exactly two regards: 407 o The algorithm below sets the size of Ko to B, not to L (L is not 408 greater than B). This resolves both ambiguity in XOR expressions 409 and incompatibility in handling of keys that have length greater 410 than L but not greater than B. 412 o The algorithm below does not change value of Text before or after 413 the computation. Both padding of a Babel packet before the 414 computation and placing of the result inside the packet are 415 performed elsewhere. 417 The intent of this is to enable the most straightforward use of 418 cryptographic libraries by implementations of this specification. At 419 the time of this writing implementations of the original HMAC 420 construct coupled with hash algorithms of choice are generally 421 available. 423 Description of the algorithm: 425 1. Preparation of the Key 427 In this application, Ko is always B octets long. If K is B 428 octets long, then Ko is set to K. If K is more than B octets 429 long, then Ko is set to H(K) with the necessary amount of zeroes 430 appended to the end of H(K), such that Ko is B octets long. If K 431 is less than B octets long, then Ko is set to K with zeroes 432 appended to the end of K, such that Ko is B octets long. 434 2. First-Hash 436 A First-Hash, also known as the inner hash, is computed as 437 follows: 439 First-Hash = H(Ko XOR Ipad || Text) 441 3. Second-Hash 443 A second hash, also known as the outer hash, is computed as 444 follows: 446 Second-Hash = H(Ko XOR Opad || First-Hash) 448 4. Result 450 The resulting Second-Hash becomes the authentication data that is 451 returned as the result of HMAC calculation. 453 Note that in the case of Babel the Text parameter will never exceed a 454 few thousands of octets in length. In this specific case the 455 optimization discussed in Section 6 of [FIPS-198] applies, namely, 456 for a given K that is more than B octets long the following 457 associated intermediate results may be precomputed only once: Ko, 458 (Ko XOR Ipad), and (Ko XOR Opad). 460 3. Updates to Protocol Data Structures 462 3.1. RxAuthRequired 464 RxAuthRequired is a boolean parameter, its default value MUST be 465 TRUE. An implementation SHOULD make RxAuthRequired a per-interface 466 parameter, but MAY make it specific to the whole protocol instance. 467 The conceptual purpose of RxAuthRequired is to enable a smooth 468 migration from an unauthenticated to an authenticated Babel packet 469 exchange and back (see Section 7.3). Current value of RxAuthRequired 470 directly affects the receiving procedure defined in Section 5.4. An 471 implementation SHOULD allow the operator to change RxAuthRequired 472 value at runtime or by means of Babel speaker restart. An 473 implementation MUST allow the operator to discover the effective 474 value of RxAuthRequired at runtime or from the system documentation. 476 3.2. LocalTS 478 LocalTS is a 32-bit unsigned integer variable, it is the TS part of a 479 per-interface TS/PC number. LocalTS is a strictly per-interface 480 variable not intended to be changed by the operator. Its 481 initialization is explained in Section 5.1. 483 3.3. LocalPC 485 LocalPC is a 16-bit unsigned integer variable, it is the PC part of a 486 per-interface TS/PC number. LocalPC is a strictly per-interface 487 variable not intended to be changed by the operator. Its 488 initialization is explained in Section 5.1. 490 3.4. MaxDigestsIn 492 MaxDigestsIn is an unsigned integer parameter conceptually purposed 493 for limiting the amount of CPU time spent processing a received 494 authenticated packet. The receiving procedure performs the most CPU- 495 intensive operation, the HMAC computation, only at most MaxDigestsIn 496 (Section 5.4 item 7) times for a given packet. 498 MaxDigestsIn value MUST be at least 2. An implementation SHOULD make 499 MaxDigestsIn a per-interface parameter, but MAY make it specific to 500 the whole protocol instance. An implementation SHOULD allow the 501 operator to change the value of MaxDigestsIn at runtime or by means 502 of Babel speaker restart. An implementation MUST allow the operator 503 to discover the effective value of MaxDigestsIn at runtime or from 504 the system documentation. 506 3.5. MaxDigestsOut 508 MaxDigestsOut is an unsigned integer parameter conceptually purposed 509 for limiting the amount of a sent authenticated packet's space spent 510 on authentication data. The sending procedure adds at most 511 MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet, 512 concurring with the output buffer management explained in 513 Section 6.2. 515 The MaxDigestsOut value MUST be at least 2. An implementation SHOULD 516 make MaxDigestsOut a per-interface parameter, but MAY make it 517 specific to the whole protocol instance. An implementation SHOULD 518 allow the operator to change the value of MaxDigestsOut at runtime or 519 by means of Babel speaker restart, in a safe range. The maximum safe 520 value of MaxDigestsOut is implementation-specific (see Section 6.2). 521 An implementation MUST allow the operator to discover the effective 522 value of MaxDigestsOut at runtime or from the system documentation. 524 3.6. ANM Table 526 The ANM (Authentic Neighbours Memory) table resembles the neighbour 527 table defined in Section 3.2.3 of [BABEL]. Note that the term 528 "neighbour table" means the neighbour table of the original Babel 529 specification, and the term "ANM table" means the table defined 530 herein. Indexing of the ANM table is done in exactly the same way as 531 indexing of the neighbour table, but purpose, field set and 532 associated procedures are different. 534 The conceptual purpose of the ANM table is to provide longer term 535 replay attack protection than it would be possible using the 536 neighbour table. Expiry of an inactive entry in the neighbour table 537 depends on the last received Hello Interval of the neighbour and 538 typically stands for tens to hundreds of seconds (see Appendix A and 539 Appendix B of [BABEL]). Expiry of an inactive entry in the ANM table 540 depends only on the local speaker's configuration. The ANM table 541 retains (for at least the amount of seconds set by ANM timeout 542 parameter defined in Section 3.7) a copy of TS/PC number advertised 543 in authentic packets by each remote Babel speaker. 545 The ANM table is indexed by pairs of the form (Interface, Source). 546 Every table entry consists of the following fields: 548 o Interface 550 An implementation-specific reference to the local node's interface 551 that the authentic packet was received through. 553 o Source 555 The source address of the Babel speaker that the authentic packet 556 was received from. 558 o LastTS 560 A 32-bit unsigned integer, the TS part of a remote TS/PC number. 562 o LastPC 564 A 16-bit unsigned integer, the PC part of a remote TS/PC number. 566 Each ANM table entry has an associated aging timer, which is reset by 567 the receiving procedure (Section 5.4 item 9). If the timer expires, 568 the entry is deleted from the ANM table. 570 An implementation SHOULD use a persistent memory (NVRAM) to retain 571 the contents of ANM table across restarts of the Babel speaker, but 572 only as long as both the Interface field reference and expiry of the 573 aging timer remain correct. An implementation MUST make it clear, if 574 and how persistent memory is used for ANM table. An implementation 575 SHOULD allow the operator to retrieve the current contents of ANM 576 table at runtime. An implementation SHOULD allow the operator to 577 remove some or all of ANM table entries at runtime or by means of 578 Babel speaker restart. 580 3.7. ANM Timeout 582 ANM timeout is an unsigned integer parameter. An implementation 583 SHOULD make ANM timeout a per-interface parameter, but MAY make it 584 specific to the whole protocol instance. ANM timeout is conceptually 585 purposed for limiting the maximum age (in seconds) of entries in the 586 ANM table standing for inactive Babel speakers. The maximum age is 587 immediately related to replay attack protection strength. The 588 strongest protection is achieved with the maximum possible value of 589 ANM timeout set, but it may not provide the best overall result for 590 specific network segments and implementations of this mechanism. 592 In the first turn, implementations unable to maintain local TS/PC 593 number strictly increasing across Babel speaker restarts will reuse 594 the advertised TS/PC numbers after each restart (see Section 5.1). 595 The neighbouring speakers will treat the new packets as replayed and 596 discard them until the aging timer of respective ANM table entry 597 expires or the new TS/PC number exceeds the one stored in the entry. 599 Another possible, but less probable, case could be an environment 600 using IPv6 for Babel datagrams exchange and involving physical moves 601 of network interfaces hardware between Babel speakers. Even 602 performed without restarting the speakers, these would cause random 603 drops of the TS/PC number advertised for a given (Interface, Source) 604 index, as viewed by neighbouring speakers, since IPv6 link-local 605 addresses are typically derived from interface hardware addresses. 607 Assuming that in such cases the operators would prefer to use a lower 608 ANM timeout value to let the entries expire on their own rather than 609 having to manually remove them from the ANM table each time, an 610 implementation SHOULD set the default value of ANM timeout to a value 611 between 30 and 300 seconds. 613 At the same time, network segments may exist with every Babel speaker 614 having its advertised TS/PC number strictly increasing over the 615 deployed lifetime. Assuming that in such cases the operators would 616 prefer using a much higher ANM timeout value, an implementation 617 SHOULD allow the operator to change the value of ANM timeout at 618 runtime or by means of Babel speaker restart. An implementation MUST 619 allow the operator to discover the effective value of ANM timeout at 620 runtime or from the system documentation. 622 3.8. Configured Security Associations 624 A Configured Security Association (CSA) is a data structure 625 conceptually purposed for associating authentication keys and hash 626 algorithms with Babel interfaces. All CSAs are managed in finite 627 sequences, one sequence per interface ("interface's sequence of CSAs" 628 hereafter). Each interface's sequence of CSAs, as an integral part 629 of the Babel speaker configuration, MAY be intended for a persistent 630 storage as long as this conforms with the implementation's key 631 management policy. The default state of an interface's sequence of 632 CSAs is empty, which has a special meaning of no authentication 633 configured for the interface. The sending (Section 5.3 item 1) and 634 the receiving (Section 5.4 item 1) procedures address this convention 635 accordingly. 637 A single CSA structure consists of the following fields: 639 o HashAlgo 641 An implementation-specific reference to one of the hash algorithms 642 supported by this implementation (see Section 2.1). 644 o KeyChain 646 A finite sequence of elements ("KeyChain sequence" hereafter) 647 representing authentication keys, each element being a structure 648 consisting of the following fields: 650 * LocalKeyID 652 An unsigned integer of an implementation-specific bit length. 654 * AuthKeyOctets 656 A sequence of octets of an arbitrary, known length to be used 657 as the authentication key. 659 * KeyStartAccept 661 The time that this Babel speaker will begin considering this 662 authentication key for accepting packets with authentication 663 data. 665 * KeyStartGenerate 667 The time that this Babel speaker will begin considering this 668 authentication key for generating packet authentication data. 670 * KeyStopGenerate 672 The time that this Babel speaker will stop considering this 673 authentication key for generating packet authentication data. 675 * KeyStopAccept 677 The time that this Babel speaker will stop considering this 678 authentication key for accepting packets with authentication 679 data. 681 Since there is no limit imposed on the number of CSAs per interface, 682 but the number of HMAC computations per sent/received packet is 683 limited (through MaxDigestsOut and MaxDigestsIn respectively), only a 684 fraction of the associated keys and hash algorithms may appear used 685 in the process. The ordering of elements within a sequence of CSAs 686 and within a KeyChain sequence is important to make the association 687 selection process deterministic and transparent. Once this ordering 688 is deterministic at the Babel interface level, the intermediate data 689 derived by the procedure defined in Section 5.2 will be 690 deterministically ordered as well. 692 An implementation SHOULD allow an operator to set any arbitrary order 693 of elements within a given interface's sequence of CSAs and within 694 the KeyChain sequence of a given CSA. Regardless if this requirement 695 is or isn't met, the implementation MUST provide a mean to discover 696 the actual element order used. Whichever order is used by an 697 implementation, it MUST be preserved across Babel speaker restarts. 699 Note that none of the CSA structure fields is constrained to contain 700 unique values. Section 6.4 explains this in more detail. It is 701 possible for the KeyChain sequence to be empty, although this is not 702 the intended manner of CSAs use. 704 The KeyChain sequence has a direct prototype, which is the "key 705 chain" syntax item of some existing router configuration languages. 706 Whereas an implementation already implements this syntax item, it is 707 suggested to reuse it, that is, to implement a CSA syntax item 708 referring to a key chain item instead of reimplementing the latter in 709 full. 711 3.9. Effective Security Associations 713 An Effective Security Association (ESA) is a data structure 714 immediately used in sending (Section 5.3) and receiving (Section 5.4) 715 procedures. Its conceptual purpose is to determine a runtime 716 interface between those procedures and the deriving procedure defined 717 in Section 5.2. All ESAs are temporary data units managed as 718 elements of finite sequences that are not intended for a persistent 719 storage. Element ordering within each such finite sequence 720 ("sequence of ESAs" hereafter) MUST be preserved as long as the 721 sequence exists. 723 A single ESA structure consists of the following fields: 725 o HashAlgo 727 An implementation-specific reference to one of the hash algorithms 728 supported by this implementation (see Section 2.1). 730 o KeyID 732 A 16-bit unsigned integer. 734 o AuthKeyOctets 736 A sequence of octets of an arbitrary, known length to be used as 737 the authentication key. 739 Note that among the protocol data structures introduced by this 740 mechanism ESA is the only one not directly interfaced with the system 741 operator (see Figure 1), it is not immediately present in the 742 protocol encoding either. However, ESA is not just a possible 743 implementation technique, but an integral part of this specification: 744 the deriving (Section 5.2), the sending (Section 5.3), and the 745 receiving (Section 5.4) procedures are defined in terms of the ESA 746 structure and its semantics provided herein. ESA is as meaningful 747 for a correct implementation as the other protocol data structures. 749 4. Updates to Protocol Encoding 751 4.1. Justification 753 Choice of encoding is very important in the long term. The protocol 754 encoding limits various authentication mechanism designs and 755 encodings, which in turn limit future developments of the protocol. 757 Considering existing implementations of Babel protocol instance 758 itself and related modules of packet analysers, the current encoding 759 of Babel allows for compact and robust decoders. At the same time, 760 this encoding allows for future extensions of Babel by three (not 761 excluding each other) principal means defined by Section 4.2 and 762 Section 4.3 of [BABEL] and further discussed in 764 [I-D.chroboczek-babel-extension-mechanism]: 766 a. A Babel packet consists of a four-octet header followed by a 767 packet body, that is, a sequence of TLVs (see Figure 2). Besides 768 the header and the body, an actual Babel datagram may have an 769 arbitrary amount of trailing data between the end of the packet 770 body and the end of the datagram. An instance of the original 771 protocol silently ignores such trailing data. 773 b. The packet body uses a binary format allowing for 256 TLV types 774 and imposing no requirements on TLV ordering or number of TLVs of 775 a given type in a packet. [BABEL] allocates TLV types 0 through 776 10 (see Table 1), defines TLV body structure for each and 777 establishes the requirement for a Babel protocol instance to 778 ignore any unknown TLV types silently. This makes it possible to 779 examine a packet body (to validate the framing and/or to pick 780 particular TLVs for further processing) considering only the type 781 (to distinguish between a Pad1 TLV and any other TLV) and the 782 length of each TLV, regardless if and how many additional TLV 783 types are eventually deployed. 785 c. Within each TLV of the packet body there may be some "extra data" 786 after the "expected length" of the TLV body. An instance of the 787 original protocol silently ignores any such extra data. Note 788 that any TLV types without the expected length defined (such as 789 PadN TLV) cannot be extended with the extra data. 791 Considering each principal extension mean for the specific purpose of 792 adding authentication data items to each protocol packet, the 793 following arguments can be made: 795 o Use of the TLV extra data of some existing TLV type would not be a 796 solution, since no particular TLV type is guaranteed to be present 797 in a Babel packet. 799 o Use of the TLV extra data could also conflict with future 800 developments of the protocol encoding. 802 o Since the packet trailing data is currently unstructured, using it 803 would involve defining an encoding structure and associated 804 procedures, adding to the complexity of both specification and 805 implementation and increasing the exposure to protocol attacks 806 such as fuzzing. 808 o A naive use of the packet trailing data would make it unavailable 809 to any future extension of Babel. Since this mechanism is 810 possibly not the last extension and since some other extensions 811 may allow no other embedding means except the packet trailing 812 data, the defined encoding structure would have to enable 813 multiplexing of data items belonging to different extensions. 814 Such a definition is out of the scope of this work. 816 o Deprecating an extension (or only its protocol encoding) that uses 817 purely purpose-allocated TLVs is as simple as deprecating the 818 TLVs. 820 o Use of purpose-allocated TLVs is transparent for both the original 821 protocol and any its future extensions, regardless of the 822 embedding mean(s) used by the latter. 824 Considering all of the above, this mechanism neither uses the packet 825 trailing data nor uses the TLV extra data, but uses two new TLV 826 types: type 11 for a TS/PC number and type 12 for an HMAC result (see 827 Table 1). 829 4.2. TS/PC TLV 831 The purpose of a TS/PC TLV is to store a single TS/PC number. There 832 is exactly one TS/PC TLV in an authenticated Babel packet. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Type = 11 | Length | PacketCounter | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Timestamp | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Fields: 844 Type Set to 11 to indicate a TS/PC TLV. 846 Length The length in octets of the body, exclusive of the 847 Type and Length fields. 849 PacketCounter A 16-bit unsigned integer in network byte order, the 850 PC part of a TS/PC number stored in this TLV. 852 Timestamp A 32-bit unsigned integer in network byte order, the 853 TS part of a TS/PC number stored in this TLV. 855 Note that the ordering of PacketCounter and Timestamp in the TLV 856 structure is opposite to the ordering of TS and PC in "TS/PC" term 857 and the 48-bit equivalent (see Section 2.3). 859 Considering the "expected length" and the "extra data" in the 860 definition of Section 4.3 of [BABEL], the expected length of a TS/PC 861 TLV body is unambiguously defined as 6 octets. The receiving 862 procedure correctly processes any TS/PC TLV with body length not less 863 than the expected, ignoring any extra data (Section 5.4 items 3 and 864 9). The sending procedure produces a TS/PC TLV with body length 865 equal to the expected and Length field set respectively (Section 5.3 866 item 3). 868 Future Babel extensions (such as sub-TLVs) MAY modify the sending 869 procedure to include the extra data after the fixed-size TS/PC TLV 870 body defined herein, making necessary adjustments to Length TLV 871 field, "Body length" packet header field and output buffer management 872 explained in Section 6.2. 874 4.3. HMAC TLV 876 The purpose of an HMAC TLV is to store a single HMAC result. To 877 assist a receiver in reproducing the HMAC computation, LocalKeyID 878 modulo 2^16 of the authentication key is also provided in the TLV. 879 There is at least one HMAC TLV in an authenticated Babel packet. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Type = 12 | Length | KeyID | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Digest... 887 +-+-+-+-+-+-+-+-+-+-+-+- 889 Fields: 891 Type Set to 12 to indicate an HMAC TLV. 893 Length The length in octets of the body, exclusive of the 894 Type and Length fields. 896 KeyID A 16-bit unsigned integer in network byte order. 898 Digest A variable-length sequence of octets, which is at 899 least 16 octets long (see Section 2.2). 901 Considering the "expected length" and the "extra data" in the 902 definition of Section 4.3 of [BABEL], the expected length of an HMAC 903 TLV body is not defined. The receiving and the padding procedures 904 process every octet of the Digest field, deriving the field boundary 905 from the Length field value (Section 5.4 item 7 and Section 2.2 906 respectively). The sending procedure produces HMAC TLVs with Length 907 field precisely sizing the Digest field to match digest length of the 908 hash algorithm used (Section 5.3 items 5 and 8). 910 The HMAC TLV structure defined herein is final, future Babel 911 extensions MUST NOT extend it with any extra data. 913 5. Updates to Protocol Operation 915 5.1. Per-Interface TS/PC Number Updates 917 The LocalTS and LocalPC interface-specific variables constitute the 918 TS/PC number of a Babel interface. This number is advertised in the 919 TS/PC TLV of authenticated Babel packets sent from that interface. 920 There is only one property mandatory for the advertised TS/PC number: 921 its 48-bit equivalent (see Section 2.3) MUST be strictly increasing 922 within the scope of a given interface of a Babel speaker as long as 923 the protocol instance is continuously operating. This property 924 combined with ANM tables of neighbouring Babel speakers provides them 925 with the most basic replay attack protection. 927 Initialization and increment are two principal updates performed on 928 an interface TS/PC number. The initialization is performed when a 929 new interface becomes a part of a Babel protocol instance. The 930 increment is performed by the sending procedure (Section 5.3 item 2) 931 before advertising the TS/PC number in a TS/PC TLV. 933 Depending on particular implementation method of these two updates 934 the advertised TS/PC number may possess additional properties 935 improving the replay attack protection strength. This includes, but 936 is not limited to the methods below. 938 a. The most straightforward implementation would use LocalTS as a 939 plain wrap counter, defining the updates as follows: 941 initialization Set LocalPC to 0, set LocalTS to 0. 943 increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF 944 + 1 = 0x0000), increment LocalTS by 1. 946 In this case the advertised TS/PC numbers would be reused after 947 each Babel protocol instance restart, making neighbouring 948 speakers reject authenticated packets until the respective ANM 949 table entries expire or the new TS/PC number exceeds the old (see 950 Section 3.6 and Section 3.7). 952 b. A more advanced implementation could make a use of any 32-bit 953 unsigned integer timestamp (number of time units since an 954 arbitrary epoch) such as the UNIX timestamp, whereas the 955 timestamp itself spans a reasonable time range and is guaranteed 956 against a decrease (such as one resulting from network time use). 957 The updates would be defined as follows: 959 initialization Set LocalPC to 0, set LocalTS to 0. 961 increment If the current timestamp is greater than LocalTS, 962 set LocalTS to the current timestamp and LocalPC 963 to 0, then consider the update complete. 964 Otherwise increment LocalPC by 1 and, if LocalPC 965 wraps, increment LocalTS by 1. 967 In this case the advertised TS/PC number would remain unique 968 across the speaker's deployed lifetime without the need for any 969 persistent storage. However, a suitable timestamp source is not 970 available in every implementation case. 972 c. Another advanced implementation could use LocalTS in a way 973 similar to the "wrap/boot counter" suggested in Section 4.1.1 of 974 [OSPF3-AUTH], defining the updates as follows: 976 initialization Set LocalPC to 0. If there is a TS value stored 977 in NVRAM for the current interface, set LocalTS 978 to the stored TS value, then increment the stored 979 TS value by 1. Otherwise set LocalTS to 0 and 980 set the stored TS value to 1. 982 increment Increment LocalPC by 1. If LocalPC wraps, set 983 LocalTS to the TS value stored in NVRAM for the 984 current interface, then increment the stored TS 985 value by 1. 987 In this case the advertised TS/PC number would also remain unique 988 across the speaker's deployed lifetime, relying on NVRAM for 989 storing multiple TS numbers, one per interface. 991 As long as the TS/PC number retains its mandatory property stated 992 above, it is up to the implementor, which TS/PC number updates 993 methods are available and if the operator can configure the method 994 per-interface and/or at runtime. However, an implementation MUST 995 disclose the essence of each update method it includes, in a 996 comprehensible form such as natural language description, pseudocode, 997 or source code. An implementation MUST allow the operator to 998 discover, which update method is effective for any given interface, 999 either at runtime or from the system documentation. These 1000 requirements are necessary to enable the optimal (see Section 3.7) 1001 management of ANM timeout in a network segment. 1003 Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is 1004 unlikely, but possible, causing the advertised TS/PC number to be 1005 reused. Resolving this situation requires replacing all 1006 authentication keys of the involved interface. In addition to that, 1007 if the wrap was caused by a timestamp reaching its end of epoch, 1008 using this mechanism will be impossible for the involved interface 1009 until some different timestamp or update implementation method is 1010 used. 1012 5.2. Deriving ESAs from CSAs 1014 Neither receiving nor sending procedures work with the contents of 1015 interface's sequence of CSAs directly, both (Section 5.4 item 4 and 1016 Section 5.3 item 4 respectively) derive a sequence of ESAs from the 1017 sequence of CSAs and use the derived sequence (see Figure 1). There 1018 are two main goals achieved through this indirection: 1020 o Elimination of expired authentication keys and deduplication of 1021 security associations. This is done as early as possible to keep 1022 subsequent procedures focused on their respective tasks. 1024 o Maintenance of particular ordering within the derived sequence of 1025 ESAs. The ordering deterministically depends on the ordering 1026 within the interface's sequence of CSAs and the ordering within 1027 KeyChain sequence of each CSA. The particular correlation 1028 maintained by this procedure implements a concept of fair 1029 (independent of number of keys contained by each) competition 1030 between CSAs. 1032 The deriving procedure uses the following input arguments: 1034 o input sequence of CSAs 1036 o direction (sending or receiving) 1038 o current time (CT) 1040 The processing of input arguments begins with an empty output 1041 sequence of ESAs and consists of the following steps: 1043 1. Make a temporary copy of the input sequence of CSAs. 1045 2. Remove all expired authentication keys from each KeyChain 1046 sequence of the copy, that is, any keys such that: 1048 * for receiving: KeyStartAccept is greater than CT or 1049 KeyStopAccept is less than CT 1051 * for sending: KeyStartGenerate is greater than CT or 1052 KeyStopGenerate is less than CT 1054 Note well that there are no special exceptions. Remove all 1055 expired keys, even if there are no keys left after that (see 1056 Section 7.4). 1058 3. Use the copy to populate the output sequence of ESAs as follows: 1060 1. When the KeyChain sequence of the first CSA contains at least 1061 one key, use its first key to produce an ESA with fields set 1062 as follows: 1064 HashAlgo Set to HashAlgo of the current CSA. 1066 KeyID Set to LocalKeyID modulo 2^16 of the current 1067 key of the current CSA. 1069 AuthKeyOctets Set to AuthKeyOctets of the current key of the 1070 current CSA. 1072 Append this ESA to the end of the output sequence. 1074 2. When the KeyChain sequence of the second CSA contains at 1075 least one key, use its first key the same way and so forth 1076 until all first keys of the copy are processed. 1078 3. When the KeyChain sequence of the first CSA contains at least 1079 two keys, use its second key the same way. 1081 4. When the KeyChain sequence of the second CSA contains at 1082 least two keys, use its second key the same way and so forth 1083 until all second keys of the copy are processed. 1085 5. And so forth until all keys of all CSAs of the copy are 1086 processed, exactly once each. 1088 In the description above the ordinals ("first", "second", and so 1089 on) with regard to keys stand for an element position after the 1090 removal of expired keys, not before. For example, if a KeyChain 1091 sequence was { Ka, Kb, Kc, Kd } before the removal and became 1092 { Ka, Kd } after, then Ka would be the "first" element and Kd 1093 would be the "second". 1095 4. Deduplicate the ESAs in the output sequence, that is, wherever 1096 two or more ESAs exist that share the same (HashAlgo, KeyID, 1097 AuthKeyOctets) triplet value, remove all of these ESAs except the 1098 one closest to the beginning of the sequence. 1100 The resulting sequence will contain zero or more unique ESAs, ordered 1101 in a way deterministically correlated with ordering of CSAs within 1102 the original input sequence of CSAs and ordering of keys within each 1103 KeyChain sequence. This ordering maximizes the probability of having 1104 equal amount of keys per original CSA in any N first elements of the 1105 resulting sequence. Possible optimizations of this deriving 1106 procedure are outlined in Section 6.3. 1108 5.3. Updates to Packet Sending 1110 Perform the following authentication-specific processing after the 1111 instance of the original protocol considers an outgoing Babel packet 1112 ready for sending, but before the packet is actually sent (see 1113 Figure 1). After that send the packet regardless if the 1114 authentication-specific processing modified the outgoing packet or 1115 left it intact. 1117 1. If the current outgoing interface's sequence of CSAs is empty, 1118 finish authentication-specific processing and consider the packet 1119 ready for sending. 1121 2. Increment TS/PC number of the current outgoing interface as 1122 explained in Section 5.1. 1124 3. Add to the packet body (see the note at the end of this section) 1125 a TS/PC TLV with fields set as follows: 1127 Type Set to 11. 1129 Length Set to 6. 1131 PacketCounter Set to the current value of LocalPC variable of 1132 the current outgoing interface. 1134 Timestamp Set to the current value of LocalTS variable of 1135 the current outgoing interface. 1137 Note that the current step may involve byte order conversion. 1139 4. Derive a sequence of ESAs using procedure defined in Section 5.2 1140 with the current interface's sequence of CSAs as the input 1141 sequence of CSAs, the current time as CT and "sending" as the 1142 direction. Proceed to the next step even if the derived sequence 1143 is empty. 1145 5. Iterate over the derived sequence using its ordering. For each 1146 ESA add to the packet body (see the note at the end of this 1147 section) an HMAC TLV with fields set as follows: 1149 Type Set to 12. 1151 Length Set to 2 plus digest length of HashAlgo of the current 1152 ESA. 1154 KeyID Set to KeyID of the current ESA. 1156 Digest Size exactly equal to the digest length of HashAlgo of 1157 the current ESA. Pad (see Section 2.2) using the source 1158 address of the current packet (see Section 6.1). 1160 As soon as there are MaxDigestsOut HMAC TLVs added to the current 1161 packet body, immediately proceed to the next step. 1163 Note that the current step may involve byte order conversion. 1165 6. Increment the "Body length" field value of the current packet 1166 header by the total length of TS/PC and HMAC TLVs appended to the 1167 current packet body so far. 1169 Note that the current step may involve byte order conversion. 1171 7. Make a temporary copy of the current packet. 1173 8. Iterate over the derived sequence again, using the same order and 1174 number of elements. For each ESA (and respectively for each HMAC 1175 TLV recently appended to the current packet body) compute an HMAC 1176 result (see Section 2.4) using the temporary copy (not the 1177 original packet) as Text, HashAlgo of the current ESA as H, and 1178 AuthKeyOctets of the current ESA as K. Write the HMAC result to 1179 the Digest field of the current HMAC TLV (see Table 4) of the 1180 current packet (not the copy). 1182 9. After this point, allow no more changes to the current packet 1183 header and body and consider it ready for sending. 1185 Note that even when the derived sequence of ESAs is empty, the packet 1186 is sent anyway with only a TS/PC TLV appended to its body. Although 1187 such a packet would not be authenticated, the presence of the sole 1188 TS/PC TLV would indicate authentication key exhaustion to operators 1189 of neighbouring Babel speakers. See also Section 7.4. 1191 Also note that it is possible to place the authentication-specific 1192 TLVs in the packet's sequence of TLVs in a number of different valid 1193 ways so long as there is exactly one TS/PC TLV in the sequence and 1194 the ordering of HMAC TLVs relative to each other, as produced in step 1195 5 above, is preserved. 1197 For example, see Figure 2. The diagrams represent a Babel packet 1198 without (D1) and with (D2, D3, D4) authentication-specific TLVs. The 1199 optional trailing data block that is present in D1 is preserved in 1200 D2, D3, and D4. Indexing (1, 2, ..., n) of the HMAC TLVs means the 1201 order in which the sending procedure produced them (and respectively 1202 the HMAC results). In D2 the added TLVs are appended: the previously 1203 existing TLVs are followed by the TS/PC TLV, which is followed by the 1204 HMAC TLVs. In D3 the added TLVs are prepended: the TS/PC TLV is the 1205 first and is followed by the HMAC TLVs, which are followed by the 1206 previously existing TLVs. In D4 the added TLVs are intermixed with 1207 the previously existing TLVs and the TS/PC TLV is placed after the 1208 HMAC TLVs. All three packets meet the requirements above. 1210 Implementors SHOULD use appending (D2) for adding the authentication- 1211 specific TLVs to the sequence, this is expected to result in more 1212 straightforward implementation and troubleshooting in most use cases. 1214 5.4. Updates to Packet Receiving 1216 Perform the following authentication-specific processing after an 1217 incoming Babel packet is received from the local network stack, but 1218 before it is acted upon by the Babel protocol instance (see 1219 Figure 1). The final action conceptually depends not only upon the 1220 result of the authentication-specific processing, but also on the 1221 current value of RxAuthRequired parameter. Immediately after any 1222 processing step below accepts or refuses the packet, either deliver 1223 the packet to the instance of the original protocol (when the packet 1224 is accepted or RxAuthRequired is FALSE) or discard it (when the 1225 packet is refused and RxAuthRequired is TRUE). 1227 1. If the current incoming interface's sequence of CSAs is empty, 1228 accept the packet. 1230 2. If the current packet does not contain exactly one TS/PC TLV, 1231 refuse it. 1233 3. Perform a lookup in the ANM table for an entry having Interface 1234 equal to the current incoming interface and Source equal to the 1235 source address of the current packet. If such an entry does not 1236 exist, immediately proceed to the next step. Otherwise, compare 1237 the entry's LastTS and LastPC field values with Timestamp and 1238 PacketCounter values respectively of the TS/PC TLV of the 1239 packet. That is, refuse the packet, if at least one of the 1240 following two conditions is true: 1242 * Timestamp is less than LastTS 1243 * Timestamp is equal to LastTS and PacketCounter is not greater 1244 than LastPC 1246 Note that the current step may involve byte order conversion. 1248 4. Derive a sequence of ESAs using procedure defined in Section 5.2 1249 with the current interface's sequence of CSAs as the input 1250 sequence of CSAs, current time as CT and "receiving" as the 1251 direction. If the derived sequence is empty, refuse the packet. 1253 5. Make a temporary copy of the current packet. 1255 6. Pad (see Section 2.2) every HMAC TLV present in the temporary 1256 copy (not the original packet) using the source address of the 1257 original packet. 1259 7. Iterate over all the HMAC TLVs of the original input packet (not 1260 the copy) using their order of appearance in the packet. For 1261 each HMAC TLV look up all ESAs in the derived sequence such that 1262 2 plus digest length of HashAlgo of the ESA is equal to Length 1263 of the TLV and KeyID of the ESA is equal to value of KeyID of 1264 the TLV. Iterate over these ESAs in the relative order of their 1265 appearance on the full sequence of ESAs. Note that nesting the 1266 iterations the opposite way (over ESAs, then over HMAC TLVs) 1267 would be wrong. 1269 For each of these ESAs compute an HMAC result (see Section 2.4) 1270 using the temporary copy (not the original packet) as Text, 1271 HashAlgo of the current ESA as H, and AuthKeyOctets of the 1272 current ESA as K. If the current HMAC result exactly matches the 1273 contents of Digest field of the current HMAC TLV, immediately 1274 proceed to the next step. Otherwise, if the number of HMAC 1275 computations done for the current packet so far is equal to 1276 MaxDigestsIn, immediately proceed to the next step. Otherwise 1277 follow the normal order of iterations. 1279 Note that the current step may involve byte order conversion. 1281 8. Refuse the input packet unless there was a matching HMAC result 1282 in the previous step. 1284 9. Modify the ANM table, using the same index as for the entry 1285 lookup above, to contain an entry with LastTS set to the value 1286 of Timestamp and LastPC set to the value of PacketCounter fields 1287 of the TS/PC TLV of the current packet. That is, either add a 1288 new ANM table entry or update the existing one, depending on the 1289 result of the entry lookup above. Reset the entry's aging timer 1290 to the current value of ANM timeout. 1292 Note that the current step may involve byte order conversion. 1294 10. Accept the input packet. 1296 An implementation SHOULD before the authentication-specific 1297 processing above perform those basic procedures of the original 1298 protocol that don't take any protocol actions upon the contents of 1299 the packet but discard it unless the packet is sufficiently well- 1300 formed for further processing. Although exact composition of such 1301 procedures belongs to the scope of the original protocol, it seems 1302 reasonable to state that a packet SHOULD be discarded early, 1303 regardless if any authentication-specific processing is due, unless 1304 its source address conforms to Section 3.1 of [BABEL] and is not the 1305 receiving speaker's own address (see item (e) of Section 9). 1307 Note that RxAuthRequired affects only the final action, but not the 1308 defined flow of authentication-specific processing. The purpose of 1309 this is to preserve authentication-specific processing feedback (such 1310 as log messages and event counters updates) even with RxAuthRequired 1311 set to FALSE. This allows an operator to predict the effect of 1312 changing RxAuthRequired from FALSE to TRUE during a migration 1313 scenario (Section 7.3) implementation. 1315 5.5. Authentication-Specific Statistics Maintenance 1317 A Babel speaker implementing this mechanism SHOULD maintain a set of 1318 counters for the following events, per protocol instance and per 1319 interface: 1321 a. Sending of an unauthenticated Babel packet through an interface 1322 having an empty sequence of CSAs (Section 5.3 item 1). 1324 b. Sending of an unauthenticated Babel packet with a TS/PC TLV but 1325 without any HMAC TLVs due to an empty derived sequence of ESAs 1326 (Section 5.3 item 4). 1328 c. Sending of an authenticated Babel packet containing both TS/PC 1329 and HMAC TLVs (Section 5.3 item 9). 1331 d. Accepting of a Babel packet received through an interface having 1332 an empty sequence of CSAs (Section 5.4 item 1). 1334 e. Refusing of a received Babel packet due to an empty derived 1335 sequence of ESAs (Section 5.4 item 4). 1337 f. Refusing of a received Babel packet that does not contain exactly 1338 one TS/PC TLV (Section 5.4 item 2). 1340 g. Refusing of a received Babel packet due to the TS/PC TLV failing 1341 the ANM table check (Section 5.4 item 3). In the view of future 1342 extensions this event SHOULD leave out some small amount, per 1343 current (Interface, Source, LastTS, LastPC) tuple, of the packets 1344 refused due to Timestamp value being equal to LastTS and 1345 PacketCounter value being equal to LastPC. 1347 h. Refusing of a received Babel packet missing any HMAC TLVs 1348 (Section 5.4 item 8). 1350 i. Refusing of a received Babel packet due to none of the processed 1351 HMAC TLVs passing the ESA check (Section 5.4 item 8). 1353 j. Accepting of a received Babel packet having both TS/PC and HMAC 1354 TLVs (Section 5.4 item 10). 1356 k. Delivery of a refused packet to the instance of the original 1357 protocol due to RxAuthRequired parameter set to FALSE. 1359 Note that terms "accepting" and "refusing" are used in the sense of 1360 the receiving procedure, that is, "accepting" does not mean a packet 1361 delivered to the instance of the original protocol purely because the 1362 RxAuthRequired parameter is set to FALSE. Event counters readings 1363 SHOULD be available to the operator at runtime. 1365 6. Implementation Notes 1367 6.1. Source Address Selection for Sending 1369 Section 3.1 of [BABEL] allows for exchange of protocol datagrams 1370 using IPv4 or IPv6 or both. The source address of the datagram is a 1371 unicast (link-local in the case of IPv6) address. Within an address 1372 family used by a Babel speaker there may be more than one addresses 1373 eligible for the exchange and assigned to the same network interface. 1374 The original specification considers this case out of scope and 1375 leaves it up to the speaker's network stack to select one particular 1376 address as the datagram source address. But the sending procedure 1377 requires (Section 5.3 item 5) exact knowledge of packet source 1378 address for proper padding of HMAC TLVs. 1380 As long as a network interface has more than one addresses eligible 1381 for the exchange within the same address family, the Babel speaker 1382 SHOULD internally choose one of those addresses for Babel packet 1383 sending purposes and make this choice to both the sending procedure 1384 and the network stack (see Figure 1). Wherever this requirement 1385 cannot be met, this limitation MUST be clearly stated in the system 1386 documentation to allow an operator to plan network address management 1387 accordingly. 1389 6.2. Output Buffer Management 1391 An instance of the original protocol buffers produced TLVs until the 1392 buffer becomes full or a delay timer has expired. This is performed 1393 independently for each Babel interface with each buffer sized 1394 according to the interface MTU (see Sections 3.1 and 4 of [BABEL]). 1396 Since TS/PC and HMAC TLVs and any other TLVs, in the first place 1397 those of the original protocol, share the same packet space (see 1398 Figure 2) and respectively the same buffer space, a particular 1399 portion of each interface buffer needs to be reserved for 1 TS/PC TLV 1400 and up to MaxDigestsOut HMAC TLVs. The amount (R) of this reserved 1401 buffer space is calculated as follows: 1403 R = St + MaxDigestsOut * Sh = 1404 = 8 + MaxDigestsOut * (4 + Lmax) 1406 St Is the size of a TS/PC TLV. 1408 Sh Is the size of an HMAC TLV. 1410 Lmax Is the maximum digest length in octets possible for a 1411 particular interface. It SHOULD be calculated based on 1412 particular interface's sequence of CSAs, but MAY be taken as 1413 the maximum digest length supported by particular 1414 implementation. 1416 An implementation allowing for per-interface value of MaxDigestsOut 1417 or Lmax has to account for different value of R across different 1418 interfaces, even having the same MTU. An implementation allowing for 1419 runtime change of the value of R (due to MaxDigestsOut or Lmax) has 1420 to take care of the TLVs already buffered by the time of the change, 1421 especially when the value of R increases. 1423 The maximum safe value of MaxDigestsOut parameter depends on the 1424 interface MTU and maximum digest length used. In general, at least 1425 200-300 octets of a Babel packet should be always available to data 1426 other than TS/PC and HMAC TLVs. An implementation following the 1427 requirements of Section 4 of [BABEL] would send packets sized 512 1428 octets or larger. If, for example, the maximum digest length is 64 1429 octets and MaxDigestsOut value is 4, the value of R would be 280, 1430 leaving less than a half of a 512-octet packet for any other TLVs. 1431 As long as the interface MTU is larger or digest length is smaller, 1432 higher values of MaxDigestsOut can be used safely. 1434 6.3. Optimizations of ESAs Deriving 1436 The following optimizations of the ESAs deriving procedure can reduce 1437 amount of CPU time consumed by authentication-specific processing, 1438 preserving an implementation's effective behaviour. 1440 a. The most straightforward implementation would treat the deriving 1441 procedure as a per-packet action. But since the procedure is 1442 deterministic (its output depends on its input only), it is 1443 possible to significantly reduce the number of times the 1444 procedure is performed. 1446 The procedure would obviously return the same result for the same 1447 input arguments (sequence of CSAs, direction, CT) values. 1448 However, it is possible to predict when the result will remain 1449 the same even for a different input. That is, when the input 1450 sequence of CSAs and the direction both remain the same but CT 1451 changes, the result will remain the same as long as CT's order on 1452 the time axis (relative to all critical points of the sequence of 1453 CSAs) remains unchanged. Here, the critical points are 1454 KeyStartAccept and KeyStopAccept (for the "receiving" direction) 1455 and KeyStartGenerate and KeyStopGenerate (for the "sending" 1456 direction) of all keys of all CSAs of the input sequence. In 1457 other words, in this case the result will remain the same as long 1458 as both none of the active keys expire and none of the inactive 1459 keys enter into operation. 1461 An implementation optimized this way would perform the full 1462 deriving procedure for a given (interface, direction) pair only 1463 after an operator's change to the interface's sequence of CSAs or 1464 after reaching one of the critical points mentioned above. 1466 b. Considering that the sending procedure iterates over at most 1467 MaxDigestsOut elements of the derived sequence of ESAs 1468 (Section 5.3 item 5), there would be little sense in the case of 1469 "sending" direction in returning more than MaxDigestsOut ESAs in 1470 the derived sequence. Note that a similar optimization would be 1471 relatively difficult in the case of "receiving" direction, since 1472 the number of ESAs actually used in examining a particular 1473 received packet (not to be confused with the number of HMAC 1474 computations) depends on additional factors besides just 1475 MaxDigestsIn. 1477 6.4. Security Associations Duplication 1479 This specification defines three data structures as finite sequences: 1480 a KeyChain sequence, an interface's sequence of CSAs, and a sequence 1481 of ESAs. There are associated semantics to take into account during 1482 implementation, in that the same element can appear multiple times at 1483 different positions of the sequence. In particular, none of CSA 1484 structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets) 1485 alone or in a combination has to be unique within a given CSA, or 1486 within a given sequence of CSAs, or within all sequences of CSAs of a 1487 Babel speaker. 1489 In the CSA space defined this way, for any two authentication keys 1490 their one field (in)equality would not imply their another field 1491 (in)equality. In other words, it is acceptable to have more than one 1492 authentication key with the same LocalKeyID or the same AuthKeyOctets 1493 or both at a time. It is a conscious design decision that CSA 1494 semantics allow for duplication of security associations. 1495 Consequently, ESA semantics allow for duplication of intermediate 1496 ESAs in the sequence until the explicit deduplication (Section 5.2 1497 item 4). 1499 One of the intentions of this is to define the security association 1500 management in a way that allows the addressing of some specifics of 1501 Babel as a mesh routing protocol. For example, a system operator 1502 configuring a Babel speaker to participate in more than one 1503 administrative domain could find each domain using its own 1504 authentication key (AuthKeyOctets) under the same LocalKeyID value, 1505 e.g., a "well-known" or "default" value like 0 or 1. Since 1506 reconfiguring the domains to use distinct LocalKeyID values isn't 1507 always feasible, the multi-domain Babel speaker using several 1508 distinct authentication keys under the same LocalKeyID would make a 1509 valid use case for such duplication. 1511 Furthermore, if in this situation the operator decided to migrate one 1512 of the domains to a different LocalKeyID value in a seamless way, 1513 respective Babel speakers would use the same authentication key 1514 (AuthKeyOctets) under two different LocalKeyID values for the time of 1515 the transition (see also item (f) of Section 9). This would make a 1516 similar use case. 1518 Another intention of this design decision is to decouple security 1519 association management from authentication key management as much as 1520 possible, so that the latter, be it manual keying or a key management 1521 protocol, could be designed and implemented independently (as 1522 respective reasoning made in Section 3.1 of [RIP2-AUTH] still 1523 applies). This way the additional key management constraints, if 1524 any, would remain out of scope of this authentication mechanism. A 1525 similar thinking justifies LocalKeyID field having bit length in ESA 1526 structure definition, but not in that of CSA. 1528 7. Network Management Aspects 1530 7.1. Backward Compatibility 1532 Support of this mechanism is optional, it does not change the default 1533 behaviour of a Babel speaker and causes no compatibility issues with 1534 speakers properly implementing the original Babel specification. 1535 Given two Babel speakers, one implementing this mechanism and 1536 configured for authenticated exchange (A) and another not 1537 implementing it (B), these would not distribute routing information 1538 uni-directionally or form a routing loop or experience other protocol 1539 logic issues specific purely to the use of this mechanism. 1541 The Babel design requires a bi-directional neighbour reachability 1542 condition between two given speakers for a successful exchange of 1543 routing information. Apparently, in the case above neighbour 1544 reachability would be uni-directional. Presence of TS/PC and HMAC 1545 TLVs in Babel packets sent by A would be transparent to B. But lack 1546 of authentication data in Babel packets send by B would make them 1547 effectively invisible to the instance of the original protocol of A. 1548 Uni-directional links are not specific to use of this mechanism, they 1549 naturally exist on their own and are properly detected and coped with 1550 by the original protocol (see Section 3.4.2 of [BABEL]). 1552 7.2. Multi-Domain Authentication 1554 The receiving procedure treats a packet as authentic as soon as one 1555 of its HMAC TLVs passes the check against the derived sequence of 1556 ESAs. This allows for packet exchange authenticated with multiple 1557 (hash algorithm, authentication key) pairs simultaneously, in 1558 combinations as arbitrary as permitted by MaxDigestsIn and 1559 MaxDigestsOut. 1561 For example, consider three Babel speakers with one interface each, 1562 configured with the following CSAs: 1564 o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key 1565 SK2) 1567 o speaker B: (hash algorithm H1; key SK1) 1569 o speaker C: (hash algorithm H1; key SK2) 1571 Packets sent by A would contain 2 HMAC TLVs each, packets sent by B 1572 and C would contain 1 HMAC TLV each. A and B would authenticate the 1573 exchange between themselves using H1 and SK1; A and C would use H1 1574 and SK2; B and C would discard each other's packets. 1576 Consider a similar set of speakers configured with different CSAs: 1578 o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key 1579 SK4) 1581 o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys 1582 SK5 and SK6) 1584 o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm 1585 H5, key SK8) 1587 Packets sent by D would contain 2 HMAC TLVs each, packets sent by E 1588 and F would contain 3 HMAC TLVs each. D and E would authenticate the 1589 exchange between themselves using H2 and SK3; D and F would use H3 1590 and SK4; E and F would discard each other's packets. The 1591 simultaneous use of H4, SK5, and SK6 by E, as well as use of SK7, H5, 1592 and SK8 by F (for their own purposes) would remain insignificant to 1593 A. 1595 An operator implementing a multi-domain authentication should keep in 1596 mind that values of MaxDigestsIn and MaxDigestsOut may be different 1597 both within the same Babel speaker and across different speakers. 1598 Since the minimum value of both parameters is 2 (see Section 3.4 and 1599 Section 3.5), when more than 2 authentication domains are configured 1600 simultaneously it is advised to confirm that every involved speaker 1601 can handle sufficient number of HMAC results for both sending and 1602 receiving. 1604 The recommended method of Babel speaker configuration for multi- 1605 domain authentication is not only using a different authentication 1606 key for each domain, but also using a separate CSA for each domain, 1607 even when hash algorithms are the same. This allows for fair 1608 competition between CSAs and sometimes limits the consequences of a 1609 possible misconfiguration to the scope of one CSA. See also item (f) 1610 of Section 9. 1612 7.3. Migration to and from Authenticated Exchange 1614 It is common in practice to consider a migration to authenticated 1615 exchange of routing information only after the network has already 1616 been deployed and put to an active use. Performing the migration in 1617 a way without regular traffic interruption is typically demanded, and 1618 this specification allows a smooth migration using the RxAuthRequired 1619 interface parameter defined in Section 3.1. This measure is similar 1620 to the "transition mode" suggested in Section 5 of [OSPF3-AUTH]. 1622 An operator performing the migration needs to arrange configuration 1623 changes as follows: 1625 1. Decide on particular hash algorithm(s) and key(s) to be used. 1627 2. Identify all speakers and their involved interfaces that need to 1628 be migrated to authenticated exchange. 1630 3. For each of the speakers and the interfaces to be reconfigured 1631 first set RxAuthRequired parameter to FALSE, then configure 1632 necessary CSA(s). 1634 4. Examine the speakers to confirm that Babel packets are 1635 successfully authenticated according to the configuration 1636 (supposedly, through examining ANM table entries and 1637 authentication-specific statistics, see Figure 1) and address any 1638 discrepancies before proceeding further. 1640 5. For each of the speakers and the reconfigured interfaces set the 1641 RxAuthRequired parameter to TRUE. 1643 Likewise, temporarily setting RxAuthRequired to FALSE can be used to 1644 migrate smoothly from an authenticated packet exchange back to 1645 unauthenticated one. 1647 7.4. Handling of Authentication Keys Exhaustion 1649 This specification employs a common concept of multiple authenticaion 1650 keys co-existing for a given interface, with two independent lifetime 1651 ranges associated with each key (one for sending and another for 1652 receiving). It is typically recommended to configure the keys using 1653 finite lifetimes, adding new keys before the old keys expire. 1654 However, it is obviously possible for all keys to expire for a given 1655 interface (for sending or receiving or both). Possible ways of 1656 addressing this situation raise their own concerns: 1658 o Automatic switching to unauthenticated protocol exchange. This 1659 behaviour invalidates the initial purposes of authentication and 1660 is commonly viewed as "unacceptable" ([RIP2-AUTH] Section 5.1, 1661 [OSPF2-AUTH] Section 3.2, [OSPF3-AUTH] Section 3, [OSPF3-AUTH-BIS] 1662 Section 3). 1664 o Stopping routing information exchange over the interface. This 1665 behaviour is likely to impact regular traffic routing and is 1666 commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], 1667 [OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this 1668 regard. 1670 o Use of the "most recently expired" key over its intended lifetime 1671 range. This behaviour is recommended for implementation in 1672 [RIP2-AUTH], [OSPF2-AUTH], [OSPF3-AUTH], but not in 1674 [OSPF3-AUTH-BIS]. The use may become a problem due to an offline 1675 cryptographic attack (see item (f) of Section 9) or a compromise 1676 of the key. In addition, telling a recently expired key from a 1677 key never ever been in a use may be impossible after a router 1678 restart. 1680 Design of this mechanism prevents the automatic switching to 1681 unauthenticated exchange and is consistent with similar 1682 authentication mechanisms in this regard. But since the best choice 1683 between two other options depends on local site policy, this decision 1684 is left up to the operator rather than the implementor (in a way 1685 resembling the "fail secure" configuration knob described in Section 1686 5.1 of [RIP2-AUTH]). 1688 Although the deriving procedure does not allow for any exceptions in 1689 expired keys filtering (Section 5.2 item 2), the operator can 1690 trivially enforce one of the two remaining behaviour options through 1691 local key management procedures. In particular, when using the key 1692 over its intended lifetime is more preferred than regular traffic 1693 disruption, the operator would explicitly leave the old key expiry 1694 time open until the new key is added to the router configuration. In 1695 the opposite case the operator would always configure the old key 1696 with a finite lifetime and bear associated risks. 1698 8. Implementation Status 1700 [RFC Editor: before publication please remove this section and the 1701 reference to [RFC6982], along the offered experiment of which this 1702 section exists to assist document reviewers.] 1704 At the time of this writing the original Babel protocol is available 1705 in two free, production-quality implementations, both of which 1706 support IPv4 and IPv6 routing but exchange Babel packets using IPv6 1707 only: 1709 o The "standalone" babeld, a BSD-licensed software with source code 1710 publicly available [1]. 1712 That implementation does not support this authentication 1713 mechanism. 1715 o The integrated babeld component of Quagga-RE, a work derived from 1716 Quagga routing protocol suite, a GPL-lisensed software with source 1717 code publicly available [2]. 1719 That implementation supports this authentication mechanism as 1720 defined in revision 09 of this document. It supports both 1721 mandatory-to-implement hash algorithms (RIPEMD-160 and SHA-1) and 1722 a few additional algorithms (SHA-224, SHA-256, SHA-384, SHA-512 1723 and Whirlpool). It does not support more than one link-local IPv6 1724 address per interface. It does not distinguish refused replayed 1725 packets for purpose of logging in the sense of item (g) of 1726 Section 5.5 and does not check the packet source address before 1727 the authentication-specific processing as suggested in 1728 Section 5.4. It implements authentication-specific parameters, 1729 data structures and methods as follows (whether a parameter can be 1730 "changed at runtime", it is done by means of CLI and can also be 1731 set in a configuration file): 1733 * MaxDigestsIn value is fixed to 4. 1735 * MaxDigestsOut value is fixed to 4. 1737 * RxAuthRequired value is specific to each interface and can be 1738 changed at runtime. 1740 * ANM Table contents is not retained across speaker restarts, can 1741 be retrieved and reset (all entries at once) by means of CLI. 1743 * ANM Timeout value is specific to the whole protocol instance, 1744 has a default value of 300 seconds and can be changed at 1745 runtime. 1747 * Ordering of elements within each interface's sequence of CSAs 1748 is arbitrary as set by operator at runtime. CSAs are 1749 implemented to refer to existing key chain syntax items. 1750 Elements of an interface's sequence of CSAs are constrained to 1751 be unique reference-wise, but not contents-wise, that is, it is 1752 possible to duplicate security associations using a different 1753 key chain name to contain the same keys. 1755 * Ordering of elements within each KeyChain sequence is fixed to 1756 the sort order of LocalKeyID. LocalKeyID is constrained to be 1757 unique within each KeyChain sequence. 1759 * TS/PC number updates method can be configured at runtime for 1760 the whole protocol instance to one of two methods standing for 1761 items (a) and (b) of Section 5.1. The default method is (b). 1763 * Most of the authentication-specific statistics counters listed 1764 in Section 5.5 are implemented (per protocol instance and per 1765 each interface) and their readings are available by means of 1766 CLI with an option to log respective events into a file. 1768 No other implementations of this authentication mechanism are 1769 known to exist, thus interoperability can only be assessed on 1770 paper. The only existing implementation has been tested to be 1771 fully compatible with itself regardless of a speaker CPU 1772 endianness. 1774 9. Security Considerations 1776 Use of this mechanism implies requirements common to a use of shared 1777 authentication keys, including, but not limited to: 1779 o holding the keys secret, 1781 o including sufficient amounts of random bits into each key, 1783 o rekeying on a regular basis, and 1785 o never reusing a used key for a different purpose 1787 That said, proper design and implementation of a key management 1788 policy is out of scope of this work. Many publications on this 1789 subject exist and should be used for this purpose (BCP 107 [RFC4107], 1790 BCP 132 [RFC4962], and [RFC6039] may be suggested as starting 1791 points). 1793 It is possible for a network that exercises authentication keys 1794 rollover to experience accidental expiration of all the keys for a 1795 network interface as discussed at greater length in Section 7.4. 1796 With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in 1797 such an event the Babel speaker MUST send a "last key expired" 1798 notification to the operator (e.g. via syslog, SNMP, and/or other 1799 implementation-specific means), most likely in relation to the item 1800 (b) of Section 5.5. Also, any actual occurrence of an authentication 1801 key expiration MUST cause a security event to be logged by the 1802 implementation. The log item MUST include at least a note that the 1803 authentication key has expired, the Babel routing protocol 1804 instance(s) affected, the network interface(s) affected, the 1805 LocalKeyID that is affected, and the current date/time. Operators 1806 are encouraged to check such logs as an operational security 1807 practice. 1809 Considering particular attacks being in-scope or out of scope on one 1810 hand and measures taken to protect against particular in-scope 1811 attacks on the other, the original Babel protocol and this 1812 authentication mechanism are in line with similar datagram-based 1813 routing protocols and their respective mechanisms. In particular, 1814 the primary concerns addressed are: 1816 a. Peer Entity Authentication 1818 The Babel speaker authentication mechanism defined herein is 1819 believed to be as strong as is the class itself that it belongs 1820 to. This specification is built on fundamental concepts 1821 implemented for authentication of similar routing protocols: per- 1822 packet authentication, use of HMAC construct, use of shared keys. 1823 Although this design approach does not address all possible 1824 concerns, it is so far known to be sufficient for most practical 1825 cases. 1827 b. Data Integrity 1829 Meaningful parts of a Babel datagram are the contents of the 1830 Babel packet (in the definition of Section 4.2 of [BABEL]) and 1831 the source address of the datagram (Section 3.5.3 ibid.). This 1832 mechanism authenticates both parts using the HMAC construct, so 1833 that making any meaningful change to an authenticated packet 1834 after it has been emitted by the sender should be as hard as 1835 attacking the HMAC construct itself or successfully recovering 1836 the authentication key. 1838 Note well that any trailing data of the Babel datagram is not 1839 meaningful in the scope of the original specification and does 1840 not belong to the Babel packet. Integrity of the trailing data 1841 is respectively not protected by this mechanism. At the same 1842 time, although any TLV extra data is also not meaningful in the 1843 same scope, its integrity is protected, since this extra data is 1844 a part of the Babel packet (see Figure 2). 1846 c. Denial of Service 1848 Proper deployment of this mechanism in a Babel network 1849 significantly increases the efforts required for an attacker to 1850 feed arbitrary Babel PDUs into protocol exchange (with an intent 1851 of attacking a particular Babel speaker or disrupting exchange of 1852 regular traffic in a routing domain). It also protects the 1853 neighbour table from being flooded with forged speaker entries. 1855 At the same time, this protection comes with a price of CPU time 1856 being spent on HMAC computations. This may be a concern for low- 1857 performance CPUs combined with high-speed interfaces, as 1858 sometimes seen in embedded systems and hardware routers. The 1859 MaxDigestsIn parameter, which is used to limit the maximum amount 1860 of CPU time spent on a single received Babel packet, addresses 1861 this concern to some extent. 1863 d. Reflection Attacks 1865 Given the approach discussed in item (b), the only potential 1866 reflection attack on this mechanism could be replaying exact 1867 copies of Babel packets back to the sender from the same source 1868 address. The mitigation in this case is straightforward and is 1869 discussed in Section 5.4. 1871 The following in-scope concern is only partially addressed: 1873 e. Replay Attacks 1875 This specification establishes a basic replay protection measure 1876 (see Section 3.6), defines a timeout parameter affecting its 1877 strength (see Section 3.7), and outlines implementation methods 1878 also affecting protection strength in several ways (see 1879 Section 5.1). The implementor's choice of the timeout value and 1880 particular implementation methods may be suboptimal due to, for 1881 example, insufficient hardware resources of the Babel speaker. 1882 Furthermore, it may be possible that an operator configures the 1883 timeout and the methods to address particular local specifics and 1884 this further weakens the protection. An operator concerned about 1885 replay attack protection strength should understand these factors 1886 and their meaning in a given network segment. 1888 That said, a particular form of replay attack on this mechanism 1889 remains possible anyway. Whether there are two or more network 1890 segments using the same CSA and there is an adversary that 1891 captures Babel packets on one segment and replays on another (and 1892 vice versa due to the bi-directional reachability requirement for 1893 neighbourship), some of the speakers on one such segment will 1894 detect the "virtual" neighbours from another and may prefer them 1895 for some destinations. This applies even more so as Babel 1896 doesn't require a common pre-configured network prefix between 1897 neighbours. 1899 A reliable solution to this particular problem, which Section 4.5 1900 of [RFC7186] discusses as well, is not currently known. It is 1901 recommended that the operators use distinct CSAs for distinct 1902 network segments. 1904 The following in-scope concerns are not addressed: 1906 f. Offline Cryptographic Attacks 1908 This mechanism is obviously subject to offline cryptographic 1909 attacks. As soon as an attacker has obtained a copy of an 1910 authenticated Babel packet of interest (which gets easier to do 1911 in wireless networks), he has got all the parameters of the 1912 authentication-specific processing performed by the sender, 1913 except authentication key(s) and choice of particular hash 1914 algorithm(s). Since digest lengths of common hash algorithms are 1915 well-known and can be matched with those seen in the packet, 1916 complexity of this attack is essentially that of the 1917 authentication key attack. 1919 Viewing the cryptographic strength of particular hash algorithms 1920 as a concern of its own, the main practical means of resisting 1921 offline cryptographic attacks on this mechanism are periodic 1922 rekeying and use of strong keys with a sufficient number of 1923 random bits. 1925 It is important to understand that in the case of multiple keys 1926 being used within single interface (for a multi-domain 1927 authentication or during a key rollover) the strength of the 1928 combined configuration would be that of the weakest key, since 1929 only one successful HMAC test is required for an authentic 1930 packet. Operators concerned about offline cryptographic attacks 1931 should enforce the same strength policy for all keys used for a 1932 given interface. 1934 Note that a special pathological case is possible with this 1935 mechanism. Whenever two or more authentication keys are 1936 configured for a given interface such that all keys share the 1937 same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 1938 2^16 is different for each key, these keys will not be treated as 1939 duplicate (Section 5.2 item 4), but an HMAC result computed for a 1940 given packet will be the same for each of these keys. In the 1941 case of sending procedure this can produce multiple HMAC TLVs 1942 with exactly the same value of the Digest field, but different 1943 values of KeyID field. In this case the attacker will see that 1944 the keys are the same, even without the knowledge of the key 1945 itself. Reuse of authentication keys is not the intended use 1946 case of this mechanism and should be strongly avoided. 1948 g. Non-repudiation 1950 This specification relies on a use of shared keys. There is no 1951 timestamp infrastructure and no key revocation mechanism defined 1952 to address a shared key compromise. Establishing the time that a 1953 particular authentic Babel packet was generated is thus not 1954 possible. Proving that a particular Babel speaker had actually 1955 sent a given authentic packet is also impossible as soon as the 1956 shared key is claimed compromised. Even with the shared key not 1957 being compromised, reliably identifying the speaker that had 1958 actually sent a given authentic Babel packet is not possible any 1959 better than proving the speaker belongs to the group sharing the 1960 key (any of the speakers sharing a key can impose any other 1961 speaker sharing the same key). 1963 h. Confidentiality Violations 1965 The original Babel protocol does not encrypt any of the 1966 information contained in its packets. The contents of a Babel 1967 packet is trivial to decode, revealing network topology details. 1968 This mechanism does not improve this situation in any way. Since 1969 routing protocol messages are not the only kind of information 1970 subject to confidentiality concerns, a complete solution to this 1971 problem is likely to include measures based on the channel 1972 security model, such as IPSec and WPA2 at the time of this 1973 writing. 1975 i. Key Management 1977 Any authentication key exchange/distribution concerns are left 1978 out of scope. However, the internal representation of 1979 authentication keys (see Section 3.8) allows for diverse key 1980 management means, manual configuration in the first place. 1982 j. Message Deletion 1984 Any message deletion attacks are left out of scope. Since a 1985 datagram deleted by an attacker cannot be distinguished from a 1986 datagram naturally lost in transmission and since datagram-based 1987 routing protocols are designed to withstand a certain loss of 1988 packets, the currently established practice is treating 1989 authentication purely as a per-packet function without any added 1990 detection of lost packets. 1992 10. IANA Considerations 1994 [RFC Editor: please do not remove this section.] 1996 At the time of this publication Babel TLV Types namespace did not 1997 have an IANA registry. TLV types 11 and 12 were assigned (see 1998 Table 1) to the TS/PC and HMAC TLV types by Juliusz Chroboczek, 1999 designer of the original Babel protocol. Therefore, this document 2000 has no IANA actions. 2002 11. Acknowledgements 2004 Thanks to Randall Atkinson and Matthew Fanto for their comprehensive 2005 work on [RIP2-AUTH] that initiated a series of publications on 2006 routing protocols authentication, including this one. This 2007 specification adopts many concepts belonging to the whole series. 2009 Thanks to Juliusz Chroboczek, Gabriel Kerneis, and Matthieu Boutier. 2010 This document incorporates many technical and editorial corrections 2011 based on their feedback. Thanks to all contributors to Babel, 2012 because this work would not be possible without the prior works. 2013 Thanks to Dominic Mulligan for editorial proofreading of this 2014 document. Thanks to Riku Hietamaki for suggesting the test vectors 2015 section. 2017 Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen 2018 Farrell for providing (in chronological order) valuable feedback on 2019 draft versions of this document. 2021 Thanks to Jim Gettys and Dave Taht for developing CeroWrt wireless 2022 router project and collaborating on many integration issues. A 2023 practical need for Babel authentication emerged during a research 2024 based on CeroWrt that eventually became the very first use case of 2025 this mechanism. 2027 Thanks to Kunihiro Ishiguro and Paul Jakma for establishing GNU Zebra 2028 and Quagga routing software projects respectively. Thanks to Werner 2029 Koch, the author of Libgcrypt. The very first implementation of this 2030 mechanism was made on base of Quagga and Libgcrypt. 2032 This document was produced using the xml2rfc ([RFC2629]) authoring 2033 tool. 2035 12. References 2037 12.1. Normative References 2039 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2040 Hashing for Message Authentication", RFC 2104, 2041 February 1997. 2043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2044 Requirement Levels", BCP 14, RFC 2119, March 1997. 2046 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2047 Architecture", RFC 4291, February 2006. 2049 [FIPS-198] 2050 US National Institute of Standards & Technology, "The 2051 Keyed-Hash Message Authentication Code (HMAC)", FIPS 2052 PUB 198-1, July 2008. 2054 [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 2055 April 2011. 2057 12.2. Informative References 2059 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2060 June 1999. 2062 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2063 and M. Carney, "Dynamic Host Configuration Protocol for 2064 IPv6 (DHCPv6)", RFC 3315, July 2003. 2066 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 2067 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 2069 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 2070 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 2071 Option", RFC 4030, March 2005. 2073 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 2074 Key Management", BCP 107, RFC 4107, June 2005. 2076 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 2077 Hashes in Internet Protocols", RFC 4270, November 2005. 2079 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2080 December 2005. 2082 [RIP2-AUTH] 2083 Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 2084 Authentication", RFC 4822, February 2007. 2086 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 2087 Authorization, and Accounting (AAA) Key Management", 2088 BCP 132, RFC 4962, July 2007. 2090 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2091 Aboba, "Dynamic Authorization Extensions to Remote 2092 Authentication Dial In User Service (RADIUS)", RFC 5176, 2093 January 2008. 2095 [ISIS-AUTH-A] 2096 Li, T. and R. Atkinson, "IS-IS Cryptographic 2097 Authentication", RFC 5304, October 2008. 2099 [ISIS-AUTH-B] 2100 Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 2101 and M. Fanto, "IS-IS Generic Cryptographic 2102 Authentication", RFC 5310, February 2009. 2104 [OSPF2-AUTH] 2105 Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 2106 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 2107 Authentication", RFC 5709, October 2009. 2109 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 2110 with Existing Cryptographic Protection Methods for Routing 2111 Protocols", RFC 6039, October 2010. 2113 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 2114 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 2115 RFC 6151, March 2011. 2117 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 2118 Considerations for the SHA-0 and SHA-1 Message-Digest 2119 Algorithms", RFC 6194, March 2011. 2121 [OSPF3-AUTH] 2122 Bhatia, M., Manral, V., and A. Lindem, "Supporting 2123 Authentication Trailer for OSPFv3", RFC 6506, 2124 February 2012. 2126 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 2127 Considerations for Protocol Extensions", RFC 6709, 2128 September 2012. 2130 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2131 Code: The Implementation Status Section", RFC 6982, 2132 July 2013. 2134 [I-D.chroboczek-babel-extension-mechanism] 2135 Chroboczek, J., "Extension Mechanism for the Babel Routing 2136 Protocol", draft-chroboczek-babel-extension-mechanism-00 2137 (work in progress), June 2013. 2139 [OSPF3-AUTH-BIS] 2140 Bhatia, M., Manral, V., and A. Lindem, "Supporting 2141 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 2143 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 2144 Protection for the Neighborhood Discovery Protocol (NHDP) 2145 and Optimized Link State Routing Protocol Version 2 2146 (OLSRv2)", RFC 7183, April 2014. 2148 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 2149 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 2150 April 2014. 2152 URIs 2154 [1] 2156 [2] 2158 Appendix A. Figures and Tables 2160 +-------------------------------------------------------------+ 2161 | authentication-specific statistics | 2162 +-------------------------------------------------------------+ 2163 ^ | ^ 2164 | v | 2165 | +-----------------------------------------------+ | 2166 | | system operator | | 2167 | +-----------------------------------------------+ | 2168 | ^ | ^ | ^ | ^ | ^ | | 2169 | | v | | | | | | | v | 2170 +---+ +---------+ | | | | | | +---------+ +---+ 2171 | |->| ANM | | | | | | | | LocalTS |->| | 2172 | R |<-| table | | | | | | | | LocalPC |<-| T | 2173 | x | +---------+ | v | v | v +---------+ | x | 2174 | | +----------------+ +---------+ +----------------+ | | 2175 | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | 2176 | r |<-| ANM timeout | | CSAs | | |->| r | 2177 | o | | RxAuthRequired | | | | | | o | 2178 | c | +----------------+ +---------+ +----------------+ | c | 2179 | e | +-------------+ | | +-------------+ | e | 2180 | s | | Rx ESAs | | | | Tx ESAs | | s | 2181 | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | 2182 | i | +-------------+ +-------------+ | i | 2183 | n | +------------------------------+----------------+ | n | 2184 | g | | instance of | output buffers |=>| g | 2185 | |=>| the original +----------------+ | | 2186 | | | protocol | source address |->| | 2187 +---+ +------------------------------+----------------+ +---+ 2188 /\ | || 2189 || v \/ 2190 +-------------------------------------------------------------+ 2191 | network stack | 2192 +-------------------------------------------------------------+ 2193 /\ || /\ || /\ || /\ || 2194 || \/ || \/ || \/ || \/ 2195 +---------+ +---------+ +---------+ +---------+ 2196 | speaker | | speaker | ... | speaker | | speaker | 2197 +---------+ +---------+ +---------+ +---------+ 2199 Flow of control data : ---> 2200 Flow of Babel datagrams/packets: ===> 2202 Figure 1: Interaction Diagram 2204 P 2205 |<---------------------------->| (D1) 2206 | B | 2207 | |<------------------------->| 2208 | | | 2209 +--+-----+-----+...+-----+-----+--+ P: Babel packet 2210 |H |some |some | |some |some |T | H: Babel packet header 2211 | |TLV |TLV | |TLV |TLV | | B: Babel packet body 2212 | | | | | | | | T: optional trailing data block 2213 +--+-----+-----+...+-----+-----+--+ 2215 P 2216 |<----------------------------------------------------->| (D2) 2217 | B | 2218 | |<-------------------------------------------------->| 2219 | | | 2220 +--+-----+-----+...+-----+-----+------+------+...+------+--+ 2221 |H |some |some | |some |some |TS/PC |HMAC | |HMAC |T | 2222 | |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | | 2223 | | | | | | | | | | | | 2224 +--+-----+-----+...+-----+-----+------+------+...+------+--+ 2226 P 2227 |<----------------------------------------------------->| (D3) 2228 | B | 2229 | |<-------------------------------------------------->| 2230 | | | 2231 +--+------+------+...+------+-----+-----+...+-----+-----+--+ 2232 |H |TS/PC |HMAC | |HMAC |some |some | |some |some |T | 2233 | |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | | 2234 | | | | | | | | | | | | 2235 +--+------+------+...+------+-----+-----+...+-----+-----+--+ 2237 P 2238 |<------------------------------------------------------------>| (D4) 2239 | B | 2240 | |<--------------------------------------------------------->| 2241 | | | 2242 +--+-----+------+-----+------+...+-----+------+...+------+-----+--+ 2243 |H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T | 2244 | |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | | 2245 | | | | | | | | | | | | | 2246 +--+-----+------+-----+------+...+-----+------+...+------+-----+--+ 2248 Figure 2: Babel Datagram Structure 2250 +-------+-------------------------+---------------+ 2251 | Value | Name | Reference | 2252 +-------+-------------------------+---------------+ 2253 | 0 | Pad1 | [BABEL] | 2254 | 1 | PadN | [BABEL] | 2255 | 2 | Acknowledgement Request | [BABEL] | 2256 | 3 | Acknowledgement | [BABEL] | 2257 | 4 | Hello | [BABEL] | 2258 | 5 | IHU | [BABEL] | 2259 | 6 | Router-Id | [BABEL] | 2260 | 7 | Next Hop | [BABEL] | 2261 | 8 | Update | [BABEL] | 2262 | 9 | Route Request | [BABEL] | 2263 | 10 | Seqno Request | [BABEL] | 2264 | 11 | TS/PC | this document | 2265 | 12 | HMAC | this document | 2266 +-------+-------------------------+---------------+ 2268 Table 1: Babel TLV Types 0 through 12 2270 +--------------+-----------------------------+-------------------+ 2271 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2272 +--------------+-----------------------------+-------------------+ 2273 | Magic | 2a | 42 | 2274 | Version | 02 | version 2 | 2275 | Body length | 00:14 | 20 octets | 2276 | [TLV] Type | 04 | 4 (Hello) | 2277 | [TLV] Length | 06 | 6 octets | 2278 | Reserved | 00:00 | no meaning | 2279 | Seqno | 09:25 | 2341 | 2280 | Interval | 01:90 | 400 (4.00 s) | 2281 | [TLV] Type | 08 | 8 (Update) | 2282 | [TLV] Length | 0a | 10 octets | 2283 | AE | 00 | 0 (wildcard) | 2284 | Flags | 40 | default router-id | 2285 | Plen | 00 | 0 bits | 2286 | Omitted | 00 | 0 bits | 2287 | Interval | ff:ff | infinity | 2288 | Seqno | 68:21 | 26657 | 2289 | Metric | ff:ff | infinity | 2290 +--------------+-----------------------------+-------------------+ 2292 Table 2: A Babel Packet without Authentication TLVs 2294 +---------------+-------------------------------+-------------------+ 2295 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2296 +---------------+-------------------------------+-------------------+ 2297 | Magic | 2a | 42 | 2298 | Version | 02 | version 2 | 2299 | Body length | 00:4c | 76 octets | 2300 | [TLV] Type | 04 | 4 (Hello) | 2301 | [TLV] Length | 06 | 6 octets | 2302 | Reserved | 00:00 | no meaning | 2303 | Seqno | 09:25 | 2341 | 2304 | Interval | 01:90 | 400 (4.00 s) | 2305 | [TLV] Type | 08 | 8 (Update) | 2306 | [TLV] Length | 0a | 10 octets | 2307 | AE | 00 | 0 (wildcard) | 2308 | Flags | 40 | default router-id | 2309 | Plen | 00 | 0 bits | 2310 | Omitted | 00 | 0 bits | 2311 | Interval | ff:ff | infinity | 2312 | Seqno | 68:21 | 26657 | 2313 | Metric | ff:ff | infinity | 2314 | [TLV] Type | 0b | 11 (TS/PC) | 2315 | [TLV] Length | 06 | 6 octets | 2316 | PacketCounter | 00:01 | 1 | 2317 | Timestamp | 52:1d:7e:8b | 1377664651 | 2318 | [TLV] Type | 0c | 12 (HMAC) | 2319 | [TLV] Length | 16 | 22 octets | 2320 | KeyID | 00:c8 | 200 | 2321 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2322 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2323 | [TLV] Type | 0c | 12 (HMAC) | 2324 | [TLV] Length | 16 | 22 octets | 2325 | KeyID | 00:64 | 100 | 2326 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2327 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2328 +---------------+-------------------------------+-------------------+ 2330 Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address 2331 fe80::0a11:96ff:fe1c:10c8 2333 +---------------+-------------------------------+-------------------+ 2334 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2335 +---------------+-------------------------------+-------------------+ 2336 | Magic | 2a | 42 | 2337 | Version | 02 | version 2 | 2338 | Body length | 00:4c | 76 octets | 2339 | [TLV] Type | 04 | 4 (Hello) | 2340 | [TLV] Length | 06 | 6 octets | 2341 | Reserved | 00:00 | no meaning | 2342 | Seqno | 09:25 | 2341 | 2343 | Interval | 01:90 | 400 (4.00 s) | 2344 | [TLV] Type | 08 | 8 (Update) | 2345 | [TLV] Length | 0a | 10 octets | 2346 | AE | 00 | 0 (wildcard) | 2347 | Flags | 40 | default router-id | 2348 | Plen | 00 | 0 bits | 2349 | Omitted | 00 | 0 bits | 2350 | Interval | ff:ff | infinity | 2351 | Seqno | 68:21 | 26657 | 2352 | Metric | ff:ff | infinity | 2353 | [TLV] Type | 0b | 11 (TS/PC) | 2354 | [TLV] Length | 06 | 6 octets | 2355 | PacketCounter | 00:01 | 1 | 2356 | Timestamp | 52:1d:7e:8b | 1377664651 | 2357 | [TLV] Type | 0c | 12 (HMAC) | 2358 | [TLV] Length | 16 | 22 octets | 2359 | KeyID | 00:c8 | 200 | 2360 | Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result | 2361 | | 60:3a:ed:fd:06:55:83:f7:ee:79 | | 2362 | [TLV] Type | 0c | 12 (HMAC) | 2363 | [TLV] Length | 16 | 22 octets | 2364 | KeyID | 00:64 | 100 | 2365 | Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result | 2366 | | c7:73:e0:b5:22:82:ce:fe:e2:3c | | 2367 +---------------+-------------------------------+-------------------+ 2369 Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result 2371 Appendix B. Test Vectors 2373 The test vectors below may be used to verify the correctness of some 2374 procedures performed by an implementation of this mechanism, namely: 2376 o appending of TS/PC and HMAC TLVs to the Babel packet body, 2378 o padding of the HMAC TLV(s), 2379 o computation of the HMAC result(s), and 2381 o placement of the result(s) in the TLV(s). 2383 This verification isn't exhaustive, there are other important 2384 implementation aspects that would require testing methods of their 2385 own. 2387 The test vectors were produced as follows. 2389 1. A Babel speaker with a network interface with IPv6 link-local 2390 address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs 2391 for the interface: 2393 * CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, 2394 AuthKeyOctets=Key26}}} 2396 * CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, 2397 AuthKeyOctets=Key70}}} 2399 The authentication keys above are: 2401 * Key26 in ASCII: 2403 ABCDEFGHIJKLMNOPQRSTUVWXYZ 2405 * Key26 in hexadecimal: 2407 41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50 2408 51:52:53:54:55:56:57:58:59:5a 2410 * Key70 in ASCII: 2412 This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567 2414 * Key70 in hexadecimal: 2416 54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63 2417 74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f 2418 6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c 2419 4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31 2420 32:33:34:35:36:37 2422 The length of each key was picked to relate (in the terms of 2423 Section 2.4) with the properties of respective hash algorithm as 2424 follows: 2426 * the digest length (L) of both RIPEMD-160 and SHA-1 is 20 2427 octets, 2429 * the internal block size (B) of both RIPEMD-160 and SHA-1 is 64 2430 octets, 2432 * the length of Key26 (26) is greater than L but less than B, 2433 and 2435 * the length of Key70 (70) is greater than B (and thus greater 2436 than L). 2438 KeyStartAccept, KeyStopAccept, KeyStartGenerate and 2439 KeyStopGenerate were set to make both authentication keys valid. 2441 2. The instance of the original protocol of the speaker produced a 2442 Babel packet (PktO) to be sent from the interface. Table 2 2443 provides a decoding of PktO, contents of which is below: 2445 2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40 2446 00:00:ff:ff:68:21:ff:ff 2448 3. The authentication mechanism appended one TS/PC TLV and two HMAC 2449 TLVs to the packet body, updated the "Body length" packet header 2450 field and padded the Digest field of the HMAC TLVs using the 2451 link-local IPv6 address of the interface and necessary amount of 2452 zeroes. Table 3 provides a decoding of the resulting temporary 2453 packet (PktT), contents of which is below: 2455 2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40 2456 00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b 2457 0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff 2458 fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00 2459 00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00 2461 4. The authentication mechanism produced two HMAC results, 2462 performing the computations as follows: 2464 * For H=RIPEMD-160, K=Key26, and Text=PktT the HMAC result is: 2466 c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55 2467 83:f7:ee:79 2469 * For H=SHA-1, K=Key70, and Text=PktT the HMAC result is: 2471 df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82 2472 ce:fe:e2:3c 2473 5. The authentication mechanism placed each HMAC result into 2474 respective HMAC TLV, producing the final authenticated Babel 2475 packet (PktA), which was eventually sent from the interface. 2476 Table 4 provides a decoding of PktA, contents of which is below: 2478 2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40 2479 00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b 2480 0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a 2481 ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e 2482 d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c 2484 Interpretation of this process is to be done in the view of Figure 1, 2485 differently for the sending and the receiving directions. 2487 For the sending direction, given a Babel speaker configured using the 2488 IPv6 address and the sequence of CSAs as described above, the 2489 implementation SHOULD (see notes in Section 5.3) produce exactly the 2490 temporary packet PktT if the original protocol instance produces 2491 exactly the packet PktO to be sent from the interface. If the 2492 temporary packet exactly matches PktT, the HMAC results computed 2493 afterwards MUST exactly match respective results above and the final 2494 authenticated packet MUST exactly match the PktA above. 2496 For the receiving direction, given a Babel speaker configured using 2497 the sequence of CSAs as described above (but a different IPv6 2498 address), the implementation MUST (assuming the TS/PC check didn't 2499 fail) produce exactly the temporary packet PktT above if its network 2500 stack receives through the interface exactly the packet PktA above 2501 from the source IPv6 address above. The first HMAC result computed 2502 afterwards MUST match the first result above. The receiving 2503 procedure doesn't compute the second HMAC result in this case, but if 2504 the implementor decides to compute it anyway for the verification 2505 purpose, it MUST exactly match the second result above. 2507 Author's Address 2509 Denis Ovsienko 2510 Yandex 2511 16, Leo Tolstoy St. 2512 Moscow, 119021 2513 Russia 2515 Email: infrastation@yandex.ru