idnits 2.17.1 draft-ovsienko-babel-rfc7298bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TLV' is mentioned on line 2429, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-04 -- 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 7298 (Obsoleted by RFC 8967) -- Obsolete informational reference (is this intentional?): RFC 7557 (Obsoleted by RFC 8966) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ovsienko 3 Internet-Draft March 5, 2018 4 Obsoletes: 7298 (if approved) 5 Intended status: Standards Track 6 Expires: September 6, 2018 8 Babel HMAC Cryptographic Authentication 9 draft-ovsienko-babel-rfc7298bis-00 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 the Babel routing protocol. The mechanism uses two TLV types and one 15 sub-STV type for the authentication data, uses HMAC and is both 16 optional and backward compatible. This document obsoletes RFC 7298. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 54 2. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Mandatory-to-Implement and Optional Hash Algorithms . . . 5 56 2.2. Definition of Padding . . . . . . . . . . . . . . . . . . 6 57 2.3. Cryptographic Sequence Number Specifics . . . . . . . . . 8 58 2.4. Definition of HMAC . . . . . . . . . . . . . . . . . . . 8 59 3. Updates to Protocol Data Structures . . . . . . . . . . . . . 10 60 3.1. RxAuthRequired . . . . . . . . . . . . . . . . . . . . . 10 61 3.2. LocalTS . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 3.3. LocalPC . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.4. MaxDigestsIn . . . . . . . . . . . . . . . . . . . . . . 11 64 3.5. MaxDigestsOut . . . . . . . . . . . . . . . . . . . . . . 11 65 3.6. ANM Table . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.7. ANMTimeout . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.8. Sent TS/PC Numbers Table . . . . . . . . . . . . . . . . 14 68 3.9. TSPCMaxRTT . . . . . . . . . . . . . . . . . . . . . . . 15 69 3.10. Configured Security Associations . . . . . . . . . . . . 15 70 3.11. Effective Security Associations . . . . . . . . . . . . . 17 71 4. Updates to Protocol Encoding . . . . . . . . . . . . . . . . 18 72 4.1. Justification . . . . . . . . . . . . . . . . . . . . . . 18 73 4.2. TS/PC TLV . . . . . . . . . . . . . . . . . . . . . . . . 19 74 4.3. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 20 75 4.4. TS/PC sub-TLV . . . . . . . . . . . . . . . . . . . . . . 21 76 5. Updates to Protocol Operation . . . . . . . . . . . . . . . . 22 77 5.1. Per-Interface TS/PC Number Updates . . . . . . . . . . . 22 78 5.2. Deriving ESAs from CSAs . . . . . . . . . . . . . . . . . 24 79 5.3. Updates to Packet Sending . . . . . . . . . . . . . . . . 26 80 5.4. Updates to Packet Receiving . . . . . . . . . . . . . . . 29 81 5.5. Authentication-Specific Statistics Maintenance . . . . . 31 82 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32 83 6.1. Source Address Selection for Sending . . . . . . . . . . 32 84 6.2. Output Buffer Management . . . . . . . . . . . . . . . . 33 85 6.3. Optimizations of ESAs Deriving . . . . . . . . . . . . . 34 86 6.4. Security Associations Duplication . . . . . . . . . . . . 35 87 7. Network Management Aspects . . . . . . . . . . . . . . . . . 36 88 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . 36 89 7.2. Multi-Domain Authentication . . . . . . . . . . . . . . . 36 90 7.3. Migration to and from Authenticated Exchange . . . . . . 38 91 7.4. Handling of Authentication Keys Exhaustion . . . . . . . 38 92 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 39 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 44 97 11.2. Informative References . . . . . . . . . . . . . . . . . 45 99 Appendix A. Figures and Tables . . . . . . . . . . . . . . . . . 47 100 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 52 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55 103 1. Introduction 105 [RFC Editor: before publication please remove the sentence below.] 106 Comments are solicited and should be addressed to the author. 108 Authentication of routing protocol exchanges is a common mean of 109 securing computer networks. Use of protocol authentication 110 mechanisms helps in ascertaining that only the intended routers 111 participate in routing information exchange, and that the exchanged 112 routing information is not modified by a third party. 114 [BABEL] ("the original specification") defines data structures, 115 encoding, and the operation of a basic Babel routing protocol 116 instance ("instance of the original protocol"). This document ("this 117 specification") defines data structures, encoding, and the operation 118 of an extension to the Babel protocol, an authentication mechanism 119 ("this mechanism"). Both the instance of the original protocol and 120 this mechanism are mostly self-contained and interact only at 121 coupling points defined in this specification. 123 A major design goal of this mechanism is transparency to operators 124 that is not affected by implementation and configuration specifics. 125 A complying implementation makes all meaningful details of 126 authentication-specific processing clear to the operator, even when 127 some of the operational parameters cannot be changed. 129 The currently established (see [RIP2-AUTH], [OSPF2-AUTH], 130 [OSPF3-AUTH], [ISIS-AUTH-A], and [RFC6039]) approach to 131 authentication mechanism design for datagram-based routing protocols 132 such as Babel relies on two principal data items embedded into 133 protocol packets, typically as two integral parts of a single data 134 structure: 136 o A fixed-length unsigned integer, typically called a cryptographic 137 sequence number, used in replay attack protection. 139 o A variable-length sequence of octets, a result of the HMAC 140 construct (see [RFC2104]) computed on meaningful data items of the 141 packet (including the cryptographic sequence number) on one hand 142 and a secret key on the other, used in proving that both the 143 sender and the receiver share the same secret key and that the 144 meaningful data was not changed in transmission. 146 Depending on the design specifics either all protocol packets are 147 authenticated or only those protecting the integrity of protocol 148 exchange. This mechanism authenticates all protocol packets. 150 Although the HMAC construct is just one of many possible approaches 151 to cryptographic authentication of packets, this mechanism makes use 152 of relevant prior experience by using HMAC too and its solution space 153 correlates with the solution spaces of the mechanisms above. At the 154 same time, it allows for a future extension that treats HMAC as a 155 particular case of a more generic mechanism. Practical experience 156 with the mechanism defined herein should be useful in designing such 157 future extension. 159 This specification defines the use of the cryptographic sequence 160 number in details sufficient to make replay attack protection 161 strength predictable. That is, an operator can tell the strength 162 from the declared characteristics of an implementation and, whereas 163 the implementation allows to change relevant parameters, the effect 164 of a reconfiguration. 166 This mechanism explicitly allows for multiple HMAC results per 167 authenticated packet. Since meaningful data items of a given packet 168 remain the same, each such HMAC result stands for a different secret 169 key and/or a different hash algorithm. This enables a simultaneous, 170 independent authentication within multiple domains. This 171 specification is not novel in this regard, e.g., L2TPv3 allows for 1 172 or 2 ([RFC3931] Section 5.4.1) and MANET protocols allow for several 173 ([RFC7183] Section 6.1) results per authenticated packet. 175 An important concern addressed by this mechanism is limiting the 176 amount of HMAC computations done per authenticated packet, 177 independently for sending and receiving. Without these limits the 178 number of computations per packet could be as high as the number of 179 configured authentication keys (in the sending case) or as the number 180 of keys multiplied by the number of supplied HMAC results (in the 181 receiving case). 183 These limits establish a basic competition between the configured 184 keys and (in the receiving case) an additional competition between 185 the supplied HMAC results. This specification defines related data 186 structures and procedures in a way to make such competition 187 transparent and predictable for an operator. 189 Wherever this specification mentions the operator reading or changing 190 a particular data structure, variable, parameter, or event counter 191 "at runtime", it is up to the implementor how this is to be done. 192 For example, the implementation can employ an interactive CLI, or a 193 management protocol such as SNMP, or an inter-process communication 194 mean such as a local socket, or a combination of these. 196 1.1. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in 201 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 2. Cryptographic Aspects 206 2.1. Mandatory-to-Implement and Optional Hash Algorithms 208 [RFC2104] defines HMAC as a construct that can use any cryptographic 209 hash algorithm with a known digest length and internal block size. 210 This specification preserves this property of HMAC by defining data 211 processing that itself does not depend on any particular hash 212 algorithm either. However, since this mechanism is a protocol 213 extension case, there are relevant design considerations to take into 214 account. 216 Section 4.5 of [RFC6709] suggests selecting one hash algorithm as 217 mandatory-to-implement for the purpose of global interoperability 218 (Section 3.2 ibid.) and selecting another of distinct lineage as 219 recommended for implementation for the purpose of cryptographic 220 agility. This specification makes the latter property guaranteed, 221 rather than probable, through an elevation of the requirement level. 222 There are two hash algorithms mandatory-to-implement, unambiguously 223 defined and generally available in multiple implementations each. 224 This design choice fully conforms to BCP 201 [RFC7696]. 226 An implementation of this mechanism MUST include support for two hash 227 algorithms: 229 o RIPEMD-160 (160-bit digest) 231 o SHA-1 (160-bit digest) 233 Besides that, an implementation of this mechanism MAY include support 234 for additional hash algorithms, provided each such algorithm is 235 publicly and openly specified and its digest length is 128 bits or 236 more (to meet the constraint implied in Section 2.2). Implementors 237 SHOULD consider strong, well-known hash algorithms as additional 238 implementation options and MUST NOT consider hash algorithms for that 239 by the time of implementation meaningful attacks exist or that are 240 commonly viewed as deprecated. 242 In the latter case it is important to take into account 243 considerations both common (such as those made in [RFC4270]) and 244 specific to the HMAC application of the hash algorithm. E.g., 245 [RFC6151] considers MD5 collisions and concludes that new protocol 246 designs should not use HMAC-MD5, while [RFC6194] includes a 247 comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the 248 same purpose. 250 For example, the following hash algorithms meet these requirements at 251 the time of this writing (in alphabetical order): 253 o GOST R 34.11-94 (256-bit digest) 255 o SHA-224 (224-bit digest, SHA-2 family) 257 o SHA-256 (256-bit digest, SHA-2 family) 259 o SHA-384 (384-bit digest, SHA-2 family) 261 o SHA-512 (512-bit digest, SHA-2 family) 263 o Tiger (192-bit digest) 265 o Whirlpool (512-bit digest, 2nd rev., 2003) 267 The set of hash algorithms available in an implementation MUST be 268 clearly stated. When known weak authentication keys exist for a hash 269 algorithm used in the HMAC construct, an implementation MUST deny a 270 use of such keys. 272 2.2. Definition of Padding 274 Many practical applications of HMAC for authentication of datagram- 275 based network protocols (including routing protocols) involve the 276 padding procedure, a design-specific conditioning of the message that 277 both the sender and the receiver perform before the HMAC computation. 278 Specific padding procedure of this mechanism addresses the following 279 needs: 281 o Data Initialization 283 A design that places the HMAC result(s) computed for a message 284 inside the same message after the computation has to allocate in 285 the message some data unit(s) purposed for the result(s) (in this 286 mechanism it is the HMAC TLV(s), see Section 4.3). The padding 287 procedure sets respective octets of the data unit(s), in the 288 simplest case to a fixed value known as the padding constant. 290 Particular value of the constant is specific to each design. For 291 instance, in [RIP2-AUTH] as well as works derived from it 292 ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH]) the value is 293 0x878FE1F3. In many other designs (for instance, [RFC3315], 294 [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]) the 295 value is 0x00. 297 However, the HMAC construct is defined on the base of a 298 cryptographic hash algorithm, that is, an algorithm meeting 299 particular set of requirements made for any input message. Thus 300 any padding constant values, whether single- or multiple-octet, as 301 well as any other message conditioning methods, don't affect 302 cryptographic characteristics of the hash algorithm and the HMAC 303 construct respectively. 305 o Source Address Protection 307 In the specific case of datagram-based routing protocols the 308 protocol packet (that is, the message being authenticated) often 309 does not include network layer addresses, although the source and 310 (to a lesser extent) the destination address of the datagram may 311 be meaningful in the scope of the protocol instance. 313 In Babel the source address may be used as a prefix hext hop (see 314 Section 3.5.3 of [BABEL]). A well-known (see Section 2.3 of 315 [OSPF3-AUTH]) solution to the source address protection problem is 316 to set the first respective octets of the data unit(s) above to 317 the source address (yet setting the rest of the octets to the 318 padding constant). This procedure adapts this solution to the 319 specifics of Babel, which allows for exchange of protocol packets 320 using both IPv4 and IPv6 datagrams (see Section 4 of [BABEL]). 321 Even though in the case of IPv6 exchange a Babel speaker currently 322 uses only link-local source addresses (Section 3.1 ibid.), this 323 procedure protects all octets of an arbitrary given source address 324 for the reasons of future extensibility. The procedure implies 325 that future Babel extensions will never use an IPv4-mapped IPv6 326 address as a packet source address. 328 This procedure does not protect the destination address, which is 329 currently considered meaningless (ibid.) in the same scope. A 330 future extension that looks to add such protection would likely 331 use a new TLV or sub-TLV to include the destination address into 332 the protocol packet (see Section 4.1). 334 Description of the padding procedure: 336 1. Set the first 16 octets of the Digest field of the given HMAC TLV 337 to: 339 * the given source address, if it is an IPv6 address, or 341 * the IPv4-mapped IPv6 address (per Section 2.5.5.2 of 342 [RFC4291]) holding the given source address, if it is an IPv4 343 address. 345 2. Set the remaining (TLV Length - 18) octets of the Digest field of 346 the given HMAC TLV to 0x00. 348 For an example of a Babel packet with padded HMAC TLVs see Table 3. 350 2.3. Cryptographic Sequence Number Specifics 352 Operation of this mechanism may involve multiple local and multiple 353 remote cryptographic sequence numbers, each essentially being a 354 48-bit unsigned integer. This specification uses a term "TS/PC 355 number" to avoid confusion with the route's (Section 2.5 of [BABEL]) 356 or node's (Section 3.2.1 ibid.) sequence numbers of the original 357 Babel specification and to stress the fact that there are two 358 distinguished parts of this 48-bit number, each handled in its 359 specific way (see Section 5.1): 361 0 1 2 3 4 362 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 363 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | TS // | PC | 365 +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 // 368 The high-order 32 bits are called "timestamp" (TS) and the low-order 369 16 bits are called "packet counter" (PC). 371 This mechanism stores, updates, compares, and encodes each TS/PC 372 number as two independent unsigned integers, TS and PC respectively. 373 Such comparison of TS/PC numbers performed in item 3 of Section 5.4 374 is algebraically equivalent to comparison of respective 48-bit 375 unsigned integers. Any byte order conversion, when required, is 376 performed on TS and PC parts independently. 378 2.4. Definition of HMAC 380 The algorithm description below uses the following nomenclature, 381 which is consistent with [FIPS-198]: 383 Text Is the data on which the HMAC is calculated (note item (b) of 384 Section 9). In this specification it is the contents of a 385 Babel packet ranging from the beginning of the Magic field of 386 the Babel packet header to the end of the last octet of the 387 Packet Body field, as defined in Section 4.2 of [BABEL] (see 388 Figure 2). 390 H Is the specific hash algorithm (see Section 2.1). 392 K Is a sequence of octets of an arbitrary, known length. 394 Ko Is the cryptographic key used with the hash algorithm. 396 B Is the block size of H, measured in octets rather than bits. 397 Note that B is the internal block size, not the digest length. 399 L Is the digest length of H, measured in octets rather than 400 bits. 402 XOR Is the bitwise exclusive-or operation. 404 Opad Is the hexadecimal value 0x5C repeated B times. 406 Ipad Is the hexadecimal value 0x36 repeated B times. 408 The algorithm below is the original, unmodified HMAC construct as 409 defined in both [RFC2104] and [FIPS-198], hence it is different from 410 the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], 411 and [OSPF3-AUTH] in exactly two regards: 413 o The algorithm below sets the size of Ko to B, not to L (L is not 414 greater than B). This resolves both ambiguity in XOR expressions 415 and incompatibility in handling of keys that have length greater 416 than L but not greater than B. 418 o The algorithm below does not change value of Text before or after 419 the computation. Both padding of a Babel packet before the 420 computation and placing of the result inside the packet are 421 performed elsewhere. 423 The intent of this is to enable the most straightforward use of 424 cryptographic libraries by implementations of this specification. At 425 the time of this writing implementations of the original HMAC 426 construct coupled with hash algorithms of choice are generally 427 available. 429 Description of the algorithm: 431 1. Preparation of the Key 433 In this application, Ko is always B octets long. If K is B 434 octets long, then Ko is set to K. If K is more than B octets 435 long, then Ko is set to H(K) with the necessary amount of zeroes 436 appended to the end of H(K), such that Ko is B octets long. If K 437 is less than B octets long, then Ko is set to K with zeroes 438 appended to the end of K, such that Ko is B octets long. 440 2. First-Hash 442 A First-Hash, also known as the inner hash, is computed as follows: 444 First-Hash = H(Ko XOR Ipad || Text) 446 3. Second-Hash 448 A second hash, also known as the outer hash, is computed as follows: 450 Second-Hash = H(Ko XOR Opad || First-Hash) 452 4. Result 454 The resulting Second-Hash becomes the authentication data that is 455 returned as the result of HMAC calculation. 457 Note that in the case of Babel the Text parameter will never exceed a 458 few thousands of octets in length. In this specific case the 459 optimization discussed in Section 6 of [FIPS-198] applies, namely, 460 for a given K that is more than B octets long the following 461 associated intermediate results may be precomputed only once: Ko, 462 (Ko XOR Ipad), and (Ko XOR Opad). 464 3. Updates to Protocol Data Structures 466 3.1. RxAuthRequired 468 RxAuthRequired is a boolean parameter, its default value MUST be 469 TRUE. An implementation SHOULD make RxAuthRequired a per-interface 470 parameter, but MAY make it specific to the whole protocol instance. 471 The conceptual purpose of RxAuthRequired is to enable a smooth 472 migration from an unauthenticated to an authenticated Babel packet 473 exchange and back (see Section 7.3). Current value of RxAuthRequired 474 directly affects the receiving procedure defined in Section 5.4. An 475 implementation SHOULD allow the operator to change RxAuthRequired 476 value at runtime or by means of Babel speaker restart. An 477 implementation MUST allow the operator to discover the effective 478 value of RxAuthRequired at runtime or from the system documentation. 480 3.2. LocalTS 482 LocalTS is a 32-bit unsigned integer variable, it is the TS part of a 483 per-interface TS/PC number. LocalTS is a strictly per-interface 484 variable not intended to be changed by the operator. Its 485 initialization is explained in Section 5.1. 487 3.3. LocalPC 489 LocalPC is a 16-bit unsigned integer variable, it is the PC part of a 490 per-interface TS/PC number. LocalPC is a strictly per-interface 491 variable not intended to be changed by the operator. Its 492 initialization is explained in Section 5.1. 494 3.4. MaxDigestsIn 496 MaxDigestsIn is an unsigned integer parameter conceptually purposed 497 for limiting the amount of CPU time spent processing a received 498 authenticated packet. The receiving procedure performs the most CPU- 499 intensive operation, the HMAC computation, only at most MaxDigestsIn 500 (Section 5.4 item 8) times for a given packet. 502 MaxDigestsIn value MUST be at least 2. An implementation SHOULD make 503 MaxDigestsIn a per-interface parameter, but MAY make it specific to 504 the whole protocol instance. An implementation SHOULD allow the 505 operator to change the value of MaxDigestsIn at runtime or by means 506 of Babel speaker restart. An implementation MUST allow the operator 507 to discover the effective value of MaxDigestsIn at runtime or from 508 the system documentation. 510 3.5. MaxDigestsOut 512 MaxDigestsOut is an unsigned integer parameter conceptually purposed 513 for limiting the amount of a sent authenticated packet's space spent 514 on authentication data. The sending procedure adds at most 515 MaxDigestsOut (Section 5.3 item 7) HMAC results to a given packet, 516 concurring with the output buffer management explained in 517 Section 6.2. 519 The MaxDigestsOut value MUST be at least 2. An implementation SHOULD 520 make MaxDigestsOut a per-interface parameter, but MAY make it 521 specific to the whole protocol instance. An implementation SHOULD 522 allow the operator to change the value of MaxDigestsOut at runtime or 523 by means of Babel speaker restart, in a safe range. The maximum safe 524 value of MaxDigestsOut is implementation-specific (see Section 6.2). 525 An implementation MUST allow the operator to discover the effective 526 value of MaxDigestsOut at runtime or from the system documentation. 528 3.6. ANM Table 530 The ANM (Authentic Neighbours Memory) table resembles the neighbour 531 table defined in Section 3.2.4 of [BABEL]. Note that the term 532 "neighbour table" means the neighbour table of the original Babel 533 specification, and the term "ANM table" means the table defined 534 herein. Indexing of the ANM table is done in exactly the same way as 535 indexing of the neighbour table, but purpose, field set and 536 associated procedures are different. 538 The conceptual purpose of the ANM table is to provide longer term 539 replay attack protection than it would be possible using the 540 neighbour table. Expiry of an inactive entry in the neighbour table 541 depends on the last received Hello Interval of the neighbour and 542 typically stands for tens to hundreds of seconds (see Appendix A and 543 Appendix B of [BABEL]). Expiry of an inactive entry in the ANM table 544 depends only on the local speaker's configuration. The ANM table 545 retains (for at least the amount of seconds set by ANMTimeout 546 parameter defined in Section 3.7) a copy of TS/PC number advertised 547 in authentic packets by each remote Babel speaker. 549 The ANM table is indexed by pairs of the form (Interface, Source). 550 Every table entry consists of the following fields: 552 o Interface 554 An implementation-specific reference to the local node's interface 555 that the authentic packet was received through. 557 o Source 559 The source address of the Babel speaker that the authentic packet 560 was received from. 562 o LastTS 564 A 32-bit unsigned integer, the TS part of a remote TS/PC number. 566 o LastPC 568 A 16-bit unsigned integer, the PC part of a remote TS/PC number. 570 Each ANM table entry has an associated aging timer, which is reset by 571 the receiving procedure (Section 5.4 item 10). If the timer expires, 572 the entry is deleted from the ANM table. 574 An implementation SHOULD use a persistent memory (NVRAM) to retain 575 the contents of ANM table across restarts of the Babel speaker, but 576 only as long as both the Interface field reference and expiry of the 577 aging timer remain correct. An implementation MUST make it clear, if 578 and how persistent memory is used for ANM table. An implementation 579 SHOULD allow the operator to retrieve the current contents of ANM 580 table at runtime. An implementation SHOULD allow the operator to 581 remove some or all of ANM table entries at runtime or by means of 582 Babel speaker restart. 584 3.7. ANMTimeout 586 ANMTimeout is an unsigned integer parameter. An implementation 587 SHOULD make ANMTimeout a per-interface parameter, but MAY make it 588 specific to the whole protocol instance. ANMTimeout is conceptually 589 purposed for limiting the maximum age (in seconds) of entries in the 590 ANM table standing for inactive Babel speakers. The maximum age is 591 immediately related to replay attack protection strength. The 592 strongest protection is achieved with the maximum possible value of 593 ANMTimeout set, but it may not provide the best overall result for 594 specific network segments and implementations of this mechanism. 596 In the first turn, implementations unable to maintain local TS/PC 597 number strictly increasing across Babel speaker restarts will reuse 598 the advertised TS/PC numbers after each restart (see Section 5.1). 599 The neighbouring speakers will treat the new packets as replayed and 600 discard them until the aging timer of respective ANM table entry 601 expires or the new TS/PC number exceeds the one stored in the entry. 603 Another possible, but less probable, case could be an environment 604 using IPv6 for Babel datagrams exchange and involving physical moves 605 of network interfaces hardware between Babel speakers. Even 606 performed without restarting the speakers, these would cause random 607 drops of the TS/PC number advertised for a given (Interface, Source) 608 index, as viewed by neighbouring speakers, since IPv6 link-local 609 addresses are typically derived from interface hardware addresses. 611 Assuming that in such cases the operators would prefer to use a lower 612 ANMTimeout value to let the entries expire on their own rather than 613 having to manually remove them from the ANM table each time, an 614 implementation SHOULD set the default value of ANMTimeout to a value 615 between 30 and 300 seconds. 617 At the same time, network segments may exist with every Babel speaker 618 having its advertised TS/PC number strictly increasing over the 619 deployed lifetime. Assuming that in such cases the operators would 620 prefer using a much higher ANMTimeout value, an implementation SHOULD 621 allow the operator to change the value of ANMTimeout at runtime or by 622 means of Babel speaker restart. An implementation MUST allow the 623 operator to discover the effective value of ANMTimeout at runtime or 624 from the system documentation. 626 3.8. Sent TS/PC Numbers Table 628 The purpose of the sent TS/PC numbers table is to provide protection 629 from those attacks that introduce a meaningful arbitrary delay into 630 the protocol exchange. Such attacks are in scope because the 631 original specification does not relate a specific received IHU TLV to 632 a specific sent Hello TLV. This way, if an adversary intercepts all 633 packets sent by a Babel speaker and starts replaying them later, the 634 IHU TLVs will mislead respective speakers into detecting 635 bidirectional reachability with the neighbour and processing the 636 other TLVs from the replayed packets. Since the checks based on the 637 ANM table are unable to tell the replayed packets when the replayed 638 TS/PC number is strictly increasing, this mechanism adds a proof of 639 freshness to the protocol exchange to address this problem. 641 The sent TS/PC numbers table is indexed by pairs of the form 642 (Interface, FirstTimestamp). Every table entry consists of the 643 following fields: 645 o Interface 647 An implementation-specific reference to the local node's interface 648 through that the authenticated packet was sent. 650 o FirstTimestamp 652 An implementation-specific reference to a point in time when the 653 entry was added to the table, accurate to exactly one second. 655 o FirstTS 657 A 32-bit unsigned integer, the TS part of respective local TS/PC 658 number. 660 o FirstPC 662 A 16-bit unsigned integer, the PC part of respective local TS/PC 663 number. 665 An implementation MUST at least once per second remove from the table 666 all entries that have FirstTimestamp more than TSPCMaxRTT (see 667 Section 3.9) seconds into the past. Consequently, the time reference 668 MUST NOT be affected by the speaker's clock adjustments (monotonic 669 clock and system uptime are examples of good time references in this 670 sense). 672 An implementation SHOULD NOT retain the contents of this table across 673 restarts of the Babel speaker. An implementation SHOULD allow the 674 operator to retrieve the current contents of the table at runtime. 676 3.9. TSPCMaxRTT 678 TSPCMaxRTT is an unsigned integer parameter. An implementation 679 SHOULD make TSPCMaxRTT a per-interface parameter, but MAY make it 680 specific to the whole protocol instance. TSPCMaxRTT limits the 681 maximum age (in seconds) of entries in the sent TS/PC numbers table. 682 On one hand, TSPCMaxRTT should be set as low as possible to leave out 683 the speakers that try to respond to obviously stale Hello TLVs. On 684 the other, a normal Babel protocol exchange requires some minimal 685 leeway to accommodate its timers, jitter, and natural delays and 686 losses in transmission, so good judgement should be applied. 688 An implementation SHOULD set the default value of TSPCMaxRTT to a 689 value between 30 and 300 seconds, SHOULD allow the operator to change 690 the value of TSPCMaxRTT at runtime or by means of a Babel speaker 691 restart, and MUST allow the operator to discover the effective value 692 of TSPCMaxRTT at runtime or from the system documentation. 694 3.10. Configured Security Associations 696 A Configured Security Association (CSA) is a data structure 697 conceptually purposed for associating authentication keys and hash 698 algorithms with Babel interfaces. All CSAs are managed in finite 699 sequences, one sequence per interface ("interface's sequence of CSAs" 700 hereafter). Each interface's sequence of CSAs, as an integral part 701 of the Babel speaker configuration, MAY be intended for a persistent 702 storage as long as this conforms with the implementation's key 703 management policy. The default state of an interface's sequence of 704 CSAs is empty, which has a special meaning of no authentication 705 configured for the interface. The sending (Section 5.3 item 1) and 706 the receiving (Section 5.4 item 1) procedures address this convention 707 accordingly. 709 A single CSA structure consists of the following fields: 711 o HashAlgo 713 An implementation-specific reference to one of the hash algorithms 714 supported by this implementation (see Section 2.1). 716 o KeyChain 717 A finite sequence of elements ("KeyChain sequence" hereafter) 718 representing authentication keys, each element being a structure 719 consisting of the following fields: 721 * LocalKeyID 723 An unsigned integer of an implementation-specific bit length. 725 * AuthKeyOctets 727 A sequence of octets of an arbitrary, known length to be used 728 as the authentication key. 730 * KeyStartAccept 732 The time that this Babel speaker will begin considering this 733 authentication key for accepting packets with authentication 734 data. 736 * KeyStartGenerate 738 The time that this Babel speaker will begin considering this 739 authentication key for generating packet authentication data. 741 * KeyStopGenerate 743 The time that this Babel speaker will stop considering this 744 authentication key for generating packet authentication data. 746 * KeyStopAccept 748 The time that this Babel speaker will stop considering this 749 authentication key for accepting packets with authentication 750 data. 752 Since there is no limit imposed on the number of CSAs per interface, 753 but the number of HMAC computations per sent/received packet is 754 limited (through MaxDigestsOut and MaxDigestsIn respectively), only a 755 fraction of the associated keys and hash algorithms may appear used 756 in the process. The ordering of elements within a sequence of CSAs 757 and within a KeyChain sequence is important to make the association 758 selection process deterministic and transparent. Once this ordering 759 is deterministic at the Babel interface level, the intermediate data 760 derived by the procedure defined in Section 5.2 will be 761 deterministically ordered as well. 763 An implementation SHOULD allow an operator to set any arbitrary order 764 of elements within a given interface's sequence of CSAs and within 765 the KeyChain sequence of a given CSA. Regardless if this requirement 766 is or isn't met, the implementation MUST provide a mean to discover 767 the actual element order used. Whichever order is used by an 768 implementation, it MUST be preserved across Babel speaker restarts. 770 Note that none of the CSA structure fields is constrained to contain 771 unique values. Section 6.4 explains this in more detail. It is 772 possible for the KeyChain sequence to be empty, although this is not 773 the intended manner of CSAs use. 775 The KeyChain sequence has a direct prototype, which is the "key 776 chain" syntax item of some existing router configuration languages. 777 Whereas an implementation already implements this syntax item, it is 778 suggested to reuse it, that is, to implement a CSA syntax item 779 referring to a key chain item instead of reimplementing the latter in 780 full. 782 3.11. Effective Security Associations 784 An Effective Security Association (ESA) is a data structure 785 immediately used in sending (Section 5.3) and receiving (Section 5.4) 786 procedures. Its conceptual purpose is to determine a runtime 787 interface between those procedures and the deriving procedure defined 788 in Section 5.2. All ESAs are temporary data units managed as 789 elements of finite sequences that are not intended for a persistent 790 storage. Element ordering within each such finite sequence 791 ("sequence of ESAs" hereafter) MUST be preserved as long as the 792 sequence exists. 794 A single ESA structure consists of the following fields: 796 o HashAlgo 798 An implementation-specific reference to one of the hash algorithms 799 supported by this implementation (see Section 2.1). 801 o KeyID 803 A 16-bit unsigned integer. 805 o AuthKeyOctets 807 A sequence of octets of an arbitrary, known length to be used as 808 the authentication key. 810 Note that among the protocol data structures introduced by this 811 mechanism ESA is the only one not directly interfaced with the system 812 operator (see Figure 1), it is not immediately present in the 813 protocol encoding either. However, ESA is not just a possible 814 implementation technique, but an integral part of this specification: 815 the deriving (Section 5.2), the sending (Section 5.3), and the 816 receiving (Section 5.4) procedures are defined in terms of the ESA 817 structure and its semantics provided herein. ESA is as meaningful 818 for a correct implementation as the other protocol data structures. 820 4. Updates to Protocol Encoding 822 4.1. Justification 824 Choice of encoding is very important in the long term. The protocol 825 encoding limits various authentication mechanism designs and 826 encodings, which in turn limit future developments of the protocol. 828 Considering existing implementations of Babel protocol instance 829 itself and related modules of packet analysers, the current encoding 830 of Babel allows for compact and robust decoders. At the same time, 831 this encoding allows for future extensions of Babel by three (not 832 excluding each other) principal means defined by Section 4.2, 833 Section 4.3 and Appendix C of [BABEL]: 835 a. A Babel packet consists of a four-octet header followed by a 836 packet body, that is, a sequence of TLVs (see Figure 2). Besides 837 the header and the body, an actual Babel datagram may have an 838 arbitrary amount of trailing data between the end of the packet 839 body and the end of the datagram. An instance of the original 840 protocol silently ignores such trailing data. 842 b. The packet body uses a binary format allowing for 256 TLV types 843 and imposing no requirements on TLV ordering or number of TLVs of 844 a given type in a packet. [BABEL] allocates TLV types 0 through 845 10 (see Table 1), defines TLV body structure for each and 846 establishes the requirement for a Babel protocol instance to 847 ignore any unknown TLV types silently. This makes it possible to 848 examine a packet body (to validate the framing and/or to pick 849 particular TLVs for further processing) considering only the type 850 (to distinguish between a Pad1 TLV and any other TLV) and the 851 length of each TLV, regardless if and how many additional TLV 852 types are eventually deployed. 854 c. Within each TLV of the packet body there may be some "extra data" 855 after the "expected length" of the TLV body. An instance of the 856 original protocol silently ignores any such extra data. Note 857 that any TLV types without the expected length defined (such as 858 PadN TLV) cannot be extended with the extra data. 860 Considering each principal extension mean for the specific purpose of 861 adding authentication data items to each protocol packet, the 862 following arguments can be made: 864 o Use of the TLV extra data of some existing TLV type would not be a 865 solution, since no particular TLV type is guaranteed to be present 866 in a Babel packet. 868 o Use of the TLV extra data could also conflict with future 869 developments of the protocol encoding. 871 o Since the packet trailing data is currently unstructured, using it 872 would involve defining an encoding structure and associated 873 procedures, adding to the complexity of both specification and 874 implementation and increasing the exposure to protocol attacks 875 such as fuzzing. 877 o A naive use of the packet trailing data would make it unavailable 878 to any future extension of Babel. Since this mechanism is 879 possibly not the last extension and since some other extensions 880 may allow no other embedding means except the packet trailing 881 data, the defined encoding structure would have to enable 882 multiplexing of data items belonging to different extensions. 883 Such a definition is out of the scope of this work. 885 o Deprecating an extension (or only its protocol encoding) that uses 886 purely purpose-allocated TLVs is as simple as deprecating the 887 TLVs. 889 o Use of purpose-allocated TLVs is transparent for both the original 890 protocol and any its future extensions, regardless of the 891 embedding mean(s) used by the latter. 893 Considering all of the above, this mechanism neither uses the packet 894 trailing data nor uses the TLV extra data, but uses two new TLV 895 types: type 11 for a TS/PC number and type 12 for an HMAC result (see 896 Table 1). 898 4.2. TS/PC TLV 899 The purpose of a TS/PC TLV is to store a single TS/PC number. There 900 is exactly one TS/PC TLV in an authenticated Babel packet. 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Type = 11 | Length | PacketCounter | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Timestamp | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Fields: 912 Type Set to 11 to indicate a TS/PC TLV. 914 Length The length in octets of the body, exclusive of the 915 Type and Length fields. 917 PacketCounter A 16-bit unsigned integer in network byte order, the 918 PC part of a TS/PC number stored in this TLV. 920 Timestamp A 32-bit unsigned integer in network byte order, the 921 TS part of a TS/PC number stored in this TLV. 923 Note that the ordering of PacketCounter and Timestamp in the TLV 924 structure is opposite to the ordering of TS and PC in "TS/PC" term 925 and the 48-bit equivalent (see Section 2.3). 927 Considering the "expected length" and the "extra data" in the 928 definition of Section 4.3 of [BABEL], the expected length of a TS/PC 929 TLV body is unambiguously defined as 6 octets. The receiving 930 procedure correctly processes any TS/PC TLV with body length not less 931 than the expected, ignoring any extra data (Section 5.4 items 3 and 932 10). The sending procedure produces a TS/PC TLV with body length 933 equal to the expected and Length field set respectively (Section 5.3 934 item 5). 936 Future Babel extensions (such as sub-TLVs) MAY modify the sending 937 procedure to include the extra data after the fixed-size TS/PC TLV 938 body defined herein, making necessary adjustments to Length TLV 939 field, "Body length" packet header field and output buffer management 940 explained in Section 6.2. 942 4.3. HMAC TLV 943 The purpose of an HMAC TLV is to store a single HMAC result. To 944 assist a receiver in reproducing the HMAC computation, LocalKeyID 945 modulo 2^16 of the authentication key is also provided in the TLV. 946 There is at least one HMAC TLV in an authenticated Babel packet. 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Type = 12 | Length | KeyID | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Digest... 954 +-+-+-+-+-+-+-+-+-+-+-+- 956 Fields: 958 Type Set to 12 to indicate an HMAC TLV. 960 Length The length in octets of the body, exclusive of the 961 Type and Length fields. 963 KeyID A 16-bit unsigned integer in network byte order. 965 Digest A variable-length sequence of octets, which is at 966 least 16 octets long (see Section 2.2). 968 Considering the "expected length" and the "extra data" in the 969 definition of Section 4.3 of [BABEL], the expected length of an HMAC 970 TLV body is not defined. The receiving and the padding procedures 971 process every octet of the Digest field, deriving the field boundary 972 from the Length field value (Section 5.4 item 8 and Section 2.2 973 respectively). The sending procedure produces HMAC TLVs with Length 974 field precisely sizing the Digest field to match digest length of the 975 hash algorithm used (Section 5.3 items 7 and 10). 977 The HMAC TLV structure defined herein is final, future Babel 978 extensions MUST NOT extend it with any extra data. 980 4.4. TS/PC sub-TLV 981 The purpose of a TS/PC sub-TLV is to store a single TS/PC number. 982 There is at most one TS/PC sub-TLV in an IHU TLV. 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Type = TBD1 | Length | PacketCounter | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Timestamp | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 Fields: 994 Type Set to TBD1 to indicate a TS/PC sub-TLV. 996 Length The length in octets of the body, exclusive of the 997 Type and Length fields. 999 PacketCounter A 16-bit unsigned integer in network byte order, the 1000 PC part of a TS/PC number stored in this sub-TLV. 1002 Timestamp A 32-bit unsigned integer in network byte order, the 1003 TS part of a TS/PC number stored in this sub-TLV. 1005 5. Updates to Protocol Operation 1007 5.1. Per-Interface TS/PC Number Updates 1009 The LocalTS and LocalPC interface-specific variables constitute the 1010 TS/PC number of a Babel interface. This number is advertised in the 1011 TS/PC TLV of authenticated Babel packets sent from that interface. 1012 There is only one property mandatory for the advertised TS/PC number: 1013 its 48-bit equivalent (see Section 2.3) MUST be strictly increasing 1014 within the scope of a given interface of a Babel speaker as long as 1015 the protocol instance is continuously operating. This property 1016 combined with ANM tables of neighbouring Babel speakers provides them 1017 with the most basic replay attack protection. 1019 Initialization and increment are two principal updates performed on 1020 an interface TS/PC number. The initialization is performed when a 1021 new interface becomes a part of a Babel protocol instance. The 1022 increment is performed by the sending procedure (Section 5.3 item 2) 1023 before advertising the TS/PC number in a TS/PC TLV. 1025 Depending on particular implementation method of these two updates 1026 the advertised TS/PC number may possess additional properties 1027 improving the replay attack protection strength. This includes, but 1028 is not limited to the methods below. 1030 a. The most straightforward implementation would use LocalTS as a 1031 plain wrap counter, defining the updates as follows: 1033 initialization Set LocalPC to 0, set LocalTS to 0. 1035 increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF 1036 + 1 = 0x0000), increment LocalTS by 1. 1038 In this case the advertised TS/PC numbers would be reused after 1039 each Babel protocol instance restart, making neighbouring 1040 speakers reject authenticated packets until the respective ANM 1041 table entries expire or the new TS/PC number exceeds the old (see 1042 Section 3.6 and Section 3.7). 1044 b. A more advanced implementation could make a use of any 32-bit 1045 unsigned integer timestamp (number of time units since an 1046 arbitrary epoch) such as the UNIX timestamp, whereas the 1047 timestamp itself spans a reasonable time range and is guaranteed 1048 against a decrease (such as one resulting from network time use). 1049 The updates would be defined as follows: 1051 initialization Set LocalPC to 0, set LocalTS to 0. 1053 increment If the current timestamp is greater than LocalTS, 1054 set LocalTS to the current timestamp and LocalPC 1055 to 0, then consider the update complete. 1056 Otherwise increment LocalPC by 1 and, if LocalPC 1057 wraps, increment LocalTS by 1. 1059 In this case the advertised TS/PC number would remain unique 1060 across the speaker's deployed lifetime without the need for any 1061 persistent storage. However, a suitable timestamp source is not 1062 available in every implementation case. 1064 c. Another advanced implementation could use LocalTS in a way 1065 similar to the "wrap/boot counter" suggested in Section 4.1.1 of 1066 [OSPF3-AUTH], defining the updates as follows: 1068 initialization Set LocalPC to 0. If there is a TS value stored 1069 in NVRAM for the current interface, set LocalTS 1070 to the stored TS value, then increment the stored 1071 TS value by 1. Otherwise set LocalTS to 0 and 1072 set the stored TS value to 1. 1074 increment Increment LocalPC by 1. If LocalPC wraps, set 1075 LocalTS to the TS value stored in NVRAM for the 1076 current interface, then increment the stored TS 1077 value by 1. 1079 In this case the advertised TS/PC number would also remain unique 1080 across the speaker's deployed lifetime, relying on NVRAM for 1081 storing multiple TS numbers, one per interface. 1083 As long as the TS/PC number retains its mandatory property stated 1084 above, it is up to the implementor, which TS/PC number updates 1085 methods are available and if the operator can configure the method 1086 per-interface and/or at runtime. However, an implementation MUST 1087 disclose the essence of each update method it includes, in a 1088 comprehensible form such as natural language description, pseudocode, 1089 or source code. An implementation MUST allow the operator to 1090 discover, which update method is effective for any given interface, 1091 either at runtime or from the system documentation. These 1092 requirements are necessary to enable the optimal (see Section 3.7) 1093 management of ANMTimeout in a network segment. 1095 Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is 1096 unlikely, but possible, causing the advertised TS/PC number to be 1097 reused. Resolving this situation requires replacing all 1098 authentication keys of the involved interface. In addition to that, 1099 if the wrap was caused by a timestamp reaching its end of epoch, 1100 using this mechanism will be impossible for the involved interface 1101 until some different timestamp or update implementation method is 1102 used. 1104 5.2. Deriving ESAs from CSAs 1106 Neither receiving nor sending procedures work with the contents of 1107 interface's sequence of CSAs directly, both (Section 5.4 item 5 and 1108 Section 5.3 item 6 respectively) derive a sequence of ESAs from the 1109 sequence of CSAs and use the derived sequence (see Figure 1). There 1110 are two main goals achieved through this indirection: 1112 o Elimination of expired authentication keys and deduplication of 1113 security associations. This is done as early as possible to keep 1114 subsequent procedures focused on their respective tasks. 1116 o Maintenance of particular ordering within the derived sequence of 1117 ESAs. The ordering deterministically depends on the ordering 1118 within the interface's sequence of CSAs and the ordering within 1119 KeyChain sequence of each CSA. The particular correlation 1120 maintained by this procedure implements a concept of fair 1121 (independent of number of keys contained by each) competition 1122 between CSAs. 1124 The deriving procedure uses the following input arguments: 1126 o input sequence of CSAs 1127 o direction (sending or receiving) 1129 o current time (CT) 1131 The processing of input arguments begins with an empty output 1132 sequence of ESAs and consists of the following steps: 1134 1. Make a temporary copy of the input sequence of CSAs. 1136 2. Remove all expired authentication keys from each KeyChain 1137 sequence of the copy, that is, any keys such that: 1139 * for receiving: KeyStartAccept is greater than CT or 1140 KeyStopAccept is less than CT 1142 * for sending: KeyStartGenerate is greater than CT or 1143 KeyStopGenerate is less than CT 1145 Note well that there are no special exceptions. Remove all 1146 expired keys, even if there are no keys left after that (see 1147 Section 7.4). 1149 3. Use the copy to populate the output sequence of ESAs as follows: 1151 1. When the KeyChain sequence of the first CSA contains at least 1152 one key, use its first key to produce an ESA with fields set 1153 as follows: 1155 HashAlgo Set to HashAlgo of the current CSA. 1157 KeyID Set to LocalKeyID modulo 2^16 of the current 1158 key of the current CSA. 1160 AuthKeyOctets Set to AuthKeyOctets of the current key of the 1161 current CSA. 1163 Append this ESA to the end of the output sequence. 1165 2. When the KeyChain sequence of the second CSA contains at 1166 least one key, use its first key the same way and so forth 1167 until all first keys of the copy are processed. 1169 3. When the KeyChain sequence of the first CSA contains at least 1170 two keys, use its second key the same way. 1172 4. When the KeyChain sequence of the second CSA contains at 1173 least two keys, use its second key the same way and so forth 1174 until all second keys of the copy are processed. 1176 5. And so forth until all keys of all CSAs of the copy are 1177 processed, exactly once each. 1179 In the description above the ordinals ("first", "second", and so 1180 on) with regard to keys stand for an element position after the 1181 removal of expired keys, not before. For example, if a KeyChain 1182 sequence was { Ka, Kb, Kc, Kd } before the removal and became 1183 { Ka, Kd } after, then Ka would be the "first" element and Kd 1184 would be the "second". 1186 4. Deduplicate the ESAs in the output sequence, that is, wherever 1187 two or more ESAs exist that share the same (HashAlgo, KeyID, 1188 AuthKeyOctets) triplet value, remove all of these ESAs except the 1189 one closest to the beginning of the sequence. 1191 The resulting sequence will contain zero or more unique ESAs, ordered 1192 in a way deterministically correlated with ordering of CSAs within 1193 the original input sequence of CSAs and ordering of keys within each 1194 KeyChain sequence. This ordering maximizes the probability of having 1195 equal amount of keys per original CSA in any N first elements of the 1196 resulting sequence. Possible optimizations of this deriving 1197 procedure are outlined in Section 6.3. 1199 5.3. Updates to Packet Sending 1201 Perform the following authentication-specific processing after the 1202 instance of the original protocol considers an outgoing Babel packet 1203 ready for sending, but before the packet is actually sent (see 1204 Figure 1). After that send the packet regardless if the 1205 authentication-specific processing modified the outgoing packet or 1206 left it intact. 1208 1. If the current outgoing interface's sequence of CSAs is empty, 1209 finish authentication-specific processing and consider the 1210 packet ready for sending. 1212 2. Increment TS/PC number of the current outgoing interface as 1213 explained in Section 5.1. 1215 3. Perform a lookup in the sent TS/PC numbers table for an entry 1216 having Interface equal to the current outgoing interface and 1217 FirstTimestamp equal to the current point in time. If such an 1218 entry does not exist, add a new entry to the table with the 1219 fields set as follows: 1221 Interface Set to the current outgoing interface. 1223 FirstTimestamp Set to the current point in time. 1225 FirstTS Set to the current value of LocalTS variable of 1226 the current outgoing interface. 1228 FirstPC Set to the current value of LocalPC variable of 1229 the current outgoing interface. 1231 4. Iterate over all the IHU TLVs of the packet body and for each 1232 TLV perform a lookup in the ANM table for an entry having 1233 Interface equal to the current outgoing interface and Source 1234 equal to the Address field of the TLV. If such an entry exists, 1235 add to the IHU TLV a TS/PC sub-TLV with fields set as follows: 1237 Type Set to TBD1. 1239 Length Set to 6. 1241 PacketCounter Set to LastPC of the entry. 1243 Timestamp Set to LastTS of the entry. 1245 Update the Length field of the IHU TLV as necessary. 1247 Note that the current step may involve byte order conversion. 1249 5. Add to the packet body (see the note at the end of this section) 1250 a TS/PC TLV with fields set as follows: 1252 Type Set to 11. 1254 Length Set to 6. 1256 PacketCounter Set to the current value of LocalPC variable of 1257 the current outgoing interface. 1259 Timestamp Set to the current value of LocalTS variable of 1260 the current outgoing interface. 1262 Note that the current step may involve byte order conversion. 1264 6. Derive a sequence of ESAs using procedure defined in Section 5.2 1265 with the current interface's sequence of CSAs as the input 1266 sequence of CSAs, the current time as CT and "sending" as the 1267 direction. Proceed to the next step even if the derived 1268 sequence is empty. 1270 7. Iterate over the derived sequence using its ordering. For each 1271 ESA add to the packet body (see the note at the end of this 1272 section) an HMAC TLV with fields set as follows: 1274 Type Set to 12. 1276 Length Set to 2 plus digest length of HashAlgo of the current 1277 ESA. 1279 KeyID Set to KeyID of the current ESA. 1281 Digest Size exactly equal to the digest length of HashAlgo of 1282 the current ESA. Pad (see Section 2.2) using the 1283 source address of the current packet (see Section 6.1). 1285 As soon as there are MaxDigestsOut HMAC TLVs added to the 1286 current packet body, immediately proceed to the next step. 1288 Note that the current step may involve byte order conversion. 1290 8. Increment the "Body length" field value of the current packet 1291 header by the total length of TS/PC and HMAC TLVs appended to 1292 the current packet body so far plus the total amount of any 1293 octets appended to the IHU TLVs to make space for the TS/PC sub- 1294 TLVs. 1296 Note that the current step may involve byte order conversion. 1298 9. Make a temporary copy of the current packet. 1300 10. Iterate over the derived sequence again, using the same order 1301 and number of elements. For each ESA (and respectively for each 1302 HMAC TLV recently appended to the current packet body) compute 1303 an HMAC result (see Section 2.4) using the temporary copy (not 1304 the original packet) as Text, HashAlgo of the current ESA as H, 1305 and AuthKeyOctets of the current ESA as K. Write the HMAC 1306 result to the Digest field of the current HMAC TLV (see Table 4) 1307 of the current packet (not the copy). 1309 11. After this point, allow no more changes to the current packet 1310 header and body and consider it ready for sending. 1312 Note that even when the derived sequence of ESAs is empty, the packet 1313 is sent anyway with only a TS/PC TLV appended to its body. Although 1314 such a packet would not be authenticated, the presence of the sole 1315 TS/PC TLV would indicate authentication key exhaustion to operators 1316 of neighbouring Babel speakers. See also Section 7.4. 1318 Also note that it is possible to place the authentication-specific 1319 TLVs in the packet's sequence of TLVs in a number of different valid 1320 ways so long as there is exactly one TS/PC TLV in the sequence and 1321 the ordering of HMAC TLVs relative to each other, as produced in step 1322 5 above, is preserved. 1324 For example, see Figure 2. The diagrams represent a Babel packet 1325 without (D1) and with (D2, D3, D4) authentication-specific TLVs. The 1326 optional trailing data block that is present in D1 is preserved in 1327 D2, D3, and D4. Indexing (1, 2, ..., n) of the HMAC TLVs means the 1328 order in which the sending procedure produced them (and respectively 1329 the HMAC results). In D2 the added TLVs are appended: the previously 1330 existing TLVs are followed by the TS/PC TLV, which is followed by the 1331 HMAC TLVs. In D3 the added TLVs are prepended: the TS/PC TLV is the 1332 first and is followed by the HMAC TLVs, which are followed by the 1333 previously existing TLVs. In D4 the added TLVs are intermixed with 1334 the previously existing TLVs and the TS/PC TLV is placed after the 1335 HMAC TLVs. All three packets meet the requirements above. 1337 Implementors SHOULD use appending (D2) for adding the authentication- 1338 specific TLVs to the sequence, this is expected to result in more 1339 straightforward implementation and troubleshooting in most use cases. 1341 5.4. Updates to Packet Receiving 1343 Perform the following authentication-specific processing after an 1344 incoming Babel packet is received from the local network stack, but 1345 before it is acted upon by the Babel protocol instance (see 1346 Figure 1). The final action conceptually depends not only upon the 1347 result of the authentication-specific processing, but also on the 1348 current value of RxAuthRequired parameter. Immediately after any 1349 processing step below accepts or refuses the packet, either deliver 1350 the packet to the instance of the original protocol (when the packet 1351 is accepted or RxAuthRequired is FALSE) or discard it (when the 1352 packet is refused and RxAuthRequired is TRUE). 1354 1. If the current incoming interface's sequence of CSAs is empty, 1355 accept the packet. 1357 2. If the current packet does not contain exactly one TS/PC TLV, 1358 refuse it. 1360 3. Perform a lookup in the ANM table for an entry having Interface 1361 equal to the current incoming interface and Source equal to the 1362 source address of the current packet. If such an entry does not 1363 exist, immediately proceed to the next step. Otherwise, compare 1364 the entry's LastTS and LastPC field values with Timestamp and 1365 PacketCounter values respectively of the TS/PC TLV of the 1366 packet. That is, refuse the packet, if at least one of the 1367 following two conditions is true: 1369 * Timestamp is less than LastTS 1371 * Timestamp is equal to LastTS and PacketCounter is not greater 1372 than LastPC 1374 Note that the current step may involve byte order conversion. 1376 4. If the current packet has any IHU TLVs that have the Address 1377 field value equal to one of the addresses of the current 1378 incoming interface, iterate over those TLVs. For each such TLV, 1379 if it does not contain exactly one TS/PC sub-TLV, immediately 1380 refuse the current packet. Otherwise, if the sent TS/PC numbers 1381 table has no entries having Interface equal to the current 1382 incoming interface, immediately refuse the current packet. 1383 Otherwise, from those entries pick the one with the lowest 1384 FirstTimestamp and use its FirstTS and FirstPC values as a TS/PC 1385 number. If that number is greater than the TS/PC number in the 1386 sub-TLV, immediately refuse the current packet. 1388 Note that the current step may involve byte order conversion. 1390 5. Derive a sequence of ESAs using procedure defined in Section 5.2 1391 with the current interface's sequence of CSAs as the input 1392 sequence of CSAs, current time as CT and "receiving" as the 1393 direction. If the derived sequence is empty, refuse the packet. 1395 6. Make a temporary copy of the current packet. 1397 7. Pad (see Section 2.2) every HMAC TLV present in the temporary 1398 copy (not the original packet) using the source address of the 1399 original packet. 1401 8. Iterate over all the HMAC TLVs of the original input packet (not 1402 the copy) using their order of appearance in the packet. For 1403 each HMAC TLV look up all ESAs in the derived sequence such that 1404 2 plus digest length of HashAlgo of the ESA is equal to Length 1405 of the TLV and KeyID of the ESA is equal to value of KeyID of 1406 the TLV. Iterate over these ESAs in the relative order of their 1407 appearance on the full sequence of ESAs. Note that nesting the 1408 iterations the opposite way (over ESAs, then over HMAC TLVs) 1409 would be wrong. 1411 For each of these ESAs compute an HMAC result (see Section 2.4) 1412 using the temporary copy (not the original packet) as Text, 1413 HashAlgo of the current ESA as H, and AuthKeyOctets of the 1414 current ESA as K. If the current HMAC result exactly matches 1415 the contents of Digest field of the current HMAC TLV, 1416 immediately proceed to the next step. Otherwise, if the number 1417 of HMAC computations done for the current packet so far is equal 1418 to MaxDigestsIn, immediately proceed to the next step. 1419 Otherwise follow the normal order of iterations. 1421 Note that the current step may involve byte order conversion. 1423 9. Refuse the input packet unless there was a matching HMAC result 1424 in the previous step. 1426 10. Modify the ANM table, using the same index as for the entry 1427 lookup above, to contain an entry with LastTS set to the value 1428 of Timestamp and LastPC set to the value of PacketCounter fields 1429 of the TS/PC TLV of the current packet. That is, either add a 1430 new ANM table entry or update the existing one, depending on the 1431 result of the entry lookup above. Reset the entry's aging timer 1432 to the current value of ANMTimeout. 1434 Note that the current step may involve byte order conversion. 1436 11. Accept the input packet. 1438 An implementation SHOULD before the authentication-specific 1439 processing above perform those basic procedures of the original 1440 protocol that don't take any protocol actions upon the contents of 1441 the packet but discard it unless the packet is sufficiently well- 1442 formed for further processing. Although exact composition of such 1443 procedures belongs to the scope of the original protocol, it seems 1444 reasonable to state that a packet SHOULD be discarded early, 1445 regardless if any authentication-specific processing is due, unless 1446 its source address conforms to Section 3.1 of [BABEL] and is not the 1447 receiving speaker's own address (see item (e) of Section 9). 1449 Note that RxAuthRequired affects only the final action, but not the 1450 defined flow of authentication-specific processing. The purpose of 1451 this is to preserve authentication-specific processing feedback (such 1452 as log messages and event counters updates) even with RxAuthRequired 1453 set to FALSE. This allows an operator to predict the effect of 1454 changing RxAuthRequired from FALSE to TRUE during a migration 1455 scenario (Section 7.3) implementation. 1457 5.5. Authentication-Specific Statistics Maintenance 1459 A Babel speaker implementing this mechanism SHOULD maintain a set of 1460 counters for the following events, per protocol instance and per 1461 interface: 1463 a. Sending of an unauthenticated Babel packet through an interface 1464 having an empty sequence of CSAs (Section 5.3 item 1). 1466 b. Sending of an unauthenticated Babel packet with a TS/PC TLV but 1467 without any HMAC TLVs due to an empty derived sequence of ESAs 1468 (Section 5.3 item 6). 1470 c. Sending of an authenticated Babel packet containing both TS/PC 1471 and HMAC TLVs (Section 5.3 item 11). 1473 d. Accepting of a Babel packet received through an interface having 1474 an empty sequence of CSAs (Section 5.4 item 1). 1476 e. Refusing of a received Babel packet due to an empty derived 1477 sequence of ESAs (Section 5.4 item 5). 1479 f. Refusing of a received Babel packet that does not contain exactly 1480 one TS/PC TLV (Section 5.4 item 2). 1482 g. Refusing of a received Babel packet due to the TS/PC TLV failing 1483 the ANM table check (Section 5.4 item 3). In the view of future 1484 extensions this event SHOULD leave out some small amount, per 1485 current (Interface, Source, LastTS, LastPC) tuple, of the packets 1486 refused due to Timestamp value being equal to LastTS and 1487 PacketCounter value being equal to LastPC. 1489 h. Refusing of a received Babel packet missing any HMAC TLVs 1490 (Section 5.4 item 9). 1492 i. Refusing of a received Babel packet due to none of the processed 1493 HMAC TLVs passing the ESA check (Section 5.4 item 9). 1495 j. Accepting of a received Babel packet having both TS/PC and HMAC 1496 TLVs (Section 5.4 item 11). 1498 k. Delivery of a refused packet to the instance of the original 1499 protocol due to RxAuthRequired parameter set to FALSE. 1501 Note that terms "accepting" and "refusing" are used in the sense of 1502 the receiving procedure, that is, "accepting" does not mean a packet 1503 delivered to the instance of the original protocol purely because the 1504 RxAuthRequired parameter is set to FALSE. Event counters readings 1505 SHOULD be available to the operator at runtime. 1507 6. Implementation Notes 1509 6.1. Source Address Selection for Sending 1511 Section 3.1 of [BABEL] allows for exchange of protocol datagrams 1512 using IPv4 or IPv6 or both. The source address of the datagram is a 1513 unicast (link-local in the case of IPv6) address. Within an address 1514 family used by a Babel speaker there may be more than one addresses 1515 eligible for the exchange and assigned to the same network interface. 1516 The original specification considers this case out of scope and 1517 leaves it up to the speaker's network stack to select one particular 1518 address as the datagram source address. But the sending procedure 1519 requires (Section 5.3 item 7) exact knowledge of packet source 1520 address for proper padding of HMAC TLVs. 1522 As long as a network interface has more than one addresses eligible 1523 for the exchange within the same address family, the Babel speaker 1524 SHOULD internally choose one of those addresses for Babel packet 1525 sending purposes and make this choice to both the sending procedure 1526 and the network stack (see Figure 1). Wherever this requirement 1527 cannot be met, this limitation MUST be clearly stated in the system 1528 documentation to allow an operator to plan network address management 1529 accordingly. 1531 6.2. Output Buffer Management 1533 An instance of the original protocol buffers produced TLVs until the 1534 buffer becomes full or a delay timer has expired. This is performed 1535 independently for each Babel interface with each buffer sized 1536 according to the interface MTU (see Sections 3.1 and 4 of [BABEL]). 1538 Since TS/PC and HMAC TLVs and any other TLVs, in the first place 1539 those of the original protocol, share the same packet space (see 1540 Figure 2) and respectively the same buffer space, a particular 1541 portion of each interface buffer needs to be reserved for 1 TS/PC TLV 1542 and up to MaxDigestsOut HMAC TLVs. The amount (R) of this reserved 1543 buffer space is calculated as follows: 1545 R = St + MaxDigestsOut * Sh = 1546 = 8 + MaxDigestsOut * (4 + Lmax) 1548 St Is the size of a TS/PC TLV. 1550 Sh Is the size of an HMAC TLV. 1552 Lmax Is the maximum digest length in octets possible for a 1553 particular interface. It SHOULD be calculated based on 1554 particular interface's sequence of CSAs, but MAY be taken as 1555 the maximum digest length supported by particular 1556 implementation. 1558 An implementation allowing for per-interface value of MaxDigestsOut 1559 or Lmax has to account for different value of R across different 1560 interfaces, even having the same MTU. An implementation allowing for 1561 runtime change of the value of R (due to MaxDigestsOut or Lmax) has 1562 to take care of the TLVs already buffered by the time of the change, 1563 especially when the value of R increases. 1565 The maximum safe value of MaxDigestsOut parameter depends on the 1566 interface MTU and maximum digest length used. In general, at least 1567 200-300 octets of a Babel packet should be always available to data 1568 other than TS/PC and HMAC TLVs. An implementation following the 1569 requirements of Section 4 of [BABEL] would send packets sized 512 1570 octets or larger. If, for example, the maximum digest length is 64 1571 octets and MaxDigestsOut value is 4, the value of R would be 280, 1572 leaving less than a half of a 512-octet packet for any other TLVs. 1573 As long as the interface MTU is larger or digest length is smaller, 1574 higher values of MaxDigestsOut can be used safely. 1576 6.3. Optimizations of ESAs Deriving 1578 The following optimizations of the ESAs deriving procedure can reduce 1579 amount of CPU time consumed by authentication-specific processing, 1580 preserving an implementation's effective behaviour. 1582 a. The most straightforward implementation would treat the deriving 1583 procedure as a per-packet action. But since the procedure is 1584 deterministic (its output depends on its input only), it is 1585 possible to significantly reduce the number of times the 1586 procedure is performed. 1588 The procedure would obviously return the same result for the same 1589 input arguments (sequence of CSAs, direction, CT) values. 1590 However, it is possible to predict when the result will remain 1591 the same even for a different input. That is, when the input 1592 sequence of CSAs and the direction both remain the same but CT 1593 changes, the result will remain the same as long as CT's order on 1594 the time axis (relative to all critical points of the sequence of 1595 CSAs) remains unchanged. Here, the critical points are 1596 KeyStartAccept and KeyStopAccept (for the "receiving" direction) 1597 and KeyStartGenerate and KeyStopGenerate (for the "sending" 1598 direction) of all keys of all CSAs of the input sequence. In 1599 other words, in this case the result will remain the same as long 1600 as both none of the active keys expire and none of the inactive 1601 keys enter into operation. 1603 An implementation optimized this way would perform the full 1604 deriving procedure for a given (interface, direction) pair only 1605 after an operator's change to the interface's sequence of CSAs or 1606 after reaching one of the critical points mentioned above. 1608 b. Considering that the sending procedure iterates over at most 1609 MaxDigestsOut elements of the derived sequence of ESAs 1610 (Section 5.3 item 7), there would be little sense in the case of 1611 "sending" direction in returning more than MaxDigestsOut ESAs in 1612 the derived sequence. Note that a similar optimization would be 1613 relatively difficult in the case of "receiving" direction, since 1614 the number of ESAs actually used in examining a particular 1615 received packet (not to be confused with the number of HMAC 1616 computations) depends on additional factors besides just 1617 MaxDigestsIn. 1619 6.4. Security Associations Duplication 1621 This specification defines three data structures as finite sequences: 1622 a KeyChain sequence, an interface's sequence of CSAs, and a sequence 1623 of ESAs. There are associated semantics to take into account during 1624 implementation, in that the same element can appear multiple times at 1625 different positions of the sequence. In particular, none of CSA 1626 structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets) 1627 alone or in a combination has to be unique within a given CSA, or 1628 within a given sequence of CSAs, or within all sequences of CSAs of a 1629 Babel speaker. 1631 In the CSA space defined this way, for any two authentication keys 1632 their one field (in)equality would not imply their another field 1633 (in)equality. In other words, it is acceptable to have more than one 1634 authentication key with the same LocalKeyID or the same AuthKeyOctets 1635 or both at a time. It is a conscious design decision that CSA 1636 semantics allow for duplication of security associations. 1637 Consequently, ESA semantics allow for duplication of intermediate 1638 ESAs in the sequence until the explicit deduplication (Section 5.2 1639 item 4). 1641 One of the intentions of this is to define the security association 1642 management in a way that allows the addressing of some specifics of 1643 Babel as a mesh routing protocol. For example, a system operator 1644 configuring a Babel speaker to participate in more than one 1645 administrative domain could find each domain using its own 1646 authentication key (AuthKeyOctets) under the same LocalKeyID value, 1647 e.g., a "well-known" or "default" value like 0 or 1. Since 1648 reconfiguring the domains to use distinct LocalKeyID values isn't 1649 always feasible, the multi-domain Babel speaker using several 1650 distinct authentication keys under the same LocalKeyID would make a 1651 valid use case for such duplication. 1653 Furthermore, if in this situation the operator decided to migrate one 1654 of the domains to a different LocalKeyID value in a seamless way, 1655 respective Babel speakers would use the same authentication key 1656 (AuthKeyOctets) under two different LocalKeyID values for the time of 1657 the transition (see also item (f) of Section 9). This would make a 1658 similar use case. 1660 Another intention of this design decision is to decouple security 1661 association management from authentication key management as much as 1662 possible, so that the latter, be it manual keying or a key management 1663 protocol, could be designed and implemented independently (as 1664 respective reasoning made in Section 3.1 of [RIP2-AUTH] still 1665 applies). This way the additional key management constraints, if 1666 any, would remain out of scope of this authentication mechanism. A 1667 similar thinking justifies LocalKeyID field having bit length in ESA 1668 structure definition, but not in that of CSA. 1670 7. Network Management Aspects 1672 7.1. Backward Compatibility 1674 Support of this mechanism is optional, it does not change the default 1675 behaviour of a Babel speaker and causes no compatibility issues with 1676 speakers properly implementing the original Babel specification. 1677 Given two Babel speakers, one implementing this mechanism and 1678 configured for authenticated exchange (A) and another not 1679 implementing it (B), these would not distribute routing information 1680 uni-directionally or form a routing loop or experience other protocol 1681 logic issues specific purely to the use of this mechanism. 1683 The Babel design requires a bidirectional neighbour reachability 1684 condition between two given speakers for a successful exchange of 1685 routing information. Apparently, in the case above neighbour 1686 reachability would be uni-directional. Presence of TS/PC and HMAC 1687 TLVs in Babel packets sent by A would be transparent to B. But lack 1688 of authentication data in Babel packets send by B would make them 1689 effectively invisible to the instance of the original protocol of A. 1690 Uni-directional links are not specific to use of this mechanism, they 1691 naturally exist on their own and are properly detected and coped with 1692 by the original protocol (see Section 3.4.2 of [BABEL]). 1694 7.2. Multi-Domain Authentication 1696 The receiving procedure treats a packet as authentic as soon as one 1697 of its HMAC TLVs passes the check against the derived sequence of 1698 ESAs. This allows for packet exchange authenticated with multiple 1699 (hash algorithm, authentication key) pairs simultaneously, in 1700 combinations as arbitrary as permitted by MaxDigestsIn and 1701 MaxDigestsOut. 1703 For example, consider three Babel speakers with one interface each, 1704 configured with the following CSAs: 1706 o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key 1707 SK2) 1709 o speaker B: (hash algorithm H1; key SK1) 1711 o speaker C: (hash algorithm H1; key SK2) 1713 Packets sent by A would contain 2 HMAC TLVs each, packets sent by B 1714 and C would contain 1 HMAC TLV each. A and B would authenticate the 1715 exchange between themselves using H1 and SK1; A and C would use H1 1716 and SK2; B and C would discard each other's packets. 1718 Consider a similar set of speakers configured with different CSAs: 1720 o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key 1721 SK4) 1723 o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys 1724 SK5 and SK6) 1726 o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm 1727 H5, key SK8) 1729 Packets sent by D would contain 2 HMAC TLVs each, packets sent by E 1730 and F would contain 3 HMAC TLVs each. D and E would authenticate the 1731 exchange between themselves using H2 and SK3; D and F would use H3 1732 and SK4; E and F would discard each other's packets. The 1733 simultaneous use of H4, SK5, and SK6 by E, as well as use of SK7, H5, 1734 and SK8 by F (for their own purposes) would remain insignificant to 1735 A. 1737 An operator implementing a multi-domain authentication should keep in 1738 mind that values of MaxDigestsIn and MaxDigestsOut may be different 1739 both within the same Babel speaker and across different speakers. 1740 Since the minimum value of both parameters is 2 (see Section 3.4 and 1741 Section 3.5), when more than 2 authentication domains are configured 1742 simultaneously it is advised to confirm that every involved speaker 1743 can handle sufficient number of HMAC results for both sending and 1744 receiving. 1746 The recommended method of Babel speaker configuration for multi- 1747 domain authentication is not only using a different authentication 1748 key for each domain, but also using a separate CSA for each domain, 1749 even when hash algorithms are the same. This allows for fair 1750 competition between CSAs and sometimes limits the consequences of a 1751 possible misconfiguration to the scope of one CSA. See also item (f) 1752 of Section 9. 1754 7.3. Migration to and from Authenticated Exchange 1756 It is common in practice to consider a migration to authenticated 1757 exchange of routing information only after the network has already 1758 been deployed and put to an active use. Performing the migration in 1759 a way without regular traffic interruption is typically demanded, and 1760 this specification allows a smooth migration using the RxAuthRequired 1761 interface parameter defined in Section 3.1. This measure is similar 1762 to the "transition mode" suggested in Section 5 of [OSPF3-AUTH]. 1764 An operator performing the migration needs to arrange configuration 1765 changes as follows: 1767 1. Decide on particular hash algorithm(s) and key(s) to be used. 1769 2. Identify all speakers and their involved interfaces that need to 1770 be migrated to authenticated exchange. 1772 3. For each of the speakers and the interfaces to be reconfigured 1773 first set RxAuthRequired parameter to FALSE, then configure 1774 necessary CSA(s). 1776 4. Examine the speakers to confirm that Babel packets are 1777 successfully authenticated according to the configuration 1778 (supposedly, through examining ANM table entries and 1779 authentication-specific statistics, see Figure 1) and address any 1780 discrepancies before proceeding further. 1782 5. For each of the speakers and the reconfigured interfaces set the 1783 RxAuthRequired parameter to TRUE. 1785 Likewise, temporarily setting RxAuthRequired to FALSE can be used to 1786 migrate smoothly from an authenticated packet exchange back to 1787 unauthenticated one. 1789 7.4. Handling of Authentication Keys Exhaustion 1791 This specification employs a common concept of multiple authenticaion 1792 keys co-existing for a given interface, with two independent lifetime 1793 ranges associated with each key (one for sending and another for 1794 receiving). It is typically recommended to configure the keys using 1795 finite lifetimes, adding new keys before the old keys expire. 1796 However, it is obviously possible for all keys to expire for a given 1797 interface (for sending or receiving or both). Possible ways of 1798 addressing this situation raise their own concerns: 1800 o Automatic switching to unauthenticated protocol exchange. This 1801 behaviour invalidates the initial purposes of authentication and 1802 is commonly viewed as "unacceptable" ([RIP2-AUTH] Section 5.1, 1803 [OSPF2-AUTH] Section 3.2, [OSPF3-AUTH] Section 3, [OSPF3-AUTH-BIS] 1804 Section 3). 1806 o Stopping routing information exchange over the interface. This 1807 behaviour is likely to impact regular traffic routing and is 1808 commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], 1809 [OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this 1810 regard. 1812 o Use of the "most recently expired" key over its intended lifetime 1813 range. This behaviour is recommended for implementation in 1814 [RIP2-AUTH], [OSPF2-AUTH], [OSPF3-AUTH], but not in 1815 [OSPF3-AUTH-BIS]. The use may become a problem due to an offline 1816 cryptographic attack (see item (f) of Section 9) or a compromise 1817 of the key. In addition, telling a recently expired key from a 1818 key never ever been in a use may be impossible after a router 1819 restart. 1821 Design of this mechanism prevents the automatic switching to 1822 unauthenticated exchange and is consistent with similar 1823 authentication mechanisms in this regard. But since the best choice 1824 between two other options depends on local site policy, this decision 1825 is left up to the operator rather than the implementor (in a way 1826 resembling the "fail secure" configuration knob described in 1827 Section 5.1 of [RIP2-AUTH]). 1829 Although the deriving procedure does not allow for any exceptions in 1830 expired keys filtering (Section 5.2 item 2), the operator can 1831 trivially enforce one of the two remaining behaviour options through 1832 local key management procedures. In particular, when using the key 1833 over its intended lifetime is more preferred than regular traffic 1834 disruption, the operator would explicitly leave the old key expiry 1835 time open until the new key is added to the router configuration. In 1836 the opposite case the operator would always configure the old key 1837 with a finite lifetime and bear associated risks. 1839 8. Implementation Status 1841 [RFC Editor: before publication please remove this section and the 1842 reference to [RFC7942], along the guidelines of which this section 1843 exists to assist document reviewers.] 1845 FIXME: update with the current status 1847 9. Security Considerations 1849 Use of this mechanism implies requirements common to a use of shared 1850 authentication keys, including, but not limited to: 1852 o holding the keys secret, 1854 o including sufficient amounts of random bits into each key, 1856 o rekeying on a regular basis, and 1858 o never reusing a used key for a different purpose 1860 That said, proper design and implementation of a key management 1861 policy is out of scope of this work. Many publications on this 1862 subject exist and should be used for this purpose (BCP 107 [RFC4107], 1863 BCP 132 [RFC4962], and [RFC6039] may be suggested as starting 1864 points). 1866 It is possible for a network that exercises authentication keys 1867 rollover to experience accidental expiration of all the keys for a 1868 network interface as discussed at greater length in Section 7.4. 1869 With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in 1870 such an event the Babel speaker MUST send a "last key expired" 1871 notification to the operator (e.g. via syslog, SNMP, and/or other 1872 implementation-specific means), most likely in relation to the item 1873 (b) of Section 5.5. Also, any actual occurrence of an authentication 1874 key expiration MUST cause a security event to be logged by the 1875 implementation. The log item MUST include at least a note that the 1876 authentication key has expired, the Babel routing protocol 1877 instance(s) affected, the network interface(s) affected, the 1878 LocalKeyID that is affected, and the current date/time. Operators 1879 are encouraged to check such logs as an operational security 1880 practice. 1882 Considering particular attacks being in-scope or out of scope on one 1883 hand and measures taken to protect against particular in-scope 1884 attacks on the other, the original Babel protocol and this 1885 authentication mechanism are in line with similar datagram-based 1886 routing protocols and their respective mechanisms. In particular, 1887 the primary concerns addressed are: 1889 a. Peer Entity Authentication 1891 The Babel speaker authentication mechanism defined herein is 1892 believed to be as strong as is the class itself that it belongs 1893 to. This specification is built on fundamental concepts 1894 implemented for authentication of similar routing protocols: per- 1895 packet authentication, use of HMAC construct, use of shared keys. 1896 Although this design approach does not address all possible 1897 concerns, it is so far known to be sufficient for most practical 1898 cases. 1900 b. Data Integrity 1902 Meaningful parts of a Babel datagram are the contents of the 1903 Babel packet (in the definition of Section 4.2 of [BABEL]) and 1904 the source address of the datagram (Section 3.5.3 ibid.). This 1905 mechanism authenticates both parts using the HMAC construct, so 1906 that making any meaningful change to an authenticated packet 1907 after it has been emitted by the sender should be as hard as 1908 attacking the HMAC construct itself or successfully recovering 1909 the authentication key. 1911 Note well that any trailing data of the Babel datagram is not 1912 meaningful in the scope of the original specification and does 1913 not belong to the Babel packet. Integrity of the trailing data 1914 is respectively not protected by this mechanism. At the same 1915 time, although any TLV extra data is also not meaningful in the 1916 same scope, its integrity is protected, since this extra data is 1917 a part of the Babel packet (see Figure 2). 1919 c. Denial of Service 1921 Proper deployment of this mechanism in a Babel network 1922 significantly increases the efforts required for an attacker to 1923 feed arbitrary Babel PDUs into protocol exchange (with an intent 1924 of attacking a particular Babel speaker or disrupting exchange of 1925 regular traffic in a routing domain). It also protects the 1926 neighbour table from being flooded with forged speaker entries. 1928 At the same time, this protection comes with a price of CPU time 1929 being spent on HMAC computations. This may be a concern for low- 1930 performance CPUs combined with high-speed interfaces, as 1931 sometimes seen in embedded systems and hardware routers. The 1932 MaxDigestsIn parameter, which is used to limit the maximum amount 1933 of CPU time spent on a single received Babel packet, addresses 1934 this concern to some extent. 1936 d. Reflection Attacks 1938 Given the approach discussed in item (b), the only potential 1939 reflection attack on this mechanism could be replaying exact 1940 copies of Babel packets back to the sender from the same source 1941 address. The mitigation in this case is straightforward and is 1942 discussed in Section 5.4. 1944 The following in-scope concern is only partially addressed: 1946 e. Replay Attacks 1948 This specification establishes a basic replay protection measure 1949 (see Section 3.6), defines a timeout parameter affecting its 1950 strength (see Section 3.7), and outlines implementation methods 1951 also affecting protection strength in several ways (see 1952 Section 5.1). The implementor's choice of the timeout value and 1953 particular implementation methods may be suboptimal due to, for 1954 example, insufficient hardware resources of the Babel speaker. 1955 Furthermore, it may be possible that an operator configures the 1956 timeout and the methods to address particular local specifics and 1957 this further weakens the protection. An operator concerned about 1958 replay attack protection strength should understand these factors 1959 and their meaning in a given network segment. 1961 That said, a particular form of replay attack on this mechanism 1962 remains possible anyway. Whether there are two or more network 1963 segments using the same CSA and there is an adversary that 1964 captures Babel packets on one segment and replays on another (and 1965 vice versa due to the bidirectional reachability requirement for 1966 neighbourship), some of the speakers on one such segment will 1967 detect the "virtual" neighbours from another and may prefer them 1968 for some destinations. This applies even more so as Babel 1969 doesn't require a common pre-configured network prefix between 1970 neighbours. 1972 A reliable solution to this particular problem, which Section 4.5 1973 of [RFC7186] discusses as well, is not currently known. It is 1974 recommended that the operators use distinct CSAs for distinct 1975 network segments. 1977 The following in-scope concerns are not addressed: 1979 f. Offline Cryptographic Attacks 1981 This mechanism is obviously subject to offline cryptographic 1982 attacks. As soon as an attacker has obtained a copy of an 1983 authenticated Babel packet of interest (which gets easier to do 1984 in wireless networks), he has got all the parameters of the 1985 authentication-specific processing performed by the sender, 1986 except authentication key(s) and choice of particular hash 1987 algorithm(s). Since digest lengths of common hash algorithms are 1988 well-known and can be matched with those seen in the packet, 1989 complexity of this attack is essentially that of the 1990 authentication key attack. 1992 Viewing the cryptographic strength of particular hash algorithms 1993 as a concern of its own, the main practical means of resisting 1994 offline cryptographic attacks on this mechanism are periodic 1995 rekeying and use of strong keys with a sufficient number of 1996 random bits. 1998 It is important to understand that in the case of multiple keys 1999 being used within single interface (for a multi-domain 2000 authentication or during a key rollover) the strength of the 2001 combined configuration would be that of the weakest key, since 2002 only one successful HMAC test is required for an authentic 2003 packet. Operators concerned about offline cryptographic attacks 2004 should enforce the same strength policy for all keys used for a 2005 given interface. 2007 Note that a special pathological case is possible with this 2008 mechanism. Whenever two or more authentication keys are 2009 configured for a given interface such that all keys share the 2010 same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 2011 2^16 is different for each key, these keys will not be treated as 2012 duplicate (Section 5.2 item 4), but an HMAC result computed for a 2013 given packet will be the same for each of these keys. In the 2014 case of sending procedure this can produce multiple HMAC TLVs 2015 with exactly the same value of the Digest field, but different 2016 values of KeyID field. In this case the attacker will see that 2017 the keys are the same, even without the knowledge of the key 2018 itself. Reuse of authentication keys is not the intended use 2019 case of this mechanism and should be strongly avoided. 2021 g. Non-repudiation 2023 This specification relies on a use of shared keys. There is no 2024 timestamp infrastructure and no key revocation mechanism defined 2025 to address a shared key compromise. Establishing the time that a 2026 particular authentic Babel packet was generated is thus not 2027 possible. Proving that a particular Babel speaker had actually 2028 sent a given authentic packet is also impossible as soon as the 2029 shared key is claimed compromised. Even with the shared key not 2030 being compromised, reliably identifying the speaker that had 2031 actually sent a given authentic Babel packet is not possible any 2032 better than proving the speaker belongs to the group sharing the 2033 key (any of the speakers sharing a key can impose any other 2034 speaker sharing the same key). 2036 h. Confidentiality Violations 2038 The original Babel protocol does not encrypt any of the 2039 information contained in its packets. The contents of a Babel 2040 packet is trivial to decode, revealing network topology details. 2041 This mechanism does not improve this situation in any way. Since 2042 routing protocol messages are not the only kind of information 2043 subject to confidentiality concerns, a complete solution to this 2044 problem is likely to include measures based on the channel 2045 security model, such as IPSec and WPA2 at the time of this 2046 writing. 2048 i. Key Management 2050 Any authentication key exchange/distribution concerns are left 2051 out of scope. However, the internal representation of 2052 authentication keys (see Section 3.10) allows for diverse key 2053 management means, manual configuration in the first place. 2055 j. Message Deletion 2057 Any message deletion attacks are left out of scope. Since a 2058 datagram deleted by an attacker cannot be distinguished from a 2059 datagram naturally lost in transmission and since datagram-based 2060 routing protocols are designed to withstand a certain loss of 2061 packets, the currently established practice is treating 2062 authentication purely as a per-packet function without any added 2063 detection of lost packets. 2065 10. IANA Considerations 2067 [RFC Editor: please do not remove this section.] 2069 Because this document obsoletes [RFC7298], IANA is asked to update 2070 the existing "Babel TLV Types" protocol registry defined in Section 5 2071 of [RFC7557] such that the TLV types 11 and 12 refer to this document 2072 instead of [RFC7298]. Also IANA is asked to assign a sub-TLV type of 2073 TBD1 to the "TS/PC" sub-TLV from the the existing "Babel Sub-TLV 2074 Types" registry defined in Section 5 of [RFC7557]. 2076 11. References 2078 11.1. Normative References 2080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2081 Requirement Levels", BCP 14, RFC 2119, 2082 DOI 10.17487/RFC2119, March 1997, 2083 . 2085 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2086 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2087 2006, . 2089 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 2090 Agility and Selecting Mandatory-to-Implement Algorithms", 2091 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 2092 . 2094 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2095 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2096 May 2017, . 2098 [BABEL] Chroboczek, J. and D. Schinazi, "The Babel Routing 2099 Protocol", draft-ietf-babel-rfc6126bis-04 (work in 2100 progress), October 2017. 2102 11.2. Informative References 2104 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2105 Hashing for Message Authentication", RFC 2104, 2106 DOI 10.17487/RFC2104, February 1997, 2107 . 2109 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2110 C., and M. Carney, "Dynamic Host Configuration Protocol 2111 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2112 2003, . 2114 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 2115 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 2116 RFC 3931, DOI 10.17487/RFC3931, March 2005, 2117 . 2119 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 2120 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 2121 Option", RFC 4030, DOI 10.17487/RFC4030, March 2005, 2122 . 2124 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 2125 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 2126 June 2005, . 2128 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 2129 Hashes in Internet Protocols", RFC 4270, 2130 DOI 10.17487/RFC4270, November 2005, 2131 . 2133 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2134 DOI 10.17487/RFC4302, December 2005, 2135 . 2137 [RIP2-AUTH] 2138 Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 2139 Authentication", RFC 4822, February 2007. 2141 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 2142 Authorization, and Accounting (AAA) Key Management", 2143 BCP 132, RFC 4962, DOI 10.17487/RFC4962, July 2007, 2144 . 2146 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2147 Aboba, "Dynamic Authorization Extensions to Remote 2148 Authentication Dial In User Service (RADIUS)", RFC 5176, 2149 DOI 10.17487/RFC5176, January 2008, 2150 . 2152 [FIPS-198] 2153 US National Institute of Standards & Technology, "The 2154 Keyed-Hash Message Authentication Code (HMAC)", FIPS 2155 PUB 198-1, July 2008. 2157 [ISIS-AUTH-A] 2158 Li, T. and R. Atkinson, "IS-IS Cryptographic 2159 Authentication", RFC 5304, October 2008. 2161 [ISIS-AUTH-B] 2162 Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 2163 and M. Fanto, "IS-IS Generic Cryptographic 2164 Authentication", RFC 5310, February 2009. 2166 [OSPF2-AUTH] 2167 Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 2168 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 2169 Authentication", RFC 5709, October 2009. 2171 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 2172 with Existing Cryptographic Protection Methods for Routing 2173 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 2174 . 2176 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 2177 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 2178 RFC 6151, DOI 10.17487/RFC6151, March 2011, 2179 . 2181 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 2182 Considerations for the SHA-0 and SHA-1 Message-Digest 2183 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 2184 . 2186 [OSPF3-AUTH] 2187 Bhatia, M., Manral, V., and A. Lindem, "Supporting 2188 Authentication Trailer for OSPFv3", RFC 6506, February 2189 2012. 2191 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 2192 Considerations for Protocol Extensions", RFC 6709, 2193 DOI 10.17487/RFC6709, September 2012, 2194 . 2196 [OSPF3-AUTH-BIS] 2197 Bhatia, M., Manral, V., and A. Lindem, "Supporting 2198 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 2200 [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity 2201 Protection for the Neighborhood Discovery Protocol (NHDP) 2202 and Optimized Link State Routing Protocol Version 2 2203 (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014, 2204 . 2206 [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for 2207 the Neighborhood Discovery Protocol (NHDP)", RFC 7186, 2208 DOI 10.17487/RFC7186, April 2014, 2209 . 2211 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 2212 (HMAC) Cryptographic Authentication", RFC 7298, 2213 DOI 10.17487/RFC7298, July 2014, 2214 . 2216 [RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing 2217 Protocol", RFC 7557, DOI 10.17487/RFC7557, May 2015, 2218 . 2220 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2221 Code: The Implementation Status Section", BCP 205, 2222 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2223 . 2225 Appendix A. Figures and Tables 2226 +-------------------------------------------------------------+ 2227 | authentication-specific statistics | 2228 +-------------------------------------------------------------+ 2229 ^ | ^ 2230 | v | 2231 | +-----------------------------------------------+ | 2232 | | system operator | | 2233 | +-----------------------------------------------+ | 2234 | ^ | ^ | ^ | ^ | ^ | | 2235 | | v | | | | | | | v | 2236 +---+ +---------+ | | | | | | +---------+ +---+ 2237 | |->| ANM | | | | | | | | LocalTS |->| | 2238 | R |<-| table | | | | | | | | LocalPC |<-| T | 2239 | x | +---------+ | v | v | v +---------+ | x | 2240 | | +----------------+ +---------+ +----------------+ | | 2241 | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | 2242 | r |<-| ANMTimeout | | CSAs | | |->| r | 2243 | o | | RxAuthRequired | | | | | | o | 2244 | c | +----------------+ +---------+ +----------------+ | c | 2245 | e | +-------------+ | | +-------------+ | e | 2246 | s | | Rx ESAs | | | | Tx ESAs | | s | 2247 | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | 2248 | i | +-------------+ +-------------+ | i | 2249 | n | +------------------------------+----------------+ | n | 2250 | g | | instance of | output buffers |=>| g | 2251 | |=>| the original +----------------+ | | 2252 | | | protocol | source address |->| | 2253 +---+ +------------------------------+----------------+ +---+ 2254 /\ | || 2255 || v \/ 2256 +-------------------------------------------------------------+ 2257 | network stack | 2258 +-------------------------------------------------------------+ 2259 /\ || /\ || /\ || /\ || 2260 || \/ || \/ || \/ || \/ 2261 +---------+ +---------+ +---------+ +---------+ 2262 | speaker | | speaker | ... | speaker | | speaker | 2263 +---------+ +---------+ +---------+ +---------+ 2265 Flow of control data : ---> 2266 Flow of Babel datagrams/packets: ===> 2268 Figure 1: Interaction Diagram 2270 P 2271 |<---------------------------->| (D1) 2272 | B | 2273 | |<------------------------->| 2274 | | | 2275 +--+-----+-----+...+-----+-----+--+ P: Babel packet 2276 |H |some |some | |some |some |T | H: Babel packet header 2277 | |TLV |TLV | |TLV |TLV | | B: Babel packet body 2278 | | | | | | | | T: optional trailing data block 2279 +--+-----+-----+...+-----+-----+--+ 2281 P 2282 |<----------------------------------------------------->| (D2) 2283 | B | 2284 | |<-------------------------------------------------->| 2285 | | | 2286 +--+-----+-----+...+-----+-----+------+------+...+------+--+ 2287 |H |some |some | |some |some |TS/PC |HMAC | |HMAC |T | 2288 | |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | | 2289 | | | | | | | | | | | | 2290 +--+-----+-----+...+-----+-----+------+------+...+------+--+ 2292 P 2293 |<----------------------------------------------------->| (D3) 2294 | B | 2295 | |<-------------------------------------------------->| 2296 | | | 2297 +--+------+------+...+------+-----+-----+...+-----+-----+--+ 2298 |H |TS/PC |HMAC | |HMAC |some |some | |some |some |T | 2299 | |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | | 2300 | | | | | | | | | | | | 2301 +--+------+------+...+------+-----+-----+...+-----+-----+--+ 2303 P 2304 |<------------------------------------------------------------>| (D4) 2305 | B | 2306 | |<--------------------------------------------------------->| 2307 | | | 2308 +--+-----+------+-----+------+...+-----+------+...+------+-----+--+ 2309 |H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T | 2310 | |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | | 2311 | | | | | | | | | | | | | 2312 +--+-----+------+-----+------+...+-----+------+...+------+-----+--+ 2314 Figure 2: Babel Datagram Structure 2316 +-------+-------------------------+---------------+ 2317 | Value | Name | Reference | 2318 +-------+-------------------------+---------------+ 2319 | 0 | Pad1 | [BABEL] | 2320 | 1 | PadN | [BABEL] | 2321 | 2 | Acknowledgement Request | [BABEL] | 2322 | 3 | Acknowledgement | [BABEL] | 2323 | 4 | Hello | [BABEL] | 2324 | 5 | IHU | [BABEL] | 2325 | 6 | Router-Id | [BABEL] | 2326 | 7 | Next Hop | [BABEL] | 2327 | 8 | Update | [BABEL] | 2328 | 9 | Route Request | [BABEL] | 2329 | 10 | Seqno Request | [BABEL] | 2330 | 11 | TS/PC | this document | 2331 | 12 | HMAC | this document | 2332 +-------+-------------------------+---------------+ 2334 Table 1: Babel TLV Types 0 through 12 2336 +--------------+-----------------------------+-------------------+ 2337 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2338 +--------------+-----------------------------+-------------------+ 2339 | Magic | 2a | 42 | 2340 | Version | 02 | version 2 | 2341 | Body length | 00:14 | 20 octets | 2342 | [TLV] Type | 04 | 4 (Hello) | 2343 | [TLV] Length | 06 | 6 octets | 2344 | Reserved | 00:00 | no meaning | 2345 | Seqno | 09:25 | 2341 | 2346 | Interval | 01:90 | 400 (4.00 s) | 2347 | [TLV] Type | 08 | 8 (Update) | 2348 | [TLV] Length | 0a | 10 octets | 2349 | AE | 00 | 0 (wildcard) | 2350 | Flags | 40 | default router-id | 2351 | Plen | 00 | 0 bits | 2352 | Omitted | 00 | 0 bits | 2353 | Interval | ff:ff | infinity | 2354 | Seqno | 68:21 | 26657 | 2355 | Metric | ff:ff | infinity | 2356 +--------------+-----------------------------+-------------------+ 2358 Table 2: A Babel Packet without Authentication TLVs 2360 +---------------+-------------------------------+-------------------+ 2361 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2362 +---------------+-------------------------------+-------------------+ 2363 | Magic | 2a | 42 | 2364 | Version | 02 | version 2 | 2365 | Body length | 00:4c | 76 octets | 2366 | [TLV] Type | 04 | 4 (Hello) | 2367 | [TLV] Length | 06 | 6 octets | 2368 | Reserved | 00:00 | no meaning | 2369 | Seqno | 09:25 | 2341 | 2370 | Interval | 01:90 | 400 (4.00 s) | 2371 | [TLV] Type | 08 | 8 (Update) | 2372 | [TLV] Length | 0a | 10 octets | 2373 | AE | 00 | 0 (wildcard) | 2374 | Flags | 40 | default router-id | 2375 | Plen | 00 | 0 bits | 2376 | Omitted | 00 | 0 bits | 2377 | Interval | ff:ff | infinity | 2378 | Seqno | 68:21 | 26657 | 2379 | Metric | ff:ff | infinity | 2380 | [TLV] Type | 0b | 11 (TS/PC) | 2381 | [TLV] Length | 06 | 6 octets | 2382 | PacketCounter | 00:01 | 1 | 2383 | Timestamp | 52:1d:7e:8b | 1377664651 | 2384 | [TLV] Type | 0c | 12 (HMAC) | 2385 | [TLV] Length | 16 | 22 octets | 2386 | KeyID | 00:c8 | 200 | 2387 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2388 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2389 | [TLV] Type | 0c | 12 (HMAC) | 2390 | [TLV] Length | 16 | 22 octets | 2391 | KeyID | 00:64 | 100 | 2392 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2393 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2394 +---------------+-------------------------------+-------------------+ 2396 Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address 2397 fe80::0a11:96ff:fe1c:10c8 2399 +---------------+-------------------------------+-------------------+ 2400 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2401 +---------------+-------------------------------+-------------------+ 2402 | Magic | 2a | 42 | 2403 | Version | 02 | version 2 | 2404 | Body length | 00:4c | 76 octets | 2405 | [TLV] Type | 04 | 4 (Hello) | 2406 | [TLV] Length | 06 | 6 octets | 2407 | Reserved | 00:00 | no meaning | 2408 | Seqno | 09:25 | 2341 | 2409 | Interval | 01:90 | 400 (4.00 s) | 2410 | [TLV] Type | 08 | 8 (Update) | 2411 | [TLV] Length | 0a | 10 octets | 2412 | AE | 00 | 0 (wildcard) | 2413 | Flags | 40 | default router-id | 2414 | Plen | 00 | 0 bits | 2415 | Omitted | 00 | 0 bits | 2416 | Interval | ff:ff | infinity | 2417 | Seqno | 68:21 | 26657 | 2418 | Metric | ff:ff | infinity | 2419 | [TLV] Type | 0b | 11 (TS/PC) | 2420 | [TLV] Length | 06 | 6 octets | 2421 | PacketCounter | 00:01 | 1 | 2422 | Timestamp | 52:1d:7e:8b | 1377664651 | 2423 | [TLV] Type | 0c | 12 (HMAC) | 2424 | [TLV] Length | 16 | 22 octets | 2425 | KeyID | 00:c8 | 200 | 2426 | Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result | 2427 | | 60:3a:ed:fd:06:55:83:f7:ee:79 | | 2428 | [TLV] Type | 0c | 12 (HMAC) | 2429 | [TLV] Length | 16 | 22 octets | 2430 | KeyID | 00:64 | 100 | 2431 | Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result | 2432 | | c7:73:e0:b5:22:82:ce:fe:e2:3c | | 2433 +---------------+-------------------------------+-------------------+ 2435 Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result 2437 Appendix B. Test Vectors 2439 The test vectors below may be used to verify the correctness of some 2440 procedures performed by an implementation of this mechanism, namely: 2442 o appending of TS/PC and HMAC TLVs to the Babel packet body, 2444 o padding of the HMAC TLV(s), 2446 o computation of the HMAC result(s), and 2447 o placement of the result(s) in the TLV(s). 2449 This verification isn't exhaustive, there are other important 2450 implementation aspects that would require testing methods of their 2451 own. 2453 The test vectors were produced as follows. 2455 1. A Babel speaker with a network interface with IPv6 link-local 2456 address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs 2457 for the interface: 2459 * CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, 2460 AuthKeyOctets=Key26}}} 2462 * CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, 2463 AuthKeyOctets=Key70}}} 2465 The authentication keys above are: 2467 * Key26 in ASCII: 2469 ABCDEFGHIJKLMNOPQRSTUVWXYZ 2471 * Key26 in hexadecimal: 2473 41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50 2474 51:52:53:54:55:56:57:58:59:5a 2476 * Key70 in ASCII: 2478 This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567 2480 * Key70 in hexadecimal: 2482 54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63 2483 74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f 2484 6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c 2485 4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31 2486 32:33:34:35:36:37 2488 The length of each key was picked to relate (in the terms of 2489 Section 2.4) with the properties of respective hash algorithm as 2490 follows: 2492 * the digest length (L) of both RIPEMD-160 and SHA-1 is 20 2493 octets, 2495 * the internal block size (B) of both RIPEMD-160 and SHA-1 is 64 2496 octets, 2498 * the length of Key26 (26) is greater than L but less than B, 2499 and 2501 * the length of Key70 (70) is greater than B (and thus greater 2502 than L). 2504 KeyStartAccept, KeyStopAccept, KeyStartGenerate and 2505 KeyStopGenerate were set to make both authentication keys valid. 2507 2. The instance of the original protocol of the speaker produced a 2508 Babel packet (PktO) to be sent from the interface. Table 2 2509 provides a decoding of PktO, contents of which is below: 2511 2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40 2512 00:00:ff:ff:68:21:ff:ff 2514 3. The authentication mechanism appended one TS/PC TLV and two HMAC 2515 TLVs to the packet body, updated the "Body length" packet header 2516 field and padded the Digest field of the HMAC TLVs using the 2517 link-local IPv6 address of the interface and necessary amount of 2518 zeroes. Table 3 provides a decoding of the resulting temporary 2519 packet (PktT), contents of which is below: 2521 2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40 2522 00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b 2523 0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff 2524 fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00 2525 00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00 2527 4. The authentication mechanism produced two HMAC results, 2528 performing the computations as follows: 2530 * For H=RIPEMD-160, K=Key26, and Text=PktT the HMAC result is: 2532 c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55 2533 83:f7:ee:79 2535 * For H=SHA-1, K=Key70, and Text=PktT the HMAC result is: 2537 df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82 2538 ce:fe:e2:3c 2540 5. The authentication mechanism placed each HMAC result into 2541 respective HMAC TLV, producing the final authenticated Babel 2542 packet (PktA), which was eventually sent from the interface. 2543 Table 4 provides a decoding of PktA, contents of which is below: 2545 2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40 2546 00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b 2547 0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a 2548 ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e 2549 d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c 2551 Interpretation of this process is to be done in the view of Figure 1, 2552 differently for the sending and the receiving directions. 2554 For the sending direction, given a Babel speaker configured using the 2555 IPv6 address and the sequence of CSAs as described above, the 2556 implementation SHOULD (see notes in Section 5.3) produce exactly the 2557 temporary packet PktT if the original protocol instance produces 2558 exactly the packet PktO to be sent from the interface. If the 2559 temporary packet exactly matches PktT, the HMAC results computed 2560 afterwards MUST exactly match respective results above and the final 2561 authenticated packet MUST exactly match the PktA above. 2563 For the receiving direction, given a Babel speaker configured using 2564 the sequence of CSAs as described above (but a different IPv6 2565 address), the implementation MUST (assuming the TS/PC check didn't 2566 fail) produce exactly the temporary packet PktT above if its network 2567 stack receives through the interface exactly the packet PktA above 2568 from the source IPv6 address above. The first HMAC result computed 2569 afterwards MUST match the first result above. The receiving 2570 procedure doesn't compute the second HMAC result in this case, but if 2571 the implementor decides to compute it anyway for the verification 2572 purpose, it MUST exactly match the second result above. 2574 Author's Address 2576 Denis Ovsienko 2578 Email: denis@ovsienko.info