rfc8967xml2.original.xml   rfc8967.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc toc="yes"?> category="std"
<?rfc tocdepth="2"?> number="8967"
<?rfc symrefs="yes"?> docName="draft-ietf-babel-hmac-12"
<?rfc sortrefs="yes" ?>
<?rfc compact="no" ?>
<rfc category="std" docName="draft-ietf-babel-hmac-12"
ipr="trust200902" ipr="trust200902"
obsoletes="7298"> obsoletes="7298"
<front> updates=""
<title abbrev="MAC authentication for Babel">MAC authentication for the submissionType="IETF"
Babel routing protocol</title> consensus="true"
<author fullname="Clara Do" initials="C." surname="Do"> xml:lang="en"
<organization>IRIF, University of Paris-Diderot</organization> tocInclude="true"
<address> tocDepth="2"
<postal> symRefs="true"
<street></street> sortRefs="true"
<city>75205 Paris Cedex 13</city> version="3">
<region></region> <!-- xml2rfc v2v3 conversion 3.0.0 -->
<code></code> <front>
<country>France</country> <title abbrev="MAC Authentication for Babel">MAC Authentication for the
</postal> Babel Routing Protocol</title>
<email>clarado_perso@yahoo.fr</email> <seriesInfo name="RFC" value="8967"/>
</address> <author fullname="Clara Dô" initials="C." surname="Dô">
</author> <organization>IRIF, University of Paris-Diderot</organization>
<author fullname="Weronika Kolodziejak" initials="W." surname="Kolodziejak"> <address>
<organization>IRIF, University of Paris-Diderot</organization> <postal>
<address> <city>Paris CEDEX 13</city>
<postal> <code>75205</code>
<street></street> <country>France</country>
<city>75205 Paris Cedex 13</city> </postal>
<region></region> <email>clarado_perso@yahoo.fr</email>
<code></code> </address>
<country>France</country> </author>
</postal> <author fullname="Weronika Kolodziejak" initials="W." surname="Kolodziejak">
<email>weronika.kolodziejak@gmail.com</email> <organization>IRIF, University of Paris-Diderot</organization>
</address> <address>
</author> <postal>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"> <city>Paris CEDEX 13</city>
<organization>IRIF, University of Paris-Diderot</organization> <code>75205</code>
<address> <country>France</country>
<postal> </postal>
<street>Case 7014</street> <email>weronika.kolodziejak@gmail.com</email>
<city>75205 Paris Cedex 13</city> </address>
<region></region> </author>
<code></code> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
<country>France</country> <organization>IRIF, University of Paris-Diderot</organization>
</postal> <address>
<email>jch@irif.fr</email> <postal>
</address> <street>Case 7014</street>
</author> <city>Paris CEDEX 13</city>
<code>75205</code>
<country>France</country>
</postal>
<email>jch@irif.fr</email>
</address>
</author>
<date month="January" year="2021"/>
<date day="4" month="September" year="2020"/> <keyword>routing protocol</keyword>
<keyword>authentication</keyword>
<keyword>replay</keyword>
<keyword>replay protection</keyword>
<abstract> <abstract>
<t>This document describes a cryptographic authentication mechanism for <t>This document describes a cryptographic authentication mechanism for
the Babel routing protocol that has provisions for replay avoidance. This the Babel routing protocol that has provisions for replay avoidance. This
document obsoletes RFC 7298.</t> document obsoletes RFC 7298.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>By default, the Babel routing protocol <xref target="RFC8966" format="d
<section title="Introduction"> efault"/>
trusts the information contained
<t>By default, the Babel routing protocol trusts the information contained
in every UDP datagram that it receives on the Babel port. An attacker can in every UDP datagram that it receives on the Babel port. An attacker can
redirect traffic to itself or to a different node in the network, causing redirect traffic to itself or to a different node in the network, causing
a variety of potential issues. In particular, an attacker might: a variety of potential issues. In particular, an attacker might:
<list style="symbols"> </t>
<t>spoof a Babel packet, and redirect traffic by announcing a route with
a smaller metric, a larger sequence number, or a longer prefix;</t>
<t>spoof a malformed packet, which could cause an insufficiently robust
implementation to crash or interfere with the rest of the network;</t>
<t>replay a previously captured Babel packet, which could cause traffic to
be redirected or otherwise interfere with the network.</t>
</list></t>
<t>Protecting a Babel network is challenging due to the fact that the <ul spacing="normal">
<li>spoof a Babel packet and redirect traffic by announcing a route with
a smaller metric, a larger sequence number, or a longer prefix;</li>
<li>spoof a malformed packet, which could cause an insufficiently robust
implementation to crash or interfere with the rest of the network;</li>
<li>replay a previously captured Babel packet, which could cause traffic
to
be redirected or otherwise interfere with the network.</li>
</ul>
<t>Protecting a Babel network is challenging due to the fact that the
Babel protocol uses both unicast and multicast communication. One Babel protocol uses both unicast and multicast communication. One
possible approach, used notably by the Babel over Datagram Transport Layer possible approach, used notably by the Babel over Datagram Transport Layer
Security (DTLS) protocol <xref target="I-D.ietf-babel-dtls"/>, is to use Security (DTLS) protocol <xref target="RFC8968" format="default"/>, is to use
unicast communication for all semantically significant communication, and unicast communication for all semantically significant communication, and
then use a standard unicast security protocol to protect the Babel then use a standard unicast security protocol to protect the Babel
traffic. In this document, we take the opposite approach: we define traffic. In this document, we take the opposite approach: we define
a cryptographic extension to the Babel protocol that is able to protect a cryptographic extension to the Babel protocol that is able to protect
both unicast and multicast traffic, and thus requires very few changes to both unicast and multicast traffic and thus requires very few changes to
the core protocol. This document obsoletes <xref target="RFC7298"/>.</t> the core protocol. This document obsoletes <xref target="RFC7298" format="defau
lt"/>.</t>
<section title="Applicability"> <section numbered="true" toc="default">
<name>Applicability</name>
<t>The protocol defined in this document assumes that all interfaces on <t>The protocol defined in this document assumes that all interfaces on
a given link are equally trusted and share a small set of symmetric keys a given link are equally trusted and share a small set of symmetric keys
(usually just one, and two during key rotation). The protocol is inapplicable (usually just one, and two during key rotation). The protocol is inapplicable
in situations where asymmetric keying is required, where the trust in situations where asymmetric keying is required, where the trust
relationship is partial, or where large numbers of trusted keys are relationship is partial, or where large numbers of trusted keys are
provisioned on a single link at the same time.</t> provisioned on a single link at the same time.</t>
<t>This protocol supports incremental deployment (where an insecure Babe
<t>This protocol supports incremental deployment (where an insecure Babel l
network is made secure with no service interruption), and it supports network is made secure with no service interruption), and it supports
graceful key rotation (where the set of keys is changed with no service graceful key rotation (where the set of keys is changed with no service
interruption).</t> interruption).</t>
<t>This protocol does not require synchronised clocks, it does not require <t>This protocol does not require synchronised clocks, it does not requi re
persistently monotonic clocks, and it does not require persistent storage persistently monotonic clocks, and it does not require persistent storage
except for what might be required for storing cryptographic keys.</t> except for what might be required for storing cryptographic keys.</t>
</section>
</section> <section anchor="security-properties" numbered="true" toc="default">
<name>Assumptions and Security Properties</name>
<section title="Assumptions and security properties" <t>The correctness of the protocol relies on the following assumptions:
anchor="security-properties"> </t>
<ul spacing="normal">
<t>The correctness of the protocol relies on the following assumptions: <li>that the Message Authentication Code (MAC) being used is invulnera
<list style="symbols"> ble
<t>that the Message Authentication Code (MAC) being used is invulnerable
to forgery, i.e., that an attacker is unable to generate a packet with to forgery, i.e., that an attacker is unable to generate a packet with
a correct MAC without access to the secret key;</t> a correct MAC without access to the secret key;</li>
<t>that a node never generates the same index or nonce twice over the <li>that a node never generates the same index or nonce twice over the
lifetime of a key.</t> lifetime of a key.</li>
</list> </ul>
<t>
The first assumption is a property of the MAC being used. The second The first assumption is a property of the MAC being used. The second
assumption can be met either by using a robust random number generator assumption can be met either by using a robust random number generator
<xref target="RFC4086"/> and sufficiently large indices and nonces, by <xref target="RFC4086" format="default"/> and sufficiently large indices and non ces, by
using a reliable hardware clock, or by rekeying often enough that using a reliable hardware clock, or by rekeying often enough that
collisions are unlikely.</t> collisions are unlikely.</t>
<t>If the assumptions above are met, the protocol described in this
<t>If the assumptions above are met, the protocol described in this
document has the following properties: document has the following properties:
<list style="symbols"> </t>
<t>it is invulnerable to spoofing: any Babel packet accepted as authentic <ul spacing="normal">
is the exact copy of a packet originally sent by an authorised node;</t> <li>it is invulnerable to spoofing: any Babel packet accepted as authe
<t>locally to a single node, it is invulnerable to replay: if a node has ntic
is the exact copy of a packet originally sent by an authorised node;</li>
<li>locally to a single node, it is invulnerable to replay: if a node
has
previously accepted a given packet, then it will never again accept a copy previously accepted a given packet, then it will never again accept a copy
of this packet or an earlier packet from the same sender;</t> of this packet or an earlier packet from the same sender;</li>
<t>among different nodes, it is only vulnerable to immediate replay: if <li>among different nodes, it is only vulnerable to immediate replay:
if
a node A has accepted an authentic packet from C, then a node B will only a node A has accepted an authentic packet from C, then a node B will only
accept a copy of that packet if B has accepted an older packet from C and accept a copy of that packet if B has accepted an older packet from C, and
B has received no later packet from C.</t> B has received no later packet from C.</li>
</list></t> </ul>
<t>While this protocol makes efforts to mitigate the effects of a denial
<t>While this protocol makes efforts to mitigate the effects of a denial
of service attack, it does not fully protect against such attacks.</t> of service attack, it does not fully protect against such attacks.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Specification of Requirements</name>
<section title="Specification of Requirements"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14
"OPTIONAL" in this document are to be interpreted as described in BCP 14 >",
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bc
they appear in all capitals, as shown here.</t> p14>"
in this document are to be interpreted as described in BCP 14 <xref target="RFC2
</section> 119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</section> </t>
</section>
<section title="Conceptual overview of the protocol"> </section>
<section numbered="true" toc="default">
<t>When a node B sends out a Babel packet through an interface that is <name>Conceptual Overview of the Protocol</name>
<t>When a node B sends out a Babel packet through an interface that is
configured for MAC cryptographic protection, it computes one or more MACs configured for MAC cryptographic protection, it computes one or more MACs
(one per key) which it appends to the packet. When a node A receives (one per key) that it appends to the packet. When a node A receives
a packet over an interface that requires MAC cryptographic protection, it a packet over an interface that requires MAC cryptographic protection, it
independently computes a set of MACs and compares them to the MACs independently computes a set of MACs and compares them to the MACs
appended to the packet; if there is no match, the packet is discarded.</t> appended to the packet; if there is no match, the packet is discarded.</t>
<t>In order to protect against replay, B maintains a per-interface 32-bit <t>In order to protect against replay, B maintains a per-interface 32-bit
integer known as the "packet counter" (PC). Whenever B sends a packet integer known as the "packet counter" (PC). Whenever B sends a packet
through the interface, it embeds the current value of the PC within the through the interface, it embeds the current value of the PC within the
region of the packet that is protected by the MACs and increases the PC region of the packet that is protected by the MACs and increases the PC
by at least one. When A receives the packet, it compares the value of the by at least one. When A receives the packet, it compares the value of the
PC with the one contained in the previous packet received from B, and PC with the one contained in the previous packet received from B, and
unless it is strictly greater, the packet is discarded.</t> unless it is strictly greater, the packet is discarded.</t>
<t>By itself, the PC mechanism is not sufficient to protect against
<t>By itself, the PC mechanism is not sufficient to protect against
replay. Consider a peer A that has no information about a peer replay. Consider a peer A that has no information about a peer
B (e.g., because it has recently rebooted). Suppose that A receives B (e.g., because it has recently rebooted). Suppose that A receives
a packet ostensibly from B carrying a given PC; since A has no information a 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 freshly about B, it has no way to determine whether the packet is freshly
generated or a replay of a previously sent packet.</t> generated or a replay of a previously sent packet.</t>
<t>In this situation, peer A discards the packet and challenges B to prove
<t>In this situation, A discards the packet and challenges B to prove that that
it knows the MAC key. It sends a "challenge request", a TLV containing it knows the MAC key. It sends a "Challenge Request", a TLV containing
a unique nonce, a value that has never been used before and will never be a unique nonce, a value that has never been used before and will never be
used again. B replies to the challenge request with a "challenge reply", used 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 by a TLV containing a copy of the nonce chosen by A, in a packet protected by
MAC and containing the new value of B's PC. Since the nonce has never MAC and containing the new value of B's PC. Since the nonce has never
been used before, B's reply proves B's knowledge of the MAC key and the been used before, B's reply proves B's knowledge of the MAC key and the
freshness of the PC.</t> freshness of the PC.</t>
<t>By itself, this mechanism is safe against replay if B never resets its
<t>By itself, this mechanism is safe against replay if B never resets its
PC. In practice, however, this is difficult to ensure, as persistent PC. In practice, however, this is difficult to ensure, as persistent
storage is prone to failure, and hardware clocks, even when available, are storage is prone to failure, and hardware clocks, even when available, are
occasionally reset. Suppose that B resets its PC to an earlier value, and occasionally reset. Suppose that B resets its PC to an earlier value and
sends a packet with a previously used PC n. A challenges B, 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 to B successfully responds to the challenge, and A accepts the PC equal to
n&nbsp;+&nbsp;1. At this point, an attacker C may send a replayed packet n + 1. At this point, an attacker C may send a replayed packet
with PC equal to n&nbsp;+&nbsp;2, which will be accepted by A.</t> with PC equal to n + 2, which will be accepted by A.</t>
<t>Another mechanism is needed to protect against this attack. In this
<t>Another mechanism is needed to protect against this attack. In this
protocol, every PC is tagged with an "index", an arbitrary string of protocol, every PC is tagged with an "index", an arbitrary string of
octets. Whenever B resets its PC, or whenever B doesn't know whether its octets. Whenever B resets its PC, or whenever B doesn't know whether its
PC has been reset, it picks an index that it has never used before (either PC has been reset, it picks an index that it has never used before (either
by drawing it randomly or by using a reliable hardware clock) and starts by drawing it randomly or by using a reliable hardware clock) and starts
sending PCs with that index. Whenever A detects that B has changed its sending PCs with that index. Whenever A detects that B has changed its
index, it challenges B again.</t> index, it challenges B again.</t>
<t>With this additional mechanism, this protocol is invulnerable to replay
<t>With this additional mechanism, this protocol is invulnerable to replay attacks (see <xref target="security-properties" format="default"/>).</t>
attacks (see <xref target="security-properties"/> above).</t> </section>
<section numbered="true" toc="default">
</section> <name>Data Structures</name>
<t>Every Babel node maintains a set of conceptual data structures
<section title="Data Structures"> described in <xref target="RFC8966" sectionFormat="of" section="3.2"/>. This pr
otocol
<t>Every Babel node maintains a set of conceptual data structures
described in Section 3.2 of <xref target="RFC6126bis"/>. This protocol
extends these data structures as follows.</t> extends these data structures as follows.</t>
<section anchor="interface-table" numbered="true" toc="default">
<section title="The Interface Table" anchor="interface-table"> <name>The Interface Table</name>
<t>Every Babel node maintains an interface table, as described in
<t>Every Babel node maintains an interface table, as described in Section <xref target="RFC8966" sectionFormat="of" section="3.2.3"/>. Implementations of
3.2.3 of <xref target="RFC6126bis"/>. Implementations of this protocol MUST this protocol <bcp14>MUST</bcp14>
allow each interface to be provisioned with a set of one or more MAC keys allow each interface to be provisioned with a set of one or more MAC keys
and the associated MAC algorithms (see <xref target="mac-computation"/> and the associated MAC algorithms (see <xref target="mac-computation" format="de
for suggested algorithms, and <xref target="security-considerations"/> for fault"/>
for suggested algorithms and <xref target="security-considerations" format="defa
ult"/> for
suggested methods for key generation). In order to allow incremental suggested methods for key generation). In order to allow incremental
deployment of this protocol (see <xref target="incremental-deployment"/>), deployment of this protocol (see <xref target="incremental-deployment" format="d
implementations SHOULD allow an interface to be configured in a mode in efault"/>),
implementations <bcp14>SHOULD</bcp14> allow an interface to be configured in a m
ode in
which it participates in the MAC authentication protocol but accepts which it participates in the MAC authentication protocol but accepts
packets that are not authenticated.</t> packets that are not authenticated.</t>
<t>This protocol extends each table entry associated with
<t>This protocol extends each entry in this table that is associated with
an interface on which MAC authentication has been configured with two new an interface on which MAC authentication has been configured with two new
pieces of data: pieces of data:
<list style="symbols"> </t>
<t> a set of one or more MAC keys, each associated with a given MAC <ul spacing="normal">
algorithm;</t> <li> a set of one or more MAC keys, each associated with a given MAC
<t> a pair (Index, PC), where Index is an arbitrary string of 0 to 32 algorithm;</li>
octets, and PC is a 32-bit (4-octet) integer.</t> <li> a pair (Index, PC), where Index is an arbitrary string of 0 to 32
</list> octets, and PC is a 32-bit (4-octet) integer.</li>
</ul>
<t>
We say that an index is fresh when it has never been used before with any 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 field is of the keys currently configured on the interface. The Index field is
initialised to a fresh index, for example by drawing a random string of initialised to a fresh index, for example, by drawing a random string of
sufficient length (see <xref target="security-considerations"/> for sufficient length (see <xref target="security-considerations" format="default"/>
for
suggested sizes), and the PC is initialised to an arbitrary value suggested sizes), and the PC is initialised to an arbitrary value
(typically 0).</t> (typically 0).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="The Neighbour table"> <name>The Neighbour Table</name>
<t>Every Babel node maintains a neighbour table, as described in <t>Every Babel node maintains a neighbour table, as described in
Section 3.2.4 of <xref target="RFC6126bis"/>. This protocol extends each <xref target="RFC8966" sectionFormat="of" section="3.2.4"/>. This protocol exte
nds each
entry in this table with two new pieces of data: entry in this table with two new pieces of data:
<list style="symbols"> </t>
<t> a pair (Index, PC), where Index is a string of 0 to 32 octets, and PC <ul spacing="normal">
is a 32-bit (4-octet) integer;</t> <li> a pair (Index, PC), where Index is a string of 0 to 32 octets, an
<t> a Nonce, which is an arbitrary string of 0 to 192 octets, and an d PC
associated challenge expiry timer.</t> is a 32-bit (4-octet) integer;</li>
</list> <li> a Nonce, which is an arbitrary string of 0 to 192 octets, and an
The Index and PC are initially undefined, and are managed as described in associated challenge expiry timer.</li>
<xref target="packet-reception"/>. The Nonce and challenge expiry timer are </ul>
initially undefined, and used as described in <t>
<xref target="sending-challenges"/>.</t> The Index and PC are initially undefined, and they are managed as described in
<xref target="packet-reception" format="default"/>. The Nonce and challenge exp
</section> iry timer are
initially undefined, and they are used as described in
</section> <xref target="sending-challenges" format="default"/>.</t>
</section>
<section title="Protocol Operation"> </section>
<section numbered="true" toc="default">
<section title="MAC computation" anchor="mac-computation"> <name>Protocol Operation</name>
<section anchor="mac-computation" numbered="true" toc="default">
<t>A Babel node computes the MAC of a Babel packet as follows.</t> <name>MAC Computation</name>
<t>A Babel node computes the MAC of a Babel packet as follows.</t>
<t>First, the node builds a pseudo-header that will participate in MAC <t>First, the node builds a pseudo-header that will participate in MAC
computation but will not be sent. If the packet is carried over IPv6, computation but will not be sent. If the packet is carried over IPv6,
the pseudo-header has the following format: the pseudo-header has the following format:
<figure><artwork><![CDATA[ </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 line 302 skipping to change at line 294
| Src port | | | Src port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| Dest address | | Dest address |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Dest port | | | Dest port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
<t>
If the packet is carried over IPv4, the pseudo-header has the following If the packet is carried over IPv4, the pseudo-header has the following
format: format:
<figure><artwork><![CDATA[ </t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src port | Dest address | | Src port | Dest address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Dest port | | | Dest port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure></t> ]]></artwork>
<t>Fields :
<list style="hanging" hangIndent="14"> <t>Fields:
<t hangText="Src address">The source IP address of the packet.</t> </t>
<t hangText="Src port">The source UDP port number of the packet.</t> <dl newline="false" spacing="normal" indent="14">
<t hangText="Dest address">The destination IP address of the packet.</t> <dt>Src address</dt>
<t hangText="Src port">The destination UDP port number of the packet.</t> <dd>The source IP address of the packet.</dd>
</list></t> <dt>Src port</dt>
<t>The node takes the concatenation of the pseudo-header and the Babel <dd>The source UDP port number of the packet.</dd>
<dt>Dest address</dt>
<dd>The destination IP address of the packet.</dd>
<dt>Src port</dt>
<dd>The destination UDP port number of the packet.</dd>
</dl>
<t>The node takes the concatenation of the pseudo-header and the Babel
packet including the packet header but excluding the packet trailer (from packet including the packet header but excluding the packet trailer (from
octet 0 inclusive up to (Body Length&nbsp;+&nbsp;4) exclusive) and octet 0 inclusive up to (Body Length + 4) exclusive) and
computes a MAC with one of the implemented algorithms. Every computes a MAC with one of the implemented algorithms. Every
implementation MUST implement HMAC-SHA256 as defined in implementation <bcp14>MUST</bcp14> implement HMAC-SHA256 as defined in
<xref target="RFC6234"/> and Section 2 of <xref target="RFC2104"/>, <xref target="RFC6234" format="default"/> and <xref target="RFC2104" sectionForm
SHOULD implement keyed BLAKE2s <xref target="RFC7693"/>, and MAY implement at="of" section="2"/>,
<bcp14>SHOULD</bcp14> implement keyed BLAKE2s <xref target="RFC7693" format="def
ault"/> with 128-bit (16-octet) digests, and <bcp14>MAY</bcp14> implement
other MAC algorithms.</t> other MAC algorithms.</t>
</section> </section>
<section anchor="packet-transmission" numbered="true" toc="default">
<section title="Packet Transmission" anchor="packet-transmission"> <name>Packet Transmission</name>
<t>A Babel node might delay actually sending TLVs by a small amount, in
<t>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 <xref target="RFC6126bis"/>). For an interface MTU (<xref target="RFC8966" sectionFormat="of" section="4"/>). For an
interface on which MAC protection is configured, the TLV aggregation interface on which MAC protection is configured, the TLV aggregation
logic MUST take into account the overhead due to PC TLVs (one in each logic <bcp14>MUST</bcp14> take into account the overhead due to PC TLVs (one in each
packet) and MAC TLVs (one per configured key).</t> packet) and MAC TLVs (one per configured key).</t>
<t>Before sending a packet, the following actions are performed:
<t>Before sending a packet, the following actions are performed: </t>
<list style="symbols"> <ul spacing="normal">
<t>a PC TLV containing the PC and Index associated with the <li>
outgoing interface MUST be appended to the packet body; the PC MUST be <t>a PC TLV containing the PC and Index associated with the
incremented by a strictly positive amount (typically just 1); if the outgoing interface <bcp14>MUST</bcp14> be appended to the packet body;</t>
PC overflows, a fresh index MUST be generated (as defined in <ul>
<xref target="interface-table"/>); a node MUST NOT include multiple PC <li>the PC <bcp14>MUST</bcp14> be
TLVs in a single packet;</t> incremented by a strictly positive amount (typically just 1);</li>
<t>for each key configured on the interface, a MAC is computed as <li>if the
specified in <xref target="mac-computation"/> above, and stored in a PC overflows, a fresh index <bcp14>MUST</bcp14> be generated (as defined in
MAC TLV that MUST be appended to the packet trailer (see Section 4.2 of <xref target="interface-table" format="default"/>); </li>
<xref target="RFC6126bis"/>).</t> </ul>
</list></t> <t>a node <bcp14>MUST NOT</bcp14> include multiple PC
TLVs in a single packet;</t>
</section> </li>
<li>for each key configured on the interface, a MAC is computed as
<section title="Packet Reception" anchor="packet-reception"> specified in <xref target="mac-computation" format="default"/> and stored in a
MAC TLV that <bcp14>MUST</bcp14> be appended to the packet trailer (see
<t>When a packet is received on an interface that is configured for MAC <xref target="RFC8966" sectionFormat="of" section="4.2"/>).</li>
</ul>
</section>
<section anchor="packet-reception" numbered="true" toc="default">
<name>Packet Reception</name>
<t>When a packet is received on an interface that is configured for MAC
protection, the following steps are performed before the packet is passed protection, the following steps are performed before the packet is passed
to normal processing: to normal processing:
</t> </t>
<t> <ul spacing="normal">
<list style="symbols"> <li>First, the receiver checks whether the trailer of the received pac
<t>First, the receiver checks whether the trailer of the received packet ket
carries at least one MAC TLV; if not, the packet MUST be immediately dropped carries at least one MAC TLV; if not, the packet <bcp14>MUST</bcp14> be immediat
ely dropped
and processing stops. Then, for each key configured on the receiving and processing stops. Then, for each key configured on the receiving
interface, the receiver computes the MAC of the packet. It then interface, the receiver computes the MAC of the packet. It then
compares every generated MAC against every MAC included in the packet; compares every generated MAC against every MAC included in the packet;
if there is at least one match, the packet passes the MAC test; if there if there is at least one match, the packet passes the MAC test; if there
is none, the packet MUST be silently dropped and processing stops at this is none, the packet <bcp14>MUST</bcp14> be silently dropped and processing stops at this
point. In order to avoid memory exhaustion attacks, an entry in the point. In order to avoid memory exhaustion attacks, an entry in the
Neighbour Table MUST NOT be created before the MAC test has passed neighbour table <bcp14>MUST NOT</bcp14> be created before the MAC test has passe
successfully. The MAC of the packet MUST NOT be computed for each MAC d
TLV contained in the packet, but only once for each configured key.</t> successfully. The MAC of the packet <bcp14>MUST NOT</bcp14> be computed for eac
<t>If an entry for the sender does not exist in the Neighbour Table, it h MAC
MAY be created at this point (or, alternatively, its creation can be TLV contained in the packet, but only once for each configured key.</li>
delayed until a challenge needs to be sent, see below);</t> <li>If an entry for the sender does not exist in the neighbour table,
<t>The packet body is then parsed a first time. During this "preparse" it
<bcp14>MAY</bcp14> be created at this point (or, alternatively, its creation can
be
delayed until a challenge needs to be sent, see below).</li>
<li>The packet body is then parsed a first time. During this "prepars
e"
phase, the packet body is traversed and all TLVs are ignored except PC, phase, the packet body is traversed and all TLVs are ignored except PC,
Challenge Request and Challenge Reply TLVs. When a PC TLV is Challenge Request, and Challenge Reply TLVs. When a PC TLV is
encountered, the enclosed PC and Index are saved for later processing; if encountered, the enclosed PC and Index are saved for later processing. If
multiple PCs are found (which should not happen, see multiple PCs are found (which should not happen, see
<xref target="packet-transmission"/> above), only the first one is <xref target="packet-transmission" format="default"/>), only the first one is
processed, the remaining ones MUST be silently ignored. If a Challenge processed, the remaining ones <bcp14>MUST</bcp14> be silently ignored. If a Cha
Request is encountered, a Challenge Reply MUST be scheduled, as described llenge
in <xref target="replying-challenges"/>. If a Challenge Reply is Request is encountered, a Challenge Reply <bcp14>MUST</bcp14> be scheduled, as d
escribed
in <xref target="replying-challenges" format="default"/>. If a Challenge Reply
is
encountered, it is tested for validity as described in encountered, it is tested for validity as described in
<xref target="receiving-challenges"/> and a note is made of the result of <xref target="receiving-challenges" format="default"/>, and a note is made of th
the test.</t> e result of
<t>The preparse phase above has yielded two pieces of data: the PC and the test.</li>
<li>The preparse phase above yields two pieces of data: the PC and
Index from the first PC TLV, and a bit indicating whether the packet Index from the first PC TLV, and a bit indicating whether the packet
contains a successful Challenge Reply. If the packet does not contain contains a successful Challenge Reply. If the packet does not contain
a PC TLV, the packet MUST be dropped and processing stops at this point. a PC TLV, the packet <bcp14>MUST</bcp14> be dropped, and processing stops at thi s point.
If the packet contains a successful Challenge Reply, then the PC and Index If the packet contains a successful Challenge Reply, then the PC and Index
contained in the PC TLV MUST be stored in the Neighbour Table entry contained in the PC TLV <bcp14>MUST</bcp14> be stored in the neighbour table ent ry
corresponding to the sender (which already exists in this case), and the corresponding to the sender (which already exists in this case), and the
packet is accepted.</t> packet is accepted.</li>
<t>Otherwise, if there is no entry in the Neighbour Table corresponding to
<li>Otherwise, if there is no entry in the neighbour table correspondi
ng to
the sender, or if such an entry exists but contains no Index, or if the the sender, or if such an entry exists but contains no Index, or if the
Index it contains is different from the Index contained in the PC TLV, Index it contains is different from the Index contained in the PC TLV,
then a challenge MUST be sent as described in then a challenge <bcp14>MUST</bcp14> be sent as described in
<xref target="sending-challenges"/>, the packet MUST be dropped, and <xref target="sending-challenges" format="default"/>, the packet <bcp14>MUST</bc
processing stops at this stage.</t> p14> be dropped, and
<t>At this stage, the packet contains no successful challenge reply and processing stops at this stage.</li>
the Index contained in the PC TLV is equal to the Index in the Neighbour <li>At this stage, the packet contains no successful Challenge Reply,
Table entry corresponding to the sender. The receiver compares the and
received PC with the PC contained in the Neighbour Table; if the received the Index contained in the PC TLV is equal to the Index in the neighbour
PC is smaller or equal than the PC contained in the Neighbour Table, the table entry corresponding to the sender. The receiver compares the
packet MUST be dropped and processing stops (no challenge is sent in this received PC with the PC contained in the neighbour table; if the received
PC is smaller or equal than the PC contained in the neighbour table, the
packet <bcp14>MUST</bcp14> be dropped and processing stops (no challenge is sent
in this
case, since the mismatch might be caused by harmless packet reordering on case, since the mismatch might be caused by harmless packet reordering on
the link). Otherwise, the PC contained in the Neighbour Table entry is the link). Otherwise, the PC contained in the neighbour table entry is
set to the received PC, and the packet is accepted.</t> set to the received PC, and the packet is accepted.</li>
</list></t> </ul>
<t>In the algorithm described above, Challenge Requests are processed an
<t>In the algorithm described above, challenge requests are processed and d
challenges are sent before the PC/Index pair is verified against the challenges are sent before the (Index, PC) pair is verified against the
neighbour table. This simplifies the implementation somewhat (the node neighbour table. This simplifies the implementation somewhat (the node
may simply schedule outgoing requests as it walks the packet during the may simply schedule outgoing requests as it walks the packet during the
preparse phase), but relies on the rate-limiting described in preparse phase) but relies on the rate limiting described in
<xref target="sending-challenges"/> to avoid sending too many challenges <xref target="sending-challenges" format="default"/> to avoid sending too many c
in response to replayed packets. As an optimisation, a node MAY ignore hallenges
all challenge requests contained in a packet except the last one, and it in response to replayed packets. As an optimisation, a node <bcp14>MAY</bcp14>
MAY ignore a challenge request in the case where it is contained in ignore
a packet with an Index that matches the one in the Neighbour Table and all Challenge Requests contained in a packet except the last one, and it
a PC that is smaller or equal to the one contained in the Neighbour Table. <bcp14>MAY</bcp14> ignore a Challenge Request in the case where it is contained
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 neighbour table.
Since it is still possible to replay a packet with an obsolete Index, the Since it is still possible to replay a packet with an obsolete Index, the
rate-limiting described in <xref target="sending-challenges"/> is rate limiting described in <xref target="sending-challenges" format="default"/> is
required even if this optimisation is implemented.</t> required even if this optimisation is implemented.</t>
<t>The same is true of Challenge Replies. However, since validating
<t>The same is true of challenge replies. However, since validating a Challenge Reply has minimal additional cost (it is just a bitwise
a challenge reply has minimal additional cost (it's just a bitwise comparison of two strings of octets), a similar optimisation for Challenge
comparison of two strings of octets), a similar optimisation for challenge Replies is not worthwhile.</t>
replies is not worthwhile.</t> <t>After the packet has been accepted, it is processed as normal, except
that any PC, Challenge Request, and Challenge Reply TLVs that it contains
<t>After the packet has been accepted, it is processed as normal, except
that any PC, Challenge Request and Challenge Reply TLVs that it contains
are silently ignored.</t> are silently ignored.</t>
<section numbered="true" toc="default">
<section title="Challenge requests and replies"> <name>Challenge Requests and Replies</name>
<t>During the preparse stage, the receiver might encounter a mismatche
<t>During the preparse stage, the receiver might encounter a mismatched d
Index, to which it will react by scheduling a Challenge Request. It might Index, to which it will react by scheduling a Challenge Request. It might
encounter a Challenge Request TLV, to which it will reply with a Challenge encounter a Challenge Request TLV, to which it will reply with a Challenge
Reply TLV. Finally, it might encounter a Challenge Reply TLV, which it Reply TLV. Finally, it might encounter a Challenge Reply TLV, which it
will attempt to match with a previously sent Challenge Request TLV in will attempt to match with a previously sent Challenge Request TLV in
order to update the Neighbour Table entry corresponding to the sender of order to update the neighbour table entry corresponding to the sender of
the packet.</t> the packet.</t>
<section anchor="sending-challenges" numbered="true" toc="default">
<section title="Sending challenges" anchor="sending-challenges"> <name>Sending Challenges</name>
<t>When it encounters a mismatched Index during the preparse phase,
<t>When it encounters a mismatched Index during the preparse phase, a node a node
picks a nonce that it has never used with any of the keys currently picks a nonce that it has never used with any of the keys currently
configured on the relevant interface, for example by drawing configured on the relevant interface, for example, by drawing
a sufficiently large random string of bytes or by consulting a strictly a sufficiently large random string of bytes or by consulting a strictly
monotonic hardware clock. It MUST then store the nonce in the entry of monotonic hardware clock. It <bcp14>MUST</bcp14> then store the nonce in the en
the Neighbour Table associated to the neighbour (the entry might need to try of
the neighbour table associated to the neighbour (the entry might need to
be created at this stage), initialise the neighbour's challenge expiry be created at this stage), initialise the neighbour's challenge expiry
timer to 30 seconds, and send a Challenge Request TLV to the unicast timer to 30 seconds, and send a Challenge Request TLV to the unicast
address corresponding to the neighbour.</t> address corresponding to the neighbour.</t>
<t>A node <bcp14>MAY</bcp14> aggregate a Challenge Request with othe
<t>A node MAY aggregate a Challenge Request with other TLVs; in other r TLVs; in other
words, if it has already buffered TLVs to be sent to the unicast address words, if it has already buffered TLVs to be sent to the unicast address
of the neighbour, it MAY send the buffered TLVs in the same packet as the of the neighbour, it <bcp14>MAY</bcp14> send the buffered TLVs in the same packe
Challenge Request. However, it MUST arrange for the Challenge Request to t as the
Challenge Request. However, it <bcp14>MUST</bcp14> arrange for the Challenge Re
quest to
be sent in a timely manner, as any packets received from that neighbour be sent in a timely manner, as any packets received from that neighbour
will be silently ignored until the challenge completes.</t> will be silently ignored until the challenge completes.</t>
<t>A node <bcp14>MUST</bcp14> impose a rate limitation to the challe
<t>A node MUST impose a rate limitation to the challenges it sends; the nges it sends; the
limit SHOULD default to one challenge request every 300ms, and MAY be limit <bcp14>SHOULD</bcp14> default to one Challenge Request every 300 ms and <b
cp14>MAY</bcp14> be
configurable. This rate limiting serves two purposes. First, since configurable. This rate limiting serves two purposes. First, since
a challenge may be sent in response to a packet replayed by an attacker, a 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 to it limits the number of challenges that an attacker can cause a node to
send. Second, it limits the number of challenges sent when there are send. Second, it limits the number of challenges sent when there are
multiple packets in flight from a single neighbour.</t> multiple packets in flight from a single neighbour.</t>
</section>
</section> <section anchor="replying-challenges" numbered="true" toc="default">
<name>Replying to Challenges</name>
<section title="Replying to challenges" anchor="replying-challenges"> <t>When it encounters a Challenge Request during the preparse phase,
<t>When it encounters a Challenge Request during the preparse phase,
a node constructs a Challenge Reply TLV by copying the Nonce from the a node constructs a Challenge Reply TLV by copying the Nonce from the
Challenge Request into the Challenge Reply. It MUST then send the Challenge Request into the Challenge Reply. It <bcp14>MUST</bcp14> then send th e
Challenge Reply to the unicast address from which the Challenge Request Challenge Reply to the unicast address from which the Challenge Request
was sent. A challenge sent to a multicast address MUST be silently ignored.</t> was sent. A challenge sent to a multicast address <bcp14>MUST</bcp14> be silent
ly ignored.</t>
<t>A node MAY aggregate a Challenge Reply with other TLVs; in other words, <t>A node <bcp14>MAY</bcp14> aggregate a Challenge Reply with other
TLVs; in other words,
if it has already buffered TLVs to be sent to the unicast address of the if it has already buffered TLVs to be sent to the unicast address of the
sender of the Challenge Request, it MAY send the buffered TLVs in the same sender of the Challenge Request, it <bcp14>MAY</bcp14> send the buffered TLVs in
packet as the Challenge Reply. However, it MUST arrange for the Challenge the same
Reply to be sent in a timely manner (within a few seconds), and SHOULD NOT packet as the Challenge Reply. However, it <bcp14>MUST</bcp14> arrange for the
Challenge
Reply to be sent in a timely manner (within a few seconds) and <bcp14>SHOULD NOT
</bcp14>
send any other packets over the same interface before sending the send any other packets over the same interface before sending the
Challenge Reply, as those would be dropped by the challenger.</t> Challenge Reply, as those would be dropped by the challenger.</t>
<t>Since a Challenge Reply might be caused by a replayed Challenge R
<t>Since a challenge reply might be caused by a replayed challenge request, equest,
a node MUST impose a rate limitation to the challenge replies it sends; a node <bcp14>MUST</bcp14> impose a rate limitation to the Challenge Replies it
the limit SHOULD default to one challenge reply for each peer every sends;
300ms and MAY be configurable.</t> the limit <bcp14>SHOULD</bcp14> default to one Challenge Reply for each peer eve
ry
</section> 300 ms and <bcp14>MAY</bcp14> be configurable.</t>
</section>
<section title="Receiving challenge replies" anchor="receiving-challenges"> <section anchor="receiving-challenges" numbered="true" toc="default">
<name>Receiving Challenge Replies</name>
<t>When it encounters a Challenge Reply during the preparse phase, a node <t>When it encounters a Challenge Reply during the preparse phase, a
consults the Neighbour Table entry corresponding to the neighbour that node
consults the neighbour table entry corresponding to the neighbour that
sent the Challenge Reply. If no challenge is in progress, i.e., if sent the Challenge Reply. If no challenge is in progress, i.e., if
there is no Nonce stored in the Neighbour Table entry or the challenge there is no Nonce stored in the neighbour table entry or the challenge
timer has expired, the Challenge Reply MUST be silently ignored and the timer has expired, the Challenge Reply <bcp14>MUST</bcp14> be silently ignored,
and the
challenge has failed.</t> challenge has failed.</t>
<t>Otherwise, the node compares the Nonce contained in the Challenge
<t>Otherwise, the node compares the Nonce contained in the Challenge Reply Reply
with the Nonce contained in the Neighbour Table entry. If the two are with the Nonce contained in the neighbour table entry. If the two are
equal (they have the same length and content), then the challenge has equal (they have the same length and content), then the challenge has
succeeded and the nonce stored in the Neighbour Table for this neighbour succeeded and the nonce stored in the neighbour table for this neighbour
SHOULD be discarded; otherwise, the challenge has failed (and the nonce is <bcp14>SHOULD</bcp14> be discarded; otherwise, the challenge has failed (and the
nonce is
not discarded).</t> not discarded).</t>
</section>
</section> </section>
</section>
</section> <section anchor="expire" numbered="true" toc="default">
<name>Expiring Per-Neighbour State</name>
</section> <t>The per-neighbour (Index, PC) pair is maintained in the neighbour
<section title="Expiring per-neighbour state" anchor="expire">
<t>The per-neighbour (Index, PC) pair is maintained in the neighbour
table, and is normally discarded when the neighbour table entry expires. table, and is normally discarded when the neighbour table entry expires.
Implementations MUST ensure that an (Index, PC) pair is discarded within Implementations <bcp14>MUST</bcp14> ensure that an (Index, PC) pair is discarded within
a finite time since the last time a packet has been accepted. In a finite time since the last time a packet has been accepted. In
particular, unsuccessful challenges MUST NOT prevent an (Index, PC) pair particular, unsuccessful challenges <bcp14>MUST NOT</bcp14> prevent an (Index, P C) pair
from being discarded for unbounded periods of time.</t> from being discarded for unbounded periods of time.</t>
<t>A possible implementation strategy for implementations that use a Hel
<t>A possible implementation strategy for implementations that use a Hello lo
history (Appendix A of <xref target="RFC6126bis"/>) is to discard the history (Appendix A of <xref target="RFC8966" format="default"/>) is to discard
the
(Index, PC) pair whenever the Hello history becomes empty. Another (Index, PC) pair whenever the Hello history becomes empty. Another
implementation strategy is to use a timer that is reset whenever a packet implementation strategy is to use a timer that is reset whenever a packet
is accepted, and to discard the (Index, PC) pair whenever the timer is accepted and to discard the (Index, PC) pair whenever the timer
expires. If the latter strategy is being used, the timer SHOULD default expires. If the latter strategy is used, the timer <bcp14>SHOULD</bcp14> defaul
to a value of 5&nbsp;min, and MAY be configurable.</t> t
to a value of 5 minutes and <bcp14>MAY</bcp14> be configurable.</t>
</section> </section>
</section>
</section> <section anchor="incremental-deployment" numbered="true" toc="default">
<name>Incremental Deployment and Key Rotation</name>
<section title="Incremental deployment and key rotation" <t>In order to perform incremental deployment, the nodes in the network
anchor="incremental-deployment">
<t>In order to perform incremental deployment, the nodes in the network
are first configured in a mode where packets are sent with authentication are first configured in a mode where packets are sent with authentication
but not checked on reception. Once all the nodes in the network are but not checked on reception. Once all the nodes in the network are
configured to send authenticated packets, nodes are reconfigured to reject configured to send authenticated packets, nodes are reconfigured to reject
unauthenticated packets.</t> unauthenticated packets.</t>
<t>In order to perform key rotation, the new key is added to all the
<t>In order to perform key rotation, the new key is added to all the nodes. Once this is done, both the old and the new key are sent in all
nodes; once this is done, both the old and the new key are sent in all
packets, and packets are accepted if they are properly signed by either of packets, and packets are accepted if they are properly signed by either of
the keys. At that point, the old key is removed.</t> the keys. At that point, the old key is removed.</t>
<t>In order to support the procedures described above, implementations of
<t>In order to support the procedures described above, implementations of this protocol <bcp14>SHOULD</bcp14> support an interface configuration in which
this protocol SHOULD support an interface configuration in which packets packets
are sent authenticated but received packets are accepted without are sent authenticated but received packets are accepted without
verification, and they SHOULD allow changing the set of keys associated verification, and they <bcp14>SHOULD</bcp14> allow changing the set of keys asso ciated
with an interface without a restart.</t> with an interface without a restart.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Packet Format</name>
<section title="Packet Format"> <section numbered="true" toc="default">
<name>MAC TLV</name>
<section title="MAC TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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 | MAC... | Type = 16 | Length | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure> ]]></artwork>
<t>Fields:
<t>Fields : </t>
<list style="hanging" hangIndent="10"> <dl newline="false" spacing="normal" indent="10">
<t hangText="Type">Set to 16 to indicate a MAC TLV.</t> <dt>Type</dt>
<t hangText="Length">The length of the body, in octets, exclusive of the <dd>Set to 16 to indicate a MAC TLV.</dd>
<dt>Length</dt>
<dd>The length of the body, in octets, exclusive of the
Type and Length fields. The length depends on the MAC algorithm being Type and Length fields. The length depends on the MAC algorithm being
used.</t> used.</dd>
<t hangText="MAC">The body contains the MAC of the packet, computed as <dt>MAC</dt>
described in <xref target="mac-computation"/>.</t> <dd>The body contains the MAC of the packet, computed as
</list></t> described in <xref target="mac-computation" format="default"/>.</dd>
</dl>
<t>This TLV is allowed in the packet trailer (see Section 4.2 of <t>This TLV is allowed in the packet trailer (see
<xref target="RFC6126bis"/>), and MUST be ignored if it is found in the <xref target="RFC8966" sectionFormat="of" section="4.2"/>) and <bcp14>MUST</bcp1
4> be ignored if it is found in the
packet body.</t> packet body.</t>
</section>
</section> <section numbered="true" toc="default">
<name>PC TLV</name>
<section title="PC TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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 = 17 | Length | PC | | Type = 17 | Length | PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Index... | | Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure> ]]></artwork>
<t>Fields:
<t>Fields : </t>
<list style="hanging" hangIndent="10"> <dl newline="false" spacing="normal" indent="10">
<t hangText="Type">Set to 17 to indicate a PC TLV.</t> <dt>Type</dt>
<t hangText="Length">The length of the body, in octets, exclusive of the <dd>Set to 17 to indicate a PC TLV.</dd>
Type and Length fields.</t> <dt>Length</dt>
<t hangText="PC">The Packet Counter (PC), a 32-bit (4-octet) unsigned <dd>The length of the body, in octets, exclusive of the
integer which is increased with every packet sent over this interface. Type and Length fields.</dd>
A fresh index (as defined in <xref target="interface-table"/>) MUST be <dt>PC</dt>
generated whenever the PC overflows.</t> <dd>The Packet Counter (PC), a 32-bit (4-octet) unsigned
<t hangText="Index">The sender's Index, an opaque string of 0 to 32 integer that is increased with every packet sent over this interface.
octets.</t> A fresh index (as defined in <xref target="interface-table" format="default"/>)
</list></t> <bcp14>MUST</bcp14> be
generated whenever the PC overflows.</dd>
<t>Indices are limited to a size of 32 octets: a node MUST NOT send a TLV <dt>Index</dt>
with an index of size strictly larger than 32 octets, and a node MAY <dd>The sender's Index, an opaque string of 0 to 32
octets.</dd>
</dl>
<t>Indices are limited to a size of 32 octets: a node <bcp14>MUST NOT</b
cp14> send a TLV
with an index of size strictly larger than 32 octets, and a node <bcp14>MAY</bcp
14>
ignore a PC TLV with an index of length strictly larger than 32 octets. ignore 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 and Indices of length 0 are valid: if a node has reliable stable storage and
the packet counter never overflows, then only one index is necessary, and the packet counter never overflows, then only one index is necessary, and
the value of length 0 is the canonical choice.</t> the value of length 0 is the canonical choice.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Challenge Request TLV</name>
<section title="Challenge Request TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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 = 18 | Length | Nonce... | Type = 18 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure> ]]></artwork>
<t>Fields:
<t>Fields : </t>
<list style="hanging" hangIndent="10"> <dl newline="false" spacing="normal" indent="10">
<t hangText="Type">Set to 18 to indicate a Challenge Request TLV.</t> <dt>Type</dt>
<t hangText="Length">The length of the body, in octets, exclusive of the <dd>Set to 18 to indicate a Challenge Request TLV.</dd>
Type and Length fields.</t> <dt>Length</dt>
<t hangText="Nonce">The nonce uniquely identifying the challenge, an <dd>The length of the body, in octets, exclusive of the
opaque string of 0 to 192 octets.</t> Type and Length fields.</dd>
</list></t> <dt>Nonce</dt>
<dd>The nonce uniquely identifying the challenge, an
<t>Nonces are limited to a size of 192 octets: a node MUST NOT send opaque string of 0 to 192 octets.</dd>
</dl>
<t>Nonces are limited to a size of 192 octets: a node <bcp14>MUST NOT</b
cp14> send
a Challenge Request TLV with a nonce of size strictly larger than 192 a Challenge Request TLV with a nonce of size strictly larger than 192
octets, and a node MAY ignore a nonce that is of size strictly larger than octets, and a node <bcp14>MAY</bcp14> ignore a nonce that is of size strictly la rger than
192 octets. Nonces of length 0 are valid: if a node has reliable stable 192 octets. Nonces of length 0 are valid: if a node has reliable stable
storage, then it may use a sequential counter for generating nonces which storage, then it may use a sequential counter for generating nonces that
get encoded in the minimum number of octets required; the value 0 is then get encoded in the minimum number of octets required; the value 0 is then
encoded as the string of length 0.</t> encoded as the string of length 0.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Challenge Reply TLV</name>
<section title="Challenge Reply TLV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
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 = 19 | Length | Nonce... | Type = 19 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure> ]]></artwork>
<t>Fields:
<t>Fields : </t>
<list style="hanging" hangIndent="10"> <dl newline="false" spacing="normal" indent="10">
<t hangText="Type">Set to 19 to indicate a Challenge Reply TLV.</t> <dt>Type</dt>
<t hangText="Length">The length of the body, in octets, exclusive of the <dd>Set to 19 to indicate a Challenge Reply TLV.</dd>
Type and Length fields.</t> <dt>Length</dt>
<t hangText="Nonce">A copy of the nonce contained in the corresponding <dd>The length of the body, in octets, exclusive of the
challenge request.</t> Type and Length fields.</dd>
</list></t> <dt>Nonce</dt>
</section> <dd>A copy of the nonce contained in the corresponding
Challenge Request.</dd>
</section> </dl>
</section>
<section title="Security Considerations" anchor="security-considerations"> </section>
<section anchor="security-considerations" numbered="true" toc="default">
<t>This document defines a mechanism that provides basic security <name>Security Considerations</name>
<t>This document defines a mechanism that provides basic security
properties for the Babel routing protocol. The scope of this protocol is properties for the Babel routing protocol. The scope of this protocol is
strictly limited: it only provides authentication (we assume that routing strictly limited: it only provides authentication (we assume that routing
information is not confidential), it only supports symmetric keying, and information is not confidential), it only supports symmetric keying, and
it only allows for the use of a small number of symmetric keys on every it only allows for the use of a small number of symmetric keys on every
link. Deployments that need more features, e.g., confidentiality or link. Deployments that need more features, e.g., confidentiality or
asymmetric keying, should use a more featureful security mechanism such as asymmetric keying, should use a more feature-rich security mechanism such as
the one described in <xref target="I-D.ietf-babel-dtls"/>.</t> the one described in <xref target="RFC8968" format="default"/>.</t>
<t>This mechanism relies on two assumptions, as described in
<t>This mechanism relies on two assumptions, as described in <xref <xref target="security-properties" format="default"/>. First, it assumes that t
target="security-properties"/>. First, it assumes that the MAC being used he MAC being used
is invulnerable to forgery (Section 1.1 of <xref target="RFC6039"/>); at is invulnerable to forgery (<xref target="RFC6039" sectionFormat="of" section="1
.1"/>); at
the time of writing, HMAC-SHA256, which is mandatory to implement the time of writing, HMAC-SHA256, which is mandatory to implement
(<xref target="mac-computation"/>), is believed to be safe against (<xref target="mac-computation" format="default"/>), is believed to be safe agai nst
practical attacks.</t> practical attacks.</t>
<t>Second, it assumes that indices and nonces are generated uniquely over
<t>Second, it assumes that indices and nonces are generated uniquely over
the lifetime of a key used for MAC computation (more precisely, indices the lifetime of a key used for MAC computation (more precisely, indices
must be unique for a given (key, source) pair, and nonces must be unique must be unique for a given (key, source) pair, and nonces must be unique
for a given (key, source, destination) triple). This property can be for a given (key, source, destination) triple). This property can be
satisfied either by using a cryptographically secure random number satisfied either by using a cryptographically secure random number
generator to generate indices and nonces that contain enough entropy generator to generate indices and nonces that contain enough entropy
(64-bit values are believed to be large enough for all practical (64-bit values are believed to be large enough for all practical
applications), or by using a reliably monotonic hardware clock. If applications) or by using a reliably monotonic hardware clock. If
uniqueness cannot be guaranteed (e.g., because a hardware clock has been uniqueness cannot be guaranteed (e.g., because a hardware clock has been
reset), then rekeying is necessary.</t> reset), then rekeying is necessary.</t>
<t>The expiry mechanism mandated in <xref target="expire" format="default"
<t>The expiry mechanism mandated in <xref target="expire"/> is required to /> is required to
prevent an attacker from delaying an authentic packet by an unbounded prevent 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 amount 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 be (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 present at the accepted as long as the corresponding (Index, PC) pair is present at the
receiver. If the attacker is able to cause the (Index, PC) pair to receiver. If the attacker is able to cause the (Index, PC) pair to
persist for arbitrary amounts of time (e.g., by repeatedly causing failed persist for arbitrary amounts of time (e.g., by repeatedly causing failed
challenges), then it is able to delay the packet by arbitrary amounts of challenges), then it is able to delay the packet by arbitrary amounts of
time, even after the sender has left the network, which could allow it to time, even after the sender has left the network, which could allow it to
redirect or blackhole traffic to destinations previously advertised by the redirect or blackhole traffic to destinations previously advertised by the
sender.</t> sender.</t>
<t>This protocol exposes large numbers of packets and their MACs to an
<t>This protocol exposes large numbers of packets and their MACs to an
attacker that is able to capture packets; it is therefore vulnerable to 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 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 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 for HMAC-SHA256 and BLAKE2s), and be chosen randomly. If, for some
reason, it is necessary to derive keys from a human-readable passphrase, reason, it is necessary to derive keys from a human-readable passphrase,
it is recommended to use a key derivation function that hampers dictionary it is recommended to use a key derivation function that hampers dictionary
attacks, such as PBKDF2 <xref target="RFC2898"/>, bcrypt attacks, such as PBKDF2 <xref target="RFC8018" format="default"/>, bcrypt
<xref target="BCRYPT"/> or scrypt <xref target="RFC7914"/>. In that case, <xref target="BCRYPT" format="default"/>, or scrypt <xref target="RFC7914" forma
t="default"/>. In that case,
only the derived keys should be communicated to the routers; the original 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 passphrase itself should be kept on the host used to perform the key
generation (e.g., an administator's secure laptop computer).</t> generation (e.g., an administrator's secure laptop computer).</t>
<t>While it is probably not possible to be immune against denial of
<t>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, reception of mechanisms designed to mitigate such attacks. In particular, reception of
a packet with no correct MAC creates no local Babel state a packet with no correct MAC creates no local Babel state
(<xref target="packet-reception"/>). Reception of a replayed packet with (<xref target="packet-reception" format="default"/>). Reception of a replayed p acket with
correct MAC, on the other hand, causes a challenge to be sent; this is correct 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
(<xref target="sending-challenges"/>).</t> (<xref target="sending-challenges" format="default"/>).</t>
<t>Receiving a replayed packet with an obsolete index causes an entry to
<t>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 <xref target="RFC4987"/>). However, familiar "TCP SYN Flooding" attack <xref target="RFC4987" format="default"/>).
the MAC computation includes the sender address (<xref However,
target="mac-computation"/>), and thus the amount of storage that an the MAC computation includes the sender address (<xref target="mac-computation"
format="default"/>),
and thus the amount of storage that an
attacker can force a node to consume is limited by the number of distinct attacker can force a node to consume is limited by the number of distinct
source addresses used with a single MAC key (see also Section 4 of source addresses used with a single MAC key (see also
<xref target="RFC6126bis"/>, which mandates that the source address is <xref target="RFC8966" sectionFormat="of" section="4"/>, which mandates that the
source address is
a link-local IPv6 address or a local IPv4 address).</t> a link-local IPv6 address or a local IPv4 address).</t>
<t>In order to make this kind of resource exhaustion attacks less
<t>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 <xref protocol (the data structures described in <xref target="RFC8966" sectionFormat=
target="RFC6126bis"/> are conceptual, and any data structure that yields the "of" section="3.2"/> are conceptual, and any data structure that yields the
same result may be used). Implementers might also consider using the fact same result may be used). Implementers might also consider using the fact
that the nonces included in challenge requests and replies can be fairly that the nonces included in Challenge Requests and Replies can be fairly
large (up to 192 octets), which should in principle allow encoding the large (up to 192 octets), which should in principle allow encoding the
per-challenge state as a secure "cookie" within the nonce itself; note per-challenge state as a secure "cookie" within the nonce itself; note,
however that any such scheme will need to prevent cookie replay.</t> however, that any such scheme will need to prevent cookie replay.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <t>IANA has allocated the following values in the Babel TLV Types
<t>IANA has allocated the following values in the Babel TLV Types
registry:</t> registry:</t>
<texttable> <table align="center">
<ttcol>Type</ttcol><ttcol>Name</ttcol><ttcol>Reference</ttcol> <thead>
<c>16</c><c>MAC</c><c>this document</c> <tr>
<c>17</c><c>PC</c><c>this document</c> <th align="left">Type</th>
<c>18</c><c>Challenge Request</c><c>this document</c> <th align="left">Name</th>
<c>19</c><c>Challenge Reply</c><c>this document</c> <th align="left">Reference</th>
</texttable> </tr>
</thead>
</section> <tbody>
<tr>
<section title="Acknowledgments"> <td align="left">16</td>
<td align="left">MAC</td>
<t>The protocol described in this document is based on the original HMAC <td align="left">RFC 8967</td>
protocol defined by Denis Ovsienko <xref target="RFC7298"/>. The use of </tr>
a pseudo-header was suggested by David Schinazi. The use of an index to <tr>
avoid replay was suggested by Markus Stenberg. The authors are also <td align="left">17</td>
indebted to Antonin Decimo, Donald Eastlake, Toke Hoiland-Jorgensen, <td align="left">PC</td>
Florian Horn, Benjamin Kaduk, Dave Taht and Martin Vigoureux.</t> <td align="left">RFC 8967</td>
</tr>
</section> <tr>
<td align="left">18</td>
</middle> <td align="left">Challenge Request</td>
<td align="left">RFC 8967</td>
<back> </tr>
<tr>
<references title="Normative References"> <td align="left">19</td>
<td align="left">Challenge Reply</td>
<reference anchor="RFC2119"><front> <td align="left">RFC 8967</td>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> </tr>
<author initials="S." surname="Bradner" fullname="S. Bradner"/> </tbody>
<date year="1997" month="March"/> </table>
</front> </section>
<seriesInfo name="BCP" value="14"/> </middle>
<seriesInfo name="RFC" value="2119"/> <back>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174"><front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor='RFC6126bis'><front>
<title>The Babel Routing Protocol</title>
<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'/>
<author initials='D' surname='Schinazi' fullname='David Schinazi'/>
<date month='October' day='23' year='2018' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-babel-rfc6126bis-06'/>
</reference>
<reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2104">
<front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H." surname="Krawczyk" fullname="H. Krawczyk"></author>
<author initials="M." surname="Bellare" fullname="M. Bellare"></author>
<author initials="R." surname="Canetti" fullname="R. Canetti"></author>
<date year="1997" month="February"/>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234">
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
</author>
<author initials="T." surname="Hansen" fullname="T. Hansen"></author>
<date year="2011" month="May"/>
</front>
<seriesInfo name="RFC" value="6234"/>
<seriesInfo name="DOI" value="10.17487/RFC6234"/>
</reference>
<reference anchor="RFC7693" target="https://www.rfc-editor.org/info/rfc7693">
<front>
<title>The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)</titl
e>
<author initials="M-J." surname="Saarinen" fullname="M-J. Saarinen" role="editor
"/>
<author initials="J-P." surname="Aumasson" fullname="J-P. Aumasson"/>
<date year="2015" month="November"/>
</front>
<seriesInfo name="RFC" value="7693"/>
<seriesInfo name="DOI" value="10.17487/RFC7693"/>
</reference>
</references>
<references title="Informational References">
<reference anchor="RFC7298"
target="https://www.rfc-editor.org/info/rfc7298"><front>
<title>Babel Hashed Message Authentication Code (HMAC) Cryptographic
Authentication</title>
<author initials="D." surname="Ovsienko" fullname="D. Ovsienko"></author>
<date year="2014" month="July"/>
</front>
<seriesInfo name="RFC" value="7298"/>
<seriesInfo name="DOI" value="10.17487/RFC7298"/>
</reference>
<reference anchor="I-D.ietf-babel-dtls"><front>
<title>Babel Routing Protocol over Datagram Transport Layer Security</title>
<author initials="A" surname="Decimo" fullname="Antonin Decimo"/>
<author initials="D" surname="Schinazi" fullname="David Schinazi"/>
<author initials="J" surname="Chroboczek" fullname="Juliusz Chroboczek"/>
<date month="July" day="5" year="2019"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-babel-dtls-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-babel-
dtls-07.txt"/>
</reference>
<reference anchor="RFC6039" target="https://www.rfc-editor.org/info/rfc6039">
<front>
<title>
Issues with Existing Cryptographic Protection Methods for Routing Protocols
</title>
<author initials="V." surname="Manral" fullname="V. Manral"/>
<author initials="M." surname="Bhatia" fullname="M. Bhatia"/>
<author initials="J." surname="Jaeggli" fullname="J. Jaeggli"/>
<author initials="R." surname="White" fullname="R. White"/>
<date year="2010" month="October"/>
</front>
<seriesInfo name="RFC" value="6039"/>
<seriesInfo name="DOI" value="10.17487/RFC6039"/>
</reference>
<reference anchor='RFC4086' target='http://www.rfc-editor.org/info/rfc4086'>
<front>
<title>Randomness Requirements for Security</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'/>
<author initials='J.' surname='Schiller' fullname='J. Schiller'/>
<author initials='S.' surname='Crocker' fullname='S. Crocker'/>
<date year='2005' month='June'/>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>
<reference anchor="RFC4987" target="https://www.rfc-editor.org/info/rfc4987">
<front>
<title>TCP SYN Flooding Attacks and Common Mitigations</title>
<author initials="W." surname="Eddy" fullname="W. Eddy"/>
<date year="2007" month="August"/>
</front>
<seriesInfo name="RFC" value="4987"/>
<seriesInfo name="DOI" value="10.17487/RFC4987"/>
</reference>
<reference anchor="BCRYPT">
<front>
<title>A Future-Adaptable Password Scheme</title>
<author initials="P." surname="Niels" fullname="Niels Provos"/>
<author initials="D." surname="Mazieres" fullname="David Mazieres"/>
<date year="1999"/>
</front>
<annotation>In Proceedings of the 1999 USENIX Annual Technical
Conference.</annotation>
</reference>
<reference anchor="RFC2898" target="https://www.rfc-editor.org/info/rfc2898">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"/>
<date year="2000" month="September"/>
</front>
<seriesInfo name="RFC" value="2898"/>
<seriesInfo name="DOI" value="10.17487/RFC2898"/>
</reference>
<reference anchor="RFC7914" target="https://www.rfc-editor.org/info/rfc7914">
<front>
<title>The scrypt Password-Based Key Derivation Function</title>
<author initials="C." surname="Percival" fullname="C. Percival"/>
<author initials="S." surname="Josefsson" fullname="S. Josefsson"/>
<date year="2016" month="August"/>
</front>
<seriesInfo name="RFC" value="7914"/>
<seriesInfo name="DOI" value="10.17487/RFC7914"/>
</reference>
</references>
<section title="Changes from previous versions">
<t>[RFC Editor: please remove this section before publication.]</t>
<section title="Changes since draft-ietf-babel-hmac-00">
<t><list style="symbols">
<t>Changed the title.</t>
<t>Removed the appendix about the packet trailer, this is now in
rfc6126bis.</t>
<t>Removed the appendix with implicit indices.</t>
<t>Clarified the definitions of acronyms.</t>
<t>Limited the size of nonces and indices.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-01">
<t><list style="symbols">
<t>Made BLAKE2s a recommended HMAC algorithm.</t>
<t>Added requirement to expire per-neighbour crypto state.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-02">
<t><list style="symbols">
<t>Clarified that PCs are 32-bit unsigned integers.</t>
<t>Clarified that indices and nonces are of arbitrary size.</t>
<t>Added reference to RFC 4086.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-03">
<t><list style="symbols">
<t>Use the TLV values allocated by IANA.</t>
<t>Fixed an issue with packets that contain a successful challenge
reply: they should be accepted before checking the PC value.</t>
<t>Clarified that keys are the exact value of the HMAC hash size, and not
subject to preprocessing; this makes management more deterministic.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-04">
<t><list style="symbols">
<t>Use normative language in more places.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-05">
<t><list style="symbols">
<t>Do not update RFC 6126bis.</t>
<t>Clarify that indices and nonces of length 0 are valid.</t>
<t>Clarify that multiple PC TLVs in a single packet are not allowed.</t>
<t>Allow discarding challenge requests when they carry an old PC.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-06">
<t><list style="symbols">
<t>Do not update RFC 6126bis, for real this time.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-07">
<t><list style="symbols">
<t>Clarify that a Neighbour Table entry may be created just after the HMAC
has been computed.</t>
<t>Clarify that a Neighbour Table entry already exists when a successful
Challenge Reply has been received.</t>
<t>Expand the Security Considerations section with information about
resource exhaustion attacks.</t>
</list></t>
<section title="Changes since draft-ietf-babel-hmac-08">
<t><list style="symbols">
<t>Fix the size of the key to be equal to the block size, not the hash size.</t>
<t>Moved the information about incremental deployment to the body.</t>
<t>Clarified the double purpose of rate limitation.</t>
<t>Editorial changes.</t>
</list></t>
</section>
<section title="Changes since draft-ietf-babel-hmac-09">
<t><list style="symbols">
<t>Renamed HMAC to MAC throughout, relevant rewording.</t>
<t>Made it mandatory to rate-limit challenge replies in addition to
requests.</t>
<t>Added discussion of key generation.</t>
<t>Added discussion of the consequences of delaying packets.</t>
</list></t>
</section> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<section title="Changes since draft-ietf-babel-hmac-10"> <reference anchor="RFC8966" target="https://www.rfc-editor.org/info/rfc8
966">
<front>
<title>The Babel Routing Protocol</title>
<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboc
zek"/>
<author fullname="David Schinazi" initials="D." surname="Schinazi"/>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8966"/>
<seriesInfo name="DOI" value="10.17487/RFC8966"/>
</reference>
<t><list style="symbols"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Fixed minor typos.</t> FC.2104.xml"/>
</list></t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7693.xml"/>
</references>
<references>
<name>Informational References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7298.xml"/>
</section> <reference anchor="RFC8968" target="https://www.rfc-editor.org/info/rfc8968">
<front>
<title>Babel Routing Protocol over Datagram Transport Layer Security</tit
le>
<author initials="A" surname="Décimo" fullname="Antonin Décimo">
<organization />
</author>
<author initials="D" surname="Schinazi" fullname="David Schinazi">
<organization />
</author>
<author initials="J" surname="Chroboczek" fullname="Juliusz Chroboczek">
<organization />
</author>
<section title="Changes since draft-ietf-babel-hmac-11"> <date month="January" year="2021" />
</front>
<seriesInfo name="RFC" value="8968" />
<seriesInfo name="DOI" value="10.17487/RFC8968"/>
<t><list style="symbols"> </reference>
<t>Clarified that the state SHOULD be discarded after a successful challenge.</t
>
<t>Replaced "pre-image attack" with "forgery", this is more accurate.</t>
<t>Minor editorial changes.</t>
</list></t>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.6039.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4987.xml"/>
</back> <reference anchor="BCRYPT">
<front>
<title>A Future-Adaptable Password Scheme</title>
<author initials="P." surname="Niels" fullname="Niels Provos"/>
<author initials="D." surname="Mazières" fullname="David Mazières"/>
<date month="June" year="1999"/>
</front>
<refcontent>Proceedings of the FREENIX Track: 1999 USENIX Annual Techn
ical Conference</refcontent>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8018.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7914.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The protocol described in this document is based on the original HMAC
protocol defined by <contact fullname="Denis Ovsienko"/> <xref target="RFC7298"
format="default"/>.
The use of a pseudo-header was suggested by <contact fullname="David Schinazi"/>
.
The use of an index to avoid replay was suggested by <contact fullname="Markus S
tenberg"/>.
The authors are also indebted to <contact fullname="Antonin Décimo"/>,
<contact fullname="Donald Eastlake"/>, <contact fullname="Toke Høiland-Jørgensen
"/>,
<contact fullname="Florian Horn"/>, <contact fullname="Benjamin Kaduk"/>,
<contact fullname="Dave Taht"/>, and <contact fullname="Martin Vigoureux"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 123 change blocks. 
831 lines changed or deleted 687 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/