| RFC 8967 | MAC Authentication for Babel | January 2021 |
| Dô, et al. | Standards Track | [Page] |
This document describes a cryptographic authentication mechanism forthe Babel routing protocol that has provisions for replay avoidance. Thisdocument obsoletes RFC 7298.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8967.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
By default, the Babel routing protocol[RFC8966]trusts the information containedin every UDP datagram that it receives on the Babel port. An attacker canredirect traffic to itself or to a different node in the network, causinga variety of potential issues. In particular, an attacker might:¶
Protecting a Babel network is challenging due to the fact that theBabel protocol uses both unicast and multicast communication. Onepossible approach, used notably by the Babel over Datagram Transport LayerSecurity (DTLS) protocol[RFC8968], is to useunicast communication for all semantically significant communication, andthen use a standard unicast security protocol to protect the Babeltraffic. In this document, we take the opposite approach: we definea cryptographic extension to the Babel protocol that is able to protectboth unicast and multicast traffic and thus requires very few changes tothe core protocol. This document obsoletes[RFC7298].¶
The protocol defined in this document assumes that all interfaces ona given link are equally trusted and share a small set of symmetric keys(usually just one, and two during key rotation). The protocol is inapplicablein situations where asymmetric keying is required, where the trustrelationship is partial, or where large numbers of trusted keys areprovisioned on a single link at the same time.¶
This protocol supports incremental deployment (where an insecure Babelnetwork is made secure with no service interruption), and it supportsgraceful key rotation (where the set of keys is changed with no serviceinterruption).¶
This protocol does not require synchronised clocks, it does not requirepersistently monotonic clocks, and it does not require persistent storageexcept for what might be required for storing cryptographic keys.¶
The correctness of the protocol relies on the following assumptions:¶
The first assumption is a property of the MAC being used. The secondassumption can be met either by using a robust random number generator[RFC4086] and sufficiently large indices and nonces, byusing a reliable hardware clock, or by rekeying often enough thatcollisions are unlikely.¶
If the assumptions above are met, the protocol described in thisdocument has the following properties:¶
While this protocol makes efforts to mitigate the effects of a denialof service attack, it does not fully protect against such attacks.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
When a node B sends out a Babel packet through an interface that isconfigured for MAC cryptographic protection, it computes one or more MACs(one per key) that it appends to the packet. When a node A receivesa packet over an interface that requires MAC cryptographic protection, itindependently computes a set of MACs and compares them to the MACsappended to the packet; if there is no match, the packet is discarded.¶
In order to protect against replay, B maintains a per-interface 32-bitinteger known as the "packet counter" (PC). Whenever B sends a packetthrough the interface, it embeds the current value of the PC within theregion of the packet that is protected by the MACs and increases the PCby at least one. When A receives the packet, it compares the value of thePC with the one contained in the previous packet received from B, andunless it is strictly greater, the packet is discarded.¶
By itself, the PC mechanism is not sufficient to protect againstreplay. Consider a peer A that has no information about a peerB (e.g., because it has recently rebooted). Suppose that A receivesa packet ostensibly from B carrying a given PC; since A has no informationabout B, it has no way to determine whether the packet is freshlygenerated or a replay of a previously sent packet.¶
In this situation, peer A discards the packet and challenges B to prove thatit knows the MAC key. It sends a "Challenge Request", a TLV containinga unique nonce, a value that has never been used before and will never beused again. Peer B replies to the Challenge Request with a "Challenge Reply",a TLV containing a copy of the nonce chosen by A, in a packet protected byMAC and containing the new value of B's PC. Since the nonce has neverbeen used before, B's reply proves B's knowledge of the MAC key and thefreshness of the PC.¶
By itself, this mechanism is safe against replay if B never resets itsPC. In practice, however, this is difficult to ensure, as persistentstorage is prone to failure, and hardware clocks, even when available, areoccasionally reset. Suppose that B resets its PC to an earlier value and sends a packet with a previously used PC n. Peer A challenges B,B successfully responds to the challenge, and A accepts the PC equal ton + 1. At this point, an attacker C may send a replayed packetwith PC equal to n + 2, which will be accepted by A.¶
Another mechanism is needed to protect against this attack. In thisprotocol, every PC is tagged with an "index", an arbitrary string ofoctets. Whenever B resets its PC, or whenever B doesn't know whether itsPC has been reset, it picks an index that it has never used before (eitherby drawing it randomly or by using a reliable hardware clock) and startssending PCs with that index. Whenever A detects that B has changed itsindex, it challenges B again.¶
With this additional mechanism, this protocol is invulnerable to replayattacks (seeSection 1.2).¶
Every Babel node maintains a set of conceptual data structuresdescribed inSection 3.2 of [RFC8966]. This protocolextends these data structures as follows.¶
Every Babel node maintains an interface table, as described inSection 3.2.3 of [RFC8966]. Implementations of this protocolMUSTallow each interface to be provisioned with a set of one or more MAC keysand the associated MAC algorithms (seeSection 4.1for suggested algorithms andSection 7 forsuggested methods for key generation). In order to allow incrementaldeployment of this protocol (seeSection 5),implementationsSHOULD allow an interface to be configured in a mode inwhich it participates in the MAC authentication protocol but acceptspackets that are not authenticated.¶
This protocol extends each table entry associated withan interface on which MAC authentication has been configured with two newpieces of data:¶
We say that an index is fresh when it has never been used before with anyof the keys currently configured on the interface. The Index field isinitialised to a fresh index, for example, by drawing a random string ofsufficient length (seeSection 7 forsuggested sizes), and the PC is initialised to an arbitrary value(typically 0).¶
Every Babel node maintains a neighbour table, as described inSection 3.2.4 of [RFC8966]. This protocol extends eachentry in this table with two new pieces of data:¶
The Index and PC are initially undefined, and they are managed as described inSection 4.3. The Nonce and challenge expiry timer areinitially undefined, and they are used as described inSection 4.3.1.1.¶
A Babel node computes the MAC of a Babel packet as follows.¶
First, the node builds a pseudo-header that will participate in MACcomputation but will not be sent. If the packet is carried over IPv6,the pseudo-header has the following format:¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ +| |+ Src address +| |+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Src port | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |+ +| Dest address |+ +| |+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Dest port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
If the packet is carried over IPv4, the pseudo-header has the followingformat:¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Src address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Src port | Dest address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Dest port |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Fields:¶
The node takes the concatenation of the pseudo-header and the Babelpacket including the packet header but excluding the packet trailer (fromoctet 0 inclusive up to (Body Length + 4) exclusive) and computes a MAC with one of the implemented algorithms. EveryimplementationMUST implement HMAC-SHA256 as defined in[RFC6234] andSection 2 of [RFC2104],SHOULD implement keyed BLAKE2s[RFC7693] with 128-bit (16-octet) digests, andMAY implementother MAC algorithms.¶
A Babel node might delay actually sending TLVs by a small amount, inorder to aggregate multiple TLVs in a single packet up to theinterface MTU (Section 4 of [RFC8966]). For aninterface on which MAC protection is configured, the TLV aggregationlogicMUST take into account the overhead due to PC TLVs (one in eachpacket) and MAC TLVs (one per configured key).¶
Before sending a packet, the following actions are performed:¶
a PC TLV containing the PC and Index associated with theoutgoing interfaceMUST be appended to the packet body;¶
a nodeMUST NOT include multiple PC TLVs in a single packet;¶
When a packet is received on an interface that is configured for MACprotection, the following steps are performed before the packet is passedto normal processing:¶
In the algorithm described above, Challenge Requests are processed andchallenges are sent before the (Index, PC) pair is verified against theneighbour table. This simplifies the implementation somewhat (the nodemay simply schedule outgoing requests as it walks the packet during thepreparse phase) but relies on the rate limiting described inSection 4.3.1.1 to avoid sending too many challengesin response to replayed packets. As an optimisation, a nodeMAY ignoreall Challenge Requests contained in a packet except the last one, and itMAY ignore a Challenge Request in the case where it is contained ina packet with an Index that matches the one in the neighbour table anda PC that is smaller or equal to the one contained in the neighbour table.Since it is still possible to replay a packet with an obsolete Index, therate limiting described inSection 4.3.1.1 isrequired even if this optimisation is implemented.¶
The same is true of Challenge Replies. However, since validatinga Challenge Reply has minimal additional cost (it is just a bitwisecomparison of two strings of octets), a similar optimisation for ChallengeReplies is not worthwhile.¶
After the packet has been accepted, it is processed as normal, exceptthat any PC, Challenge Request, and Challenge Reply TLVs that it containsare silently ignored.¶
During the preparse stage, the receiver might encounter a mismatchedIndex, to which it will react by scheduling a Challenge Request. It mightencounter a Challenge Request TLV, to which it will reply with a ChallengeReply TLV. Finally, it might encounter a Challenge Reply TLV, which itwill attempt to match with a previously sent Challenge Request TLV inorder to update the neighbour table entry corresponding to the sender ofthe packet.¶
When it encounters a mismatched Index during the preparse phase, a nodepicks a nonce that it has never used with any of the keys currentlyconfigured on the relevant interface, for example, by drawinga sufficiently large random string of bytes or by consulting a strictlymonotonic hardware clock. ItMUST then store the nonce in the entry ofthe neighbour table associated to the neighbour (the entry might need tobe created at this stage), initialise the neighbour's challenge expirytimer to 30 seconds, and send a Challenge Request TLV to the unicastaddress corresponding to the neighbour.¶
A nodeMAY aggregate a Challenge Request with other TLVs; in otherwords, if it has already buffered TLVs to be sent to the unicast addressof the neighbour, itMAY send the buffered TLVs in the same packet as theChallenge Request. However, itMUST arrange for the Challenge Request tobe sent in a timely manner, as any packets received from that neighbourwill be silently ignored until the challenge completes.¶
A nodeMUST impose a rate limitation to the challenges it sends; thelimitSHOULD default to one Challenge Request every 300 ms andMAY beconfigurable. This rate limiting serves two purposes. First, sincea challenge may be sent in response to a packet replayed by an attacker,it limits the number of challenges that an attacker can cause a node tosend. Second, it limits the number of challenges sent when there aremultiple packets in flight from a single neighbour.¶
When it encounters a Challenge Request during the preparse phase,a node constructs a Challenge Reply TLV by copying the Nonce from theChallenge Request into the Challenge Reply. ItMUST then send theChallenge Reply to the unicast address from which the Challenge Requestwas sent. A challenge sent to a multicast addressMUST be silently ignored.¶
A nodeMAY aggregate a Challenge Reply with other TLVs; in other words,if it has already buffered TLVs to be sent to the unicast address of thesender of the Challenge Request, itMAY send the buffered TLVs in the samepacket as the Challenge Reply. However, itMUST arrange for the ChallengeReply to be sent in a timely manner (within a few seconds) andSHOULD NOTsend any other packets over the same interface before sending theChallenge Reply, as those would be dropped by the challenger.¶
Since a Challenge Reply might be caused by a replayed Challenge Request,a nodeMUST impose a rate limitation to the Challenge Replies it sends;the limitSHOULD default to one Challenge Reply for each peer every300 ms andMAY be configurable.¶
When it encounters a Challenge Reply during the preparse phase, a nodeconsults the neighbour table entry corresponding to the neighbour thatsent the Challenge Reply. If no challenge is in progress, i.e., ifthere is no Nonce stored in the neighbour table entry or the challengetimer has expired, the Challenge ReplyMUST be silently ignored, and thechallenge has failed.¶
Otherwise, the node compares the Nonce contained in the Challenge Replywith the Nonce contained in the neighbour table entry. If the two areequal (they have the same length and content), then the challenge hassucceeded and the nonce stored in the neighbour table for this neighbourSHOULD be discarded; otherwise, the challenge has failed (and the nonce isnot discarded).¶
The per-neighbour (Index, PC) pair is maintained in the neighbourtable, and is normally discarded when the neighbour table entry expires.ImplementationsMUST ensure that an (Index, PC) pair is discarded withina finite time since the last time a packet has been accepted. Inparticular, unsuccessful challengesMUST NOT prevent an (Index, PC) pairfrom being discarded for unbounded periods of time.¶
A possible implementation strategy for implementations that use a Hellohistory (Appendix A of[RFC8966]) is to discard the(Index, PC) pair whenever the Hello history becomes empty. Anotherimplementation strategy is to use a timer that is reset whenever a packetis accepted and to discard the (Index, PC) pair whenever the timerexpires. If the latter strategy is used, the timerSHOULD defaultto a value of 5 minutes andMAY be configurable.¶
In order to perform incremental deployment, the nodes in the networkare first configured in a mode where packets are sent with authenticationbut not checked on reception. Once all the nodes in the network areconfigured to send authenticated packets, nodes are reconfigured to rejectunauthenticated packets.¶
In order to perform key rotation, the new key is added to all thenodes. Once this is done, both the old and the new key are sent in allpackets, and packets are accepted if they are properly signed by either ofthe keys. At that point, the old key is removed.¶
In order to support the procedures described above, implementations ofthis protocolSHOULD support an interface configuration in which packetsare sent authenticated but received packets are accepted withoutverification, and theySHOULD allow changing the set of keys associatedwith an interface without a restart.¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type = 16 | Length | MAC...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-¶
Fields:¶
This TLV is allowed in the packet trailer (seeSection 4.2 of [RFC8966]) andMUST be ignored if it is found in thepacket body.¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type = 17 | Length | PC |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | Index...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-¶
Fields:¶
Indices are limited to a size of 32 octets: a nodeMUST NOT send a TLVwith an index of size strictly larger than 32 octets, and a nodeMAYignore a PC TLV with an index of length strictly larger than 32 octets.Indices of length 0 are valid: if a node has reliable stable storage andthe packet counter never overflows, then only one index is necessary, andthe value of length 0 is the canonical choice.¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type = 18 | Length | Nonce...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-¶
Fields:¶
Nonces are limited to a size of 192 octets: a nodeMUST NOT senda Challenge Request TLV with a nonce of size strictly larger than 192octets, and a nodeMAY ignore a nonce that is of size strictly larger than192 octets. Nonces of length 0 are valid: if a node has reliable stablestorage, then it may use a sequential counter for generating nonces thatget encoded in the minimum number of octets required; the value 0 is thenencoded as the string of length 0.¶
0 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type = 19 | Length | Nonce...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-¶
Fields:¶
This document defines a mechanism that provides basic securityproperties for the Babel routing protocol. The scope of this protocol isstrictly limited: it only provides authentication (we assume that routinginformation is not confidential), it only supports symmetric keying, andit only allows for the use of a small number of symmetric keys on everylink. Deployments that need more features, e.g., confidentiality orasymmetric keying, should use a more feature-rich security mechanism such asthe one described in[RFC8968].¶
This mechanism relies on two assumptions, as described inSection 1.2. First, it assumes that the MAC being usedis invulnerable to forgery (Section 1.1 of [RFC6039]); atthe time of writing, HMAC-SHA256, which is mandatory to implement(Section 4.1), is believed to be safe againstpractical attacks.¶
Second, it assumes that indices and nonces are generated uniquely overthe lifetime of a key used for MAC computation (more precisely, indicesmust be unique for a given (key, source) pair, and nonces must be uniquefor a given (key, source, destination) triple). This property can besatisfied either by using a cryptographically secure random numbergenerator to generate indices and nonces that contain enough entropy(64-bit values are believed to be large enough for all practicalapplications) or by using a reliably monotonic hardware clock. Ifuniqueness cannot be guaranteed (e.g., because a hardware clock has beenreset), then rekeying is necessary.¶
The expiry mechanism mandated inSection 4.4 is required toprevent an attacker from delaying an authentic packet by an unboundedamount of time. If an attacker is able to delay the delivery of a packet(e.g., because it is located at a Layer 2 switch), then the packet will beaccepted as long as the corresponding (Index, PC) pair is present at thereceiver. If the attacker is able to cause the (Index, PC) pair topersist for arbitrary amounts of time (e.g., by repeatedly causing failedchallenges), then it is able to delay the packet by arbitrary amounts oftime, even after the sender has left the network, which could allow it toredirect or blackhole traffic to destinations previously advertised by thesender.¶
This protocol exposes large numbers of packets and their MACs to anattacker that is able to capture packets; it is therefore vulnerable tobrute-force attacks. Keys must be chosen in a manner that makes themdifficult to guess. Ideally, they should have a length of 32 octets (bothfor HMAC-SHA256 and BLAKE2s), and be chosen randomly. If, for somereason, it is necessary to derive keys from a human-readable passphrase,it is recommended to use a key derivation function that hampers dictionaryattacks, such as PBKDF2[RFC8018], bcrypt[BCRYPT], or scrypt[RFC7914]. In that case,only the derived keys should be communicated to the routers; the originalpassphrase itself should be kept on the host used to perform the keygeneration (e.g., an administrator's secure laptop computer).¶
While it is probably not possible to be immune against denial ofservice (DoS) attacks in general, this protocol includes a number ofmechanisms designed to mitigate such attacks. In particular, reception ofa packet with no correct MAC creates no local Babel state(Section 4.3). Reception of a replayed packet withcorrect MAC, on the other hand, causes a challenge to be sent; this ismitigated somewhat by requiring that challenges be rate limited(Section 4.3.1.1).¶
Receiving a replayed packet with an obsolete index causes an entry tobe created in the neighbour table, which, at first sight, makes theprotocol susceptible to resource exhaustion attacks (similarly to thefamiliar "TCP SYN Flooding" attack[RFC4987]). However,the MAC computation includes the sender address (Section 4.1), and thus the amount of storage that anattacker can force a node to consume is limited by the number of distinctsource addresses used with a single MAC key (see alsoSection 4 of [RFC8966], which mandates that the source address isa link-local IPv6 address or a local IPv4 address).¶
In order to make this kind of resource exhaustion attacks lesseffective, implementations may use a separate table of uncompletedchallenges that is separate from the neighbour table used by the coreprotocol (the data structures described inSection 3.2 of [RFC8966] are conceptual, and any data structure that yields thesame result may be used). Implementers might also consider using the factthat the nonces included in Challenge Requests and Replies can be fairlylarge (up to 192 octets), which should in principle allow encoding theper-challenge state as a secure "cookie" within the nonce itself; note,however, that any such scheme will need to prevent cookie replay.¶
IANA has allocated the following values in the Babel TLV Typesregistry:¶
| Type | Name | Reference |
|---|---|---|
| 16 | MAC | RFC 8967 |
| 17 | PC | RFC 8967 |
| 18 | Challenge Request | RFC 8967 |
| 19 | Challenge Reply | RFC 8967 |
The protocol described in this document is based on the original HMACprotocol defined byDenis Ovsienko[RFC7298]. The use of a pseudo-header was suggested byDavid Schinazi. The use of an index to avoid replay was suggested byMarkus Stenberg. The authors are also indebted toAntonin Décimo,Donald Eastlake,Toke Høiland-Jørgensen,Florian Horn,Benjamin Kaduk,Dave Taht, andMartin Vigoureux.¶