idnits 2.17.1 draft-ovsienko-babel-hmac-authentication-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6126, but the abstract doesn't seem to directly say this. It does mention RFC6126 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2013) is 4025 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TLV' is mentioned on line 2126, but not defined ** Obsolete normative reference: RFC 6126 (ref. 'BABEL') (Obsoleted by RFC 8966) == Outdated reference: A later version (-06) exists of draft-sheffer-running-code-04 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 6506 (ref. 'OSPF3-AUTH') (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Ovsienko 3 Internet-Draft Yandex 4 Updates: 6126 (if approved) April 18, 2013 5 Intended status: Experimental 6 Expires: October 20, 2013 8 Babel HMAC Cryptographic Authentication 9 draft-ovsienko-babel-hmac-authentication-03 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 Babel routing protocol, updating, but not superceding RFC 6126. The 15 mechanism allocates two new TLV types for the authentication data, 16 uses HMAC and is both optional and backward compatible. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 20, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 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. Padding Constant Specifics . . . . . . . . . . . . . . . . 7 57 2.3. Cryptographic Sequence Number Specifics . . . . . . . . . 7 58 2.4. Definition of HMAC . . . . . . . . . . . . . . . . . . . . 8 59 3. Updates to Protocol Data Structures . . . . . . . . . . . . . 9 60 3.1. RxAuthRequired . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2. LocalTS . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 3.3. LocalPC . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4. MaxDigestsIn . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.5. MaxDigestsOut . . . . . . . . . . . . . . . . . . . . . . 10 65 3.6. ANM Table . . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.7. ANM Timeout . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.8. Configured Security Associations . . . . . . . . . . . . . 13 68 3.9. Effective Security Associations . . . . . . . . . . . . . 15 69 4. Updates to Protocol Encoding . . . . . . . . . . . . . . . . . 15 70 4.1. Justification . . . . . . . . . . . . . . . . . . . . . . 15 71 4.2. TS/PC TLV . . . . . . . . . . . . . . . . . . . . . . . . 17 72 4.3. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 5. Updates to Protocol Operation . . . . . . . . . . . . . . . . 19 74 5.1. Per-Interface TS/PC Number Updates . . . . . . . . . . . . 19 75 5.2. Deriving ESAs from CSAs . . . . . . . . . . . . . . . . . 21 76 5.3. Updates to Packet Sending . . . . . . . . . . . . . . . . 23 77 5.4. Updates to Packet Receiving . . . . . . . . . . . . . . . 25 78 5.5. Authentication-Specific Statistics Maintenance . . . . . . 27 79 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 28 80 6.1. IPv6 Source Address Selection for Sending . . . . . . . . 28 81 6.2. Output Buffer Management . . . . . . . . . . . . . . . . . 28 82 6.3. Optimisations of ESAs Deriving . . . . . . . . . . . . . . 29 83 6.4. Security Associations Duplication . . . . . . . . . . . . 30 84 7. Network Management Aspects . . . . . . . . . . . . . . . . . . 31 85 7.1. Backward Compatibility . . . . . . . . . . . . . . . . . . 31 86 7.2. Multi-Domain Authentication . . . . . . . . . . . . . . . 32 87 7.3. Migration to and from Authenticated Exchange . . . . . . . 33 88 7.4. Handling of Authentication Keys Exhaustion . . . . . . . . 34 89 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 94 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 95 12.2. Informative References . . . . . . . . . . . . . . . . . . 41 96 Appendix A. Figures and Tables . . . . . . . . . . . . . . . . . 43 97 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 48 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 100 1. Introduction 102 [RFC Editor: before publication please remove the sentence below.] 103 Comments are solicited and should be addressed to the author. 105 Authentication of routing protocol exchanges is a common mean of 106 securing computer networks. Use of protocol authentication 107 mechanisms helps in ascertaining that only the intended routers 108 participate in routing information exchange, and that the exchanged 109 routing information is not modified by a third party. 111 [BABEL] ("the original specification") defines data structures, 112 encoding, and the operation of a basic Babel routing protocol 113 instance ("instance of the original protocol"). This document ("this 114 specification") defines data structures, encoding, and the operation 115 of an extension to the Babel protocol, an authentication mechanism 116 ("this mechanism"). Both the instance of the original protocol and 117 this mechanism are mostly self-contained and interact only at 118 coupling points defined in this specification. 120 A major design goal of this mechanism is transparency to operators 121 that is not affected by implementation and configuration specifics. 122 A complying implementation makes all meaningful details of 123 authentication-specific processing clear to the operator, even when 124 some of the key parameters cannot be changed. 126 The currently established (see [RIP2-AUTH], [OSPF2-AUTH], 127 [OSPF3-AUTH], and [RFC6039]) approach to authentication mechanism 128 design for datagram-based routing protocols such as Babel relies on 129 two principal data items embedded into protocol packets, typically as 130 two integral parts of a single data structure: 132 o A fixed-length unsigned integer, typically called a cryptographic 133 sequence number, used in replay attack protection. 135 o A variable-length sequence of octets, a result of the HMAC 136 construct (see [RFC2104]) computed on meaningful data items of the 137 packet (including the cryptographic sequence number) on one hand 138 and a secret key on the other, used in proving that both the 139 sender and the receiver share the same secret key and that the 140 meaningful data was not changed in transmission. 142 Depending on the design specifics either all protocol packets are 143 authenticated or only those protecting the integrity of protocol 144 exchange. This mechanism authenticates all protocol packets. 146 This specification defines the use of the cryptographic sequence 147 number in details sufficient to make replay attack protection 148 strength predictable. That is, an operator can tell the strength 149 from the declared characteristics of an implementation and, whereas 150 the implementation allows to change relevant parameters, the effect 151 of a reconfiguration. 153 This mechanism explicitly allows for multiple HMAC results per 154 authenticated packet. Since meaningful data items of a given packet 155 remain the same, each such HMAC result stands for a different secret 156 key and/or a different hash algorithm. This enables a simultaneous, 157 independent authentication within multiple domains. 159 An important concern addressed by this mechanism is limiting the 160 amount of HMAC computations done per authenticated packet, 161 independently for sending and receiving. Without these limits the 162 number of computations per packet could be as high as the number of 163 configured authentication keys (in the sending case) or as the number 164 of keys multiplied by the number of supplied HMAC results (in the 165 receiving case). 167 These limits establish a basic competition between the configured 168 keys and (in the receiving case) an additional competition between 169 the supplied HMAC results. This specification defines related data 170 structures and procedures in a way to make such competition 171 transparent and predictable for an operator. 173 Wherever this specification mentions the operator reading or changing 174 a particular data structure, variable, parameter, or event counter 175 "at runtime", it is up to the implementor how this is to be done. 176 For example, the implementation can employ an interactive CLI, or a 177 management protocol such as SNMP, or an inter-process communication 178 mean such as a local socket, or a combination of these. 180 1.1. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC2119]. 186 2. Cryptographic Aspects 188 2.1. Mandatory-to-Implement and Optional Hash Algorithms 190 [RFC2104] defines HMAC as a construct that can use any cryptographic 191 hash algorithm with a known digest length and internal block size. 192 This specification preserves this property of HMAC by defining data 193 processing that itself does not depend on any particular hash 194 algorithm either. However, since this mechanism is a protocol 195 extension case, there are relevant design considerations to take into 196 account. 198 Section 4.5 of [RFC6709] suggests selecting one hash algorithm as 199 mandatory-to-implement for the purpose of global interoperability 200 (Section 3.2 ibid.) and selecting another of distinct lineage as 201 recommended for implementation for the purpose of cryptographic 202 agility. This specification makes the latter property guaranteed, 203 rather than probable, through an elevation of the requirement level. 204 There are two hash algorithms mandatory-to-implement, unambiguously 205 defined and generally available in multiple implementations each. 207 An implementation of this mechanism MUST include support for two hash 208 algorithms: 210 o SHA-512 (SHA-2 family) 212 o Whirlpool 2nd ed., 2003 (512-bit hash) 214 Besides that, an implementation of this mechanism MAY include support 215 for additional hash algorithms, provided each such algorithm is 216 publicly and openly specified and its digest length is 16 octets or 217 more (to meet the constraint set in Section 4.3). Implementors 218 SHOULD consider strong, well-known hash algorithms as additional 219 implementation options and MUST NOT consider hash algorithms for that 220 by the time of implementation meaningful attacks exist or that are 221 commonly viewed as deprecated. For example, the following hash 222 algorithms meet these requirements at the time of this writing (in 223 alphabetical order): 225 o GOST R 34.11-94 (256-bit hash) 227 o RIPEMD-160 229 o SHA-224 (SHA-2 family) 231 o SHA-256 (SHA-2 family) 233 o SHA-384 (SHA-2 family) 235 o Tiger (192-bit hash) 237 The set of hash algorithms available in an implementation MUST be 238 clearly stated. When known weak authentication keys exist for a hash 239 algorithm used in the HMAC construct, an implementation MUST deny a 240 use of such keys. 242 2.2. Padding Constant Specifics 244 [RIP2-AUTH] established a reference method of routing protocol 245 packets authentication using the HMAC construct. The method sets 246 that a protocol packet being authenticated is sized and structured in 247 a way to contain a data space purposed for the authentication data. 248 Before processing the packet with the HMAC computation the data space 249 is filled with some data a receiver of the packet can reproduce 250 exactly, typically involving an arbitrary number known as a padding 251 constant. After the HMAC computation the data space inside the 252 packet is overwritten with the resulting authentication data. 254 The padding constant used in [RIP2-AUTH] is 0x878FE1F3 four-octet 255 value. Subsequent works (including [OSPF2-AUTH] and [OSPF3-AUTH]) 256 inherited both the method and the padding constant value. In 257 particular, [OSPF3-AUTH] uses a source IPv6 address to set the first 258 16 octets of the padded area and the padding constant to set any 259 subsequent octets. This mechanism uses the source IPv6 address in 260 the same way, but the padding constant size and value are different. 262 Since any fixed arbitrary value of a padding constant does not affect 263 cryptographic characteristics of a hash algorithm and the HMAC 264 construct, and since single-octet padding is more straightforward to 265 implement, the padding constant used by this mechanism is 0x00 266 single-octet value. This is respectively addressed in sending 267 (Section 5.3 item 5) and receiving (Section 5.4 item 6) procedures. 269 2.3. Cryptographic Sequence Number Specifics 271 Operation of this mechanism may involve multiple local and multiple 272 remote cryptographic sequence numbers, each essentially being a 273 48-bit unsigned integer. This specification uses a term "TS/PC 274 number" to avoid confusion with the route's sequence number of the 275 original Babel specification (Section 2.5 of [BABEL]) and to stress 276 the fact that there are two distinguished parts of this 48-bit 277 number, each handled in its specific way (see Section 5.1): 279 0 1 2 3 4 280 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 281 +-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | TS // | PC | 283 +-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 // 286 The high-order 32 bits are called "timestamp" (TS) and the low-order 287 16 bits are called "packet counter" (PC). 289 This mechanism stores, updates, compares, and encodes each TS/PC 290 number as two independent unsigned integers, TS and PC respectively. 291 Such comparison of TS/PC numbers performed in item 3 of Section 5.4 292 is algebraically equivalent to comparison of respective 48-bit 293 unsigned integers. Any byte order conversion, when required, is 294 performed on TS and PC parts independently. 296 2.4. Definition of HMAC 298 The algorithm description below uses the following nomenclature, 299 which is consistent with [FIPS-198]: 301 Text Is the data on which the HMAC is calculated (note item (b) of 302 Section 9). In this specification it is the contents of a 303 Babel packet ranging from the beginning of the Magic field of 304 the Babel packet header to the end of the last octet of the 305 Packet Body field, as defined in Section 4.2 of [BABEL] (see 306 Figure 2). 308 H Is the specific hash algorithm (see Section 2.1). 310 K Is a sequence of octets of an arbitrary, known length. 312 Ko Is the cryptographic key used with the hash algorithm. 314 B Is the block size of H, measured in octets rather than bits. 315 Note that B is the internal block size, not the digest length. 317 L Is the digest length of H, measured in octets rather than 318 bits. 320 XOR Is the bitwise exclusive-or operation. 322 Opad Is the hexadecimal value 0x5c repeated B times. 324 Ipad Is the hexadecimal value 0x36 repeated B times. 326 The algorithm below is the original, unmodified HMAC construct as 327 defined in both [RFC2104] and [FIPS-198], hence it is different from 328 the algorithms defined in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] 329 in exactly two regards: 331 o The algorithm below sets the size of Ko to B, not to L (L is not 332 greater than B). This resolves both ambiguity in XOR expressions 333 and incompatibility in handling of keys having length greater than 334 L but not greater than B. 336 o The algorithm below does not change value of Text before or after 337 the computation. Both padding of a Babel packet before the 338 computation and placing of the result inside the packet are 339 performed elsewhere. 341 The intent of this is to enable the most straightforward use of 342 cryptographic libraries by implementations of this specification. At 343 the time of this writing implementations of the original HMAC 344 construct coupled with hash algorithms of choice are generally 345 available. 347 Description of the algorithm: 349 1. Preparation of the Key 351 In this application, Ko is always B octets long. If K is B 352 octets long, then Ko is set to K. If K is more than B octets 353 long, then Ko is set to H(K) with the necessary amount of zeroes 354 appended to the end of H(K), such that Ko is B octets long. If K 355 is less than B octets long, then Ko is set to K with zeroes 356 appended to the end of K, such that Ko is B octets long. 358 2. First-Hash 360 A First-Hash, also known as the inner hash, is computed as 361 follows: 363 First-Hash = H(Ko XOR Ipad || Text) 365 3. Second-Hash 367 A second hash, also known as the outer hash, is computed as 368 follows: 370 Second-Hash = H(Ko XOR Opad || First-Hash) 372 4. Result 374 The resulting Second-Hash becomes the authentication data that is 375 returned as the result of HMAC calculation. 377 3. Updates to Protocol Data Structures 379 3.1. RxAuthRequired 381 RxAuthRequired is a boolean parameter, its default value MUST be 382 TRUE. An implementation SHOULD make RxAuthRequired a per-interface 383 parameter, but MAY make it specific to the whole protocol instance. 384 The conceptual purpose of RxAuthRequired is to enable a smooth 385 migration from an unauthenticated to an authenticated Babel packet 386 exchange and back (see Section 7.3). Current value of RxAuthRequired 387 directly affects the receiving procedure defined in Section 5.4. An 388 implementation SHOULD allow the operator to change RxAuthRequired 389 value at runtime or by means of Babel speaker restart. An 390 implementation MUST allow the operator to discover the effective 391 value of RxAuthRequired at runtime or from the system documentation. 393 3.2. LocalTS 395 LocalTS is a 32-bit unsigned integer variable, it is the TS part of a 396 per-interface TS/PC number. LocalTS is a strictly per-interface 397 variable not intended to be changed by the operator. Its 398 initialization is explained in Section 5.1. 400 3.3. LocalPC 402 LocalPC is a 16-bit unsigned integer variable, it is the PC part of a 403 per-interface TS/PC number. LocalPC is a strictly per-interface 404 variable not intended to be changed by the operator. Its 405 initialization is explained in Section 5.1. 407 3.4. MaxDigestsIn 409 MaxDigestsIn is an unsigned integer parameter conceptually purposed 410 for limiting the amount of CPU time spent processing a received 411 authenticated packet. The receiving procedure performs the most CPU- 412 intensive operation, the HMAC computation, only at most MaxDigestsIn 413 (Section 5.4 item 7) times for a given packet. 415 MaxDigestsIn value MUST be at least 2. An implementation SHOULD make 416 MaxDigestsIn a per-interface parameter, but MAY make it specific to 417 the whole protocol instance. An implementation SHOULD allow the 418 operator to change the value of MaxDigestsIn at runtime or by means 419 of Babel speaker restart. An implementation MUST allow the operator 420 to discover the effective value of MaxDigestsIn at runtime or from 421 the system documentation. 423 3.5. MaxDigestsOut 425 MaxDigestsOut is an unsigned integer parameter conceptually purposed 426 for limiting the amount of a sent authenticated packet's space spent 427 on authentication data. The sending procedure adds at most 428 MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet, 429 concurring with the output buffer management explained in 430 Section 6.2. 432 The MaxDigestsOut value MUST be at least 2. An implementation SHOULD 433 make MaxDigestsOut a per-interface parameter, but MAY make it 434 specific to the whole protocol instance. An implementation SHOULD 435 allow the operator to change the value of MaxDigestsOut at runtime or 436 by means of Babel speaker restart, in a safe range. The maximum safe 437 value of MaxDigestsOut is implementation-specific (see Section 6.2). 438 An implementation MUST allow the operator to discover the effective 439 value of MaxDigestsOut at runtime or from the system documentation. 441 3.6. ANM Table 443 The ANM (Authentic Neighbours Memory) table resembles the neighbour 444 table defined in Section 3.2.3 of [BABEL]. Note that the term 445 "neighbour table" means the neighbour table of the original Babel 446 specification, and the term "ANM table" means the table defined 447 herein. Indexing of the ANM table is done in exactly the same way as 448 indexing of the neighbour table, but purpose, field set and 449 associated procedures are different. 451 The conceptual purpose of the ANM table is to provide longer term 452 replay attack protection than it would be possible using the 453 neighbour table. Expiry of an inactive entry in the neighbour table 454 depends on the last received Hello Interval of the neighbour and 455 typically stands for tens to hundreds of seconds (see Appendix A and 456 Appendix B of [BABEL]). Expiry of an inactive entry in the ANM table 457 depends only on the local speaker's configuration. The ANM table 458 retains (for at least the amount of seconds set by ANM timeout 459 parameter defined in Section 3.7) a copy of TS/PC number advertised 460 in authentic packets by each remote Babel speaker. 462 The ANM table is indexed by pairs of the form (Interface, Source). 463 Every table entry consists of the following fields: 465 o Interface 467 An implementation-specific reference to the local node's interface 468 that the authentic packet was received through. 470 o Source 472 IPv6 source address of the Babel speaker that the authentic packet 473 was received from. 475 o LastTS 477 A 32-bit unsigned integer, the TS part of a remote TS/PC number. 479 o LastPC 480 A 16-bit unsigned integer, the PC part of a remote TS/PC number. 482 Each ANM table entry has an associated aging timer, which is reset by 483 the receiving procedure (Section 5.4 item 9). If the timer expires, 484 the entry is deleted from the ANM table. 486 An implementation SHOULD use a persistent memory (NVRAM) to retain 487 the contents of ANM table across restarts of the Babel speaker, but 488 only as long as both the Interface field reference and expiry of the 489 aging timer remain correct. An implementation MUST make it clear, if 490 and how persistent memory is used for ANM table. An implementation 491 SHOULD allow the operator to retrieve the current contents of ANM 492 table at runtime. An implementation SHOULD allow the operator to 493 remove some or all of ANM table entries at runtime or by means of 494 Babel speaker restart. 496 3.7. ANM Timeout 498 ANM timeout is an unsigned integer parameter. An implementation 499 SHOULD make ANM timeout a per-interface parameter, but MAY make it 500 specific to the whole protocol instance. ANM timeout is conceptually 501 purposed for limiting the maximum age (in seconds) of entries in the 502 ANM table standing for inactive Babel speakers. The maximum age is 503 immediately related to replay attack protection strength. The 504 strongest protection is achieved with the maximum possible value of 505 ANM timeout set, but it may not provide the best overall result for 506 specific network segments and implementations of this mechanism. 508 In the first turn, implementations unable to maintain local TS/PC 509 number strictly increasing across Babel speaker restarts will reuse 510 the advertised TS/PC numbers after each restart (see Section 5.1). 511 The neighbouring speakers will treat the new packets as replayed and 512 discard them until the aging timer of respective ANM table entry 513 expires or the new TS/PC number exceeds the one stored in the entry. 515 Another possible, but less probable, case could be an environment 516 involving physical moves of network interfaces hardware between 517 routers. Even performed without restarting Babel speakers, these 518 would cause random drops of the TS/PC number advertised for a given 519 (Interface, Source) index, as viewed by neighbouring speakers, since 520 IPv6 link-local addresses are typically derived from interface 521 hardware addresses. 523 Assuming that in such cases the operators would prefer to use a lower 524 ANM timeout value to let the entries expire on their own rather than 525 having to manually remove them from the ANM table each time, an 526 implementation SHOULD set the default value of ANM timeout to a value 527 between 30 and 300 seconds. 529 At the same time, network segments may exist with every Babel speaker 530 having its advertised TS/PC number strictly increasing over the 531 deployed lifetime. Assuming that in such cases the operators would 532 prefer using a much higher ANM timeout value, an implementation 533 SHOULD allow the operator to change the value of ANM timeout at 534 runtime or by means of Babel speaker restart. An implementation MUST 535 allow the operator to discover the effective value of ANM timeout at 536 runtime or from the system documentation. 538 3.8. Configured Security Associations 540 A Configured Security Association (CSA) is a data structure 541 conceptually purposed for associating authentication keys and hash 542 algorithms with Babel interfaces. All CSAs are managed in finite 543 sequences, one sequence per interface ("interface's sequence of CSAs" 544 hereafter). Each interface's sequence of CSAs, as an integral part 545 of the Babel speaker configuration, MAY be intended for a persistent 546 storage as long as this conforms with the implementation's key 547 management policy. The default state of an interface's sequence of 548 CSAs is empty, which has a special meaning of no authentication 549 configured for the interface. The sending (Section 5.3 item 1) and 550 the receiving (Section 5.4 item 1) procedures address this convention 551 accordingly. 553 A single CSA structure consists of the following fields: 555 o HashAlgo 557 An implementation-specific reference to one of the hash algorithms 558 supported by this implementation (see Section 2.1). 560 o KeyChain 562 A finite sequence of elements ("KeyChain sequence" hereafter) 563 representing authentication keys, each element being a structure 564 consisting of the following fields: 566 * LocalKeyID 568 An unsigned integer of an implementation-specific bit length. 570 * AuthKeyOctets 572 A sequence of octets of an arbitrary, known length to be used 573 as the authentication key. 575 * KeyStartAccept 576 The time that this Babel speaker will begin considering this 577 authentication key for accepting packets with authentication 578 data. 580 * KeyStartGenerate 582 The time that this Babel speaker will begin considering this 583 authentication key for generating packet authentication data. 585 * KeyStopGenerate 587 The time that this Babel speaker will stop considering this 588 authentication key for generating packet authentication data. 590 * KeyStopAccept 592 The time that this Babel speaker will stop considering this 593 authentication key for accepting packets with authentication 594 data. 596 Since there is no limit imposed on the number of CSAs per interface, 597 but the number of HMAC computations per sent/received packet is 598 limited (through MaxDigestsOut and MaxDigestsIn respectively), only a 599 fraction of the associated keys and hash algorithms may appear used 600 in the process. The ordering of elements within a sequence of CSAs 601 and within a KeyChain sequence is important to make the association 602 selection process deterministic and transparent. Once this ordering 603 is deterministic at the Babel interface level, the intermediate data 604 derived by the procedure defined in Section 5.2 will be 605 deterministically ordered as well. 607 An implementation SHOULD allow an operator to set any arbitrary order 608 of elements within a given interface's sequence of CSAs and within 609 the KeyChain sequence of a given CSA. Regardless if this requirement 610 is or isn't met, the implementation MUST provide a mean to discover 611 the actual element order used. Whichever order is used by an 612 implementation, it MUST be preserved across Babel speaker restarts. 614 Note that none of the CSA structure fields is constrained to contain 615 unique values. Section 6.4 explains this in more detail. It is 616 possible for the KeyChain sequence to be empty, although this is not 617 the intended manner of CSAs use. 619 The KeyChain sequence has a direct prototype, which is the "key 620 chain" syntax item of some existing router configuration languages. 621 Whereas an implementation already implements this syntax item, it is 622 suggested to reuse it, that is, to implement a CSA syntax item 623 referring to a key chain item instead of reimplementing the latter in 624 full. 626 3.9. Effective Security Associations 628 An Effective Security Association (ESA) is a data structure 629 immediately used in sending (Section 5.3) and receiving (Section 5.4) 630 procedures. Its conceptual purpose is to determine a runtime 631 interface between those procedures and the deriving procedure defined 632 in Section 5.2. All ESAs are temporary data units managed as 633 elements of finite sequences that are not intended for a persistent 634 storage. Element ordering within each such finite sequence 635 ("sequence of ESAs" hereafter) MUST be preserved as long as the 636 sequence exists. 638 A single ESA structure consists of the following fields: 640 o HashAlgo 642 An implementation-specific reference to one of the hash algorithms 643 supported by this implementation (see Section 2.1). 645 o KeyID 647 A 16-bit unsigned integer. 649 o AuthKeyOctets 651 A sequence of octets of an arbitrary, known length to be used as 652 the authentication key. 654 Note that among the protocol data structures introduced by this 655 mechanism ESA is the only one not directly interfaced with the system 656 operator (see Figure 1), it is not immediately present in the 657 protocol encoding either. However, ESA is not just a possible 658 implementation technique, but an integral part of this specification: 659 the deriving (Section 5.2), the sending (Section 5.3), and the 660 receiving (Section 5.4) procedures are defined in terms of the ESA 661 structure and its semantics provided herein. ESA is as meaningful 662 for a correct implementation as the other protocol data structures. 664 4. Updates to Protocol Encoding 666 4.1. Justification 668 Choice of encoding is very important in the long term. The protocol 669 encoding limits various authentication mechanism designs and 670 encodings, which in turn limit future developments of the protocol. 672 Considering existing implementations of Babel protocol instance 673 itself and related modules of packet analysers, the current encoding 674 of Babel allows for compact and robust decoders. At the same time, 675 this encoding allows for future extensions of Babel by three (not 676 excluding each other) principal means defined by Section 4.2 and 677 Section 4.3 of [BABEL]: 679 a. A Babel packet consists of a four-octet header followed by a 680 packet body, that is, a sequence of TLVs (see Figure 2). Besides 681 the header and the body, an actual Babel datagram may have an 682 arbitrary amount of trailing data between the end of the packet 683 body and the end of the datagram. An instance of the original 684 protocol silently ignores such trailing data. 686 b. The packet body employs a binary format allowing for 256 TLV 687 types and imposing no requirements on TLV ordering or number of 688 TLVs of a given type in a packet. Only TLV length matters within 689 the packet body, TLV body contents is to be interpreted 690 elsewhere. This makes an iteration over the sequence of TLVs 691 possible without knowledge of the body structure of each TLV 692 (with the only distinction between a Pad1 TLV and any other 693 TLVs). The original specification allocates TLV types 0 through 694 10 (see Table 1) and defines TLV body structure for each. An 695 instance of the original protocol silently ignores any unknown 696 TLV types. 698 c. Within each TLV of the packet body there may be some "extra data" 699 after the "expected length" of the TLV body. An instance of the 700 original protocol silently ignores any such extra data. Note 701 that any TLV types without the expected length defined (such as 702 PadN TLV) cannot be extended with the extra data. 704 Considering each principal extension mean for the specific purpose of 705 adding authentication data items to each protocol packet, the 706 following arguments can be made: 708 o Use of the TLV extra data of some existing TLV type would not be a 709 solution, since no particular TLV type is guaranteed to be present 710 in a Babel packet. 712 o Use of the TLV extra data could also conflict with future 713 developments of the protocol encoding. 715 o Since the packet trailing data is currently unstructured, using it 716 would involve defining an encoding structure and associated 717 procedures, adding to the complexity of both specification and 718 implementation and increasing the exposure to protocol attacks 719 such as fuzzing. 721 o A naive use of the packet trailing data would make it unavailable 722 to any future extension of Babel. Since this mechanism is 723 possibly not the last extension and since some other extensions 724 may allow no other embedding means except the packet trailing 725 data, the defined encoding structure would have to enable 726 multiplexing of data items belonging to different extensions. 727 Such a definition is out of the scope of this work. 729 o Deprecating an extension (or only its protocol encoding) that uses 730 purely purpose-allocated TLVs is as simple as deprecating the 731 TLVs. 733 o Use of purpose-allocated TLVs is transparent for both the original 734 protocol and any its future extensions, regardless of the 735 embedding mean(s) used by the latter. 737 Considering all of the above, this mechanism neither uses the packet 738 trailing data nor uses the TLV extra data, but uses two new TLV 739 types: type 11 for a TS/PC number and type 12 for an HMAC result (see 740 Table 1). 742 4.2. TS/PC TLV 744 The purpose of a TS/PC TLV is to store a single TS/PC number. There 745 is normally exactly one TS/PC TLV in an authenticated Babel packet. 746 Any occurences of this TLV except the first are ignored. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type = 11 | Length | PacketCounter | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Timestamp | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Fields: 758 Type Set to 11 to indicate a TS/PC TLV. 760 Length The length of the body, exclusive of the Type and 761 Length fields. 763 PacketCounter A 16-bit unsigned integer in network byte order, the 764 PC part of a TS/PC number stored in this TLV. 766 Timestamp A 32-bit unsigned integer in network byte order, the 767 TS part of a TS/PC number stored in this TLV. 769 Note that the ordering of PacketCounter and Timestamp in the TLV 770 structure is opposite to the ordering of TS and PC in "TS/PC" term 771 and the 48-bit equivalent (see Section 2.3). 773 Considering the "expected length" and the "extra data" in the 774 definition of Section 4.2 of [BABEL], the expected length of a TS/PC 775 TLV body is unambiguously defined as 6 octets. The receiving 776 procedure correctly processes any TS/PC TLV with body length not less 777 than the expected, ignoring any extra data (Section 5.4 items 3 and 778 9). The sending procedure produces a TS/PC TLV with body length 779 equal to the expected and Length field set respectively (Section 5.3 780 item 3). 782 Future Babel extensions (such as sub-TLVs) MAY modify the sending 783 procedure to include the extra data after the fixed-size TS/PC TLV 784 body defined herein, making necessary adjustments to Length TLV 785 field, "Body length" packet header field and output buffer management 786 explained in Section 6.2. 788 4.3. HMAC TLV 790 The purpose of an HMAC TLV is to store a single HMAC result. To 791 assist a receiver in reproducing the HMAC computation, LocalKeyID 792 modulo 2^16 of the authentication key is also provided in the TLV. 793 There is normally at least one HMAC TLV in an authenticated Babel 794 packet. 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Type = 12 | Length | KeyID | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Digest... 802 +-+-+-+-+-+-+-+-+-+-+-+- 804 Fields: 806 Type Set to 12 to indicate an HMAC TLV. 808 Length The length of the body, exclusive of the Type and 809 Length fields. 811 KeyID A 16-bit unsigned integer in network byte order. 813 Digest A variable-length sequence of octets. 815 The Digest field of the TLV MUST be at least 16 octets long to make 816 sure there is enough space to be padded with a full IPv6 address (see 817 Section 5.3 item 5, Section 5.4 item 6, Table 3 and Table 4). At the 818 time of this writing an instance of the Babel protocol uses only IPv6 819 link-local addresses as the source address of the protocol packets 820 (see Section 3.1 of [BABEL]) and the first 8 octets of the address 821 always stand for the fe80::/64 prefix. However, if a future protocol 822 extension needs to send Babel packets from a source address outside 823 of the fe80::/64 prefix, as little changes to this mechanism as 824 possible should be required to authenticate such packets as well. 825 For this reason all 16 octets of the IPv6 address are used for the 826 padding. 828 Considering the "expected length" and the "extra data" in the 829 definition of Section 4.2 of [BABEL], the expected length of an HMAC 830 TLV body is not defined. The receiving procedure processes every 831 octet of the Digest field, deriving the field boundary from the 832 Length field value (Section 5.4 item 6). The sending procedure 833 produces HMAC TLVs with Length field precisely sizing the Digest 834 field to match digest length of the hash algorithm used (Section 5.3 835 items 5 and 8). 837 The HMAC TLV structure defined herein is final, future Babel 838 extensions MUST NOT extend it with any extra data. 840 5. Updates to Protocol Operation 842 5.1. Per-Interface TS/PC Number Updates 844 The LocalTS and LocalPC interface-specific variables constitute the 845 TS/PC number of a Babel interface. This number is advertised in the 846 TS/PC TLV of authenticated Babel packets sent from that interface. 847 There is only one property mandatory for the advertised TS/PC number: 848 its 48-bit equivalent (see Section 2.3) MUST be strictly increasing 849 within the scope of a given interface of a Babel speaker as long as 850 the protocol instance is continuously operating. This property 851 combined with ANM tables of neighbouring Babel speakers provides them 852 with the most basic replay attack protection. 854 Initialization and increment are two principal updates performed on 855 an interface TS/PC number. The initialization is performed when a 856 new interface becomes a part of a Babel protocol instance. The 857 increment is performed by the sending procedure (Section 5.3 item 2) 858 before advertising the TS/PC number in a TS/PC TLV. 860 Depending on particular implementation method of these two updates 861 the advertised TS/PC number may possess additional properties 862 improving the replay attack protection strength. This includes, but 863 is not limited to the methods below. 865 a. The most straightforward implementation would use LocalTS as a 866 plain wrap counter, defining the updates as follows: 868 initialization Set LocalPC to 0, set LocalTS to 0. 870 increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF 871 + 1 = 0x0000), increment LocalTS by 1. 873 In this case the advertised TS/PC numbers would be reused after 874 each Babel protocol instance restart, making neighbouring 875 speakers reject authenticated packets until the respective ANM 876 table entries expire or the new TS/PC number exceeds the old (see 877 Section 3.6 and Section 3.7). 879 b. A more advanced implementation could make a use of any 32-bit 880 unsigned integer timestamp (number of time units since an 881 arbitrary epoch) such as the UNIX timestamp, whereas the 882 timestamp itself spans a reasonable time range and is guaranteed 883 against a decrease (such as one resulting from network time use). 884 The updates would be defined as follows: 886 initialization Set LocalPC to 0, set LocalTS to 0. 888 increment If the current timestamp is greater than LocalTS, 889 set LocalTS to the current timestamp and LocalPC 890 to 0, then consider the update complete. 891 Otherwise increment LocalPC by 1 and, if LocalPC 892 wraps, increment LocalTS by 1. 894 In this case the advertised TS/PC number would remain unique 895 across the speaker's deployed lifetime without the need for any 896 persistent storage. However, a suitable timestamp source is not 897 available in every implementation case. 899 c. Another advanced implementation could use LocalTS in a way 900 similar to the "wrap/boot counter" suggested in Section 4.1.1 of 901 [OSPF3-AUTH], defining the updates as follows: 903 initialization Set LocalPC to 0. Whether there is a TS value 904 stored in NVRAM for the current interface, set 905 LocalTS to the stored TS value, then increment 906 the stored TS value by 1. Otherwise set LocalTS 907 to 0 and set the stored TS value to 1. 909 increment Increment LocalPC by 1. If LocalPC wraps, set 910 LocalTS to the TS value stored in NVRAM for the 911 current interface, then increment the stored TS 912 value by 1. 914 In this case the advertised TS/PC number would also remain unique 915 across the speaker's deployed lifetime, relying on NVRAM for 916 storing multiple TS numbers, one per interface. 918 As long as the TS/PC number retains its mandatory property stated 919 above, it is up to the implementor, which TS/PC number updates 920 methods are available and if the operator can configure the method 921 per-interface and/or at runtime. However, an implementation MUST 922 disclose the essence of each update method it includes, in a 923 comprehensible form such as natural language description, pseudocode, 924 or source code. An implementation MUST allow the operator to 925 discover, which update method is effective for any given interface, 926 either at runtime or from the system documentation. These 927 requirements are necessary to enable the optimal (see Section 3.7) 928 management of ANM timeout in a network segment. 930 Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is 931 unlikely, but possible, causing the advertised TS/PC number to be 932 reused. Resolving this situation requires replacing all 933 authentication keys of the involved interface. In addition to that, 934 if the wrap was caused by a timestamp reaching its end of epoch, 935 using this mechanism will be impossible for the involved interface 936 until some different timestamp or update implementation method is 937 used. 939 5.2. Deriving ESAs from CSAs 941 Neither receiving nor sending procedures work with the contents of 942 interface's sequence of CSAs directly, both (Section 5.4 item 4 and 943 Section 5.3 item 4 respectively) derive a sequence of ESAs from the 944 sequence of CSAs and use the derived sequence (see Figure 1). There 945 are two main goals achieved through this indirection: 947 o Elimination of expired authentication keys and deduplication of 948 security associations. This is done as early as possible to keep 949 subsequent procedures focused on their respective tasks. 951 o Maintenance of particular ordering within the derived sequence of 952 ESAs. The ordering deterministically depends on the ordering 953 within the interface's sequence of CSAs and the ordering within 954 KeyChain sequence of each CSA. The particular correlation 955 maintained by this procedure implements a concept of fair 956 (independent of number of keys contained by each) competition 957 between CSAs. 959 The deriving procedure uses the following input arguments: 961 o input sequence of CSAs 963 o direction (sending or receiving) 965 o current time (CT) 967 The processing of input arguments begins with an empty output 968 sequence of ESAs and consists of the following steps: 970 1. Make a temporary copy of the input sequence of CSAs. 972 2. Remove all expired authentication keys from each KeyChain 973 sequence of the copy, that is, any keys such that: 975 * for receiving: KeyStartAccept is greater than CT or 976 KeyStopAccept is less than CT 978 * for sending: KeyStartGenerate is greater than CT or 979 KeyStopGenerate is less than CT 981 Note well that there are no special exceptions. Remove all 982 expired keys, even if there are no keys left after that (see 983 Section 7.4). 985 3. Use the copy to populate the output sequence of ESAs as follows: 987 1. Whether the KeyChain sequence of the first CSA contains at 988 least one key, use its first key to produce an ESA with 989 fields set as follows: 991 HashAlgo Set to HashAlgo of the current CSA. 993 KeyID Set to LocalKeyID modulo 2^16 of the current 994 key of the current CSA. 996 AuthKeyOctets Set to AuthKeyOctets of the current key of the 997 current CSA. 999 Append this ESA to the end of the output sequence. 1001 2. When the KeyChain sequence of the second CSA contains at 1002 least one key, use its first key the same way and so forth 1003 until all first keys of the copy are processed. 1005 3. When the KeyChain sequence of the first CSA contains at least 1006 two keys, use its second key the same way. 1008 4. When the KeyChain sequence of the second CSA contains at 1009 least two keys, use its second key the same way and so forth 1010 until all second keys of the copy are processed. 1012 5. And so forth until all keys of all CSAs of the copy are 1013 processed, exactly once each. 1015 In the description above the ordinals ("first", "second", and so 1016 on) with regard to keys stand for an element position after the 1017 removal of expired keys, not before. For example, if a KeyChain 1018 sequence was { Ka, Kb, Kc, Kd } before the removal and became 1019 { Ka, Kd } after, then Ka would be the "first" element and Kd 1020 would be the "second". 1022 4. Deduplicate the ESAs in the output sequence, that is, wherever 1023 two or more ESAs exist that share the same (HashAlgo, KeyID, 1024 AuthKeyOctets) triplet value, remove all of these ESAs except the 1025 one closest to the beginning of the sequence. 1027 The resulting sequence will contain zero or more unique ESAs, ordered 1028 in a way deterministically correlated with ordering of CSAs within 1029 the original input sequence of CSAs and ordering of keys within each 1030 KeyChain sequence. This ordering maximizes the probability of having 1031 equal amount of keys per original CSA in any N first elements of the 1032 resulting sequence. Possible optimisations of this deriving 1033 procedure are outlined in Section 6.3. 1035 5.3. Updates to Packet Sending 1037 Perform the following authentication-specific processing after the 1038 instance of the original protocol considers an outgoing Babel packet 1039 ready for sending, but before the packet is actually sent (see 1040 Figure 1). After that send the packet regardless if the 1041 authentication-specific processing modified the outgoing packet or 1042 left it intact. 1044 1. If the current outgoing interface's sequence of CSAs is empty, 1045 finish authentication-specific processing and consider the packet 1046 ready for sending. 1048 2. Increment TS/PC number of the current outgoing interface as 1049 explained in Section 5.1. 1051 3. Append to the end of the packet body (see Figure 2) a TS/PC TLV 1052 with fields set as follows: 1054 Type Set to 11. 1056 Length Set to 6. 1058 PacketCounter Set to the current value of LocalPC variable of 1059 the current outgoing interface. 1061 Timestamp Set to the current value of LocalTS variable of 1062 the current outgoing interface. 1064 Note that the current step may involve byte order conversion. 1066 4. Derive a sequence of ESAs using procedure defined in Section 5.2 1067 with the current interface's sequence of CSAs as the input 1068 sequence of CSAs, the current time as CT and "sending" as the 1069 direction. Proceed to the next step even if the derived sequence 1070 is empty. 1072 5. Iterate over the derived sequence using its ordering. For each 1073 ESA append to the end of the packet body (see Figure 2) an HMAC 1074 TLV with fields set as follows: 1076 Type Set to 12. 1078 Length Set to 2 plus digest length of HashAlgo of the current 1079 ESA. 1081 KeyID Set to KeyID of the current ESA. 1083 Digest Size exactly equal to the digest length of HashAlgo of 1084 the current ESA. Set the first 16 octets to the source 1085 IPv6 address of the current packet (see Section 6.1) and 1086 any subsequent octets to 0x00 (see Table 3). 1088 As soon as there are MaxDigestsOut HMAC TLVs appended to the 1089 current packet body, immediately proceed to the next step. 1091 Note that the current step may involve byte order conversion. 1093 6. Increment the "Body length" field value of the current packet 1094 header by the total length of TS/PC and HMAC TLVs appended to the 1095 current packet body so far. 1097 Note that the current step may involve byte order conversion. 1099 7. Make a temporary copy of the current packet. 1101 8. Iterate over the derived sequence again, using the same order and 1102 number of elements. For each ESA (and respectively for each HMAC 1103 TLV recently appended to the current packet body) compute an HMAC 1104 result (see Section 2.4) using the temporary copy (not the 1105 original packet) as Text, HashAlgo of the current ESA as H, and 1106 AuthKeyOctets of the current ESA as K. Write the HMAC result to 1107 the Digest field of the current HMAC TLV (see Table 4) of the 1108 current packet (not the copy). 1110 9. After this point, allow no more changes to the current packet 1111 header and body and consider it ready for sending. 1113 Note that even when the derived sequence of ESAs is empty, the packet 1114 is sent anyway with only a TS/PC TLV appended to its body. Although 1115 such a packet would not be authenticated, the presence of the sole 1116 TS/PC TLV would indicate authentication key exhaustion to operators 1117 of neighbouring Babel speakers. See also Section 7.4. 1119 5.4. Updates to Packet Receiving 1121 Perform the following authentication-specific processing after an 1122 incoming Babel packet is received from the local IPv6 stack, but 1123 before it is processed by the Babel protocol instance (see Figure 1). 1124 The final action conceptually depends not only upon the result of the 1125 authentication-specific processing, but also on the current value of 1126 RxAuthRequired parameter. Immediately after any processing step 1127 below accepts or refuses the packet, either deliver the packet to the 1128 instance of the original protocol (when the packet is accepted or 1129 RxAuthRequired is FALSE) or discard it (when the packet is refused 1130 and RxAuthRequired is TRUE). 1132 1. If the current incoming interface's sequence of CSAs is empty, 1133 accept the packet. 1135 2. If the current packet does not contain a TS/PC TLV, refuse it. 1137 3. Perform a lookup in the ANM table for an entry having Interface 1138 equal to the current incoming interface and Source equal to the 1139 source address of the current packet. If such an entry does not 1140 exist, immediately proceed to the next step. Otherwise, compare 1141 the entry's LastTS and LastPC field values with Timestamp and 1142 PacketCounter values respectively of the first TS/PC TLV of the 1143 packet. That is, refuse the packet, if at least one of the 1144 following two conditions is true: 1146 * Timestamp is less than LastTS 1148 * Timestamp is equal to LastTS and PacketCounter is not greater 1149 than LastPC 1151 Note that the current step may involve byte order conversion. 1153 4. Derive a sequence of ESAs using procedure defined in Section 5.2 1154 with the current interface's sequence of CSAs as the input 1155 sequence of CSAs, current time as CT and "receiving" as the 1156 direction. If the derived sequence is empty, refuse the packet. 1158 5. Make a temporary copy of the current packet. 1160 6. For every HMAC TLV present in the temporary copy (not the 1161 original packet) pad all octets of its Digest field using the 1162 source IPv6 address of the current packet to set the first 16 1163 octets and 0x00 to set any subsequent octets (see Table 3). 1165 7. Iterate over all the HMAC TLVs of the original input packet (not 1166 the copy) using their order of appearance in the packet. For 1167 each HMAC TLV look up all ESAs in the derived sequence such that 1168 2 plus digest length of HashAlgo of the ESA is equal to Length 1169 of the TLV and KeyID of the ESA is equal to value of KeyID of 1170 the TLV. Iterate over these ESAs in the relative order of their 1171 appearance on the full sequence of ESAs. Note that nesting the 1172 iterations the opposite way (over ESAs, then over HMAC TLVs) 1173 would be wrong. 1175 For each of these ESAs compute an HMAC result (see Section 2.4) 1176 using the temporary copy (not the original packet) as Text, 1177 HashAlgo of the current ESA as H, and AuthKeyOctets of the 1178 current ESA as K. If the current HMAC result exactly matches the 1179 contents of Digest field of the current HMAC TLV, immediately 1180 proceed to the next step. Otherwise, if the number of HMAC 1181 computations done for the current packet so far is equal to 1182 MaxDigestsIn, immediately proceed to the next step. Otherwise 1183 follow the normal order of iterations. 1185 Note that the current step may involve byte order conversion. 1187 8. Refuse the input packet unless there was a matching HMAC result 1188 in the previous step. 1190 9. Modify the ANM table, using the same index as for the entry 1191 lookup above, to contain an entry with LastTS set to the value 1192 of Timestamp and LastPC set to the value of PacketCounter fields 1193 of the first TS/PC TLV of the current packet. That is, either 1194 add a new ANM table entry or update the existing one, depending 1195 on the result of the entry lookup above. Reset the entry's 1196 aging timer to the current value of ANM timeout. 1198 Note that the current step may involve byte order conversion. 1200 10. Accept the input packet. 1202 Note that RxAuthRequired affects only the final action, but not the 1203 defined flow of authentication-specific processing. The purpose of 1204 this is to preserve authentication-specific processing feedback (such 1205 as log messages and event counters updates) even with RxAuthRequired 1206 set to FALSE. This allows an operator to predict the effect of 1207 changing RxAuthRequired from FALSE to TRUE during a migration 1208 scenario (Section 7.3) implementation. 1210 5.5. Authentication-Specific Statistics Maintenance 1212 A Babel speaker implementing this mechanism SHOULD maintain a set of 1213 counters for the following events, per protocol instance and per 1214 interface: 1216 o Sending of an unauthenticated Babel packet through an interface 1217 having an empty sequence of CSAs (Section 5.3 item 1). 1219 o Sending of an unauthenticated Babel packet with a TS/PC TLV but 1220 without any HMAC TLVs due to an empty derived sequence of ESAs 1221 (Section 5.3 item 4). 1223 o Sending of an authenticated Babel packet containing both TS/PC and 1224 HMAC TLVs (Section 5.3 item 9). 1226 o Accepting of a Babel packet received through an interface having 1227 an empty sequence of CSAs (Section 5.4 item 1). 1229 o Refusing of a received Babel packet due to an empty derived 1230 sequence of ESAs (Section 5.4 item 4). 1232 o Refusing of a received Babel packet missing any TS/PC TLVs 1233 (Section 5.4 item 2). 1235 o Refusing of a received Babel packet due to the first TS/PC TLV 1236 failing the ANM table check (Section 5.4 item 3). 1238 o Refusing of a received Babel packet missing any HMAC TLVs 1239 (Section 5.4 item 8). 1241 o Refusing of a received Babel packet due to none of the processed 1242 HMAC TLVs passing the ESA check (Section 5.4 item 8). 1244 o Accepting of a received Babel packet having both TS/PC and HMAC 1245 TLVs (Section 5.4 item 10). 1247 o Delivery of a refused packet to the instance of the original 1248 protocol due to RxAuthRequired parameter set to FALSE. 1250 Note that terms "accepting" and "refusing" are used in the sense of 1251 the receiving procedure, that is, "accepting" does not mean a packet 1252 delivered to the instance of the original protocol purely because the 1253 RxAuthRequired parameter is set to FALSE. Event counters readings 1254 SHOULD be available to the operator at runtime. 1256 6. Implementation Notes 1258 6.1. IPv6 Source Address Selection for Sending 1260 Section 3.1 of [BABEL] defines that Babel datagrams are exchanged 1261 using IPv6 link-local address as source address. This implies having 1262 at least one such address assigned to an interface participating in 1263 the exchange. When the interface has more than one link-local 1264 addresses assigned, selection of one particular link-local address as 1265 packet source address is left up to the local IPv6 stack, since this 1266 choice is not meaningful in the scope of the original protocol. 1267 However, the sending procedure requires exact knowledge of packet 1268 source address for proper padding (Section 5.3 item 5) of HMAC TLVs. 1270 As long as a Babel interface has more than one IPv6 link-local 1271 addresses assigned, the Babel speaker SHOULD internally choose one 1272 particular link-local address for Babel packet sending purposes and 1273 make this choice to both the sending procedure and local IPv6 stack 1274 (see Figure 1). Wherever this requirement cannot be met, this 1275 limitation MUST be clearly stated in the system documentation to 1276 allow an operator to plan IPv6 address management accordingly. 1278 6.2. Output Buffer Management 1280 An instance of the original protocol buffers produced TLVs until the 1281 buffer becomes full or a delay timer has expired or an urgent TLV is 1282 produced. This is performed independently for each Babel interface 1283 with each buffer sized according to the interface MTU (see Sections 1284 3.1 and 4 of [BABEL]). 1286 Since TS/PC and HMAC TLVs and any other TLVs, in the first place 1287 those of the original protocol, share the same packet space (see 1288 Figure 2) and respectively the same buffer space, a particular 1289 portion of each interface buffer needs to be reserved for 1 TS/PC TLV 1290 and up to MaxDigestsOut HMAC TLVs. The amount (R) of this reserved 1291 buffer space is calculated as follows: 1293 R = St + MaxDigestsOut * Sh = 1294 = 8 + MaxDigestsOut * (4 + Lmax) 1296 St Is the size of a TS/PC TLV. 1298 Sh Is the size of an HMAC TLV. 1300 Lmax Is the maximum digest length in octets possible for a 1301 particular interface. It SHOULD be calculated based on 1302 particular interface's sequence of CSAs, but MAY be taken as 1303 the maximum digest length supported by particular 1304 implementation. 1306 An implementation allowing for per-interface value of MaxDigestsOut 1307 parameter has to account for different value of R across different 1308 interfaces, even having the same MTU. An implementation allowing for 1309 runtime change of MaxDigestsOut parameter value has to take care of 1310 the TLVs already buffered by the time of the change, especially when 1311 the change increases the value of R. 1313 The maximum safe value of MaxDigestsOut parameter depends on the 1314 interface MTU and maximum digest length used. In general, at least 1315 200-300 octets of a Babel packet should be always available to data 1316 other than TS/PC and HMAC TLVs. An implementation following the 1317 requirements of Section 4 of [BABEL] would send packets sized 512 1318 octets or larger. If, for example, the maximum digest length is 64 1319 octets and MaxDigestsOut value is 4, the value of R would be 280, 1320 leaving less than a half of a 512-octet packet for any other TLVs. 1321 As long as the interface MTU is larger or digest length is smaller, 1322 higher values of MaxDigestsOut can be used safely. 1324 6.3. Optimisations of ESAs Deriving 1326 The following optimisations of the ESAs deriving procedure can reduce 1327 amount of CPU time consumed by authentication-specific processing, 1328 preserving an implementation's effective behaviour. 1330 a. The most straightforward implementation would treat the deriving 1331 procedure as a per-packet action. But since the procedure is 1332 deterministic (its output depends on its input only), it is 1333 possible to significantly reduce the number of times the 1334 procedure is performed. 1336 The procedure would obviously return the same result for the same 1337 input arguments (sequence of CSAs, direction, CT) values. 1338 However, it is possible to predict when the result will remain 1339 the same even for a different input. That is, when the input 1340 sequence of CSAs and the direction both remain the same but CT 1341 changes, the result will remain the same as long as CT's order on 1342 the time axis (relative to all critical points of the sequence of 1343 CSAs) remains unchanged. Here, the critical points are 1344 KeyStartAccept and KeyStopAccept (for the "receiving" direction) 1345 and KeyStartGenerate and KeyStopGenerate (for the "sending" 1346 direction) of all keys of all CSAs of the input sequence. In 1347 other words, in this case the result will remain the same as long 1348 as both none of the active keys expire and none of the inactive 1349 keys enter into operation. 1351 An implementation optimised this way would perform the full 1352 deriving procedure for a given (interface, direction) pair only 1353 after an operator's change to the interface's sequence of CSAs or 1354 after reaching one of the critical points mentioned above. 1356 b. Considering that the sending procedure iterates over at most 1357 MaxDigestsOut elements of the derived sequence of ESAs 1358 (Section 5.3 item 5), there would be little sense in the case of 1359 "sending" direction in returning more than MaxDigestsOut unique 1360 ESAs in the derived sequence. Note that a similar optimisation 1361 is impossible in the case of "receiving" direction, since number 1362 of ESAs actually used in examining a particular packet cannot be 1363 determined in advance. 1365 6.4. Security Associations Duplication 1367 This specification defines three data structures as finite sequences: 1368 a KeyChain sequence, an interface's sequence of CSAs, and a sequence 1369 of ESAs. There are associated semantics to take into account during 1370 implementation, in that the same element can appear multiple times at 1371 different positions of the sequence. In particular, none of CSA 1372 structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets) 1373 alone or in a combination has to be unique within a given CSA, or 1374 within a given sequence of CSAs, or within all sequences of CSAs of a 1375 Babel speaker. 1377 In the CSA space defined this way, for any two authentication keys 1378 their one field (in)equality would not imply their another field 1379 (in)equality. In other words, it is acceptable to have more than one 1380 authentication key with the same LocalKeyID or the same AuthKeyOctets 1381 or both at a time. It is a conscious design decision that CSA 1382 semantics allow for duplication of security associations. 1383 Consequently, ESA semantics allow for duplication of intermediate 1384 ESAs in the sequence until the explicit deduplication (Section 5.2 1385 item 4). 1387 One of the intentions of this is to define the security association 1388 management in a way that allows the addressing of some specifics of 1389 Babel as a mesh routing protocol. For example, a system operator 1390 configuring a Babel speaker to participate in more than one 1391 administrative domain could find each domain using its own 1392 authentication key (AuthKeyOctets) under the same LocalKeyID value, 1393 e.g., a "well-known" or "default" value like 0 or 1. Since 1394 reconfiguring the domains to use distinct LocalKeyID values isn't 1395 always feasible, the multi-domain Babel speaker using several 1396 distinct authentication keys under the same LocalKeyID would make a 1397 valid use case for such duplication. 1399 Furthermore, if in this situation the operator decided to migrate one 1400 of the domains to a different LocalKeyID value in a seamless way, 1401 respective Babel speakers would use the same authentication key 1402 (AuthKeyOctets) under two different LocalKeyID values for the time of 1403 the transition (see also item (e) of Section 9). This would make a 1404 similar use case. 1406 Another intention of this design decision is to decouple security 1407 association management from authentication key management as much as 1408 possible, so that the latter, be it manual keying or a key management 1409 protocol, could be designed and implemented independently. This way 1410 the additional key management constraints, if any, would be left out 1411 of scope of this authentication mechanism. A similar thinking 1412 justifies LocalKeyID field having bit length in ESA structure 1413 definition, but not in that of CSA. 1415 7. Network Management Aspects 1417 7.1. Backward Compatibility 1419 Support of this mechanism is optional, it does not change the default 1420 behaviour of a Babel speaker and causes no compatibility issues with 1421 speakers properly implementing the original Babel specification. 1422 Given two Babel speakers, one implementing this mechanism and 1423 configured for authenticated exchange (A) and another not 1424 implementing it (B), these would not distribute routing information 1425 uni-directionally or form a routing loop or experience other protocol 1426 logic issues specific purely to the use of this mechanism. 1428 The Babel design requires a bi-directional neighbour reachability 1429 condition between two given speakers for a successful exchange of 1430 routing information. Apparently, in the case above neighbour 1431 reachability would be uni-directional. Presence of TS/PC and HMAC 1432 TLVs in Babel packets sent by A would be transparent to B. But lack 1433 of authentication data in Babel packets send by B would make them 1434 effectively invisible to the instance of the original protocol of A. 1435 Uni-directional links are not specific to use of this mechanism, they 1436 naturally exist on their own and are properly detected and coped with 1437 by the original protocol (see Section 3.4.2 of [BABEL]). 1439 7.2. Multi-Domain Authentication 1441 The receiving procedure treats a packet as authentic as soon as one 1442 of its HMAC TLVs passes the check against the derived sequence of 1443 ESAs. This allows for packet exchange authenticated with multiple 1444 (hash algorithm, authentication key) pairs simultaneously, in 1445 combinations as arbitrary as permitted by MaxDigestsIn and 1446 MaxDigestsOut. 1448 For example, consider three Babel speakers with one interface each, 1449 configured with the following CSAs: 1451 o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key 1452 SK2) 1454 o speaker B: (hash algorithm H1; key SK1) 1456 o speaker C: (hash algorithm H1; key SK2) 1458 Packets sent by A would contain 2 HMAC TLVs each, packets sent by B 1459 and C would contain 1 HMAC TLV each. A and B would authenticate the 1460 exchange between themselves using H1 and SK1; A and C would use H1 1461 and SK2; B and C would discard each other's packets. 1463 Consider a similar set of speakers configured with different CSAs: 1465 o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key 1466 SK4) 1468 o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4, keys 1469 SK5 and SK6) 1471 o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm 1472 H5, key SK8) 1474 Packets sent by D would contain 2 HMAC TLVs each, packets sent by E 1475 and F would contain 3 HMAC TLVs each. D and E would authenticate the 1476 exchange between themselves using H2 and SK3; D and F would use H3 1477 and SK4; E and F would discard each other's packets. The 1478 simultaneous use of H4, SK5, and SK6 by E, as well as use of SK7, H5, 1479 and SK8 by F (for their own purposes) would remain insignificant to 1480 A. 1482 An operator implementing a multi-domain authentication should keep in 1483 mind that values of MaxDigestsIn and MaxDigestsOut may be different 1484 both within the same Babel speaker and across different speakers. 1485 Since the minimum value of both parameters is 2 (see Section 3.4 and 1486 Section 3.5), when more than 2 authentication domains are configured 1487 simultaneously it is advised to confirm that every involved speaker 1488 can handle sufficient number of HMAC results for both sending and 1489 receiving. 1491 The recommended method of Babel speaker configuration for multi- 1492 domain authentication is not only using a different authentication 1493 key for each domain, but also using a separate CSA for each domain, 1494 even when hash algorithms are the same. This allows for fair 1495 competition between CSAs and sometimes limits the consequences of a 1496 possible misconfiguration to the scope of one CSA. See also item (e) 1497 of Section 9. 1499 7.3. Migration to and from Authenticated Exchange 1501 It is common in practice to consider a migration to authenticated 1502 exchange of routing information only after the network has already 1503 been deployed and put to an active use. Performing the migration in 1504 a way without regular traffic interruption is typically demanded, and 1505 this specification allows a smooth migration using the RxAuthRequired 1506 interface parameter defined in Section 3.1. This measure is similar 1507 to the "transition mode" suggested in Section 5 of [OSPF3-AUTH]. 1509 An operator performing the migration needs to arrange configuration 1510 changes as follows: 1512 1. Decide on particular hash algorithm(s) and key(s) to be used. 1514 2. Identify all speakers and their involved interfaces that need to 1515 be migrated to authenticated exchange. 1517 3. For each of the speakers and the interfaces to be reconfigured 1518 first set RxAuthRequired parameter to FALSE, then configure 1519 necessary CSA(s). 1521 4. Examine the speakers to confirm that Babel packets are 1522 successfully authenticated according to the configuration 1523 (supposedly, through examining ANM table entries and 1524 authentication-specific statistics, see Figure 1) and address any 1525 discrepancies before proceeding further. 1527 5. For each of the speakers and the reconfigured interfaces set the 1528 RxAuthRequired parameter to TRUE. 1530 Likewise, temporarily setting RxAuthRequired to FALSE can be used to 1531 migrate smoothly from an authenticated packet exchange back to 1532 unauthenticated one. 1534 7.4. Handling of Authentication Keys Exhaustion 1536 This specification employs a common concept of multiple authenticaion 1537 keys co-existing for a given interface, with two independent lifetime 1538 ranges associated with each key (one for sending and another for 1539 receiving). It is typically recommended to configure the keys using 1540 finite lifetimes, adding new keys before the old keys expire. 1541 However, it is obviously possible for all keys to expire for a given 1542 interface (for sending or receiving or both). Possible ways of 1543 addressing this situation raise their own concerns: 1545 o Automatic switching to unauthenticated protocol exchange. This 1546 behaviour invalidates the initial purposes of authentication and 1547 is commonly viewed as "unacceptable" ([RIP2-AUTH] Section 5.1, 1548 [OSPF2-AUTH] Section 3.2, [OSPF3-AUTH] Section 3). 1550 o Stopping routing information exchange over the interface. This 1551 behaviour is likely to impact regular traffic routing and is 1552 commonly viewed as "not advisable" (ibid.). 1554 o Use of the "most recently expired" key over its intended lifetime 1555 range. This behaviour is commonly recommended for implementation 1556 (ibid.), although it may become a problem due to an offline 1557 cryptographic attack (see item (e) of Section 9) or a compromise 1558 of the key. In addition, telling a recently expired key from a 1559 key never ever been in a use may be impossible after a router 1560 restart. 1562 Design of this mechanism prevents the automatic switching to 1563 unauthenticated exchange and is consistent with similar 1564 authentication mechanisms in this regard. But since the best choice 1565 between two other options depends on local site policy, this decision 1566 is left up to the operator rather than the implementor (in a way 1567 resembling the "fail secure" configuration knob described in Section 1568 5.1 of [RIP2-AUTH]). 1570 Although the deriving procedure does not allow for any exceptions in 1571 expired keys filtering (Section 5.2 item 2), the operator can 1572 trivially enforce one of the two remaining behaviour options through 1573 local key management procedures. In particular, when using the key 1574 over its intended lifetime is more preferred than regular traffic 1575 disruption, the operator would explicitly leave the old key expiry 1576 time open until the new key is added to the router configuration. In 1577 the opposite case the operator would always configure the old key 1578 with a finite lifetime and bear associated risks. 1580 8. Implementation Status 1582 [RFC Editor: before publication please remove this section and the 1583 reference to [I-D.sheffer-running-code], along the offered experiment 1584 of which this section exists to assist document reviewers.] 1586 At the time of this writing the original Babel protocol is available 1587 in two free, production-quality implementations: 1589 o The "standalone" babeld, a BSD-licensed software with source code 1590 available on GitHub [1]. 1592 That implementation does not support this authentication 1593 mechanism. 1595 o The integrated babeld component of Quagga-RE, a work derived from 1596 Quagga routing protocol suite, a GPL-lisensed software with source 1597 code available on GitHub [2]. 1599 That implementation supports this authentication mechanism as 1600 defined in revision 02 of this document. It supports both 1601 mandatory-to-implement hash algorithms (SHA-512 and Whirlpool) and 1602 a few additional algorithms (RIPEMD-160, SHA-224, SHA-256, and 1603 SHA-384). It does not support more than one link-local IPv6 1604 address per interface. It implements authentication-specific 1605 parameters, data structures and methods as follows (whether a 1606 parameter can be "changed at runtime", it is done by means of CLI 1607 and can also be set in a configuration file): 1609 * MaxDigestsIn value is fixed to 4. 1611 * MaxDigestsOut value is fixed to 4. 1613 * RxAuthRequired value is specific to each interface and can be 1614 changed at runtime. 1616 * ANM Table contents is not retained across speaker restarts, can 1617 be retrieved and reset (all entries at once) by means of CLI. 1619 * ANM Timeout value is specific to the whole protocol instance, 1620 has a default value of 300 seconds and can be changed at 1621 runtime. 1623 * Ordering of elements within each interface's sequence of CSAs 1624 is arbitrary as set by operator at runtime. CSAs are 1625 implemented to refer to existing key chain syntax items. 1626 Elements of an interface's sequence of CSAs are constrained to 1627 be unique reference-wise, but not contents-wise, that is, it is 1628 possible to duplicate security associations using a different 1629 key chain name to contain the same keys. 1631 * Ordering of elements within each KeyChain sequence is fixed to 1632 the sort order of LocalKeyID. LocalKeyID is constrained to be 1633 unique within each KeyChain sequence. 1635 * TS/PC number updates method can be configured at runtime for 1636 the whole protocol instance to one of two methods standing for 1637 items (a) and (b) of Section 5.1. The default method is (b). 1639 * Most of the authentication-specific statistics counters listed 1640 in Section 5.5 are implemented (per protocol instance and per 1641 each interface) and their readings are available by means of 1642 CLI with an option to log respective events into a file. 1644 No other implementations of this authentication mechanism are 1645 known to exist, thus interoperability can only be assessed on 1646 paper. The only existing implementation has been tested to be 1647 fully compatible with itself. 1649 9. Security Considerations 1651 Use of this mechanism implies requirements common to a use of shared 1652 authentication keys, including, but not limited to: 1654 o holding the keys secret, 1656 o including sufficient amounts of random bits into each key, 1658 o rekeying on a regular basis, and 1660 o never reusing a used key for a different purpose 1662 That said, proper design and implementation of a key management 1663 policy is out of scope of this work. Many publications on this 1664 subject exist and should be used for this purpose. 1666 Considering particular attacks being in-scope or out of scope on one 1667 hand and measures taken to protect against particular in-scope 1668 attacks on the other, the original Babel protocol and this 1669 authentication mechanism are in line with similar datagram-based 1670 routing protocols and their respective mechanisms. In particular, 1671 the primary concerns addressed are: 1673 a. Peer Entity Authentication 1675 The Babel speaker authentication mechanism defined herein is 1676 believed to be as strong as is the class itself that it belongs 1677 to. This specification is built on fundamental concepts 1678 implemented for authentication of similar routing protocols: per- 1679 packet authentication, use of HMAC construct, use of shared keys. 1680 Although this design approach does not address all possible 1681 concerns, it is so far known to be sufficient for most practical 1682 cases. 1684 b. Data Integrity 1686 Meaningful parts of a Babel datagram are the contents of the 1687 Babel packet (in the definition of Section 4.2 of [BABEL]) and 1688 IPv6 source address of the datagram (Section 3.5.3 ibid.). This 1689 mechanism authenticates both parts using an HMAC construct, so 1690 that making any meaningful change to an authenticated packet 1691 after it has been emitted by the sender should be as hard as 1692 attacking the hash algorithm itself or successfully recovering 1693 the authentication key. 1695 Note well that any trailing data of the Babel datagram is not 1696 meaningful in the scope of the original specification and does 1697 not belong to the Babel packet. Integrity of the trailing data 1698 is respectively not protected by this mechanism. At the same 1699 time, although any TLV extra data is also not meaningful in the 1700 same scope, its integrity is protected, since this extra data is 1701 a part of the Babel packet (see Figure 2). 1703 c. Replay Attacks 1705 This specification establishes a basic replay protection measure 1706 (see Section 3.6), defines a timeout parameter affecting its 1707 strength (see Section 3.7), and outlines implementation methods 1708 also affecting protection strength in several ways (see 1709 Section 5.1). The implementor's choice of the timeout value and 1710 particular implementation methods may be suboptimal due to, for 1711 example, insufficient hardware resources of the Babel speaker. 1712 Furthermore, it may be possible that an operator configures the 1713 timeout and the methods to address particular local specifics and 1714 this further weakens the protection. An operator concerned about 1715 replay attack protection strength should understand these factors 1716 and their meaning in a given network segment. 1718 d. Denial of Service 1720 Proper deployment of this mechanism in a Babel network 1721 significantly increases the efforts required for an attacker to 1722 feed arbitrary Babel PDUs into protocol exchange (with an intent 1723 of attacking a particular Babel speaker or disrupting exchange of 1724 regular traffic in a routing domain). It also protects the 1725 neighbour table from being flooded with forged speaker entries. 1727 At the same time, this protection comes with a price of CPU time 1728 being spent on HMAC computations. This may be a concern for low- 1729 performance CPUs combined with high-speed interfaces, as 1730 sometimes seen in embedded systems and hardware routers. The 1731 MaxDigestsIn parameter, which is used to limit the maximum amount 1732 of CPU time spent on a single received Babel packet, addresses 1733 this concern to some extent. 1735 The following in-scope concerns are not addressed: 1737 e. Offline Cryptographic Attacks 1739 This mechanism is obviously subject to offline cryptographic 1740 attacks. As soon as an attacker has obtained a copy of an 1741 authenticated Babel packet of interest (which gets easier to do 1742 in wireless networks), he has got all the parameters of the 1743 authentication-specific processing performed by the sender, 1744 except authentication key(s) and choice of particular hash 1745 algorithm(s). Since digest lengths of common hash algorithms are 1746 well-known and can be matched with those seen in the packet, 1747 complexity of this attack is essentially that of the 1748 authentication key attack. 1750 Viewing the cryptographic strength of particular hash algorithms 1751 as a concern of its own, the main practical means of resisting 1752 offline cryptographic attacks on this mechanism are periodic 1753 rekeying and use of strong keys with a sufficient number of 1754 random bits. 1756 It is important to understand that in the case of multiple keys 1757 being used within single interface (for a multi-domain 1758 authentication or during a key rollover) the strength of the 1759 combined configuration would be that of the weakest key, since 1760 only one successful HMAC test is required for an authentic 1761 packet. Operators concerned about offline cryptographic attacks 1762 should enforce the same strength policy for all keys used for a 1763 given interface. 1765 Note that a special pathological case is possible with this 1766 mechanism. Whenever two or more authentication keys are 1767 configured for a given interface such that all keys share the 1768 same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 1769 2^16 is different for each key, these keys will not be treated as 1770 duplicate (Section 5.2 item 4), but an HMAC result computed for a 1771 given packet will be the same for each of these keys. In the 1772 case of sending procedure this can produce multiple HMAC TLVs 1773 with exactly the same value of the Digest field, but different 1774 values of KeyID field. In this case the attacker will see that 1775 the keys are the same, even without the knowledge of the key 1776 itself. Reuse of authentication keys is not the intended use 1777 case of this mechanism and should be strongly avoided. 1779 f. Non-repudiation 1781 This specification relies on a use of shared keys. There is no 1782 timestamp infrastructure and no key revocation mechanism defined 1783 to address a shared key compromise. Establishing the time that a 1784 particular authentic Babel packet was generated is thus not 1785 possible. Proving that a particular Babel speaker had actually 1786 sent a given authentic packet is also impossible as soon as the 1787 shared key is claimed compromised. Even with the shared key not 1788 being compromised, reliably identifying the speaker that had 1789 actually sent a given authentic Babel packet is not possible any 1790 better than proving the speaker belongs to the group sharing the 1791 key (any of the speakers sharing a key can impose any other 1792 speaker sharing the same key). 1794 g. Confidentiality Violations 1796 The original Babel protocol does not encrypt any of the 1797 information contained in its packets. The contents of a Babel 1798 packet is trivial to decode, revealing network topology details. 1799 This mechanism does not improve this situation in any way. Since 1800 routing protocol messages are not the only kind of information 1801 subject to confidentiality concerns, a complete solution to this 1802 problem is likely to include measures based on the channel 1803 security model, such as IPSec and WPA2 at the time of this 1804 writing. 1806 h. Key Management 1808 Any authentication key exchange/distribution concerns are left 1809 out of scope. However, the internal representation of 1810 authentication keys (see Section 3.8) allows for diverse key 1811 management means, manual configuration in the first place. 1813 i. Message Deletion 1815 Any message deletion attacks are left out of scope. Since a 1816 datagram deleted by an attacker cannot be distinguished from a 1817 datagram naturally lost in transmission and since datagram-based 1818 routing protocols are designed to withstand a certain loss of 1819 packets, the currently established practice is treating 1820 authentication purely as a per-packet function without any added 1821 detection of lost packets. 1823 10. IANA Considerations 1825 [RFC Editor: please do not remove this section.] 1827 At the time of this publication Babel TLV Types namespace did not 1828 have an IANA registry. TLV types 11 and 12 were assigned (see 1829 Table 1) to the TS/PC and HMAC TLV types by Juliusz Chroboczek, 1830 designer of the original Babel protocol. Therefore, this document 1831 has no IANA actions. 1833 11. Acknowledgements 1835 Thanks to Randall Atkinson and Matthew Fanto for their comprehensive 1836 work on [RIP2-AUTH] that initiated a series of publications on 1837 routing protocols authentication, including this one. This 1838 specification adopts many concepts belonging to the whole series. 1840 Thanks to Juliusz Chroboczek for his works on mesh networking in 1841 general and the Babel routing protocol in particular, and also for 1842 feedback on early revisions of this document. This work would not be 1843 possible without prior works on Babel. Thanks to Gabriel Kerneis and 1844 Dominic Mulligan for reviewing and proofreading early revisions of 1845 this document. Thanks to Riku Hietamaki for suggesting the test 1846 vectors section. 1848 Thanks to Jim Gettys and Dave Taht for developing CeroWrt wireless 1849 router project and collaborating on many integration issues. A 1850 practical need for Babel authentication emerged during a research 1851 based on CeroWrt that eventually became the very first use case of 1852 this mechanism. 1854 Thanks to Kunihiro Ishiguro and Paul Jakma for establishing GNU Zebra 1855 and Quagga routing software projects respectively. Thanks to Werner 1856 Koch, the author of Libgcrypt. The very first implementation of this 1857 mechanism was made on base of Quagga and Libgcrypt. 1859 This document was produced using the xml2rfc ([RFC2629]) authoring 1860 tool. 1862 12. References 1864 12.1. Normative References 1866 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1867 Hashing for Message Authentication", RFC 2104, 1868 February 1997. 1870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1871 Requirement Levels", BCP 14, RFC 2119, March 1997. 1873 [FIPS-198] 1874 US National Institute of Standards & Technology, "The 1875 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 1876 198 , March 2002. 1878 [BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1879 April 2011. 1881 [I-D.sheffer-running-code] 1882 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1883 Code: the Implementation Status Section", 1884 draft-sheffer-running-code-04 (work in progress), 1885 April 2013. 1887 12.2. Informative References 1889 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1890 June 1999. 1892 [RIP2-AUTH] 1893 Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1894 Authentication", RFC 4822, February 2007. 1896 [OSPF2-AUTH] 1897 Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 1898 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 1899 Authentication", RFC 5709, October 2009. 1901 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 1902 with Existing Cryptographic Protection Methods for Routing 1903 Protocols", RFC 6039, October 2010. 1905 [OSPF3-AUTH] 1906 Bhatia, M., Manral, V., and A. Lindem, "Supporting 1907 Authentication Trailer for OSPFv3", RFC 6506, 1908 February 2012. 1910 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 1911 Considerations for Protocol Extensions", RFC 6709, 1912 September 2012. 1914 URIs 1916 [1] 1918 [2] 1920 Appendix A. Figures and Tables 1922 +-------------------------------------------------------------+ 1923 | authentication-specific statistics | 1924 +-------------------------------------------------------------+ 1925 ^ | ^ 1926 | v | 1927 | +-----------------------------------------------+ | 1928 | | system operator | | 1929 | +-----------------------------------------------+ | 1930 | ^ | ^ | ^ | ^ | ^ | | 1931 | | v | | | | | | | v | 1932 +---+ +---------+ | | | | | | +---------+ +---+ 1933 | |->| ANM | | | | | | | | LocalTS |->| | 1934 | R |<-| table | | | | | | | | LocalPC |<-| T | 1935 | x | +---------+ | v | v | v +---------+ | x | 1936 | | +----------------+ +---------+ +----------------+ | | 1937 | p | | MaxDigestsIn | | | | MaxDigestsOut | | p | 1938 | r |<-| ANM timeout | | CSAs | | |->| r | 1939 | o | | RxAuthRequired | | | | | | o | 1940 | c | +----------------+ +---------+ +----------------+ | c | 1941 | e | +-------------+ | | +-------------+ | e | 1942 | s | | Rx ESAs | | | | Tx ESAs | | s | 1943 | s |<-| (temporary) |<----+ +---->| (temporary) |->| s | 1944 | i | +-------------+ +-------------+ | i | 1945 | n | +------------------------------+----------------+ | n | 1946 | g | | instance of | output buffers |=>| g | 1947 | |=>| the original +----------------+ | | 1948 | | | protocol | source address |->| | 1949 +---+ +------------------------------+----------------+ +---+ 1950 /\ | || 1951 || v \/ 1952 +-------------------------------------------------------------+ 1953 | IPv6 stack | 1954 +-------------------------------------------------------------+ 1955 /\ || /\ || /\ || /\ || 1956 || \/ || \/ || \/ || \/ 1957 +---------+ +---------+ +---------+ +---------+ 1958 | speaker | | speaker | ... | speaker | | speaker | 1959 +---------+ +---------+ +---------+ +---------+ 1961 Flow of Babel datagrams: ===> Flow of control data: ---> 1963 Figure 1: Interaction Diagram 1965 The diagram below depicts structure of two Babel datagrams. The left 1966 datagram contains an unauthenticated Babel packet and an optional 1967 trailing data block. The right datagram, besides these, contains 1968 authentication-specific TLVs in the Babel packet body. 1970 +-------------------+ ------- ------- +-------------------+ 1971 | Babel packet | ^ ^ | Babel packet | 1972 | header | | | | header | 1973 +-------------------+ -- | | -- +-------------------+ 1974 | some TLV | ^ | | ^ | some TLV | 1975 +-------------------+ | | | | +-------------------+ 1976 | some TLV | | | P | | | some TLV | 1977 +-------------------+ | | | | +-------------------+ 1978 | (...) | | B | | | | (...) | 1979 +-------------------+ | | | | +-------------------+ 1980 | some TLV | | | P | | | some TLV | 1981 +-------------------+ | | | | +-------------------+ 1982 | some TLV | v v | B | | some TLV | 1983 +-------------------+ ------- | | +-------------------+ 1984 | optional trailing | | | | TS/PC TLV | 1985 | data block | | | +-------------------+ 1986 +-------------------+ | | | HMAC TLV | 1987 | | +-------------------+ 1988 | | | (...) | 1989 | | +-------------------+ 1990 P: Babel packet v v | HMAC TLV | 1991 B: Babel packet body ------- +-------------------+ 1992 | optional trailing | 1993 | data block | 1994 +-------------------+ 1996 Figure 2: Babel Datagram Structure 1998 +-------+-------------------------+---------------+ 1999 | Value | Code | Reference | 2000 +-------+-------------------------+---------------+ 2001 | 0 | Pad1 | [BABEL] | 2002 | 1 | PadN | [BABEL] | 2003 | 2 | Acknowledgement Request | [BABEL] | 2004 | 3 | Acknowledgement | [BABEL] | 2005 | 4 | Hello | [BABEL] | 2006 | 5 | IHU | [BABEL] | 2007 | 6 | Router-Id | [BABEL] | 2008 | 7 | Next Hop | [BABEL] | 2009 | 8 | Update | [BABEL] | 2010 | 9 | Route Request | [BABEL] | 2011 | 10 | Seqno Request | [BABEL] | 2012 | 11 | TS/PC | this document | 2013 | 12 | HMAC | this document | 2014 +-------+-------------------------+---------------+ 2016 Table 1: Babel TLV Types Namespace 2018 +--------------+-----------------------------+-------------------+ 2019 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2020 +--------------+-----------------------------+-------------------+ 2021 | Magic | 2a | 42 | 2022 | Version | 02 | version 2 | 2023 | Body length | 00:14 | 20 octets | 2024 | [TLV] Type | 04 | 4 (Hello) | 2025 | [TLV] Length | 06 | 6 octets | 2026 | Reserved | 00:00 | no meaning | 2027 | Seqno | 7d:60 | 32096 | 2028 | Interval | 01:90 | 400 | 2029 | [TLV] Type | 08 | 8 (Update) | 2030 | [TLV] Length | 0a | 10 octets | 2031 | AE | 00 | 0 (wildcard) | 2032 | Flags | 40 | default router-id | 2033 | Plen | 00 | 0 bits | 2034 | Omitted | 00 | 0 bits | 2035 | Interval | ff:ff | infinity | 2036 | Seqno | 7c:88 | 31880 | 2037 | Metric | ff:ff | infinity | 2038 +--------------+-----------------------------+-------------------+ 2040 Table 2: A Babel Packet without Authentication TLVs 2042 +---------------+-------------------------------+-------------------+ 2043 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2044 +---------------+-------------------------------+-------------------+ 2045 | Magic | 2a | 42 | 2046 | Version | 02 | version 2 | 2047 | Body length | 00:a4 | 164 octets | 2048 | [TLV] Type | 04 | 4 (Hello) | 2049 | [TLV] Length | 06 | 6 octets | 2050 | Reserved | 00:00 | no meaning | 2051 | Seqno | 7d:60 | 32096 | 2052 | Interval | 01:90 | 400 | 2053 | [TLV] Type | 08 | 8 (Update) | 2054 | [TLV] Length | 0a | 10 octets | 2055 | AE | 00 | 0 (wildcard) | 2056 | Flags | 40 | default router-id | 2057 | Plen | 00 | 0 bits | 2058 | Omitted | 00 | 0 bits | 2059 | Interval | ff:ff | infinity | 2060 | Seqno | 7c:88 | 31880 | 2061 | Metric | ff:ff | infinity | 2062 | [TLV] Type | 0b | 11 (TS/PC) | 2063 | [TLV] Length | 06 | 6 octets | 2064 | PacketCounter | 00:01 | 1 | 2065 | Timestamp | 51:5a:68:ee | 1364879598 | 2066 | [TLV] Type | 0c | 12 (HMAC) | 2067 | [TLV] Length | 42 | 66 octets | 2068 | KeyID | 00:c8 | 200 | 2069 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2070 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2071 | | 00:00:00:00:00:00:00:00:00:00 | | 2072 | | 00:00:00:00:00:00:00:00:00:00 | | 2073 | | 00:00:00:00:00:00:00:00:00:00 | | 2074 | | 00:00:00:00:00:00:00:00:00:00 | | 2075 | | 00:00:00:00 | | 2076 | [TLV] Type | 0c | 12 (HMAC) | 2077 | [TLV] Length | 42 | 66 octets | 2078 | KeyID | 00:64 | 100 | 2079 | Digest | fe:80:00:00:00:00:00:00:0a:11 | padding | 2080 | | 96:ff:fe:1c:10:c8:00:00:00:00 | | 2081 | | 00:00:00:00:00:00:00:00:00:00 | | 2082 | | 00:00:00:00:00:00:00:00:00:00 | | 2083 | | 00:00:00:00:00:00:00:00:00:00 | | 2084 | | 00:00:00:00:00:00:00:00:00:00 | | 2085 | | 00:00:00:00 | | 2086 +---------------+-------------------------------+-------------------+ 2088 Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address 2089 fe80::0a11:96ff:fe1c:10c8 2091 +---------------+-------------------------------+-------------------+ 2092 | Packet field | Packet octets (hexadecimal) | Meaning (decimal) | 2093 +---------------+-------------------------------+-------------------+ 2094 | Magic | 2a | 42 | 2095 | Version | 02 | version 2 | 2096 | Body length | 00:a4 | 164 octets | 2097 | [TLV] Type | 04 | 4 (Hello) | 2098 | [TLV] Length | 06 | 6 octets | 2099 | Reserved | 00:00 | no meaning | 2100 | Seqno | 7d:60 | 32096 | 2101 | Interval | 01:90 | 400 | 2102 | [TLV] Type | 08 | 8 (Update) | 2103 | [TLV] Length | 0a | 10 octets | 2104 | AE | 00 | 0 (wildcard) | 2105 | Flags | 40 | default router-id | 2106 | Plen | 00 | 0 bits | 2107 | Omitted | 00 | 0 bits | 2108 | Interval | ff:ff | infinity | 2109 | Seqno | 7c:88 | 31880 | 2110 | Metric | ff:ff | infinity | 2111 | [TLV] Type | 0b | 11 (TS/PC) | 2112 | [TLV] Length | 06 | 6 octets | 2113 | PacketCounter | 00:01 | 1 | 2114 | Timestamp | 51:5a:68:ee | 1364879598 | 2115 | [TLV] Type | 0c | 12 (HMAC) | 2116 | [TLV] Length | 42 | 66 octets | 2117 | KeyID | 00:c8 | 200 | 2118 | Digest | 4c:72:34:27:23:1a:9a:26:71:0c | HMAC result | 2119 | | 6b:24:40:58:cb:cb:e5:a6:c2:80 | | 2120 | | 9d:31:13:00:3c:a3:52:0d:c6:07 | | 2121 | | 13:69:0a:6e:32:84:44:b6:97:8b | | 2122 | | 0d:85:e6:8f:80:d1:ec:c0:dc:db | | 2123 | | 28:c2:15:42:51:36:04:15:3b:37 | | 2124 | | 7f:3d:e1:72 | | 2125 | [TLV] Type | 0c | 12 (HMAC) | 2126 | [TLV] Length | 42 | 66 octets | 2127 | KeyID | 00:64 | 100 | 2128 | Digest | ea:b3:e0:80:18:70:1a:a3:9c:d7 | HMAC result | 2129 | | cf:1d:dd:06:51:5d:e6:ab:02:99 | | 2130 | | 82:2f:cd:b5:a4:b6:f0:c6:a9:fc | | 2131 | | 04:50:1b:bd:82:4d:0d:28:90:a8 | | 2132 | | 90:32:dc:f6:5e:ad:7c:74:c2:68 | | 2133 | | 0c:8a:89:2a:bb:9e:09:ae:b0:a6 | | 2134 | | 60:98:5d:9b | | 2135 +---------------+-------------------------------+-------------------+ 2137 Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result 2139 Appendix B. Test Vectors 2141 The test vectors below may be used to verify the correctness of some 2142 procedures performed by an implementation of this mechanism, namely: 2144 o appending of TS/PC and HMAC TLVs to the Babel packet body, 2146 o padding of the HMAC TLV(s), 2148 o computing of the HMAC result(s), and 2150 o placement of the result(s) in the TLV(s). 2152 This verification isn't exhaustive, there are other implementation 2153 aspects that would require testing methods of their own. 2155 The test vectors were produced as follows. 2157 1. A Babel speaker with a network interface with IPv6 link-local 2158 address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs 2159 for the interface: 2161 * CSA1={HashAlgo=SHA-512, KeyChain={{LocalKeyID=200, 2162 AuthKeyOctets=Key70}}} 2164 * CSA2={HashAlgo=Whirlpool, KeyChain={{LocalKeyId=100, 2165 AuthKeyOctets=Key26}}} 2167 The authentication keys above are: 2169 * Key70 in ASCII: 2171 This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567 2173 * Key70 in hexadecimal: 2175 54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63 2176 74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f 2177 6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c 2178 4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31 2179 32:33:34:35:36:37 2181 * Key26 in ASCII: 2183 ABCDEFGHIJKLMNOPQRSTUVWXYZ 2184 * Key26 in hexadecimal: 2186 41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50 2187 51:52:53:54:55:56:57:58:59:5a 2189 KeyStartAccept, KeyStopAccept, KeyStartGenerate and 2190 KeyStopGenerate were set to make both authentication keys valid. 2191 The length of each key was picked to relate (in the terms of 2192 Section 2.4) with the properties of respective hash algorithm as 2193 follows: 2195 * Key70 is 70 octets long. The digest length (L) of SHA-512 is 2196 64 octets. The internal block size (B) of SHA-512 is 128 2197 octets. 2199 * Key26 is 26 octets long. The digest length (L) of Whirlpool 2200 is 64 octets. The internal block size (B) of Whirlpool is 64 2201 octets. 2203 2. The instance of the original protocol of the speaker produced a 2204 Babel packet (PktO) to be sent from the interface. Table 2 2205 provides a decoding of PktO, contents of which is below: 2207 2a:02:00:14:04:06:00:00:7d:60:01:90:08:0a:00:40 2208 00:00:ff:ff:7c:88:ff:ff 2210 3. The authentication mechanism appended one TS/PC TLV and two HMAC 2211 TLVs to the packet body, updated the "Body length" packet header 2212 field and padded the Digest field of the HMAC TLVs using the 2213 link-local IPv6 address of the interface and necessary amount of 2214 zeroes. Table 3 provides a decoding of the resulting temporary 2215 packet (PktT), contents of which is below: 2217 2a:02:00:a4:04:06:00:00:7d:60:01:90:08:0a:00:40 2218 00:00:ff:ff:7c:88:ff:ff:0b:06:00:01:51:5a:68:ee 2219 0c:42:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff 2220 fe:1c:10:c8:00:00:00:00:00:00:00:00:00:00:00:00 2221 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 2222 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 2223 00:00:00:00:0c:42:00:64:fe:80:00:00:00:00:00:00 2224 0a:11:96:ff:fe:1c:10:c8:00:00:00:00:00:00:00:00 2225 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 2226 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 2227 00:00:00:00:00:00:00:00 2229 4. The authentication mechanism produced two HMAC results, 2230 performing the computations as follows: 2232 * For H=SHA-512, K=Key70, and Text=PktT the HMAC result is: 2234 4c:72:34:27:23:1a:9a:26:71:0c:6b:24:40:58:cb:cb 2235 e5:a6:c2:80:9d:31:13:00:3c:a3:52:0d:c6:07:13:69 2236 0a:6e:32:84:44:b6:97:8b:0d:85:e6:8f:80:d1:ec:c0 2237 dc:db:28:c2:15:42:51:36:04:15:3b:37:7f:3d:e1:72 2239 * For H=Whirlpool, K=Key26, and Text=PktT the HMAC result is: 2241 ea:b3:e0:80:18:70:1a:a3:9c:d7:cf:1d:dd:06:51:5d 2242 e6:ab:02:99:82:2f:cd:b5:a4:b6:f0:c6:a9:fc:04:50 2243 1b:bd:82:4d:0d:28:90:a8:90:32:dc:f6:5e:ad:7c:74 2244 c2:68:0c:8a:89:2a:bb:9e:09:ae:b0:a6:60:98:5d:9b 2246 5. The authentication mechanism placed each HMAC result into 2247 respective HMAC TLV, producing the final authenticated Babel 2248 packet (PktA), which was eventually sent from the interface. 2249 Table 4 provides a decoding of PktA, contents of which is below: 2251 2a:02:00:a4:04:06:00:00:7d:60:01:90:08:0a:00:40 2252 00:00:ff:ff:7c:88:ff:ff:0b:06:00:01:51:5a:68:ee 2253 0c:42:00:c8:4c:72:34:27:23:1a:9a:26:71:0c:6b:24 2254 40:58:cb:cb:e5:a6:c2:80:9d:31:13:00:3c:a3:52:0d 2255 c6:07:13:69:0a:6e:32:84:44:b6:97:8b:0d:85:e6:8f 2256 80:d1:ec:c0:dc:db:28:c2:15:42:51:36:04:15:3b:37 2257 7f:3d:e1:72:0c:42:00:64:ea:b3:e0:80:18:70:1a:a3 2258 9c:d7:cf:1d:dd:06:51:5d:e6:ab:02:99:82:2f:cd:b5 2259 a4:b6:f0:c6:a9:fc:04:50:1b:bd:82:4d:0d:28:90:a8 2260 90:32:dc:f6:5e:ad:7c:74:c2:68:0c:8a:89:2a:bb:9e 2261 09:ae:b0:a6:60:98:5d:9b 2263 Interpretation of this process is to be done in the view of Figure 1, 2264 differently for the sending and the receiving directions. 2266 For the sending direction, given a Babel speaker configured using the 2267 IPv6 address and the sequence of CSAs as described above, the 2268 implementation MUST produce exactly the temporary packet PktT if the 2269 original protocol instance produces exactly the packet PktO to be 2270 sent from the interface. The HMAC results computed afterwards MUST 2271 exactly match respective results above and the final authenticated 2272 packet MUST exactly match the PktA above. 2274 For the receiving direction, given a Babel speaker configured using 2275 the sequence of CSAs (but not the IPv6 address) as described above, 2276 the implementation MUST (assuming the TS/PC check didn't fail) 2277 produce exactly the temporary packet PktT above if the local IPv6 2278 stack receives through the interface exactly the packet PktA above 2279 with the source IPv6 address above. The first HMAC result computed 2280 afterwards MUST match the first result above. The receiving 2281 procedure doesn't compute the second HMAC result in this case, but if 2282 the implementor decides to compute it anyway for the verification 2283 purpose, it MUST exactly match the second result above. 2285 Author's Address 2287 Denis Ovsienko 2288 Yandex 2289 16, Leo Tolstoy St. 2290 Moscow, 119021 2291 Russia 2293 Email: infrastation@yandex.ru