draft-ietf-babel-hmac-08.txt		draft-ietf-babel-hmac-09.txt
	Network Working Group C. Do		Network Working Group C. Do
	Internet-Draft W. Kolodziejak		Internet-Draft W. Kolodziejak
	Obsoletes: 7298 (if approved) J. Chroboczek		Obsoletes: 7298 (if approved) J. Chroboczek
	Intended status: Standards Track IRIF, University of Paris-Diderot		Intended status: Standards Track IRIF, University of Paris-Diderot
	Expires: January 8, 2020 July 7, 2019		Expires: February 11, 2020 August 10, 2019
	HMAC authentication for the Babel routing protocol		HMAC authentication for the Babel routing protocol
	draft-ietf-babel-hmac-08		draft-ietf-babel-hmac-09
	Abstract		Abstract
	This document describes a cryptographic authentication mechanism for		This document describes a cryptographic authentication mechanism for
	the Babel routing protocol that has provisions for replay avoidance.		the Babel routing protocol that has provisions for replay avoidance.
	This document obsoletes RFC 7298.		This document obsoletes RFC 7298.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 8, 2020.		This Internet-Draft will expire on February 11, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	1.3. Specification of Requirements . . . . . . . . . . . . . . 4		1.3. Specification of Requirements . . . . . . . . . . . . . . 4
	2. Conceptual overview of the protocol . . . . . . . . . . . . . 4		2. Conceptual overview of the protocol . . . . . . . . . . . . . 4
	3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6		3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6		3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6
	3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6		3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
	4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7		4.1. 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 . . . . . . . . . . . . . . 12		4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12
	5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Incremental deployment and key rotation . . . . . . . . . . . 12
	5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13		6.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14		6.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.2. Informational References . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Incremental deployment and key rotation . . . . . . 18		10.2. Informational References . . . . . . . . . . . . . . . . 17
	Appendix B. Changes from previous versions . . . . . . . . . . . 18		Appendix A. Changes from previous versions . . . . . . . . . . . 18
	B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18		A.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18
	B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18		A.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18
	B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19		A.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18
	B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19		A.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19
	B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19		A.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19
	B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19		A.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19
	B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19		A.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19
	B.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 19		A.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	By default, the Babel routing protocol trusts the information		By default, the Babel routing protocol trusts the information
	contained in every UDP datagram that it receives on the Babel port.		contained in every UDP datagram that it receives on the Babel port.
	An attacker can redirect traffic to itself or to a different node in		An attacker can redirect traffic to itself or to a different node in
	the network, causing a variety of potential issues. In particular,		the network, causing a variety of potential issues. In particular,
	an attacker might:		an attacker might:
	o spoof a Babel packet, and redirect traffic by announcing a smaller		o spoof a Babel packet, and redirect traffic by announcing a route
	metric, a larger seqno, or a longer prefix;		with a smaller metric, a larger sequence number, 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.
	Protecting a Babel network is challenging due to the fact that the		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		possible approach, used notably by the Babel over Datagram Transport
	Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use		Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use
	unicast communication for all semantically significant communication,		unicast communication for all semantically significant communication,
	and then use a standard unicast security protocol to protect the		and then use a standard unicast security protocol to protect the
	Babel traffic. In this document, we take the opposite approach: we		Babel traffic. In this document, we take the opposite approach: we
	define a cryptographic extension to the Babel protocol that is able		define a cryptographic extension to the Babel protocol that is able
	to protect both unicast and multicast traffic, and thus requires very		to protect both unicast and multicast traffic, and thus requires very
	few changes to the core protocol.		few changes to the core protocol. This document obsoletes [RFC7298].
	1.1. Applicability		1.1. Applicability
	The protocol defined in this document assumes that all interfaces on		The protocol defined in this document assumes that all interfaces on
	a given link are equally trusted and share a small set of symmetric		a given link are equally trusted and share a small set of symmetric
	keys (usually just one, and two during key rotation). The protocol		keys (usually just one, and two during key rotation). The protocol
	is inapplicable in situations where asymmetric keying is required,		is inapplicable in situations where asymmetric keying is required,
	where the trust relationship is partial, or where large numbers of		where the trust relationship is partial, or where large numbers of
	trusted keys are provisioned on a single link at the same time.		trusted keys are provisioned on a single link at the same time.
	skipping to change at page 3, line 48 ¶		skipping to change at page 4, line 4 ¶
	require persistently monotonic clocks, and it does not require		require persistently monotonic clocks, and it does not require
	persistent storage except for what might be required for storing		persistent storage except for what might be required for storing
	cryptographic keys.		cryptographic keys.
	1.2. Assumptions and security properties		1.2. Assumptions and security properties
	The correctness of the protocol relies on the following assumptions:		The correctness of the protocol relies on the following assumptions:
	o that the Hashed Message Authentication Code (HMAC) being used is		o that the Hashed Message Authentication Code (HMAC) being used is
	invulnerable to pre-image attacks, i.e., that an attacker is		invulnerable to pre-image attacks, i.e., that an attacker is
	unable to generate a packet with a correct HMAC;		unable to generate a packet with a correct HMAC without access to
			the secret key;
	o that a node never generates the same index or nonce twice over the		o that a node never generates the same index or nonce twice over the
	lifetime of a key.		lifetime of a key.
	The first assumption is a property of the HMAC being used. The		The first assumption is a property of the HMAC being used. The
	second assumption can be met either by using a robust random number		second assumption can be met either by using a robust random number
	generator [RFC4086] and sufficiently large indices and nonces, by		generator [RFC4086] and sufficiently large indices and nonces, by
	using a reliable hardware clock, or by rekeying whenever a collision		using a reliable hardware clock, or by rekeying whenever a collision
	becomes likely.		becomes likely.
	If the assumptions above are met, the protocol described in this		If the assumptions above are met, the protocol described in this
	document has the following properties:		document has the following properties:
	o it is invulnerable to spoofing: any packet accepted as authentic		o it is invulnerable to spoofing: any Babel packet accepted as
	is the exact copy of a packet originally sent by an authorised		authentic is the exact copy of a packet originally sent by an
	node;		authorised node;
	o locally to a single node, it is invulnerable to replay: if a node		o locally to a single node, it is invulnerable to replay: if a node
	has previously accepted a given packet, then it will never again		has previously accepted a given packet, then it will never again
	accept a copy of this packet or an earlier packet from the same		accept a copy of this packet or an earlier packet from the same
	sender;		sender;
	o among different nodes, it is only vulnerable to immediate replay:		o among different nodes, it is only vulnerable to immediate replay:
	if a node A has accepted a packet from C as valid, then a node B		if a node A has accepted a packet from C as valid, then a node B
	will only accept a copy of that packet as authentic if B has		will only accept a copy of that packet as authentic if B has
	accepted an older packet from C and B has received no later packet		accepted an older packet from C and B has received no later packet
	from C.		from C.
	While this protocol makes serious efforts to mitigate the effects of		While this protocol makes efforts to mitigate the effects of a denial
	a denial of service attack, it does not fully protect against such		of service attack, it does not fully protect against such attacks.
	attacks.
	1.3. Specification of Requirements		1.3. Specification of Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Conceptual overview of the protocol		2. Conceptual overview of the protocol
	When a node B sends out a Babel packet through an interface that is		When a node B sends out a Babel packet through an interface that is
	configured for HMAC cryptographic protection, it computes one or more		configured for HMAC cryptographic protection, it computes one or more
	HMACs which it appends to the packet. When a node A receives a		HMACs [RFC2104] (one per key) which it appends to the packet. When a
	packet over an interface that requires HMAC cryptographic protection,		node A receives a packet over an interface that requires HMAC
	it independently computes a set of HMACs and compares them to the		cryptographic protection, it independently computes a set of HMACs
	HMACs appended to the packet; if there is no match, the packet is		and compares them to the HMACs appended to the packet; if there is no
	discarded.		match, the packet is discarded.
	In order to protect against replay, B maintains a per-interface		In order to protect against replay, B maintains a per-interface
	32-bit integer known as the "packet counter" (PC). Whenever B sends		32-bit integer known as the "packet counter" (PC). Whenever B sends
	a packet through the interface, it embeds the current value of the PC		a packet through the interface, it embeds the current value of the PC
	within the region of the packet that is protected by the HMACs and		within the region of the packet that is protected by the 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 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	3. Data Structures		3. Data Structures
	Every Babel node maintains a set of conceptual data structures		Every Babel node maintains a set of conceptual data structures
	described in Section 3.2 of [RFC6126bis]. This protocol extends		described in Section 3.2 of [RFC6126bis]. This protocol extends
	these data structures as follows.		these data structures as follows.
	3.1. The Interface Table		3.1. The Interface Table
	Every Babel node maintains an interface table, as described in		Every Babel node maintains an interface table, as described in
	Section 3.2.3 [RFC6126bis]. Implementations of this protocol MUST		Section 3.2.3 of [RFC6126bis]. Implementations of this protocol MUST
	allow each interface to be provisioned with a set of one or more HMAC		allow each interface to be provisioned with a set of one or more 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 Section 5),
	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 authenticated.
	This protocol extends each entry in this table that is associated		This protocol extends each entry in this table that is associated
	with an interface on which HMAC authentication has been configured		with an interface on which 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 block 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 arbitrary string of 0 to 32		o a pair (Index, PC), where Index is an arbitrary string of 0 to 32
	octets, and PC is a 32-bit (4-octet) integer.		octets, and PC is a 32-bit (4-octet) integer.
	We say that an index is fresh when it has never been used before with		We say that an index is fresh when it has never been used before with
	any of the keys currently configured on the interface. The Index		any of the keys currently configured on the interface. The Index
	field is initialised to a fresh index, for example by drawing a		field is initialised to a fresh index, for example by drawing a
	random string of sufficient length, and the PC is initialised to an		random string of sufficient length, and the PC is initialised to an
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	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 the HMAC of a Babel packet 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 is carried over
	IPv6, the pseudo-header has the following format:		IPv6, the pseudo-header has the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Src address +		+ Src address +
	| |		| |
	skipping to change at page 7, line 41 ¶		skipping to change at page 7, line 41 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| |		| |
	+ +		+ +
	| Dest address |		| Dest address |
	+ +		+ +
	| |		| |
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Dest port |		| | Dest port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	If the packet was carried over IPv4, the pseudo-header has the		If the packet is carried over IPv4, the pseudo-header has the
	following format:		following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Src address |		| Src address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Src port | Dest address |		| Src port | Dest address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Dest port |		| | Dest port |
	skipping to change at page 8, line 14 ¶		skipping to change at page 8, line 14 ¶
	Fields :		Fields :
	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 Babel
	including the packet header but excluding the packet trailer (from		packet including the packet header but excluding the packet trailer
	octet 0 inclusive up to (Body Length + 4) exclusive) and computes an		(from octet 0 inclusive up to (Body Length + 4) exclusive) and
	HMAC with one of the implemented hash algorithms. Every		computes an 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 might delay actually sending TLVs by a small amount, in		A Babel node might delay actually sending TLVs by a small amount, in
	order to aggregate multiple TLVs in a single packet up to the		order to aggregate multiple TLVs in a single packet up to the
	interface MTU (Section 4 of [RFC6126bis]). For an interface on which		interface MTU (Section 4 of [RFC6126bis]). For an interface on which
	HMAC protection is configured, the TLV aggregation logic MUST take		HMAC protection is configured, the TLV aggregation logic MUST take
	skipping to change at page 10, line 24 ¶		skipping to change at page 10, line 24 ¶
	is set to the received PC, and the packet is accepted.		is set to the received PC, and the packet is accepted.
	In the algorithm described above, challenge requests are processed		In the algorithm described above, challenge requests are processed
	and challenges are sent before the PC/Index pair is verified against		and challenges are sent before the PC/Index pair is verified against
	the neighbour table. This simplifies the implementation somewhat		the neighbour table. This simplifies the implementation somewhat
	(the node may simply schedule outgoing requests as it walks the		(the node may simply schedule outgoing requests as it walks the
	packet during the preparse phase), but relies on the rate-limiting		packet during the preparse phase), but relies on the rate-limiting
	described in Section 4.3.1.1 to avoid sending too many challenges in		described in Section 4.3.1.1 to avoid sending too many challenges in
	response to replayed packets. As an optimisation, a node MAY ignore		response to replayed packets. As an optimisation, a node MAY ignore
	all challenge requests contained in a packet except the last one, and		all challenge requests contained in a packet except the last one, and
	it MAY ignore a challenge request in the case where it it contained		it MAY ignore a challenge request in the case where it is contained
	in a packet with an Index that matches the one in the Neighbour		in a packet with an Index that matches the one in the Neighbour
	Table and a PC that is smaller or equal to the one contained in the		Table and a PC that is smaller or equal to the one contained in the
	Neighbour Table. Since it is still possible to replay a packet with		Neighbour Table. Since it is still possible to replay a packet with
	an obsolete Index, the rate-limiting described in Section 4.3.1.1 is		an obsolete Index, the rate-limiting described in Section 4.3.1.1 is
	required even if this optimisation is implemented.		required even if this optimisation is implemented.
	The same is true of challenge replies. However, since validating a		The same is true of challenge replies. However, since validating a
	challenge reply is extremely cheap (it's just a bitwise comparison of		challenge reply is extremely cheap (it's just a bitwise comparison of
	two strings of octets), a similar optimisation for challenge replies		two strings of octets), a similar optimisation for challenge replies
	is not worthwile.		is not worthwile.
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 26 ¶
	neighbour.		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 neighbour, it MAY send the buffered TLVs in the same		address of the neighbour, it MAY send the buffered TLVs in the same
	packet as the Challenge Request. However, it MUST arrange for the		packet as the Challenge Request. However, it MUST arrange for the
	Challenge Request to be sent in a timely manner, as any packets		Challenge Request to be sent in a timely manner, as any packets
	received from that neighbour will be silently ignored until the		received from that neighbour will be silently ignored until the
	challenge completes.		challenge completes.
	Since a challenge may be prompted by a packet replayed by an		A node MUST impose a rate limitation to the challenges it sends; the
	attacker, a node MUST impose a rate limitation to the challenges it		limit SHOULD default to one challenge request every 300ms, and MAY be
	sends; the limit SHOULD default to one challenge request every 300ms,		configurable. This rate limiting serves two purposes. First, since
	and MAY be configurable.		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 send. Second, it limits the number of challenges
			sent when there are multiple packets in flight from a single
			neighbour.
	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 MUST then send the		Challenge Request into the Challenge Reply. It MUST then send the
	Challenge Reply to the unicast address from which the Challenge		Challenge Reply to the unicast address from which the Challenge
	Request was 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
	skipping to change at page 12, line 36 ¶		skipping to change at page 12, line 36 ¶
	(Index, PC) pair from being discarded for unbounded periods of time.		(Index, PC) pair from being discarded for unbounded periods of time.
	A possible implementation strategy for implementations that use a		A possible implementation strategy for implementations that use a
	Hello history (Appendix A of [RFC6126bis]) is to discard the (Index,		Hello history (Appendix A of [RFC6126bis]) is to discard the (Index,
	PC) pair whenever the Hello history becomes empty. Another		PC) pair whenever the Hello history becomes empty. Another
	implementation strategy is to use a timer that is reset whenever a		implementation strategy is to use a timer that is reset whenever a
	packet is accepted, and to discard the (Index, PC) pair whenever the		packet is accepted, and to discard the (Index, PC) pair whenever the
	timer expires. If the latter strategy is being used, the timer		timer expires. If the latter strategy is being used, the timer
	SHOULD default to a value of 5 min, and MAY be configurable.		SHOULD default to a value of 5 min, and MAY be configurable.
	5. Packet Format		5. Incremental deployment and key rotation
	5.1. HMAC TLV		In order to perform incremental deployment, the nodes in the network
			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 configured to send authenticated packets, nodes are
			reconfigured to reject unauthenticated packets.
			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 packets, and packets are accepted if they are properly signed by
			either of the keys. At that point, the old key is removed.
			In order to support the procedures described above, implementations
			of this protocol SHOULD support an interface configuration in which
			packets are sent authenticated but received packets are accepted
			without verification, and they SHOULD allow changing the set of keys
			associated with an interface without a restart.
			6. Packet Format
			6.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 = 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.
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 31 ¶
	Length The length of the body, in octets, exclusive of the Type		Length The length of the body, in octets, exclusive of the Type
	and Length fields. The length of the body depends on the		and Length fields. The length of the body depends on the
	HMAC algorithm being used.		HMAC algorithm being used.
	HMAC The body contains the HMAC of the packet, computed as		HMAC The body contains the HMAC of the packet, computed as
	described in Section 4.1.		described in Section 4.1.
	This TLV is allowed in the packet trailer (see Section 4.2 of		This TLV is allowed in the packet trailer (see Section 4.2 of
	[RFC6126bis]), and MUST be ignored if it is found in the packet body.		[RFC6126bis]), and MUST be ignored if it is found in the packet body.
	5.2. PC TLV		6.2. PC TLV
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 17 | Length | PC |		| Type = 17 | Length | PC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Index...		| | Index...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	Fields :		Fields :
	skipping to change at page 13, line 42 ¶		skipping to change at page 14, line 14 ¶
	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 ignore a PC TLV with an index of length strictly larger than 32		MAY 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		octets. Indices of length 0 are valid: if a node has reliable stable
	storage and the packet counter never overflows, then only one index		storage and the packet counter never overflows, then only one index
	is necessary, and the value of length 0 is the canonical choice.		is necessary, and the value of length 0 is the canonical choice.
	5.3. Challenge Request TLV		6.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.
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 37 ¶
	and Length 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. Nonces of length 0 are valid: if a node has		than 192 octets. Nonces of length 0 are valid: if a node has
	reliable stable storage, then it may use a sequential counter for		reliable stable storage, then it may use a sequential counter for
	generating nonces which get encoded in the minumum number of octets		generating nonces which get encoded in the minimum number of octets
	required; the value 0 is then encoded as the string of length 0.		required; the value 0 is then encoded as the string of length 0.
	5.4. Challenge Reply TLV		6.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 = 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, in octets, exclusive of the Type		Length The length of the body, in octets, exclusive of the Type
	and Length fields.		and Length fields.
	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		7. 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
	supports symmetric keying, and it only allows for the use of a small		supports symmetric keying, and it only allows for the use of a small
	number of symmetric keys on every link. Deployments that need more		number of symmetric keys on every link. Deployments that need more
	features, e.g., confidentiality or asymmetric keying, should use a		features, e.g., confidentiality or asymmetric keying, should use a
	more featureful security mechanism such as the one described in		more featureful security mechanism such as the one described in
	[I-D.ietf-babel-dtls].		[I-D.ietf-babel-dtls].
	skipping to change at page 15, line 32 ¶		skipping to change at page 16, line 5 ¶
	will be accepted as long as the corresponding (Index, PC) pair is		will be accepted as long as the corresponding (Index, PC) pair is
	present at the receiver. If the attacker is able to cause the		present at the receiver. If the attacker is able to cause the
	(Index, PC) pair to persist for arbitrary amounts of time (e.g., by		(Index, PC) pair to persist for arbitrary amounts of time (e.g., by
	repeatedly causing failed challenges), then it is able to delay the		repeatedly causing failed challenges), then it is able to delay the
	packet by arbitrary amounts of time, even after the sender has left		packet by arbitrary amounts of time, even after the sender has left
	the network.		the network.
	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 Babel
	whatsoever (Section 4.3). Reception of a replayed packet with		state (Section 4.3). Reception of a replayed packet with correct
	correct hash, on the other hand, causes a challenge to be sent; this		hash, on the other hand, causes a challenge to be sent; this is
	is mitigated somewhat by requiring that challenges be rate-limited		mitigated somewhat by requiring that challenges be rate-limited
	(Section 4.3.1.1).		(Section 4.3.1.1).
	Receiving a replayed packet with an obsolete index causes an entry to		Receiving a replayed packet with an obsolete index causes an entry to
	be created in the Neighbour Table, which, at first sight, makes the		be created in the Neighbour Table, which, at first sight, makes the
	protocol susceptible to resource exhaustion attacks (similarly to the		protocol susceptible to resource exhaustion attacks (similarly to the
	familiar "TCP SYN Flooding" attack [RFC4987]). However, the HMAC		familiar "TCP SYN Flooding" attack [RFC4987]). However, the HMAC
	computation includes the sender address (Section 4.1), and thus the		computation includes the sender address (Section 4.1), and thus the
	amount of storage that an attacker can force a node to consume is		amount of storage that an attacker can force a node to consume is
	limited by the number of distinct source addresses used with a single		limited by the number of distinct source addresses used with a single
	HMAC key (see also Section 4 of [RFC6126bis], which mandates that the		HMAC key (see also Section 4 of [RFC6126bis], which mandates that the
	source address is a link-local IPv6 address or a local IPv4 address).		source address is a link-local IPv6 address or a local IPv4 address).
	In order to make this kind of resource exhaustion attacks less		In order to make this kind of resource exhaustion attacks less
	effective, implementations may use a separate table of uncompleted		effective, implementations may use a separate table of uncompleted
	challenges that is separate from the Neighbour Table used by the core		challenges that is separate from the Neighbour Table used by the core
	protocol (the data structures described in Section 3.2 of		protocol (the data structures described in Section 3.2 of
			[RFC6126bis] are conceptual, and any data structure that yields the
	[RFC6126bis] are conceptual, any data structure that yields the same		same result may be used). Implementers might also consider using the
	result may be used). Implementers might also consider using the fact		fact that the nonces included in challenge requests and responses can
	that the nonces included in challenge requests and responses can be		be fairly large (up to 192 octets), which should in principle allow
	fairly large (up to 192 octets), which should in principle allow
	encoding the per-challenge state as a secure "cookie" within the		encoding the per-challenge state as a secure "cookie" within the
	nonce itself.		nonce itself.
	7. IANA Considerations		8. IANA Considerations
	IANA has allocated the following values in the Babel TLV Types		IANA has allocated the following values in the Babel TLV Types
	registry:		registry:
	+------+-------------------+---------------+		+------+-------------------+---------------+
	| Type | Name | Reference |		| Type | Name | Reference |
	+------+-------------------+---------------+		+------+-------------------+---------------+
	| 16 | HMAC | this document |		| 16 | HMAC | this document |
	| | | |		| | | |
	| 17 | PC | this document |		| 17 | PC | this document |
	| | | |		| | | |
	| 18 | Challenge Request | this document |		| 18 | Challenge Request | this document |
	| | | |		| | | |
	| 19 | Challenge Reply | this document |		| 19 | Challenge Reply | this document |
	+------+-------------------+---------------+		+------+-------------------+---------------+
	8. Acknowledgments		9. Acknowledgments
	The protocol described in this document is based on the original HMAC		The protocol described in this document is based on the original HMAC
	protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-		protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-
	header was suggested by David Schinazi. The use of an index to avoid		header was suggested by David Schinazi. The use of an index to avoid
	replay was suggested by Markus Stenberg. The authors are also		replay was suggested by Markus Stenberg. The authors are also
	indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn,		indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn,
	Dave Taht and Martin Vigoureux.		Dave Taht and Martin Vigoureux.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	<https://www.rfc-editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997.		DOI 10.17487/RFC2119, March 1997.
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 46 ¶
	[RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2		[RFC7693] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2
	Cryptographic Hash and Message Authentication Code (MAC)",		Cryptographic Hash and Message Authentication Code (MAC)",
	RFC 7693, DOI 10.17487/RFC7693, November 2015,		RFC 7693, DOI 10.17487/RFC7693, November 2015,
	<https://www.rfc-editor.org/info/rfc7693>.		<https://www.rfc-editor.org/info/rfc7693>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017.		May 2017.
	9.2. Informational References		10.2. Informational References
	[I-D.ietf-babel-dtls]		[I-D.ietf-babel-dtls]
	Decimo, A., Schinazi, D., and J. Chroboczek, "Babel		Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
	Routing Protocol over Datagram Transport Layer Security",		Routing Protocol over Datagram Transport Layer Security",
	draft-ietf-babel-dtls-07 (work in progress), July 2019.		draft-ietf-babel-dtls-07 (work in progress), July 2019.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<http://www.rfc-editor.org/info/rfc4086>.		<http://www.rfc-editor.org/info/rfc4086>.
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 24 ¶
	[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues		[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
	with Existing Cryptographic Protection Methods for Routing		with Existing Cryptographic Protection Methods for Routing
	Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,		Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
	<https://www.rfc-editor.org/info/rfc6039>.		<https://www.rfc-editor.org/info/rfc6039>.
	[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code		[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
	(HMAC) Cryptographic Authentication", RFC 7298,		(HMAC) Cryptographic Authentication", RFC 7298,
	DOI 10.17487/RFC7298, July 2014,		DOI 10.17487/RFC7298, July 2014,
	<https://www.rfc-editor.org/info/rfc7298>.		<https://www.rfc-editor.org/info/rfc7298>.
	Appendix A. Incremental deployment and key rotation		Appendix A. Changes from previous versions
	This protocol supports incremental deployment (transitioning from an
	insecure network to a secured network with no service interruption)
	and key rotation (transitioning from a set of keys to a different set
	of keys).
	In order to perform incremental deployment, the nodes in the network
	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 configured to send authenticated packets, nodes are
	reconfigured to reject unauthenticated packets.
	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 packets, and packets are accepted if they are properly signed by
	either of the keys. At that point, the old key is removed.
	In order to support incremental deployment and key rotation,
	implementations SHOULD support an interface configuration in which
	they send authenticated packets but accept all packets, and SHOULD
	allow changing the set of keys associated with an interface without a
	restart.
	Appendix B. Changes from previous versions
	[RFC Editor: please remove this section before publication.]		[RFC Editor: please remove this section before publication.]
	B.1. Changes since draft-ietf-babel-hmac-00		A.1. Changes since draft-ietf-babel-hmac-00
	o Changed the title.		o Changed the title.
	o Removed the appendix about the packet trailer, this is now in		o Removed the appendix about the packet trailer, this is now in
	rfc6126bis.		rfc6126bis.
	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.
	o Limited the size of nonces and indices.		o Limited the size of nonces and indices.
	B.2. Changes since draft-ietf-babel-hmac-01		A.2. Changes since draft-ietf-babel-hmac-01
	o Made BLAKE2s a recommended HMAC algorithm.		o Made BLAKE2s a recommended HMAC algorithm.
	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		A.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		A.4. Changes since draft-ietf-babel-hmac-03
	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		A.5. Changes since draft-ietf-babel-hmac-04
	o Use normative language in more places.		o Use normative language in more places.
	B.6. Changes since draft-ietf-babel-hmac-05		A.6. Changes since draft-ietf-babel-hmac-05
	o Do not update RFC 6126bis.		o Do not update RFC 6126bis.
	o Clarify that indices and nonces of length 0 are valid.		o Clarify that indices and nonces of length 0 are valid.
	o Clarify that multiple PC TLVs in a single packet are not allowed.		o Clarify that multiple PC TLVs in a single packet are not allowed.
	o Allow discarding challenge requests when they carry an old PC.		o Allow discarding challenge requests when they carry an old PC.
	B.7. Changes since draft-ietf-babel-hmac-06		A.7. Changes since draft-ietf-babel-hmac-06
	o Do not update RFC 6126bis, for real this time.		o Do not update RFC 6126bis, for real this time.
	B.8. Changes since draft-ietf-babel-hmac-07		A.8. Changes since draft-ietf-babel-hmac-07
	o Clarify that a Neighbour Table entry may be created just after the		o Clarify that a Neighbour Table entry may be created just after the
	HMAC has been computed.		HMAC has been computed.
	o Clarify that a Neighbour Table entry already exists when a		o Clarify that a Neighbour Table entry already exists when a
	successful Challenge Reply has been received.		successful Challenge Reply has been received.
	o Expand the Security Considerations section with information about		o Expand the Security Considerations section with information about
	resource exhaustion attacks.		resource exhaustion attacks.
			A.8.1. Changes since draft-ietf-babel-hmac-08
			o Fix the size of the key to be equal to the block size, not the
			hash size.
			o Moved the information about incremental deployment to the body.
			o Clarified the double purpose of rate limitation.
			o Editorial changes.
	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. 43 change blocks.
	108 lines changed or deleted		118 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/