draft-ietf-babel-hmac-03.txt   draft-ietf-babel-hmac-04.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 December 26, 2018 Intended status: Standards Track March 9, 2019
Expires: June 29, 2019 Expires: September 10, 2019
HMAC authentication for the Babel routing protocol HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-03 draft-ietf-babel-hmac-04
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 June 29, 2019. This Internet-Draft will expire on September 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6
3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 10 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 11
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 12
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informational References . . . . . . . . . . . . . . . . 15 9.2. Informational References . . . . . . . . . . . . . . . . 16
Appendix A. Incremental deployment and key rotation . . . . . . 15 Appendix A. Incremental deployment and key rotation . . . . . . 16
Appendix B. Changes from previous versions . . . . . . . . . . . 16 Appendix B. Changes from previous versions . . . . . . . . . . . 17
B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17
B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 16 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17
B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 16 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 17
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 packet it receives on the Babel port. An
attacker can redirect traffic to itself or to a different node in the attacker can redirect traffic to itself or to a different node in the
network, causing a variety of potential issues. In particular, an network, causing a variety of potential issues. In particular, an
attacker might: 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
skipping to change at page 4, line 40 skipping to change at page 4, line 40
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Conceptual overview of the protocol 2. Conceptual overview of the protocol
When a node B sends out a Babel packet through an interface that is When a node B sends out a Babel packet through an interface that is
configured for 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 cryptographic protection, it packet over an interface that requires HMAC cryptographic protection,
independently computes a set of HMACs and compares them to the HMACs it independently computes a set of HMACs and compares them to the
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 32-bit
integer known as the "packet counter" (PC). Whenever B sends a integer known as the "packet counter" (PC). Whenever B sends a
packet through the interface, it embeds the current value of the PC 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.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
its PC has been reset, it picks an index that it has never used its 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 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
described in [RFC6126bis] Section 3.2. This protocol extends 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. This protocol extends the entries in [RFC6126bis] Section 3.2.3. Implementations of this protocol MUST
this table with a set of HMAC keys, and a pair (Index, PC), where allow each interface to be provisioned with a set of one or more HMAC
Index is an arbitrary string of bytes and PC is a 32-bit integer. keys and the associated HMAC algorithms (see Section 4.1). In order
The Index is initialised to a value that has never been used before to allow incremental deployment of this protocol (see Appendix A),
(e.g., by choosing a random string of sufficient length). implementations SHOULD allow an interface to be configured in a mode
in which it participates in the HMAC authentication protocol but
accepts packets that are not authentified.
This protocol extends each entry in this table that is associated
with an interface on which HMAC authentication has been configured
with two new pieces of data:
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
associated HMAC algorithm (i.e., the key is not subject to the
preprocessing described in Section 2 of [RFC2104]);
o a pair (Index, PC), where Index is an arbtrary string of 0 to 32
octets, and PC is a 32-bit (4-octet) integer.
The Index and PC are initialised to arbitrary values chosen so as to
ensure that a given (Index, PC) pair is never reused. Typically, the
initial Index will be chosen as a random string of sufficient length,
and the initial PC will be set to 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 the entries in [RFC6126bis] Section 3.2.4. This protocol extends each entry in this
this table with a pair (Index, PC), as well as a nonce (an arbitrary table with two new pieces of data:
string of bytes) and a challenge expiry timer. The Index and PC are
initially undefined, and are managed as described in Section 4.3. o a pair (Index, PC), where Index is a string of 0 to 32 octets, and
The Nonce and expiry timer are initially undefined and used as PC is a 32-bit (4-octet) integer;
described in Section 4.3.1.1.
o a Nonce, an arbitrary string of 0 to 192 octets, and an associated
challenge expiry timer.
The Index and PC are initially undefined, and are managed as
described in Section 4.3. The Nonce and expiry timer are initially
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 an HMAC 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:
skipping to change at page 8, line 43 skipping to change at page 9, line 28
encountered, it is tested for validity as described in 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 is dropped and processing stops
at this point. If the packet contains a successful Challenge at this point. If the packet contains a successful Challenge
Reply, then the PC and Index contained in the PC TLV are stored in Reply, then the PC and Index contained in the PC TLV are stored in
the Neighbour Table entry corresponding to the sender (which may the Neighbour Table entry corresponding to the sender (which may
need to be created at this stage). need to be created at this stage), and the packet is accepted.
o If there is no entry in the Neighbour Table corresponding to 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, then a challenge is sent as described in Section 4.3.1.1,
processing stops at this stage, and the packet is dropped.
o At this stage, the Index contained in the PC TLV is equal to the o Otherwise, if there is no entry in the Neighbour
Index in the Neighbour Table entry corresponding to the sender. Table corresponding to 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, then a challenge is sent as
described in Section 4.3.1.1, processing stops at this stage, and
the packet is dropped.
The receiver compares the received PC with the PC contained in the o At this stage, the packet contained no successful challenge reply
Neighbour Table; if the received PC smaller or equal than the PC and the Index contained in the PC TLV is equal to the Index in the
Neighbour Table entry corresponding to the sender. The receiver
compares the 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 is silently dropped contained in the Neighbour Table, the packet is silently dropped
and processing stops (no challenge is sent in this case, since the and 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.
skipping to change at page 9, line 47 skipping to change at page 10, line 35
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 sender of the neighbour, it MAY send the buffered TLVs
in the same packet as the Challenge Request. However, it MUST in the same packet as the Challenge Request. However, it MUST
arrange for the Challenge Request to be sent in a timely manner, as arrange for the Challenge Request to be sent in a timely manner, as
any packets received from that neighbour will be silently ignored any packets received from that neighbour will be silently ignored
until the challenge completes. until the challenge completes.
Since a challenge may be prompted by a replayed packet, a node MUST Since a challenge may be prompted by a replayed packet, a node MUST
impose a rate limitation to the challenges it sends; a limit of one impose a rate limitation to the challenges it sends; the limit SHOULD
challenge every 300ms for each neighbour is suggested. default to one challenge request every 300ms, 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 sends the Challenge
Reply to the unicast address of the sender of the Challenge Reply. Reply to the unicast address from which the Challenge 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.
skipping to change at page 10, line 46 skipping to change at page 11, line 32
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
expires. Implementations MUST ensure that an (Index, PC) pair is expires. Implementations MUST ensure that an (Index, PC) pair is
discarded within a finite time since the last time a packet has been discarded within a finite time since the last time a packet has been
accepted. In particular, unsuccessful challenges MUST NOT prevent an accepted. In particular, unsuccessful challenges MUST NOT prevent an
(Index, PC) pair from being discarded for unbounded periods of time. (Index, PC) pair from being discarded for unbounded periods of time.
Implementations that use a Hello history (Appendix A of [RFC6126bis]) A possible implementation strategy for implementations that use a
may discard the (Index, PC) pair whenever the Hello history becomes Hello history (Appendix A of [RFC6126bis]) is to discard the (Index,
empty. Other impementations may use a timer that is reset whenever a PC) pair whenever the Hello history becomes empty. Another
packet is accepted, and discard the (Index, PC) pair whenever the implementation strategy is to use a timer that is reset whenever a
timer expires (a timeout of 5 min is suggested). packet is accepted, and to discard the (Index, PC) pair whenever the
timer expires. If the latter strategy is being used, the timer
SHOULD default to a value of 5 min, and MAY be configurable.
5. Packet Format 5. Packet Format
5.1. HMAC TLV 5.1. HMAC 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 | Length | HMAC... | Type = 16 | Length | HMAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD 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, exclusive of the Type and Length
fields. The length of the body depends on the hash fields. The length of the body depends on the hash
function used. function used.
HMAC The body contains the HMAC of the whole packet plus the HMAC The body contains the HMAC of the whole packet plus the
pseudo header. pseudo header.
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 | Length | PC | Type = 17 | Length | PC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index... | Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD 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, exclusive of the Type and Length
fields. 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 MUST be generated whenever the PC
overflows. 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.
skipping to change at page 12, line 15 skipping to change at page 12, line 51
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 silently ignore a PC TLV with an index of size strictly larger
than 32 octets. than 32 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 | Length | Nonce... | Type = 18 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD 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, exclusive of the Type and Length
fields. 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
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 | Length | Nonce... | Type = 19 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD 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, exclusive of the Type and Length
fields. The length of the body is set to the same size as fields. The length of the body is set to the same size as
the challenge request TLV length received. 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
skipping to change at page 14, line 14 skipping to change at page 14, line 47
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 is requested to allocate the following values in the Babel TLV IANA has allocated the following values in the Babel TLV Numbers
Numbers registry: registry:
+------+-------------------+---------------+ +------+-------------------+---------------+
| Type | Name | Reference | | Type | Name | Reference |
+------+-------------------+---------------+ +------+-------------------+---------------+
| TBD | HMAC | this document | | 16 | HMAC | this document |
| | | | | | | |
| TBD | PC | this document | | 17 | PC | this document |
| | | | | | | |
| TBD | Challenge Request | this document | | 18 | Challenge Request | this document |
| | | | | | | |
| TBD | Challenge Reply | this document | | 19 | Challenge Reply | this document |
+------+-------------------+---------------+ +------+-------------------+---------------+
8. Acknowledgments 8. Acknowledgments
The protocol described in this document is based on the original HMAC The protocol described in this document is based on the original HMAC
protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-
header was suggested by David Schinazi. The use of an index to avoid header was suggested by David Schinazi. The use of an index to avoid
replay was suggested by Markus Stenberg. The authors are also replay was suggested by Markus Stenberg. The authors are also
indebted to Toke Hoiland-Jorgensen, Florian Horn, and Dave Taht. indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn,
and Dave Taht.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 16, line 24 skipping to change at page 17, line 9
either of the keys. At that point, the old key is removed. either of the keys. At that point, the old key is removed.
In order to support incremental deployment and key rotation, In order to support incremental deployment and key rotation,
implementations SHOULD support an interface configuration in which implementations SHOULD support an interface configuration in which
they send authenticated packets but accept all packets, and SHOULD they send authenticated packets but accept all packets, and SHOULD
allow changing the set of keys associated with an interface without a allow changing the set of keys associated with an interface without a
restart. restart.
Appendix B. Changes from previous versions Appendix B. Changes from previous versions
[RFC Editor: please remove this section before publication.]
B.1. Changes since draft-ietf-babel-hmac-00 B.1. Changes since draft-ietf-babel-hmac-00
o Changed the title. o Changed the title.
o Removed the appendix about the packet trailer, this is now in o Removed the appendix about the packet trailer, this is now in
rfc6126bis. rfc6126bis.
o Removed the appendix with implicit indices. o Removed the appendix with implicit indices.
o Clarified the definitions of acronyms. o Clarified the definitions of acronyms.
skipping to change at page 17, line 5 skipping to change at page 17, line 38
o Added requirement to expire per-neighbour crypto state. o Added requirement to expire per-neighbour crypto state.
B.3. Changes since draft-ietf-babel-hmac-02 B.3. Changes since draft-ietf-babel-hmac-02
o Clarified that PCs are 32-bit unsigned integers. o Clarified that PCs are 32-bit unsigned integers.
o Clarified that indices and nonces are of arbitrary size. o Clarified that indices and nonces are of arbitrary size.
o Added reference to RFC 4086. o Added reference to RFC 4086.
B.4. Changes since draft-ietf-babel-hmac-03
o Use the TLV values allocated by IANA.
o Fixed an issue with packets that contain a successful challenge
reply: they should be accepted before checking the PC value.
o Clarified that keys are the exact value of the HMAC hash size, and
not subject to preprocessing; this makes management more
deterministic.
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. 38 change blocks. 
72 lines changed or deleted 120 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/