idnits 2.17.1 draft-ietf-babel-hmac-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 4, 2020) is 1329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-06 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7693 == Outdated reference: A later version (-10) exists of draft-ietf-babel-dtls-07 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 7298 (Obsoleted by RFC 8967) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Do 3 Internet-Draft W. Kolodziejak 4 Obsoletes: 7298 (if approved) J. Chroboczek 5 Intended status: Standards Track IRIF, University of Paris-Diderot 6 Expires: March 8, 2021 September 4, 2020 8 MAC authentication for the Babel routing protocol 9 draft-ietf-babel-hmac-12 11 Abstract 13 This document describes a cryptographic authentication mechanism for 14 the Babel routing protocol that has provisions for replay avoidance. 15 This document obsoletes RFC 7298. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 8, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Assumptions and security properties . . . . . . . . . . . 3 54 1.3. Specification of Requirements . . . . . . . . . . . . . . 4 55 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 56 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 58 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 59 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. MAC computation . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 62 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 64 5. Incremental deployment and key rotation . . . . . . . . . . . 12 65 6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. MAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 6.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 14 69 6.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 10.2. Informational References . . . . . . . . . . . . . . . . 18 76 Appendix A. Changes from previous versions . . . . . . . . . . . 19 77 A.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 19 78 A.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 19 79 A.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19 80 A.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19 81 A.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 20 82 A.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 20 83 A.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 20 84 A.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 By default, the Babel routing protocol trusts the information 90 contained in every UDP datagram that it receives on the Babel port. 91 An attacker can redirect traffic to itself or to a different node in 92 the network, causing a variety of potential issues. In particular, 93 an attacker might: 95 o spoof a Babel packet, and redirect traffic by announcing a route 96 with a smaller metric, a larger sequence number, or a longer 97 prefix; 99 o spoof a malformed packet, which could cause an insufficiently 100 robust implementation to crash or interfere with the rest of the 101 network; 103 o replay a previously captured Babel packet, which could cause 104 traffic to be redirected or otherwise interfere with the network. 106 Protecting a Babel network is challenging due to the fact that the 107 Babel protocol uses both unicast and multicast communication. One 108 possible approach, used notably by the Babel over Datagram Transport 109 Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use 110 unicast communication for all semantically significant communication, 111 and then use a standard unicast security protocol to protect the 112 Babel traffic. In this document, we take the opposite approach: we 113 define a cryptographic extension to the Babel protocol that is able 114 to protect both unicast and multicast traffic, and thus requires very 115 few changes to the core protocol. This document obsoletes [RFC7298]. 117 1.1. Applicability 119 The protocol defined in this document assumes that all interfaces on 120 a given link are equally trusted and share a small set of symmetric 121 keys (usually just one, and two during key rotation). The protocol 122 is inapplicable in situations where asymmetric keying is required, 123 where the trust relationship is partial, or where large numbers of 124 trusted keys are provisioned on a single link at the same time. 126 This protocol supports incremental deployment (where an insecure 127 Babel network is made secure with no service interruption), and it 128 supports graceful key rotation (where the set of keys is changed with 129 no service interruption). 131 This protocol does not require synchronised clocks, it does not 132 require persistently monotonic clocks, and it does not require 133 persistent storage except for what might be required for storing 134 cryptographic keys. 136 1.2. Assumptions and security properties 138 The correctness of the protocol relies on the following assumptions: 140 o that the Message Authentication Code (MAC) being used is 141 invulnerable to forgery, i.e., that an attacker is unable to 142 generate a packet with a correct MAC without access to the secret 143 key; 145 o that a node never generates the same index or nonce twice over the 146 lifetime of a key. 148 The first assumption is a property of the MAC being used. The second 149 assumption can be met either by using a robust random number 150 generator [RFC4086] and sufficiently large indices and nonces, by 151 using a reliable hardware clock, or by rekeying often enough that 152 collisions are unlikely. 154 If the assumptions above are met, the protocol described in this 155 document has the following properties: 157 o it is invulnerable to spoofing: any Babel packet accepted as 158 authentic is the exact copy of a packet originally sent by an 159 authorised node; 161 o locally to a single node, it is invulnerable to replay: if a node 162 has previously accepted a given packet, then it will never again 163 accept a copy of this packet or an earlier packet from the same 164 sender; 166 o among different nodes, it is only vulnerable to immediate replay: 167 if a node A has accepted an authentic packet from C, then a node B 168 will only accept a copy of that packet if B has accepted an older 169 packet from C and B has received no later packet from C. 171 While this protocol makes efforts to mitigate the effects of a denial 172 of service attack, it does not fully protect against such attacks. 174 1.3. Specification of Requirements 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 2. Conceptual overview of the protocol 184 When a node B sends out a Babel packet through an interface that is 185 configured for MAC cryptographic protection, it computes one or more 186 MACs (one per key) which it appends to the packet. When a node A 187 receives a packet over an interface that requires MAC cryptographic 188 protection, it independently computes a set of MACs and compares them 189 to the MACs appended to the packet; if there is no match, the packet 190 is discarded. 192 In order to protect against replay, B maintains a per-interface 193 32-bit integer known as the "packet counter" (PC). Whenever B sends 194 a packet through the interface, it embeds the current value of the PC 195 within the region of the packet that is protected by the MACs and 196 increases the PC by at least one. When A receives the packet, it 197 compares the value of the PC with the one contained in the previous 198 packet received from B, and unless it is strictly greater, the packet 199 is discarded. 201 By itself, the PC mechanism is not sufficient to protect against 202 replay. Consider a peer A that has no information about a peer B 203 (e.g., because it has recently rebooted). Suppose that A receives a 204 packet ostensibly from B carrying a given PC; since A has no 205 information about B, it has no way to determine whether the packet is 206 freshly generated or a replay of a previously sent packet. 208 In this situation, A discards the packet and challenges B to prove 209 that it knows the MAC key. It sends a "challenge request", a TLV 210 containing a unique nonce, a value that has never been used before 211 and will never be used again. B replies to the challenge request 212 with a "challenge reply", a TLV containing a copy of the nonce chosen 213 by A, in a packet protected by MAC and containing the new value of 214 B's PC. Since the nonce has never been used before, B's reply proves 215 B's knowledge of the MAC key and the freshness of the PC. 217 By itself, this mechanism is safe against replay if B never resets 218 its PC. In practice, however, this is difficult to ensure, as 219 persistent storage is prone to failure, and hardware clocks, even 220 when available, are occasionally reset. Suppose that B resets its PC 221 to an earlier value, and sends a packet with a previously used PC n. 222 A challenges B, B successfully responds to the challenge, and A 223 accepts the PC equal to n + 1. At this point, an attacker C may send 224 a replayed packet with PC equal to n + 2, which will be accepted by 225 A. 227 Another mechanism is needed to protect against this attack. In this 228 protocol, every PC is tagged with an "index", an arbitrary string of 229 octets. Whenever B resets its PC, or whenever B doesn't know whether 230 its PC has been reset, it picks an index that it has never used 231 before (either by drawing it randomly or by using a reliable hardware 232 clock) and starts sending PCs with that index. Whenever A detects 233 that B has changed its index, it challenges B again. 235 With this additional mechanism, this protocol is invulnerable to 236 replay attacks (see Section 1.2 above). 238 3. Data Structures 240 Every Babel node maintains a set of conceptual data structures 241 described in Section 3.2 of [RFC6126bis]. This protocol extends 242 these data structures as follows. 244 3.1. The Interface Table 246 Every Babel node maintains an interface table, as described in 247 Section 3.2.3 of [RFC6126bis]. Implementations of this protocol MUST 248 allow each interface to be provisioned with a set of one or more MAC 249 keys and the associated MAC algorithms (see Section 4.1 for suggested 250 algorithms, and Section 7 for suggested methods for key generation). 251 In order to allow incremental deployment of this protocol (see 252 Section 5), implementations SHOULD allow an interface to be 253 configured in a mode in which it participates in the MAC 254 authentication protocol but accepts packets that are not 255 authenticated. 257 This protocol extends each entry in this table that is associated 258 with an interface on which MAC authentication has been configured 259 with two new pieces of data: 261 o a set of one or more MAC keys, each associated with a given MAC 262 algorithm; 264 o a pair (Index, PC), where Index is an arbitrary string of 0 to 32 265 octets, and PC is a 32-bit (4-octet) integer. 267 We say that an index is fresh when it has never been used before with 268 any of the keys currently configured on the interface. The Index 269 field is initialised to a fresh index, for example by drawing a 270 random string of sufficient length (see Section 7 for suggested 271 sizes), and the PC is initialised to an arbitrary value (typically 272 0). 274 3.2. The Neighbour table 276 Every Babel node maintains a neighbour table, as described in 277 Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in 278 this table with two new pieces of data: 280 o a pair (Index, PC), where Index is a string of 0 to 32 octets, and 281 PC is a 32-bit (4-octet) integer; 283 o a Nonce, which is an arbitrary string of 0 to 192 octets, and an 284 associated challenge expiry timer. 286 The Index and PC are initially undefined, and are managed as 287 described in Section 4.3. The Nonce and challenge expiry timer are 288 initially undefined, and used as described in Section 4.3.1.1. 290 4. Protocol Operation 292 4.1. MAC computation 294 A Babel node computes the MAC of a Babel packet as follows. 296 First, the node builds a pseudo-header that will participate in MAC 297 computation but will not be sent. If the packet is carried over 298 IPv6, the pseudo-header has the following format: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 + + 305 | | 306 + Src address + 307 | | 308 + + 309 | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Src port | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 313 | | 314 + + 315 | Dest address | 316 + + 317 | | 318 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | Dest port | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 If the packet is carried over IPv4, the pseudo-header has the 323 following format: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Src address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Src port | Dest address | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | Dest port | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Fields : 336 Src address The source IP address of the packet. 338 Src port The source UDP port number of the packet. 340 Dest address The destination IP address of the packet. 342 Src port The destination UDP port number of the packet. 344 The node takes the concatenation of the pseudo-header and the Babel 345 packet including the packet header but excluding the packet trailer 346 (from octet 0 inclusive up to (Body Length + 4) exclusive) and 347 computes a MAC with one of the implemented algorithms. Every 348 implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and 349 Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and 350 MAY implement other MAC algorithms. 352 4.2. Packet Transmission 354 A Babel node might delay actually sending TLVs by a small amount, in 355 order to aggregate multiple TLVs in a single packet up to the 356 interface MTU (Section 4 of [RFC6126bis]). For an interface on which 357 MAC protection is configured, the TLV aggregation logic MUST take 358 into account the overhead due to PC TLVs (one in each packet) and MAC 359 TLVs (one per configured key). 361 Before sending a packet, the following actions are performed: 363 o a PC TLV containing the PC and Index associated with the outgoing 364 interface MUST be appended to the packet body; the PC MUST be 365 incremented by a strictly positive amount (typically just 1); if 366 the PC overflows, a fresh index MUST be generated (as defined in 367 Section 3.1); a node MUST NOT include multiple PC TLVs in a single 368 packet; 370 o for each key configured on the interface, a MAC is computed as 371 specified in Section 4.1 above, and stored in a MAC TLV that MUST 372 be appended to the packet trailer (see Section 4.2 of 373 [RFC6126bis]). 375 4.3. Packet Reception 377 When a packet is received on an interface that is configured for MAC 378 protection, the following steps are performed before the packet is 379 passed to normal processing: 381 o First, the receiver checks whether the trailer of the received 382 packet carries at least one MAC TLV; if not, the packet MUST be 383 immediately dropped and processing stops. Then, for each key 384 configured on the receiving interface, the receiver computes the 385 MAC of the packet. It then compares every generated MAC against 386 every MAC included in the packet; if there is at least one match, 387 the packet passes the MAC test; if there is none, the packet MUST 388 be silently dropped and processing stops at this point. In order 389 to avoid memory exhaustion attacks, an entry in the Neighbour 390 Table MUST NOT be created before the MAC test has passed 391 successfully. The MAC of the packet MUST NOT be computed for each 392 MAC TLV contained in the packet, but only once for each configured 393 key. 395 o If an entry for the sender does not exist in the Neighbour Table, 396 it MAY be created at this point (or, alternatively, its creation 397 can be delayed until a challenge needs to be sent, see below); 399 o The packet body is then parsed a first time. During this 400 "preparse" phase, the packet body is traversed and all TLVs are 401 ignored except PC, Challenge Request and Challenge Reply TLVs. 402 When a PC TLV is encountered, the enclosed PC and Index are saved 403 for later processing; if multiple PCs are found (which should not 404 happen, see Section 4.2 above), only the first one is processed, 405 the remaining ones MUST be silently ignored. If a Challenge 406 Request is encountered, a Challenge Reply MUST be scheduled, as 407 described in Section 4.3.1.2. If a Challenge Reply is 408 encountered, it is tested for validity as described in 409 Section 4.3.1.3 and a note is made of the result of the test. 411 o The preparse phase above has yielded two pieces of data: the PC 412 and Index from the first PC TLV, and a bit indicating whether the 413 packet contains a successful Challenge Reply. If the packet does 414 not contain a PC TLV, the packet MUST be dropped and processing 415 stops at this point. If the packet contains a successful 416 Challenge Reply, then the PC and Index contained in the PC TLV 417 MUST be stored in the Neighbour Table entry corresponding to the 418 sender (which already exists in this case), and the packet is 419 accepted. 421 o Otherwise, if there is no entry in the Neighbour 422 Table corresponding to the sender, or if such an entry exists but 423 contains no Index, or if the Index it contains is different from 424 the Index contained in the PC TLV, then a challenge MUST be sent 425 as described in Section 4.3.1.1, the packet MUST be dropped, and 426 processing stops at this stage. 428 o At this stage, the packet contains no successful challenge reply 429 and the Index contained in the PC TLV is equal to the Index in the 430 Neighbour Table entry corresponding to the sender. The receiver 431 compares the received PC with the PC contained in the Neighbour 432 Table; if the received PC is smaller or equal than the PC 433 contained in the Neighbour Table, the packet MUST be dropped and 434 processing stops (no challenge is sent in this case, since the 435 mismatch might be caused by harmless packet reordering on the 436 link). Otherwise, the PC contained in the Neighbour Table entry 437 is set to the received PC, and the packet is accepted. 439 In the algorithm described above, challenge requests are processed 440 and challenges are sent before the PC/Index pair is verified against 441 the neighbour table. This simplifies the implementation somewhat 442 (the node may simply schedule outgoing requests as it walks the 443 packet during the preparse phase), but relies on the rate-limiting 444 described in Section 4.3.1.1 to avoid sending too many challenges in 445 response to replayed packets. As an optimisation, a node MAY ignore 446 all challenge requests contained in a packet except the last one, and 447 it MAY ignore a challenge request in the case where it is contained 448 in a packet with an Index that matches the one in the Neighbour 449 Table and a PC that is smaller or equal to the one contained in the 450 Neighbour Table. Since it is still possible to replay a packet with 451 an obsolete Index, the rate-limiting described in Section 4.3.1.1 is 452 required even if this optimisation is implemented. 454 The same is true of challenge replies. However, since validating a 455 challenge reply has minimal additional cost (it's just a bitwise 456 comparison of two strings of octets), a similar optimisation for 457 challenge replies is not worthwhile. 459 After the packet has been accepted, it is processed as normal, except 460 that any PC, Challenge Request and Challenge Reply TLVs that it 461 contains are silently ignored. 463 4.3.1. Challenge requests and replies 465 During the preparse stage, the receiver might encounter a mismatched 466 Index, to which it will react by scheduling a Challenge Request. It 467 might encounter a Challenge Request TLV, to which it will reply with 468 a Challenge Reply TLV. Finally, it might encounter a Challenge Reply 469 TLV, which it will attempt to match with a previously sent Challenge 470 Request TLV in order to update the Neighbour Table entry 471 corresponding to the sender of the packet. 473 4.3.1.1. Sending challenges 475 When it encounters a mismatched Index during the preparse phase, a 476 node picks a nonce that it has never used with any of the keys 477 currently configured on the relevant interface, for example by 478 drawing a sufficiently large random string of bytes or by consulting 479 a strictly monotonic hardware clock. It MUST then store the nonce in 480 the entry of the Neighbour Table associated to the neighbour (the 481 entry might need to be created at this stage), initialise the 482 neighbour's challenge expiry timer to 30 seconds, and send a 483 Challenge Request TLV to the unicast address corresponding to the 484 neighbour. 486 A node MAY aggregate a Challenge Request with other TLVs; in other 487 words, if it has already buffered TLVs to be sent to the unicast 488 address of the neighbour, it MAY send the buffered TLVs in the same 489 packet as the Challenge Request. However, it MUST arrange for the 490 Challenge Request to be sent in a timely manner, as any packets 491 received from that neighbour will be silently ignored until the 492 challenge completes. 494 A node MUST impose a rate limitation to the challenges it sends; the 495 limit SHOULD default to one challenge request every 300ms, and MAY be 496 configurable. This rate limiting serves two purposes. First, since 497 a challenge may be sent in response to a packet replayed by an 498 attacker, it limits the number of challenges that an attacker can 499 cause a node to send. Second, it limits the number of challenges 500 sent when there are multiple packets in flight from a single 501 neighbour. 503 4.3.1.2. Replying to challenges 505 When it encounters a Challenge Request during the preparse phase, a 506 node constructs a Challenge Reply TLV by copying the Nonce from the 507 Challenge Request into the Challenge Reply. It MUST then send the 508 Challenge Reply to the unicast address from which the Challenge 509 Request was sent. A challenge sent to a multicast address MUST be 510 silently ignored. 512 A node MAY aggregate a Challenge Reply with other TLVs; in other 513 words, if it has already buffered TLVs to be sent to the unicast 514 address of the sender of the Challenge Request, it MAY send the 515 buffered TLVs in the same packet as the Challenge Reply. However, it 516 MUST arrange for the Challenge Reply to be sent in a timely manner 517 (within a few seconds), and SHOULD NOT send any other packets over 518 the same interface before sending the Challenge Reply, as those would 519 be dropped by the challenger. 521 Since a challenge reply might be caused by a replayed challenge 522 request, a node MUST impose a rate limitation to the challenge 523 replies it sends; the limit SHOULD default to one challenge reply for 524 each peer every 300ms and MAY be configurable. 526 4.3.1.3. Receiving challenge replies 528 When it encounters a Challenge Reply during the preparse phase, a 529 node consults the Neighbour Table entry corresponding to the 530 neighbour that sent the Challenge Reply. If no challenge is in 531 progress, i.e., if there is no Nonce stored in the Neighbour 532 Table entry or the challenge timer has expired, the Challenge Reply 533 MUST be silently ignored and the challenge has failed. 535 Otherwise, the node compares the Nonce contained in the Challenge 536 Reply with the Nonce contained in the Neighbour Table entry. If the 537 two are equal (they have the same length and content), then the 538 challenge has succeeded and the nonce stored in the Neighbour 539 Table for this neighbour SHOULD be discarded; otherwise, the 540 challenge has failed (and the nonce is not discarded). 542 4.4. Expiring per-neighbour state 544 The per-neighbour (Index, PC) pair is maintained in the neighbour 545 table, and is normally discarded when the neighbour table entry 546 expires. Implementations MUST ensure that an (Index, PC) pair is 547 discarded within a finite time since the last time a packet has been 548 accepted. In particular, unsuccessful challenges MUST NOT prevent an 549 (Index, PC) pair from being discarded for unbounded periods of time. 551 A possible implementation strategy for implementations that use a 552 Hello history (Appendix A of [RFC6126bis]) is to discard the (Index, 553 PC) pair whenever the Hello history becomes empty. Another 554 implementation strategy is to use a timer that is reset whenever a 555 packet is accepted, and to discard the (Index, PC) pair whenever the 556 timer expires. If the latter strategy is being used, the timer 557 SHOULD default to a value of 5 min, and MAY be configurable. 559 5. Incremental deployment and key rotation 561 In order to perform incremental deployment, the nodes in the network 562 are first configured in a mode where packets are sent with 563 authentication but not checked on reception. Once all the nodes in 564 the network are configured to send authenticated packets, nodes are 565 reconfigured to reject unauthenticated packets. 567 In order to perform key rotation, the new key is added to all the 568 nodes; once this is done, both the old and the new key are sent in 569 all packets, and packets are accepted if they are properly signed by 570 either of the keys. At that point, the old key is removed. 572 In order to support the procedures described above, implementations 573 of this protocol SHOULD support an interface configuration in which 574 packets are sent authenticated but received packets are accepted 575 without verification, and they SHOULD allow changing the set of keys 576 associated with an interface without a restart. 578 6. Packet Format 580 6.1. MAC TLV 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 16 | Length | MAC... 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 588 Fields : 590 Type Set to 16 to indicate a MAC TLV. 592 Length The length of the body, in octets, exclusive of the Type 593 and Length fields. The length depends on the MAC algorithm 594 being used. 596 MAC The body contains the MAC of the packet, computed as 597 described in Section 4.1. 599 This TLV is allowed in the packet trailer (see Section 4.2 of 600 [RFC6126bis]), and MUST be ignored if it is found in the packet body. 602 6.2. PC TLV 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type = 17 | Length | PC | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | | Index... 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 612 Fields : 614 Type Set to 17 to indicate a PC TLV. 616 Length The length of the body, in octets, exclusive of the Type 617 and Length fields. 619 PC The Packet Counter (PC), a 32-bit (4-octet) unsigned 620 integer which is increased with every packet sent over this 621 interface. A fresh index (as defined in Section 3.1) MUST 622 be generated whenever the PC overflows. 624 Index The sender's Index, an opaque string of 0 to 32 octets. 626 Indices are limited to a size of 32 octets: a node MUST NOT send a 627 TLV with an index of size strictly larger than 32 octets, and a node 628 MAY ignore a PC TLV with an index of length strictly larger than 32 629 octets. Indices of length 0 are valid: if a node has reliable stable 630 storage and the packet counter never overflows, then only one index 631 is necessary, and the value of length 0 is the canonical choice. 633 6.3. Challenge Request TLV 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Type = 18 | Length | Nonce... 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 641 Fields : 643 Type Set to 18 to indicate a Challenge Request TLV. 645 Length The length of the body, in octets, exclusive of the Type 646 and Length fields. 648 Nonce The nonce uniquely identifying the challenge, an opaque 649 string of 0 to 192 octets. 651 Nonces are limited to a size of 192 octets: a node MUST NOT send a 652 Challenge Request TLV with a nonce of size strictly larger than 192 653 octets, and a node MAY ignore a nonce that is of size strictly larger 654 than 192 octets. Nonces of length 0 are valid: if a node has 655 reliable stable storage, then it may use a sequential counter for 656 generating nonces which get encoded in the minimum number of octets 657 required; the value 0 is then encoded as the string of length 0. 659 6.4. Challenge Reply TLV 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type = 19 | Length | Nonce... 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 666 Fields : 668 Type Set to 19 to indicate a Challenge Reply TLV. 670 Length The length of the body, in octets, exclusive of the Type 671 and Length fields. 673 Nonce A copy of the nonce contained in the corresponding 674 challenge request. 676 7. Security Considerations 678 This document defines a mechanism that provides basic security 679 properties for the Babel routing protocol. The scope of this 680 protocol is strictly limited: it only provides authentication (we 681 assume that routing information is not confidential), it only 682 supports symmetric keying, and it only allows for the use of a small 683 number of symmetric keys on every link. Deployments that need more 684 features, e.g., confidentiality or asymmetric keying, should use a 685 more featureful security mechanism such as the one described in 686 [I-D.ietf-babel-dtls]. 688 This mechanism relies on two assumptions, as described in 689 Section 1.2. First, it assumes that the MAC being used is 690 invulnerable to forgery (Section 1.1 of [RFC6039]); at the time of 691 writing, HMAC-SHA256, which is mandatory to implement (Section 4.1), 692 is believed to be safe against practical attacks. 694 Second, it assumes that indices and nonces are generated uniquely 695 over the lifetime of a key used for MAC computation (more precisely, 696 indices must be unique for a given (key, source) pair, and nonces 697 must be unique for a given (key, source, destination) triple). This 698 property can be satisfied either by using a cryptographically secure 699 random number generator to generate indices and nonces that contain 700 enough entropy (64-bit values are believed to be large enough for all 701 practical applications), or by using a reliably monotonic hardware 702 clock. If uniqueness cannot be guaranteed (e.g., because a hardware 703 clock has been reset), then rekeying is necessary. 705 The expiry mechanism mandated in Section 4.4 is required to prevent 706 an attacker from delaying an authentic packet by an unbounded amount 707 of time. If an attacker is able to delay the delivery of a packet 708 (e.g., because it is located at a layer 2 switch), then the packet 709 will be accepted as long as the corresponding (Index, PC) pair is 710 present at the receiver. If the attacker is able to cause the 711 (Index, PC) pair to persist for arbitrary amounts of time (e.g., by 712 repeatedly causing failed challenges), then it is able to delay the 713 packet by arbitrary amounts of time, even after the sender has left 714 the network, which could allow it to redirect or blackhole traffic to 715 destinations previously advertised by the sender. 717 This protocol exposes large numbers of packets and their MACs to an 718 attacker that is able to capture packets; it is therefore vulnerable 719 to brute-force attacks. Keys must be chosen in a manner that makes 720 them difficult to guess. Ideally, they should have a length of 32 721 octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly. 722 If, for some reason, it is necessary to derive keys from a human- 723 readable passphrase, it is recommended to use a key derivation 724 function that hampers dictionary attacks, such as PBKDF2 [RFC2898], 725 bcrypt [BCRYPT] or scrypt [RFC7914]. In that case, only the derived 726 keys should be communicated to the routers; the original passphrase 727 itself should be kept on the host used to perform the key generation 728 (e.g., an administator's secure laptop computer). 730 While it is probably not possible to be immune against denial of 731 service (DoS) attacks in general, this protocol includes a number of 732 mechanisms designed to mitigate such attacks. In particular, 733 reception of a packet with no correct MAC creates no local Babel 734 state (Section 4.3). Reception of a replayed packet with correct 735 MAC, on the other hand, causes a challenge to be sent; this is 736 mitigated somewhat by requiring that challenges be rate-limited 737 (Section 4.3.1.1). 739 Receiving a replayed packet with an obsolete index causes an entry to 740 be created in the Neighbour Table, which, at first sight, makes the 741 protocol susceptible to resource exhaustion attacks (similarly to the 742 familiar "TCP SYN Flooding" attack [RFC4987]). However, the MAC 743 computation includes the sender address (Section 4.1), and thus the 744 amount of storage that an attacker can force a node to consume is 745 limited by the number of distinct source addresses used with a single 746 MAC key (see also Section 4 of [RFC6126bis], which mandates that the 747 source address is a link-local IPv6 address or a local IPv4 address). 749 In order to make this kind of resource exhaustion attacks less 750 effective, implementations may use a separate table of uncompleted 751 challenges that is separate from the Neighbour Table used by the core 752 protocol (the data structures described in Section 3.2 of 753 [RFC6126bis] are conceptual, and any data structure that yields the 754 same result may be used). Implementers might also consider using the 755 fact that the nonces included in challenge requests and replies can 756 be fairly large (up to 192 octets), which should in principle allow 757 encoding the per-challenge state as a secure "cookie" within the 758 nonce itself; note however that any such scheme will need to prevent 759 cookie replay. 761 8. IANA Considerations 763 IANA has allocated the following values in the Babel TLV Types 764 registry: 766 +------+-------------------+---------------+ 767 | Type | Name | Reference | 768 +------+-------------------+---------------+ 769 | 16 | MAC | this document | 770 | | | | 771 | 17 | PC | this document | 772 | | | | 773 | 18 | Challenge Request | this document | 774 | | | | 775 | 19 | Challenge Reply | this document | 776 +------+-------------------+---------------+ 778 9. Acknowledgments 780 The protocol described in this document is based on the original HMAC 781 protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- 782 header was suggested by David Schinazi. The use of an index to avoid 783 replay was suggested by Markus Stenberg. The authors are also 784 indebted to Antonin Decimo, Donald Eastlake, Toke Hoiland-Jorgensen, 785 Florian Horn, Benjamin Kaduk, Dave Taht and Martin Vigoureux. 787 10. References 789 10.1. Normative References 791 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 792 Hashing for Message Authentication", RFC 2104, 793 DOI 10.17487/RFC2104, February 1997, 794 . 796 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, 798 DOI 10.17487/RFC2119, March 1997. 800 [RFC6126bis] 801 Chroboczek, J. and D. Schinazi, "The Babel Routing 802 Protocol", draft-ietf-babel-rfc6126bis-06 (work in 803 progress), October 2018. 805 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 806 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 807 DOI 10.17487/RFC6234, May 2011, 808 . 810 [RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 811 Cryptographic Hash and Message Authentication Code (MAC)", 812 RFC 7693, DOI 10.17487/RFC7693, November 2015, 813 . 815 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 816 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 817 May 2017. 819 10.2. Informational References 821 [BCRYPT] Niels, P. and D. Mazieres, "A Future-Adaptable Password 822 Scheme", 1999. 824 In Proceedings of the 1999 USENIX Annual Technical 825 Conference. 827 [I-D.ietf-babel-dtls] 828 Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 829 Routing Protocol over Datagram Transport Layer Security", 830 draft-ietf-babel-dtls-07 (work in progress), July 2019. 832 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 833 Specification Version 2.0", RFC 2898, 834 DOI 10.17487/RFC2898, September 2000, 835 . 837 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 838 "Randomness Requirements for Security", BCP 106, RFC 4086, 839 DOI 10.17487/RFC4086, June 2005, 840 . 842 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 843 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 844 . 846 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 847 with Existing Cryptographic Protection Methods for Routing 848 Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, 849 . 851 [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code 852 (HMAC) Cryptographic Authentication", RFC 7298, 853 DOI 10.17487/RFC7298, July 2014, 854 . 856 [RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based 857 Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914, 858 August 2016, . 860 Appendix A. Changes from previous versions 862 [RFC Editor: please remove this section before publication.] 864 A.1. Changes since draft-ietf-babel-hmac-00 866 o Changed the title. 868 o Removed the appendix about the packet trailer, this is now in 869 rfc6126bis. 871 o Removed the appendix with implicit indices. 873 o Clarified the definitions of acronyms. 875 o Limited the size of nonces and indices. 877 A.2. Changes since draft-ietf-babel-hmac-01 879 o Made BLAKE2s a recommended HMAC algorithm. 881 o Added requirement to expire per-neighbour crypto state. 883 A.3. Changes since draft-ietf-babel-hmac-02 885 o Clarified that PCs are 32-bit unsigned integers. 887 o Clarified that indices and nonces are of arbitrary size. 889 o Added reference to RFC 4086. 891 A.4. Changes since draft-ietf-babel-hmac-03 893 o Use the TLV values allocated by IANA. 895 o Fixed an issue with packets that contain a successful challenge 896 reply: they should be accepted before checking the PC value. 898 o Clarified that keys are the exact value of the HMAC hash size, and 899 not subject to preprocessing; this makes management more 900 deterministic. 902 A.5. Changes since draft-ietf-babel-hmac-04 904 o Use normative language in more places. 906 A.6. Changes since draft-ietf-babel-hmac-05 908 o Do not update RFC 6126bis. 910 o Clarify that indices and nonces of length 0 are valid. 912 o Clarify that multiple PC TLVs in a single packet are not allowed. 914 o Allow discarding challenge requests when they carry an old PC. 916 A.7. Changes since draft-ietf-babel-hmac-06 918 o Do not update RFC 6126bis, for real this time. 920 A.8. Changes since draft-ietf-babel-hmac-07 922 o Clarify that a Neighbour Table entry may be created just after the 923 HMAC has been computed. 925 o Clarify that a Neighbour Table entry already exists when a 926 successful Challenge Reply has been received. 928 o Expand the Security Considerations section with information about 929 resource exhaustion attacks. 931 A.8.1. Changes since draft-ietf-babel-hmac-08 933 o Fix the size of the key to be equal to the block size, not the 934 hash size. 936 o Moved the information about incremental deployment to the body. 938 o Clarified the double purpose of rate limitation. 940 o Editorial changes. 942 A.8.2. Changes since draft-ietf-babel-hmac-09 944 o Renamed HMAC to MAC throughout, relevant rewording. 946 o Made it mandatory to rate-limit challenge replies in addition to 947 requests. 949 o Added discussion of key generation. 951 o Added discussion of the consequences of delaying packets. 953 A.8.3. Changes since draft-ietf-babel-hmac-10 955 o Fixed minor typos. 957 A.8.4. Changes since draft-ietf-babel-hmac-11 959 o Clarified that the state SHOULD be discarded after a successful 960 challenge. 962 o Replaced "pre-image attack" with "forgery", this is more accurate. 964 o Minor editorial changes. 966 Authors' Addresses 968 Clara Do 969 IRIF, University of Paris-Diderot 970 75205 Paris Cedex 13 971 France 973 Email: clarado_perso@yahoo.fr 975 Weronika Kolodziejak 976 IRIF, University of Paris-Diderot 977 75205 Paris Cedex 13 978 France 980 Email: weronika.kolodziejak@gmail.com 981 Juliusz Chroboczek 982 IRIF, University of Paris-Diderot 983 Case 7014 984 75205 Paris Cedex 13 985 France 987 Email: jch@irif.fr