draft-ietf-babel-hmac-04.txt   draft-ietf-babel-hmac-05.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
Updates: 6126bis (if approved) IRIF, University of Paris-Diderot Updates: 6126bis (if approved) IRIF, University of Paris-Diderot
Intended status: Standards Track March 9, 2019 Intended status: Standards Track June 7, 2019
Expires: September 10, 2019 Expires: December 9, 2019
HMAC authentication for the Babel routing protocol HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-04 draft-ietf-babel-hmac-05
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 updates RFC 6126bis and obsoletes RFC 7298. This document updates RFC 6126bis and 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 34 skipping to change at page 1, line 34
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 September 10, 2019. This Internet-Draft will expire on December 9, 2019.
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 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . 5 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. HMAC 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 . . . . . . . . . . . . . . 11 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 11
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informational References . . . . . . . . . . . . . . . . 16 9.2. Informational References . . . . . . . . . . . . . . . . 16
Appendix A. Incremental deployment and key rotation . . . . . . 16 Appendix A. Incremental deployment and key rotation . . . . . . 16
Appendix B. Changes from previous versions . . . . . . . . . . . 17 Appendix B. Changes from previous versions . . . . . . . . . . . 17
B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17
B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17
B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17
B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 17 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18
B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 packet it receives on the Babel port. An contained in every UDP datagram that it receives on the Babel port.
attacker can redirect traffic to itself or to a different node in the An attacker can redirect traffic to itself or to a different node in
network, causing a variety of potential issues. In particular, an the network, causing a variety of potential issues. In particular,
attacker might: an attacker might:
o spoof a Babel packet, and redirect traffic by announcing a smaller o spoof a Babel packet, and redirect traffic by announcing a smaller
metric, a larger seqno, or a longer prefix; metric, a larger seqno, or a longer prefix;
o spoof a malformed packet, which could cause an insufficiently o spoof a malformed packet, which could cause an insufficiently
robust implementation to crash or interfere with the rest of the robust implementation to crash or interfere with the rest of the
network; network;
o replay a previously captured Babel packet, which could cause o replay a previously captured Babel packet, which could cause
traffic to be redirected or otherwise interfere with the network. traffic to be redirected or otherwise interfere with the network.
skipping to change at page 4, line 47 skipping to change at page 4, line 51
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 HMAC cryptographic protection, it computes one or more
HMACs which it appends to the packet. When a node A receives a HMACs which it appends to the packet. When a node A receives a
packet over an interface that requires HMAC cryptographic protection, packet over an interface that requires HMAC cryptographic protection,
it independently computes a set of HMACs and compares them to the it independently computes a set of HMACs and compares them to the
HMACs appended to the packet; if there is no match, the packet is HMACs appended to the packet; if there is no match, the packet is
discarded. discarded.
In order to protect against replay B maintains a per-interface 32-bit In order to protect against replay, B maintains a per-interface
integer known as the "packet counter" (PC). Whenever B sends a 32-bit integer known as the "packet counter" (PC). Whenever B sends
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 HMACs 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
skipping to change at page 5, line 48 skipping to change at page 6, line 8
before (either by drawing it randomly or by using a reliable hardware before (either by drawing it randomly or by using a reliable hardware
clock) and starts sending PCs with that index. Whenever A detects clock) and starts sending PCs with that index. Whenever A detects
that B has changed its index, it challenges B again. that B has changed its index, it challenges B again.
With this additional mechanism, this protocol is invulnerable to With this additional mechanism, this protocol is invulnerable to
replay attacks (see Section 1.2 above). replay attacks (see Section 1.2 above).
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 [RFC6126bis] Section 3.2. This protocol extends these described in Section 3.2 of [RFC6126bis]. This protocol extends
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
[RFC6126bis] Section 3.2.3. Implementations of this protocol MUST Section 3.2.3 [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 HMAC
keys and the associated HMAC algorithms (see Section 4.1). In order keys and the associated HMAC algorithms (see Section 4.1). In order
to allow incremental deployment of this protocol (see Appendix A), to allow incremental deployment of this protocol (see Appendix A),
implementations SHOULD allow an interface to be configured in a mode implementations SHOULD allow an interface to be configured in a mode
in which it participates in the HMAC authentication protocol but in which it participates in the HMAC authentication protocol but
accepts packets that are not authentified. accepts packets that are not authentified.
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 HMAC 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 HMAC keys, each associated with a given HMAC
algorithm ; the length of each key is exactly the hash size of the algorithm ; the length of each key is exactly the hash size of the
associated HMAC algorithm (i.e., the key is not subject to the associated HMAC algorithm (i.e., the key is not subject to the
preprocessing described in Section 2 of [RFC2104]); preprocessing described in Section 2 of [RFC2104]);
o a pair (Index, PC), where Index is an arbtrary 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.
The Index and PC are initialised to arbitrary values chosen so as to We say that an index is fresh when it has never been used before with
ensure that a given (Index, PC) pair is never reused. Typically, the any of the keys currently configured on the interface. The Index
initial Index will be chosen as a random string of sufficient length, field is initialised to a fresh index, for example by drawing a
and the initial PC will be set to 0. random string of sufficient length, 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
[RFC6126bis] Section 3.2.4. This protocol extends each entry in this Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in
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, an arbitrary string of 0 to 192 octets, and an associated o a Nonce, which is an arbitrary string of 0 to 192 octets, and an
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. HMAC computation
A Babel node computes an HMAC as follows. A Babel node computes the HMAC 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 HMAC
computation but will not be sent. If the packet was carried over computation but will not be sent. If the packet was 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 8, line 13 skipping to change at page 8, line 16
Src address The source IP address of the packet. Src address The source IP address of the packet.
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 packet The node takes the concatenation of the pseudo-header and the packet
including the packet header but excluding the packet trailer (from including the packet header but excluding the packet trailer (from
octet 0 inclusive up to Body Length + 4 exclusive) and computes an octet 0 inclusive up to (Body Length + 4) exclusive) and computes an
HMAC with one of the implemented hash algorithms. Every HMAC with one of the implemented hash 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 HMAC algorithms.
4.2. Packet Transmission 4.2. Packet Transmission
A Babel node may 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 HMAC 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
HMAC TLVs (one per configured key). HMAC 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 is appended to the packet body; the PC is incremented by interface MUST be appended to the packet body; the PC MUST be
a strictly positive amount (typically just 1); if the PC incremented by a strictly positive amount (typically just 1); if
overflows, a fresh index is generated; the PC overflows, a fresh index MUST be generated (as defined in
Section 3.1);
o for each key configured on the interface, an HMAC is computed as o for each key configured on the interface, an HMAC is computed as
specified in Section 4.1 above, and an HMAC TLV is appended to the specified in Section 4.1 above, and stored in an HMAC TLV that
packet trailer (see Section 4.2 of [RFC6126bis]). MUST be appended to the packet trailer (see Section 4.2 of
[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 HMAC
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 is packet carries at least one HMAC 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 implementation computes configured on the receiving interface, the receiver computes the
the HMAC of the packet. It then compares every generated HMAC HMAC of the packet. It then compares every generated HMAC against
against every HMAC included in the packet; if there is at least every HMAC included in the packet; if there is at least one match,
one match, the packet passes the HMAC test; if there is none, the the packet passes the HMAC test; if there is none, the packet MUST
packet is silently dropped and processing stops at this point. In be silently dropped and processing stops at this point. In order
order to avoid memory exhaustion attacks, an entry in the to avoid memory exhaustion attacks, an entry in the Neighbour
Neighbour Table MUST NOT be created before the HMAC test has Table MUST NOT be created before the HMAC test has passed
passed successfully. The HMAC of the packet MUST NOT be computed successfully. The HMAC of the packet MUST NOT be computed for
for each HMAC TLV contained in the packet, but only once for each each HMAC TLV contained in the packet, but only once for each
configured key. configured key.
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, only the first for later processing; if multiple PCs are found, only the first
one is processed, the remaining ones are silently ignored. If a one is processed, the remaining ones MUST be silently ignored. If
Challenge Request is encountered, a Challenge Reply is scheduled, a Challenge Request is encountered, a Challenge Reply MUST be
as described in Section 4.3.1.2, and if a Challenge Reply is scheduled, as described in Section 4.3.1.2. If a Challenge Reply
encountered, it is tested for validity as described in is encountered, it is tested for validity as described in
Section 4.3.1.3 and a note is made of the result of the test. Section 4.3.1.3 and a note is made of the result of the test.
o The preparse phase above has yielded two pieces of data: the PC o The preparse phase above has yielded two pieces of data: the PC
and Index from the first PC TLV, and a bit indicating whether the and Index from the first PC TLV, and a bit indicating whether the
packet contains a successful Challenge Reply. If the packet does packet contains a successful Challenge Reply. If the packet does
not contain a PC TLV, the packet is dropped and processing stops not contain a PC TLV, the packet MUST be dropped and processing
at this point. If the packet contains a successful Challenge stops at this point. If the packet contains a successful
Reply, then the PC and Index contained in the PC TLV are stored in Challenge Reply, then the PC and Index contained in the PC TLV
the Neighbour Table entry corresponding to the sender (which may MUST be stored in the Neighbour Table entry corresponding to the
need to be created at this stage), and the packet is accepted. sender (which may need to be created at this stage), and the
packet is accepted.
o Otherwise, if there is no entry in the Neighbour o Otherwise, if there is no entry in the Neighbour
Table corresponding to the sender, or if such an entry exists but Table corresponding to the sender, or if such an entry exists but
contains no Index, or if the Index it contains is different from contains no Index, or if the Index it contains is different from
the Index contained in the PC TLV, then a challenge is sent as the Index contained in the PC TLV, then a challenge MUST be sent
described in Section 4.3.1.1, processing stops at this stage, and as described in Section 4.3.1.1, the packet MUST be dropped, and
the packet is dropped. processing stops at this stage.
o At this stage, the packet contained no successful challenge reply o At this stage, the packet contains no successful challenge reply
and the Index contained in the PC TLV is equal to the Index in the and the Index contained in the PC TLV is equal to the Index in the
Neighbour Table entry corresponding to the sender. The receiver Neighbour Table entry corresponding to the sender. The receiver
compares the received PC with the PC contained in the Neighbour compares the received PC with the PC contained in the Neighbour
Table; if the received PC is smaller or equal than the PC Table; if the received PC is smaller or equal than the PC
contained in the Neighbour Table, the packet is silently dropped contained in the Neighbour Table, the packet MUST be dropped and
and processing stops (no challenge is sent in this case, since the processing stops (no challenge is sent in this case, since the
mismatch might be caused by harmless packet reordering on the mismatch might be caused by harmless packet reordering on the
link). Otherwise, the PC contained in the Neighbour Table entry link). Otherwise, the PC contained in the Neighbour Table entry
is set to the received PC, and the packet is accepted. is set to the received PC, and the packet is accepted.
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
skipping to change at page 10, line 18 skipping to change at page 10, line 24
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
a Challenge Reply TLV. Finally, it might encounter a Challenge Reply a Challenge Reply TLV. Finally, it might encounter a Challenge Reply
TLV, which it will attempt to match with a previously sent Challenge TLV, which it will attempt to match with a previously sent Challenge
Request TLV in order to update the Neighbour Table entry Request TLV in order to update the Neighbour Table entry
corresponding to the sender of the packet. corresponding to the sender of the packet.
4.3.1.1. Sending challenges 4.3.1.1. Sending challenges
When it encounters a mismatched Index during the preparse phase, a When it encounters a mismatched Index during the preparse phase, a
node picks a nonce that it has never used before, for example by node picks a nonce that it has never used with any of the keys
currently configured on the relevant interface, for example by
drawing a sufficiently large random string of bytes or by consulting drawing a sufficiently large random string of bytes or by consulting
a strictly monotonic hardware clock. It stores the nonce in the a strictly monotonic hardware clock. It MUST then store the nonce in
entry of the Neighbour Table of the neighbour (the entry might need the entry of the Neighbour Table associated to the neighbour (the
to be created at this stage), initialises the neighbour's challenge entry might need to be created at this stage), initialise the
expiry timer to 30 seconds, and sends a Challenge Request TLV to the neighbour's challenge expiry timer to 30 seconds, and send a
unicast address corresponding to the neighbour. Challenge Request TLV to the unicast address corresponding to the
neighbour.
A node MAY aggregate a Challenge Request with other TLVs; in other A node MAY aggregate a Challenge Request 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 neighbour, it MAY send the buffered TLVs address of the neighbour, it MAY send the buffered TLVs in the same
in the same packet as the Challenge Request. However, it MUST packet as the Challenge Request. However, it MUST arrange for the
arrange for the Challenge Request to be sent in a timely manner, as Challenge Request to be sent in a timely manner, as any packets
any packets received from that neighbour will be silently ignored received from that neighbour will be silently ignored until the
until the challenge completes. challenge completes.
Since a challenge may be prompted by a replayed packet, a node MUST Since a challenge may be prompted by a packet replayed by an
impose a rate limitation to the challenges it sends; the limit SHOULD attacker, a node MUST impose a rate limitation to the challenges it
default to one challenge request every 300ms, and MAY be sends; the limit SHOULD default to one challenge request every 300ms,
configurable. and MAY be configurable.
4.3.1.2. Replying to challenges 4.3.1.2. Replying to challenges
When it encounters a Challenge Request during the preparse phase, a When it encounters a Challenge Request during the preparse phase, a
node constructs a Challenge Reply TLV by copying the Nonce from the node constructs a Challenge Reply TLV by copying the Nonce from the
Challenge Request into the Challenge Reply. It sends the Challenge Challenge Request into the Challenge Reply. It MUST then send the
Reply to the unicast address from which the Challenge Request was Challenge Reply to the unicast address from which the Challenge
sent. Request was sent.
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.
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
is silently ignored and the challenge has failed. MUST be silently ignored and the challenge has failed.
Otherwise, the node compares the Nonce contained in the Challenge Otherwise, the node compares the Nonce contained in the Challenge
Reply with the Nonce contained in the Neighbour Table entry. If the Reply with the Nonce contained in the Neighbour Table entry. If the
two are equal (they have the same length and content), then the two are equal (they have the same length and content), then the
challenge has succeeded; otherwise, the challenge has failed. challenge has succeeded; otherwise, the challenge has failed.
4.4. Expiring per-neighbour state 4.4. Expiring per-neighbour state
The per-neighbour (Index, PC) pair is maintained in the neighbour The per-neighbour (Index, PC) pair is maintained in the neighbour
table, and is normally discarded when the neighbour table entry table, and is normally discarded when the neighbour table entry
skipping to change at page 12, line 7 skipping to change at page 12, line 19
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 | HMAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 16 to indicate an HMAC TLV. Type Set to 16 to indicate an HMAC TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, in octets, exclusive of the Type
fields. The length of the body depends on the hash and Length fields. The length of the body depends on the
function used. HMAC algorithm being used.
HMAC The body contains the HMAC of the whole packet plus the HMAC The body contains the HMAC of the packet, computed as
pseudo header. 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.
5.2. PC TLV 5.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 17 | Length | PC | Type = 17 | Length | PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index... | | Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 17 to indicate a PC TLV. Type Set to 17 to indicate a PC TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, in octets, exclusive of the Type
fields. and Length fields.
PC The Packet Counter (PC), a 32-bit (4 octet) unsigned PC The Packet Counter (PC), a 32-bit (4 octet) unsigned
integer which is increased with every packet sent over this integer which is increased with every packet sent over this
interface. A fresh index MUST be generated whenever the PC interface. A fresh index (as defined in Section 3.1) MUST
overflows. be generated whenever the PC overflows.
Index The sender's Index, an opaque string of 0 to 32 octets. Index The sender's Index, an opaque string of 0 to 32 octets.
Indices are limited to a size of 32 octets: a node MUST NOT send a Indices are limited to a size of 32 octets: a node MUST NOT send a
TLV with an index of size strictly larger than 32 octets, and a node TLV with an index of size strictly larger than 32 octets, and a node
MAY silently ignore a PC TLV with an index of size strictly larger MAY ignore a PC TLV with an index of size strictly larger than 32
than 32 octets. octets.
5.3. Challenge Request TLV 5.3. Challenge Request 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 = 18 | Length | Nonce... | Type = 18 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 18 to indicate a Challenge Request TLV. Type Set to 18 to indicate a Challenge Request TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, in octets, exclusive of the Type
fields. and Length fields.
Nonce The nonce uniquely identifying the challenge, an opaque Nonce The nonce uniquely identifying the challenge, an opaque
string of 0 to 192 octets. string of 0 to 192 octets.
Nonces are limited to a size of 192 octets: a node MUST NOT send a Nonces are limited to a size of 192 octets: a node MUST NOT send a
Challenge Request TLV with a nonce of size strictly larger than 192 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 octets, and a node MAY ignore a nonce that is of size strictly larger
than 192 octets. than 192 octets.
5.4. Challenge Reply TLV 5.4. Challenge Reply TLV
skipping to change at page 13, line 31 skipping to change at page 13, line 45
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 19 to indicate a Challenge Reply TLV. Type Set to 19 to indicate a Challenge Reply TLV.
Length The length of the body, exclusive of the Type and Length Length The length of the body, in octets, exclusive of the Type
fields. The length of the body is set to the same size as and Length fields.
the challenge request TLV length received.
Nonce A copy of the nonce contained in the corresponding Nonce A copy of the nonce contained in the corresponding
challenge request. challenge request.
6. Security Considerations 6. Security Considerations
This document defines a mechanism that provides basic security This document defines a mechanism that provides basic security
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
skipping to change at page 14, line 26 skipping to change at page 14, line 41
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
causing failed challenges), then it is able to delay the packet by repeatedly causing failed challenges), then it is able to delay the
arbitrary amounts of time, even after the sender has left the packet by arbitrary amounts of time, even after the sender has left
network. the network.
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 state reception of a packet with no correct HMAC creates no local state
whatsoever (Section 4.3). Reception of a replayed packet with whatsoever (Section 4.3). Reception of a replayed packet with
correct hash, on the other hand, causes a challenge to be sent; this correct hash, on the other hand, causes a challenge to be sent; this
is mitigated somewhat by requiring that challenges be rate-limited. is mitigated somewhat by requiring that challenges be rate-limited.
At first sight, sending a challenge requires retaining enough At first sight, sending a challenge requires retaining enough
information to validate the challenge reply. However, the nonce information to validate the challenge reply. However, the nonce
included in a challenge request and echoed in the challenge reply can included in a challenge request and echoed in the challenge reply can
be fairly large (up to 192 octets), which should in principle permit be fairly large (up to 192 octets), which should in principle permit
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.
7. IANA Considerations 7. IANA Considerations
IANA has allocated the following values in the Babel TLV Numbers IANA has allocated the following values in the Babel TLV Types
registry: registry:
+------+-------------------+---------------+ +------+-------------------+---------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+-------------------+---------------+ +------+-------------------+---------------+
| 16 | HMAC | this document | | 16 | HMAC | this document |
| | | | | | | |
| 17 | PC | this document | | 17 | PC | this document |
| | | | | | | |
| 18 | Challenge Request | this document | | 18 | Challenge Request | this document |
skipping to change at page 18, line 5 skipping to change at page 18, line 16
o Use the TLV values allocated by IANA. o Use the TLV values allocated by IANA.
o Fixed an issue with packets that contain a successful challenge o Fixed an issue with packets that contain a successful challenge
reply: they should be accepted before checking the PC value. reply: they should be accepted before checking the PC value.
o Clarified that keys are the exact value of the HMAC hash size, and o Clarified that keys are the exact value of the HMAC hash size, and
not subject to preprocessing; this makes management more not subject to preprocessing; this makes management more
deterministic. deterministic.
B.5. Changes since draft-ietf-babel-hmac-04
Use normative language in more places.
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. 47 change blocks. 
104 lines changed or deleted 115 lines changed or added

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