draft-ietf-babel-hmac-07.txt		draft-ietf-babel-hmac-08.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: December 22, 2019 June 20, 2019		Expires: January 8, 2020 July 7, 2019
	HMAC authentication for the Babel routing protocol		HMAC authentication for the Babel routing protocol
	draft-ietf-babel-hmac-07		draft-ietf-babel-hmac-08
	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 December 22, 2019.		This Internet-Draft will expire on January 8, 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 26 ¶		skipping to change at page 2, line 26 ¶
	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. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13		5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13
	5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14		5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	9.2. Informational References . . . . . . . . . . . . . . . . 17		9.2. Informational References . . . . . . . . . . . . . . . . 17
	Appendix A. Incremental deployment and key rotation . . . . . . 17		Appendix A. Incremental deployment and key rotation . . . . . . 18
	Appendix B. Changes from previous versions . . . . . . . . . . . 18		Appendix B. Changes from previous versions . . . . . . . . . . . 18
	B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18		B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18
	B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18		B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18
	B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18		B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 19
	B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18		B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 19
	B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19		B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19
	B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19		B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19
	B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19		B.7. Changes since draft-ietf-babel-hmac-06 . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		B.8. Changes since draft-ietf-babel-hmac-07 . . . . . . . . . 19
			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 smaller
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 19 ¶
	HMAC of the packet. It then compares every generated HMAC against		HMAC of the packet. It then compares every generated HMAC against
	every HMAC included in the packet; if there is at least one match,		every HMAC included in the packet; if there is at least one match,
	the packet passes the HMAC test; if there is none, the packet MUST		the packet passes the HMAC test; if there is none, the packet MUST
	be silently dropped and processing stops at this point. In order		be silently dropped and processing stops at this point. In order
	to avoid memory exhaustion attacks, an entry in the Neighbour		to avoid memory exhaustion attacks, an entry in the Neighbour
	Table MUST NOT be created before the HMAC test has passed		Table MUST NOT be created before the HMAC test has passed
	successfully. The HMAC of the packet MUST NOT be computed for		successfully. The HMAC of the packet MUST NOT be computed 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 If an entry for the sender does not exist in the Neighbour Table,
			it MAY be created at this point (or, alternatively, its creation
			can be delayed until a challenge needs to be sent, see below);
	o The packet body is then parsed a first time. During this		o The packet body is then parsed a first time. During this
	"preparse" phase, the packet body is traversed and all TLVs are		"preparse" phase, the packet body is traversed and all TLVs are
	ignored except PC TLVs, Challenge Requests and Challenge Replies.		ignored except PC TLVs, Challenge Requests and Challenge Replies.
	When a PC TLV is encountered, the enclosed PC and Index are saved		When a PC TLV is encountered, the enclosed PC and Index are saved
	for later processing; if multiple PCs are found (which should not		for later processing; if multiple PCs are found (which should not
	happen, see Section 4.2 above), only the first one is processed,		happen, see Section 4.2 above), only the first one is processed,
	the remaining ones MUST be silently ignored. If a Challenge		the remaining ones MUST be silently ignored. If a Challenge
	Request is encountered, a Challenge Reply MUST be scheduled, as		Request is encountered, a Challenge Reply MUST be scheduled, as
	described in Section 4.3.1.2. If a Challenge Reply is		described in Section 4.3.1.2. If a Challenge Reply is
	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 MUST be dropped and processing		not contain a PC TLV, the packet MUST be dropped and processing
	stops at this point. If the packet contains a successful		stops at this point. If the packet contains a successful
	Challenge Reply, then the PC and Index contained in the PC TLV		Challenge Reply, then the PC and Index contained in the PC TLV
	MUST be stored in the Neighbour Table entry corresponding to the		MUST be stored in the Neighbour Table entry corresponding to the
	sender (which may need to be created at this stage), and the		sender (which already exists in this case), and the packet is
	packet is accepted.		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 MUST be sent		the Index contained in the PC TLV, then a challenge MUST be sent
	as described in Section 4.3.1.1, the packet MUST be dropped, and		as described in Section 4.3.1.1, the packet MUST be dropped, and
	processing stops at this stage.		processing stops at this stage.
	o At this stage, the packet contains 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
	skipping to change at page 15, line 28 ¶		skipping to change at page 15, line 35 ¶
	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 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
			(Section 4.3.1.1).
	At first sight, sending a challenge requires retaining enough		Receiving a replayed packet with an obsolete index causes an entry to
	information to validate the challenge reply. However, the nonce		be created in the Neighbour Table, which, at first sight, makes the
	included in a challenge request and echoed in the challenge reply can		protocol susceptible to resource exhaustion attacks (similarly to the
	be fairly large (up to 192 octets), which should in principle permit		familiar "TCP SYN Flooding" attack [RFC4987]). However, the HMAC
			computation includes the sender address (Section 4.1), and thus the
			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
			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).
			In order to make this kind of resource exhaustion attacks less
			effective, implementations may use a separate table of uncompleted
			challenges that is separate from the Neighbour Table used by the core
			protocol (the data structures described in Section 3.2 of
			[RFC6126bis] are conceptual, any data structure that yields the same
			result may be used). Implementers might also consider using the fact
			that the nonces included in challenge requests and responses can be
			fairly large (up to 192 octets), which should in principle allow
	encoding the per-challenge state as a secure "cookie" within the		encoding the per-challenge state as a secure "cookie" within the
	nonce itself.		nonce itself.
	7. IANA Considerations		7. 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 |
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 29 ¶
	[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		9.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-01 (work in progress), October 2018.		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>.
			[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
			Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
			<https://www.rfc-editor.org/info/rfc4987>.
	[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues		[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
	with Existing Cryptographic Protection Methods for Routing		with Existing Cryptographic Protection Methods for Routing
	Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,		Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
	<https://www.rfc-editor.org/info/rfc6039>.		<https://www.rfc-editor.org/info/rfc6039>.
	[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code		[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
	(HMAC) Cryptographic Authentication", RFC 7298,		(HMAC) Cryptographic Authentication", RFC 7298,
	DOI 10.17487/RFC7298, July 2014,		DOI 10.17487/RFC7298, July 2014,
	<https://www.rfc-editor.org/info/rfc7298>.		<https://www.rfc-editor.org/info/rfc7298>.
	skipping to change at page 19, line 23 ¶		skipping to change at page 19, line 42 ¶
	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		B.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
			o Clarify that a Neighbour Table entry may be created just after the
			HMAC has been computed.
			o Clarify that a Neighbour Table entry already exists when a
			successful Challenge Reply has been received.
			o Expand the Security Considerations section with information about
			resource exhaustion attacks.
	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. 14 change blocks.
	16 lines changed or deleted		52 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/