< draft-ietf-babel-hmac-09.txt   draft-ietf-babel-hmac-10.txt >
Network Working Group C. Do Network Working Group C. Do
Internet-Draft W. Kolodziejak Internet-Draft W. Kolodziejak
Obsoletes: 7298 (if approved) J. Chroboczek Obsoletes: 7298 (if approved) J. Chroboczek
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: February 11, 2020 August 10, 2019 Expires: February 18, 2020 August 17, 2019
HMAC authentication for the Babel routing protocol MAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-09 draft-ietf-babel-hmac-10
Abstract Abstract
This document describes a cryptographic authentication mechanism for This document describes a cryptographic authentication mechanism for
the Babel routing protocol that has provisions for replay avoidance. the Babel routing protocol that has provisions for replay avoidance.
This document obsoletes RFC 7298. This document obsoletes RFC 7298.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 11, 2020. This Internet-Draft will expire on February 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions and security properties . . . . . . . . . . . 3 1.2. Assumptions and security properties . . . . . . . . . . . 3
1.3. Specification of Requirements . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 4
2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6
3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 4.1. MAC computation . . . . . . . . . . . . . . . . . . . . . 7
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12
5. Incremental deployment and key rotation . . . . . . . . . . . 12 5. Incremental deployment and key rotation . . . . . . . . . . . 12
6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. MAC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 14 6.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 14
6.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14 6.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informational References . . . . . . . . . . . . . . . . 17 10.2. Informational References . . . . . . . . . . . . . . . . 18
Appendix A. Changes from previous versions . . . . . . . . . . . 18 Appendix A. Changes from previous versions . . . . . . . . . . . 19
A.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18 A.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 19
A.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18 A.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 19
A.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18 A.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19
A.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19 A.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19
A.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19 A.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 20
A.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19 A.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 20
A.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19 A.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 20
A.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 19 A.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
By default, the Babel routing protocol trusts the information By default, the Babel routing protocol trusts the information
contained in every UDP datagram that it receives on the Babel port. contained in every UDP datagram that it receives on the Babel port.
An attacker can redirect traffic to itself or to a different node in An attacker can redirect traffic to itself or to a different node in
the network, causing a variety of potential issues. In particular, the network, causing a variety of potential issues. In particular,
an attacker might: an attacker might:
o spoof a Babel packet, and redirect traffic by announcing a route o spoof a Babel packet, and redirect traffic by announcing a route
skipping to change at page 3, line 50 skipping to change at page 3, line 50
This protocol does not require synchronised clocks, it does not This protocol does not require synchronised clocks, it does not
require persistently monotonic clocks, and it does not require require persistently monotonic clocks, and it does not require
persistent storage except for what might be required for storing persistent storage except for what might be required for storing
cryptographic keys. cryptographic keys.
1.2. Assumptions and security properties 1.2. Assumptions and security properties
The correctness of the protocol relies on the following assumptions: The correctness of the protocol relies on the following assumptions:
o that the Hashed Message Authentication Code (HMAC) being used is o that the Message Authentication Code (MAC) being used is
invulnerable to pre-image attacks, i.e., that an attacker is invulnerable to pre-image attacks, i.e., that an attacker is
unable to generate a packet with a correct HMAC without access to unable to generate a packet with a correct MAC without access to
the secret key; the secret key;
o that a node never generates the same index or nonce twice over the o that a node never generates the same index or nonce twice over the
lifetime of a key. lifetime of a key.
The first assumption is a property of the HMAC being used. The The first assumption is a property of the MAC being used. The second
second assumption can be met either by using a robust random number assumption can be met either by using a robust random number
generator [RFC4086] and sufficiently large indices and nonces, by generator [RFC4086] and sufficiently large indices and nonces, by
using a reliable hardware clock, or by rekeying whenever a collision using a reliable hardware clock, or by rekeying often enough that
becomes likely. collisions are unlikely.
If the assumptions above are met, the protocol described in this If the assumptions above are met, the protocol described in this
document has the following properties: document has the following properties:
o it is invulnerable to spoofing: any Babel packet accepted as o it is invulnerable to spoofing: any Babel packet accepted as
authentic is the exact copy of a packet originally sent by an authentic is the exact copy of a packet originally sent by an
authorised node; authorised node;
o locally to a single node, it is invulnerable to replay: if a node o locally to a single node, it is invulnerable to replay: if a node
has previously accepted a given packet, then it will never again has previously accepted a given packet, then it will never again
accept a copy of this packet or an earlier packet from the same accept a copy of this packet or an earlier packet from the same
sender; sender;
o among different nodes, it is only vulnerable to immediate replay: o among different nodes, it is only vulnerable to immediate replay:
if a node A has accepted a packet from C as valid, then a node B if a node A has accepted an authentic packet from C, then a node B
will only accept a copy of that packet as authentic if B has will only accept a copy of that packet if B has accepted an older
accepted an older packet from C and B has received no later packet packet from C and B has received no later packet from C.
from C.
While this protocol makes efforts to mitigate the effects of a denial While this protocol makes efforts to mitigate the effects of a denial
of service attack, it does not fully protect against such attacks. of service attack, it does not fully protect against such attacks.
1.3. Specification of Requirements 1.3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Conceptual overview of the protocol 2. Conceptual overview of the protocol
When a node B sends out a Babel packet through an interface that is When a node B sends out a Babel packet through an interface that is
configured for HMAC cryptographic protection, it computes one or more configured for MAC cryptographic protection, it computes one or more
HMACs [RFC2104] (one per key) which it appends to the packet. When a MACs (one per key) which it appends to the packet. When a node A
node A receives a packet over an interface that requires HMAC receives a packet over an interface that requires MAC cryptographic
cryptographic protection, it independently computes a set of HMACs protection, it independently computes a set of MACs and compares them
and compares them to the HMACs appended to the packet; if there is no to the MACs appended to the packet; if there is no match, the packet
match, the packet is discarded. is discarded.
In order to protect against replay, B maintains a per-interface In order to protect against replay, B maintains a per-interface
32-bit integer known as the "packet counter" (PC). Whenever B sends 32-bit integer known as the "packet counter" (PC). Whenever B sends
a packet through the interface, it embeds the current value of the PC a packet through the interface, it embeds the current value of the PC
within the region of the packet that is protected by the HMACs and within the region of the packet that is protected by the MACs and
increases the PC by at least one. When A receives the packet, it increases the PC by at least one. When A receives the packet, it
compares the value of the PC with the one contained in the previous compares the value of the PC with the one contained in the previous
packet received from B, and unless it is strictly greater, the packet packet received from B, and unless it is strictly greater, the packet
is discarded. is discarded.
By itself, the PC mechanism is not sufficient to protect against By itself, the PC mechanism is not sufficient to protect against
replay. Consider a peer A that has no information about a peer B replay. Consider a peer A that has no information about a peer B
(e.g., because it has recently rebooted). Suppose that A receives a (e.g., because it has recently rebooted). Suppose that A receives a
packet ostensibly from B carrying a given PC; since A has no packet ostensibly from B carrying a given PC; since A has no
information about B, it has no way to determine whether the packet is information about B, it has no way to determine whether the packet is
freshly generated or a replay of a previously sent packet. freshly generated or a replay of a previously sent packet.
In this situation, A discards the packet and challenges B to prove In this situation, A discards the packet and challenges B to prove
that it knows the HMAC key. It sends a "challenge request", a TLV that it knows the MAC key. It sends a "challenge request", a TLV
containing a unique nonce, a value that has never been used before containing a unique nonce, a value that has never been used before
and will never be used again. B replies to the challenge request and will never be used again. B replies to the challenge request
with a "challenge reply", a TLV containing a copy of the nonce chosen with a "challenge reply", a TLV containing a copy of the nonce chosen
by A, in a packet protected by HMAC and containing the new value of by A, in a packet protected by MAC and containing the new value of
B's PC. Since the nonce has never been used before, B's reply proves B's PC. Since the nonce has never been used before, B's reply proves
B's knowledge of the HMAC key and the freshness of the PC. B's knowledge of the MAC key and the freshness of the PC.
By itself, this mechanism is safe against replay if B never resets By itself, this mechanism is safe against replay if B never resets
its PC. In practice, however, this is difficult to ensure, as its PC. In practice, however, this is difficult to ensure, as
persistent storage is prone to failure, and hardware clocks, even persistent storage is prone to failure, and hardware clocks, even
when available, are occasionally reset. Suppose that B resets its PC when available, are occasionally reset. Suppose that B resets its PC
to an earlier value, and sends a packet with a previously used PC n. to an earlier value, and sends a packet with a previously used PC n.
A challenges B, B successfully responds to the challenge, and A A challenges B, B successfully responds to the challenge, and A
accepts the PC equal to n + 1. At this point, an attacker C may send accepts the PC equal to n + 1. At this point, an attacker C may send
a replayed packet with PC equal to n + 2, which will be accepted by a replayed packet with PC equal to n + 2, which will be accepted by
A. A.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3. Data Structures 3. Data Structures
Every Babel node maintains a set of conceptual data structures Every Babel node maintains a set of conceptual data structures
described in Section 3.2 of [RFC6126bis]. This protocol extends described in Section 3.2 of [RFC6126bis]. This protocol extends
these data structures as follows. these data structures as follows.
3.1. The Interface Table 3.1. The Interface Table
Every Babel node maintains an interface table, as described in Every Babel node maintains an interface table, as described in
Section 3.2.3 of [RFC6126bis]. Implementations of this protocol MUST Section 3.2.3 of [RFC6126bis]. Implementations of this protocol MUST
allow each interface to be provisioned with a set of one or more HMAC allow each interface to be provisioned with a set of one or more MAC
keys and the associated HMAC algorithms (see Section 4.1). In order keys and the associated MAC algorithms (see Section 4.1 for suggested
to allow incremental deployment of this protocol (see Section 5), algorithms, and Section 7 for suggested methods for key generation).
implementations SHOULD allow an interface to be configured in a mode In order to allow incremental deployment of this protocol (see
in which it participates in the HMAC authentication protocol but Section 5), implementations SHOULD allow an interface to be
accepts packets that are not authenticated. configured in a mode in which it participates in the MAC
authentication protocol but accepts packets that are not
authenticated.
This protocol extends each entry in this table that is associated This protocol extends each entry in this table that is associated
with an interface on which HMAC authentication has been configured with an interface on which MAC authentication has been configured
with two new pieces of data: with two new pieces of data:
o a set of one or more HMAC keys, each associated with a given HMAC o a set of one or more MAC keys, each associated with a given MAC
algorithm; the length of each key is exactly the block size of the algorithm;
associated HMAC algorithm (i.e., the key is not subject to the
preprocessing described in Section 2 of [RFC2104]);
o a pair (Index, PC), where Index is an arbitrary string of 0 to 32 o a pair (Index, PC), where Index is an arbitrary string of 0 to 32
octets, and PC is a 32-bit (4-octet) integer. octets, and PC is a 32-bit (4-octet) integer.
We say that an index is fresh when it has never been used before with We say that an index is fresh when it has never been used before with
any of the keys currently configured on the interface. The Index any of the keys currently configured on the interface. The Index
field is initialised to a fresh index, for example by drawing a field is initialised to a fresh index, for example by drawing a
random string of sufficient length, and the PC is initialised to an random string of sufficient length (see Section 7 for suggested
arbitrary value (typically 0). sizes), and the PC is initialised to an arbitrary value (typically
0).
3.2. The Neighbour table 3.2. The Neighbour table
Every Babel node maintains a neighbour table, as described in Every Babel node maintains a neighbour table, as described in
Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in
this table with two new pieces of data: this table with two new pieces of data:
o a pair (Index, PC), where Index is a string of 0 to 32 octets, and o a pair (Index, PC), where Index is a string of 0 to 32 octets, and
PC is a 32-bit (4-octet) integer; PC is a 32-bit (4-octet) integer;
o a Nonce, which is an arbitrary string of 0 to 192 octets, and an o a Nonce, which is an arbitrary string of 0 to 192 octets, and an
associated challenge expiry timer. associated challenge expiry timer.
The Index and PC are initially undefined, and are managed as The Index and PC are initially undefined, and are managed as
described in Section 4.3. The Nonce and expiry timer are initially described in Section 4.3. The Nonce and expiry timer are initially
undefined, and used as described in Section 4.3.1.1. undefined, and used as described in Section 4.3.1.1.
4. Protocol Operation 4. Protocol Operation
4.1. HMAC computation 4.1. MAC computation
A Babel node computes the HMAC of a Babel packet as follows. A Babel node computes the MAC of a Babel packet as follows.
First, the node builds a pseudo-header that will participate in HMAC First, the node builds a pseudo-header that will participate in MAC
computation but will not be sent. If the packet is carried over computation but will not be sent. If the packet is carried over
IPv6, the pseudo-header has the following format: IPv6, the pseudo-header has the following format:
0 1 2 3 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 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 address +
skipping to change at page 8, line 17 skipping to change at page 8, line 17
Src port The source UDP port number of the packet. Src port The source UDP port number of the packet.
Dest address The destination IP address of the packet. Dest address The destination IP address of the packet.
Src port The destination UDP port number of the packet. Src port The destination UDP port number of the packet.
The node takes the concatenation of the pseudo-header and the Babel The node takes the concatenation of the pseudo-header and the Babel
packet including the packet header but excluding the packet trailer packet including the packet header but excluding the packet trailer
(from octet 0 inclusive up to (Body Length + 4) exclusive) and (from octet 0 inclusive up to (Body Length + 4) exclusive) and
computes an HMAC with one of the implemented hash algorithms. Every computes a MAC with one of the implemented algorithms. Every
implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and
Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and
MAY implement other HMAC algorithms. MAY implement other MAC algorithms.
4.2. Packet Transmission 4.2. Packet Transmission
A Babel node might delay actually sending TLVs by a small amount, in A Babel node might delay actually sending TLVs by a small amount, in
order to aggregate multiple TLVs in a single packet up to the order to aggregate multiple TLVs in a single packet up to the
interface MTU (Section 4 of [RFC6126bis]). For an interface on which interface MTU (Section 4 of [RFC6126bis]). For an interface on which
HMAC protection is configured, the TLV aggregation logic MUST take MAC protection is configured, the TLV aggregation logic MUST take
into account the overhead due to PC TLVs (one in each packet) and into account the overhead due to PC TLVs (one in each packet) and MAC
HMAC TLVs (one per configured key). TLVs (one per configured key).
Before sending a packet, the following actions are performed: Before sending a packet, the following actions are performed:
o a PC TLV containing the PC and Index associated with the outgoing o a PC TLV containing the PC and Index associated with the outgoing
interface MUST be appended to the packet body; the PC MUST be interface MUST be appended to the packet body; the PC MUST be
incremented by a strictly positive amount (typically just 1); if incremented by a strictly positive amount (typically just 1); if
the PC overflows, a fresh index MUST be generated (as defined in the PC overflows, a fresh index MUST be generated (as defined in
Section 3.1); a node MUST NOT include multiple PC TLVs in a single Section 3.1); a node MUST NOT include multiple PC TLVs in a single
packet; packet;
o for each key configured on the interface, an HMAC is computed as o for each key configured on the interface, a MAC is computed as
specified in Section 4.1 above, and stored in an HMAC TLV that specified in Section 4.1 above, and stored in a MAC TLV that MUST
MUST be appended to the packet trailer (see Section 4.2 of be appended to the packet trailer (see Section 4.2 of
[RFC6126bis]). [RFC6126bis]).
4.3. Packet Reception 4.3. Packet Reception
When a packet is received on an interface that is configured for HMAC When a packet is received on an interface that is configured for MAC
protection, the following steps are performed before the packet is protection, the following steps are performed before the packet is
passed to normal processing: passed to normal processing:
o First, the receiver checks whether the trailer of the received o First, the receiver checks whether the trailer of the received
packet carries at least one HMAC TLV; if not, the packet MUST be packet carries at least one MAC TLV; if not, the packet MUST be
immediately dropped and processing stops. Then, for each key immediately dropped and processing stops. Then, for each key
configured on the receiving interface, the receiver computes the configured on the receiving interface, the receiver computes the
HMAC of the packet. It then compares every generated HMAC against MAC of the packet. It then compares every generated MAC against
every HMAC included in the packet; if there is at least one match, every MAC included in the packet; if there is at least one match,
the packet passes the HMAC test; if there is none, the packet MUST the packet passes the MAC test; if there is none, the packet MUST
be silently dropped and processing stops at this point. In order be silently dropped and processing stops at this point. In order
to avoid memory exhaustion attacks, an entry in the Neighbour to avoid memory exhaustion attacks, an entry in the Neighbour
Table MUST NOT be created before the HMAC test has passed Table MUST NOT be created before the MAC test has passed
successfully. The HMAC of the packet MUST NOT be computed for successfully. The MAC of the packet MUST NOT be computed for each
each HMAC TLV contained in the packet, but only once for each MAC TLV contained in the packet, but only once for each configured
configured key. key.
o If an entry for the sender does not exist in the Neighbour Table, o If an entry for the sender does not exist in the Neighbour Table,
it MAY be created at this point (or, alternatively, its creation it MAY be created at this point (or, alternatively, its creation
can be delayed until a challenge needs to be sent, see below); can be delayed until a challenge needs to be sent, see below);
o The packet body is then parsed a first time. During this o The packet body is then parsed a first time. During this
"preparse" phase, the packet body is traversed and all TLVs are "preparse" phase, the packet body is traversed and all TLVs are
ignored except PC TLVs, Challenge Requests and Challenge Replies. ignored except PC TLVs, Challenge Requests and Challenge Replies.
When a PC TLV is encountered, the enclosed PC and Index are saved When a PC TLV is encountered, the enclosed PC and Index are saved
for later processing; if multiple PCs are found (which should not for later processing; if multiple PCs are found (which should not
skipping to change at page 10, line 32 skipping to change at page 10, line 32
response to replayed packets. As an optimisation, a node MAY ignore response to replayed packets. As an optimisation, a node MAY ignore
all challenge requests contained in a packet except the last one, and all challenge requests contained in a packet except the last one, and
it MAY ignore a challenge request in the case where it is contained it MAY ignore a challenge request in the case where it is contained
in a packet with an Index that matches the one in the Neighbour in a packet with an Index that matches the one in the Neighbour
Table and a PC that is smaller or equal to the one contained in the Table and a PC that is smaller or equal to the one contained in the
Neighbour Table. Since it is still possible to replay a packet with Neighbour Table. Since it is still possible to replay a packet with
an obsolete Index, the rate-limiting described in Section 4.3.1.1 is an obsolete Index, the rate-limiting described in Section 4.3.1.1 is
required even if this optimisation is implemented. required even if this optimisation is implemented.
The same is true of challenge replies. However, since validating a The same is true of challenge replies. However, since validating a
challenge reply is extremely cheap (it's just a bitwise comparison of challenge reply has minimal additional cost (it's just a bitwise
two strings of octets), a similar optimisation for challenge replies comparison of two strings of octets), a similar optimisation for
is not worthwile. challenge replies is not worthwile.
After the packet has been accepted, it is processed as normal, except After the packet has been accepted, it is processed as normal, except
that any PC, Challenge Request and Challenge Reply TLVs that it that any PC, Challenge Request and Challenge Reply TLVs that it
contains are silently ignored. contains are silently ignored.
4.3.1. Challenge Requests and Replies 4.3.1. Challenge Requests and Replies
During the preparse stage, the receiver might encounter a mismatched During the preparse stage, the receiver might encounter a mismatched
Index, to which it will react by scheduling a Challenge Request. It Index, to which it will react by scheduling a Challenge Request. It
might encounter a Challenge Request TLV, to which it will reply with might encounter a Challenge Request TLV, to which it will reply with
skipping to change at page 12, line 4 skipping to change at page 12, line 6
A node MAY aggregate a Challenge Reply with other TLVs; in other A node MAY aggregate a Challenge Reply with other TLVs; in other
words, if it has already buffered TLVs to be sent to the unicast words, if it has already buffered TLVs to be sent to the unicast
address of the sender of the Challenge Request, it MAY send the address of the sender of the Challenge Request, it MAY send the
buffered TLVs in the same packet as the Challenge Reply. However, it buffered TLVs in the same packet as the Challenge Reply. However, it
MUST arrange for the Challenge Reply to be sent in a timely manner MUST arrange for the Challenge Reply to be sent in a timely manner
(within a few seconds), and SHOULD NOT send any other packets over (within a few seconds), and SHOULD NOT send any other packets over
the same interface before sending the Challenge Reply, as those would the same interface before sending the Challenge Reply, as those would
be dropped by the challenger. be dropped by the challenger.
A challenge sent to a multicast address MUST be silently ignored. A challenge sent to a multicast address MUST be silently ignored.
Since a challenge reply might be caused by a replayed challenge
request, a node MUST impose a rate limitation to the challenge
replies it sends; the limit SHOULD default to one challenge reply for
each peer every 300ms and MAY be configurable.
4.3.1.3. Receiving challenge replies 4.3.1.3. Receiving challenge replies
When it encounters a Challenge Reply during the preparse phase, a When it encounters a Challenge Reply during the preparse phase, a
node consults the Neighbour Table entry corresponding to the node consults the Neighbour Table entry corresponding to the
neighbour that sent the Challenge Reply. If no challenge is in neighbour that sent the Challenge Reply. If no challenge is in
progress, i.e., if there is no Nonce stored in the Neighbour progress, i.e., if there is no Nonce stored in the Neighbour
Table entry or the Challenge timer has expired, the Challenge Reply Table entry or the Challenge timer has expired, the Challenge Reply
MUST be silently ignored and the challenge has failed. MUST be silently ignored and the challenge has failed.
skipping to change at page 13, line 9 skipping to change at page 13, line 15
either of the keys. At that point, the old key is removed. either of the keys. At that point, the old key is removed.
In order to support the procedures described above, implementations In order to support the procedures described above, implementations
of this protocol SHOULD support an interface configuration in which of this protocol SHOULD support an interface configuration in which
packets are sent authenticated but received packets are accepted packets are sent authenticated but received packets are accepted
without verification, and they SHOULD allow changing the set of keys without verification, and they SHOULD allow changing the set of keys
associated with an interface without a restart. associated with an interface without a restart.
6. Packet Format 6. Packet Format
6.1. HMAC TLV 6.1. MAC TLV
0 1 2 3 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 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 | HMAC... | Type = 16 | Length | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 16 to indicate an HMAC TLV. Type Set to 16 to indicate a MAC TLV.
Length The length of the body, in octets, exclusive of the Type Length The length of the body, in octets, exclusive of the Type
and Length fields. The length of the body depends on the and Length fields. The length depends on the MAC algorithm
HMAC algorithm being used. being used.
HMAC The body contains the HMAC of the packet, computed as MAC The body contains the MAC of the packet, computed as
described in Section 4.1. described in Section 4.1.
This TLV is allowed in the packet trailer (see Section 4.2 of This TLV is allowed in the packet trailer (see Section 4.2 of
[RFC6126bis]), and MUST be ignored if it is found in the packet body. [RFC6126bis]), and MUST be ignored if it is found in the packet body.
6.2. PC TLV 6.2. PC TLV
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 24 skipping to change at page 15, line 33
properties for the Babel routing protocol. The scope of this properties for the Babel routing protocol. The scope of this
protocol is strictly limited: it only provides authentication (we protocol is strictly limited: it only provides authentication (we
assume that routing information is not confidential), it only assume that routing information is not confidential), it only
supports symmetric keying, and it only allows for the use of a small supports symmetric keying, and it only allows for the use of a small
number of symmetric keys on every link. Deployments that need more number of symmetric keys on every link. Deployments that need more
features, e.g., confidentiality or asymmetric keying, should use a features, e.g., confidentiality or asymmetric keying, should use a
more featureful security mechanism such as the one described in more featureful security mechanism such as the one described in
[I-D.ietf-babel-dtls]. [I-D.ietf-babel-dtls].
This mechanism relies on two assumptions, as described in This mechanism relies on two assumptions, as described in
Section 1.2. First, it assumes that the hash being used is Section 1.2. First, it assumes that the MAC being used is
invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the
time of writing, SHA-256, which is mandatory to implement time of writing, SHA-256, which is mandatory to implement
(Section 4.1), is believed to be safe against practical attacks. (Section 4.1), is believed to be safe against practical attacks.
Second, it assumes that indices and nonces are generated uniquely Second, it assumes that indices and nonces are generated uniquely
over the lifetime of a key used for HMAC computation (more precisely, over the lifetime of a key used for MAC computation (more precisely,
indices must be unique for a given (key, source) pair, and nonces indices must be unique for a given (key, source) pair, and nonces
must be unique for a given (key, source, destination) triple). This must be unique for a given (key, source, destination) triple). This
property can be satisfied either by using a cryptographically secure property can be satisfied either by using a cryptographically secure
random number generator to generate indices and nonces that contain random number generator to generate indices and nonces that contain
enough entropy (64-bit values are believed to be large enough for all enough entropy (64-bit values are believed to be large enough for all
practical applications), or by using a reliably monotonic hardware practical applications), or by using a reliably monotonic hardware
clock. If uniqueness cannot be guaranteed (e.g., because a hardware clock. If uniqueness cannot be guaranteed (e.g., because a hardware
clock has been reset), then rekeying is necessary. clock has been reset), then rekeying is necessary.
The expiry mechanism mandated in Section 4.4 is required to prevent The expiry mechanism mandated in Section 4.4 is required to prevent
an attacker from delaying an authentic packet by an unbounded amount an attacker from delaying an authentic packet by an unbounded amount
of time. If an attacker is able to delay the delivery of a packet 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 (e.g., because it is located at a layer 2 switch), then the packet
will be accepted as long as the corresponding (Index, PC) pair is will be accepted as long as the corresponding (Index, PC) pair is
present at the receiver. If the attacker is able to cause the present at the receiver. If the attacker is able to cause the
(Index, PC) pair to persist for arbitrary amounts of time (e.g., by (Index, PC) pair to persist for arbitrary amounts of time (e.g., by
repeatedly causing failed challenges), then it is able to delay the repeatedly causing failed challenges), then it is able to delay the
packet by arbitrary amounts of time, even after the sender has left packet by arbitrary amounts of time, even after the sender has left
the network. the network, which could allow it to redirect or blackhole traffic to
destinations previously advertised by the sender.
This protocol exposes large numbers of packets and their MACs to an
attacker that is able to capture packets; it is therefore vulnerable
to brute-force attacks. Keys must be chosen in a manner that makes
them difficult to guess. Ideally, they should have a length of 32
octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly.
If, for some reason, it is necessary to derive keys from a human-
readable passphrase, it is recommended to use a key derivation
function that hampers dictionary attacks, such as PBKDF2 [RFC2898],
bcrypt [BCRYPT] or scrypt [RFC7914]. In that case, only the derived
keys should be communicated to the routers; the original passphrase
itself should be kept on the host used to perform the key generation
(e.g., an administators secure laptop computer).
While it is probably not possible to be immune against denial of While it is probably not possible to be immune against denial of
service (DoS) attacks in general, this protocol includes a number of service (DoS) attacks in general, this protocol includes a number of
mechanisms designed to mitigate such attacks. In particular, mechanisms designed to mitigate such attacks. In particular,
reception of a packet with no correct HMAC creates no local Babel reception of a packet with no correct MAC creates no local Babel
state (Section 4.3). Reception of a replayed packet with correct state (Section 4.3). Reception of a replayed packet with correct
hash, on the other hand, causes a challenge to be sent; this is MAC, on the other hand, causes a challenge to be sent; this is
mitigated somewhat by requiring that challenges be rate-limited mitigated somewhat by requiring that challenges be rate-limited
(Section 4.3.1.1). (Section 4.3.1.1).
Receiving a replayed packet with an obsolete index causes an entry to Receiving a replayed packet with an obsolete index causes an entry to
be created in the Neighbour Table, which, at first sight, makes the be created in the Neighbour Table, which, at first sight, makes the
protocol susceptible to resource exhaustion attacks (similarly to the protocol susceptible to resource exhaustion attacks (similarly to the
familiar "TCP SYN Flooding" attack [RFC4987]). However, the HMAC familiar "TCP SYN Flooding" attack [RFC4987]). However, the MAC
computation includes the sender address (Section 4.1), and thus the computation includes the sender address (Section 4.1), and thus the
amount of storage that an attacker can force a node to consume is amount of storage that an attacker can force a node to consume is
limited by the number of distinct source addresses used with a single limited by the number of distinct source addresses used with a single
HMAC key (see also Section 4 of [RFC6126bis], which mandates that the MAC key (see also Section 4 of [RFC6126bis], which mandates that the
source address is a link-local IPv6 address or a local IPv4 address). source address is a link-local IPv6 address or a local IPv4 address).
In order to make this kind of resource exhaustion attacks less In order to make this kind of resource exhaustion attacks less
effective, implementations may use a separate table of uncompleted effective, implementations may use a separate table of uncompleted
challenges that is separate from the Neighbour Table used by the core challenges that is separate from the Neighbour Table used by the core
protocol (the data structures described in Section 3.2 of protocol (the data structures described in Section 3.2 of
[RFC6126bis] are conceptual, and any data structure that yields the [RFC6126bis] are conceptual, and any data structure that yields the
same result may be used). Implementers might also consider using the same result may be used). Implementers might also consider using the
fact that the nonces included in challenge requests and responses can fact that the nonces included in challenge requests and responses can
be fairly large (up to 192 octets), which should in principle allow be fairly large (up to 192 octets), which should in principle allow
encoding the per-challenge state as a secure "cookie" within the encoding the per-challenge state as a secure "cookie" within the
nonce itself. nonce itself; note however that any such scheme will need to prevent
cookie replay.
8. IANA Considerations 8. IANA Considerations
IANA has allocated the following values in the Babel TLV Types IANA has allocated the following values in the Babel TLV Types
registry: registry:
+------+-------------------+---------------+ +------+-------------------+---------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+-------------------+---------------+ +------+-------------------+---------------+
| 16 | HMAC | this document | | 16 | MAC | this document |
| | | | | | | |
| 17 | PC | this document | | 17 | PC | this document |
| | | | | | | |
| 18 | Challenge Request | this document | | 18 | Challenge Request | this document |
| | | | | | | |
| 19 | Challenge Reply | this document | | 19 | Challenge Reply | this document |
+------+-------------------+---------------+ +------+-------------------+---------------+
9. Acknowledgments 9. Acknowledgments
The protocol described in this document is based on the original HMAC The protocol described in this document is based on the original HMAC
protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-
header was suggested by David Schinazi. The use of an index to avoid header was suggested by David Schinazi. The use of an index to avoid
replay was suggested by Markus Stenberg. The authors are also replay was suggested by Markus Stenberg. The authors are also
indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn, indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn,
Dave Taht and Martin Vigoureux. Benjamin Kaduk, Dave Taht and Martin Vigoureux.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 17, line 48 skipping to change at page 18, line 21
Cryptographic Hash and Message Authentication Code (MAC)", Cryptographic Hash and Message Authentication Code (MAC)",
RFC 7693, DOI 10.17487/RFC7693, November 2015, RFC 7693, DOI 10.17487/RFC7693, November 2015,
<https://www.rfc-editor.org/info/rfc7693>. <https://www.rfc-editor.org/info/rfc7693>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017. May 2017.
10.2. Informational References 10.2. Informational References
[BCRYPT] Niels, P. and D. Mazieres, "A Future-Adaptable Password
Scheme", 1999.
In Proceedings of the 1999 USENIX Annual Technical
Conference.
[I-D.ietf-babel-dtls] [I-D.ietf-babel-dtls]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security", Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-07 (work in progress), July 2019. draft-ietf-babel-dtls-07 (work in progress), July 2019.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898,
DOI 10.17487/RFC2898, September 2000,
<https://www.rfc-editor.org/info/rfc2898>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010, Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
<https://www.rfc-editor.org/info/rfc6039>. <https://www.rfc-editor.org/info/rfc6039>.
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
(HMAC) Cryptographic Authentication", RFC 7298, (HMAC) Cryptographic Authentication", RFC 7298,
DOI 10.17487/RFC7298, July 2014, DOI 10.17487/RFC7298, July 2014,
<https://www.rfc-editor.org/info/rfc7298>. <https://www.rfc-editor.org/info/rfc7298>.
[RFC7914] Percival, C. and S. Josefsson, "The scrypt Password-Based
Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
August 2016, <https://www.rfc-editor.org/info/rfc7914>.
Appendix A. Changes from previous versions Appendix A. Changes from previous versions
[RFC Editor: please remove this section before publication.] [RFC Editor: please remove this section before publication.]
A.1. Changes since draft-ietf-babel-hmac-00 A.1. Changes since draft-ietf-babel-hmac-00
o Changed the title. o Changed the title.
o Removed the appendix about the packet trailer, this is now in o Removed the appendix about the packet trailer, this is now in
rfc6126bis. rfc6126bis.
skipping to change at page 20, line 9 skipping to change at page 21, line 5
o Fix the size of the key to be equal to the block size, not the o Fix the size of the key to be equal to the block size, not the
hash size. hash size.
o Moved the information about incremental deployment to the body. o Moved the information about incremental deployment to the body.
o Clarified the double purpose of rate limitation. o Clarified the double purpose of rate limitation.
o Editorial changes. o Editorial changes.
A.8.2. Changes since draft-ietf-babel-hmac-09
o Renamed HMAC to MAC throughout, relevant rewording.
o Made it mandatory to rate-limit challenge replies in addition to
requests.
o Added discussion of key generation.
o Added discussion of the consequences of delaying packets.
Authors' Addresses Authors' Addresses
Clara Do Clara Do
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: clarado_perso@yahoo.fr Email: clarado_perso@yahoo.fr
Weronika Kolodziejak Weronika Kolodziejak
 End of changes. 54 change blocks. 
89 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/