rfc8968xml2.original.xml		rfc8968.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6347.xml">
	<!ENTITY RFC7250 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7250.xml">
	<!ENTITY RFC7918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7918.xml">
	<!ENTITY RFC7924 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7924.xml">
	<!ENTITY RFC8094 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8094.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes"?>
	<?rfc tocdepth="2"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes" ?>
	<?rfc compact="no" ?>
	<rfc category="std"
	obsoletes=""
	docName="draft-ietf-babel-dtls-10"
	ipr="trust200902">
	<front>
	<title abbrev="Babel over DTLS">Babel Routing Protocol over Datagram
	Transport Layer Security</title>
	<author fullname="Antonin Decimo" initials="A." surname="Decimo">
	<organization>IRIF, University of Paris-Diderot</organization>
	<address>
	<postal>
	<street></street>
	<city>Paris</city>
	<region></region>
	<code></code>
	<country>France</country>
	</postal>
	<email>antonin.decimo@gmail.com</email>
	</address>
	</author>
	<author fullname='David Schinazi' surname='Schinazi' initials='D.'>
	<organization>Google LLC</organization>
	<address>
	<postal>
	<street>1600 Amphitheatre Parkway</street>
	<city>Mountain View</city>
	<region>California</region>
	<code>94043</code>
	<country>USA</country>
	</postal>
	<email>dschinazi.ietf@gmail.com</email>
	</address>
	</author>
	<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<organization>IRIF, University of Paris-Diderot</organization>
	<address>
	<postal>
	<street>Case 7014</street>
	<city>75205 Paris Cedex 13</city>
	<region></region>
	<code></code>
	<country>France</country>
	</postal>
	<email>jch@irif.fr</email>
	</address>
	</author>
	<date/>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
			category="std"
			obsoletes=""
			number="8968"
			docName="draft-ietf-babel-dtls-10"
			ipr="trust200902"
			updates=""
			submissionType="IETF"
			consensus="true"
			xml:lang="en"
			tocInclude="true"
			tocDepth="2"
			symRefs="true"
			sortRefs="true"
			version="3">
			<!-- xml2rfc v2v3 conversion 3.0.0 -->
			<front>
			<title abbrev="Babel over DTLS">Babel Routing Protocol over Datagram
			Transport Layer Security</title>
			<seriesInfo name="RFC" value="8968"/>
			<author fullname="Antonin Décimo" initials="A." surname="Décimo">
			<organization>IRIF, University of Paris-Diderot</organization>
			<address>
			<postal>
			<city>Paris</city>
			<country>France</country>
			</postal>
			<email>antonin.decimo@gmail.com</email>
			</address>
			</author>
			<author fullname="David Schinazi" surname="Schinazi" initials="D.">
			<organization>Google LLC</organization>
			<address>
			<postal>
			<street>1600 Amphitheatre Parkway</street>
			<city>Mountain View</city>
			<region>CA</region>
			<code>94043</code>
			<country>United States of America</country>
			</postal>
			<email>dschinazi.ietf@gmail.com</email>
			</address>
			</author>
			<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
			<organization>IRIF, University of Paris-Diderot</organization>
			<address>
			<postal>
			<street>Case 7014</street>
			<city>Paris CEDEX 13</city>
			<code>75205</code>
			<country>France</country>
			</postal>
			<email>jch@irif.fr</email>
			</address>
			</author>
			<date month="January" year="2021"/>
	<abstract>		<abstract>
	<t>The Babel Routing Protocol does not contain any means to authenticate		<t>The Babel Routing Protocol does not contain any means to authenticate
	neighbours or provide integrity or confidentiality for messages sent between		neighbours or provide integrity or confidentiality for messages sent between
	them. This document specifies a mechanism to ensure these properties, using		them. This document specifies a mechanism to ensure these properties using
	Datagram Transport Layer Security (DTLS).</t>		Datagram Transport Layer Security (DTLS).</t>
	</abstract>		</abstract>
			</front>
	</front>		<middle>
			<section numbered="true" toc="default">
	<middle>		<name>Introduction</name>
			<t>The Babel routing protocol <xref target="RFC8966" format="default"/> do
	<section title="Introduction">		es not contain
	<t>The Babel Routing Protocol <xref target="RFC6126bis"/> does not contain
	any means to authenticate neighbours or protect messages sent between them.		any means to authenticate neighbours or protect messages sent between them.
	Because of this, an attacker is able to send maliciously crafted Babel		Because of this, an attacker is able to send maliciously crafted Babel
	messages which could lead a network to route traffic to an attacker or		messages that could lead a network to route traffic to an attacker or
	to an under-resourced target causing denial of service.		to an under-resourced target, causing denial of service.
	This document specifies a mechanism to prevent such attacks, using		This document specifies a mechanism to prevent such attacks using
	Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/>.</t>		Datagram Transport Layer Security (DTLS) <xref target="RFC6347" format="default"
			/>.</t>
	<section title="Specification of Requirements">		<section numbered="true" toc="default">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	when, they appear in all capitals, as shown here.</t>
	</section>
	<section title="Applicability">		<name>Specification of Requirements</name>
			<t>
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
			</section>
	<t>The protocol described in this document protects Babel packets with		<section numbered="true" toc="default">
			<name>Applicability</name>
			<t>The protocol described in this document protects Babel packets with
	DTLS. As such, it inherits the features offered by DTLS, notably		DTLS. As such, it inherits the features offered by DTLS, notably
	authentication, integrity, optional replay protection, confidentiality and		authentication, integrity, optional replay protection, confidentiality, and
	asymmetric keying. It is therefore expected to be applicable in a wide		asymmetric keying. It is therefore expected to be applicable in a wide
	range of environments.</t>		range of environments.</t>
			<t>There exists another mechanism for securing Babel, namely Message Aut
	<t>There exists another mechanism for securing Babel, namely Babel HMAC		hentication Code (MAC)
	authentication <xref target="BABEL-HMAC"/>. HMAC only offers basic		authentication for Babel (Babel-MAC) <xref target="RFC8967" format="default"/>.
	features, namely authentication, integrity and replay protection with		Babel-MAC only offers basic
			features, namely authentication, integrity, and replay protection with
	a small number of symmetric keys. A comparison of Babel security mechanisms		a small number of symmetric keys. A comparison of Babel security mechanisms
	and their applicability can be found in <xref target="RFC6126bis"/>.</t>		and their applicability can be found in <xref target="RFC8966" format="default"/
			>.</t>
	<t>Note that Babel over DTLS provides a single authentication domain, meaning		<t>Note that Babel over DTLS provides a single authentication domain, me
			aning
	that all nodes that have the right credentials can convey any and all routing		that all nodes that have the right credentials can convey any and all routing
	information.</t>		information.</t>
			<t>DTLS supports several mechanisms by which nodes can identify themselv
	<t>DTLS supports several mechanisms by which nodes can identify themselves		es
	and prove possession of secrets tied to these identities. This document		and prove possession of secrets tied to these identities. This document
	does not prescribe which of these mechanisms to use; details of identity		does not prescribe which of these mechanisms to use; details of identity
	management are left to deployment profiles of Babel over DTLS.</t>		management are left to deployment profiles of Babel over DTLS.</t>
			</section>
	</section>		</section>
			<section numbered="true" toc="default">
	</section>		<name>Operation of the Protocol</name>
			<t>Babel over DTLS requires some changes to how Babel operates.
	<section title="Operation of the Protocol">
	<t>Babel over DTLS requires some changes to how Babel operates.
	First, DTLS is a client-server protocol, while Babel is a peer-to-peer		First, DTLS is a client-server protocol, while Babel is a peer-to-peer
	protocol. Second, DTLS can only protect unicast communication, while		protocol. Second, DTLS can only protect unicast communication, while
	Babel packets can be sent to both unicast and multicast destinations.</t>		Babel packets can be sent to both unicast and multicast destinations.</t>
			<section numbered="true" toc="default">
	<section title="DTLS Connection Initiation">		<name>DTLS Connection Initiation</name>
			<t>Babel over DTLS operates on a different port than unencrypted Babel.
	<t>Babel over DTLS operates on a different port than unencrypted Babel.		All Babel over DTLS nodes <bcp14>MUST</bcp14> act as DTLS servers on a given UDP
	All Babel over DTLS nodes MUST act as DTLS servers on a given UDP port,		port
	and MUST listen for unencrypted Babel traffic on another UDP port, which		and <bcp14>MUST</bcp14> listen for unencrypted Babel traffic on another UDP port
	MUST be distinct from the first one. The default port for Babel over DTLS is		, which
	registered with IANA as the "babel-dtls" port (UDP port TBD, see		<bcp14>MUST</bcp14> be distinct from the first one. The default port for Babel
	<xref target="iana_considerations"/>), and the port exchanging unencrypted		over DTLS is
			registered with IANA as the "babel-dtls" port (UDP port 6699, see
			<xref target="iana_considerations" format="default"/>), and the port exchanging
			unencrypted
	Babel traffic is registered as the "babel" port (UDP port 6696,		Babel traffic is registered as the "babel" port (UDP port 6696,
	see Section 5 of <xref target="RFC6126bis"/>).</t>		see <xref target="RFC8966" sectionFormat="of" section="5"/>).</t>
			<t>When a Babel node discovers a new neighbour (generally by
	<t>When a Babel node discovers a new neighbour (generally by
	receiving an unencrypted multicast Babel packet), it compares the neighbour's		receiving an unencrypted multicast Babel packet), it compares the neighbour's
	IP address with its own, using network byte ordering. If a node's		IP address with its own, using network byte ordering. If a node's
	address is lower than the recently discovered neighbour's address, it acts		address is lower than the recently discovered neighbour's address, it acts
	as a client and connects to the neighbour. In other words, the node with		as a client and connects to the neighbour. In other words, the node with
	the lowest address is the DTLS client for this pairwise relationship.		the lowest address is the DTLS client for this pairwise relationship.
	As an example, fe80::1:2 is considered lower than fe80::2:1.</t>		As an example, fe80::1:2 is considered lower than fe80::2:1.</t>
			<t>The node acting as DTLS client initiates its DTLS connection from an
	<t>The node acting as DTLS client initiates its DTLS connection from an		ephemeral UDP port. Nodes <bcp14>SHOULD</bcp14> ensure that new client DTLS con
	ephemeral UDP port. Nodes SHOULD ensure that new client DTLS connections		nections
	use different ephemeral ports from recently used connections to allow		use different ephemeral ports from recently used connections to allow
	servers to differentiate between the new and old DTLS connections.		servers to differentiate between the new and old DTLS connections.
	Alternatively, nodes could use DTLS connection identifiers		Alternatively, nodes could use DTLS connection identifiers
	<xref target="DTLS-CID"/> as a higher-entropy mechanism to distinguish between		<xref target="I-D.ietf-tls-dtls-connection-id" format="default"/> as a higher-en tropy mechanism to distinguish between
	connections.</t>		connections.</t>
			<t>When a node receives a new DTLS connection, it <bcp14>MUST</bcp14> ve
	<t>When a node receives a new DTLS connection, it MUST verify that the source		rify that the source
	IP address is either an IPv6 link-local address or an IPv4 address belonging		IP address is either an IPv6 link-local address or an IPv4 address belonging
	to the local network; if it is neither, it MUST reject the		to the local network; if it is neither, it <bcp14>MUST</bcp14> reject the
	connection. Nodes use mutual authentication (authenticating		connection. Nodes use mutual authentication (authenticating
	both client and server); clients MUST authenticate servers and servers MUST		both client and server); clients <bcp14>MUST</bcp14> authenticate servers and se
	authenticate clients. Implementations MUST support		rvers <bcp14>MUST</bcp14>
			authenticate clients. Implementations <bcp14>MUST</bcp14> support
	authenticating peers against a local store of credentials. If either node		authenticating peers against a local store of credentials. If either node
	fails to authenticate its peer against its local policy, it MUST abort the DTLS		fails to authenticate its peer against its local policy, it <bcp14>MUST</bcp14>
	handshake. The guidance given in <xref target="BCP195"/> MUST be followed to		abort the DTLS
	avoid attacks on DTLS. Additionally, nodes MUST only negotiate DTLS version		handshake. The guidance given in <xref target="BCP195" format="default"/> <bcp1
	1.2 or higher. Nodes MUST		4>MUST</bcp14> be followed to
			avoid attacks on DTLS. Additionally, nodes <bcp14>MUST</bcp14> only negotiate D
			TLS version
			1.2 or higher. Nodes <bcp14>MUST</bcp14>
	use DTLS replay protection to prevent attackers from replaying stale		use DTLS replay protection to prevent attackers from replaying stale
	information. Nodes SHOULD drop packets that have been reordered by more than		information. Nodes <bcp14>SHOULD</bcp14> drop packets that have been reordered by more than
	two IHU (I Heard You) intervals, to avoid letting attackers make stale		two IHU (I Heard You) intervals, to avoid letting attackers make stale
	information last longer. If a node receives a new DTLS connection from a		information last longer. If a node receives a new DTLS connection from a
	neighbour to whom it already has a connection, the node MUST NOT discard the		neighbour to whom it already has a connection, the node <bcp14>MUST NOT</bcp14> discard the
	older connection until it has completed the handshake of the new one and		older connection until it has completed the handshake of the new one and
	validated the identity of the peer.</t>		validated the identity of the peer.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Protocol Encoding</name>
	<section title="Protocol Encoding">		<t>Babel over DTLS sends all unicast Babel packets protected by DTLS. T
			he
	<t>Babel over DTLS sends all unicast Babel packets protected by DTLS. The
	entire Babel packet, from the Magic byte at the start of the Babel header		entire Babel packet, from the Magic byte at the start of the Babel header
	to the last byte of the Babel packet trailer, is sent protected by DTLS.</t>		to the last byte of the Babel packet trailer, is sent protected by DTLS.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Transmission</name>
	<section title="Transmission">		<t>When sending packets, Babel over DTLS nodes <bcp14>MUST NOT</bcp14> s
			end any TLVs over
	<t>When sending packets, Babel over DTLS nodes MUST NOT send any TLVs over
	the unprotected "babel" port, with the exception of Hello TLVs without the		the unprotected "babel" port, with the exception of Hello TLVs without the
	Unicast flag set. Babel over DTLS nodes MUST NOT send any unprotected unicast		Unicast flag set. Babel over DTLS nodes <bcp14>MUST NOT</bcp14> send any unprot ected unicast
	packets. This ensures the confidentiality of the information sent in Babel		packets. This ensures the confidentiality of the information sent in Babel
	packets (e.g., the network topology) by only sending it encrypted by DTLS.		packets (e.g., the network topology) by only sending it encrypted by DTLS.
	Unless some out-of-band neighbour discovery mechanism is available,		Unless some out-of-band neighbour discovery mechanism is available,
	nodes SHOULD periodically send unprotected multicast Hellos to ensure		nodes <bcp14>SHOULD</bcp14> periodically send unprotected Multicast Hellos to en sure
	discovery of new neighbours. In order to maintain bidirectional reachability,		discovery of new neighbours. In order to maintain bidirectional reachability,
	nodes can either rely entirely on unprotected multicast Hellos, or send		nodes can either rely entirely on unprotected Multicast Hellos, or send
	protected unicast Hellos in addition to the multicast Hellos.</t>		protected Unicast Hellos in addition to the Multicast Hellos.</t>
			<t>Since Babel over DTLS only protects unicast packets, implementors may
	<t>Since Babel over DTLS only protects unicast packets, implementors may
	implement Babel over DTLS by modifying an implementation of Babel without DTLS		implement Babel over DTLS by modifying an implementation of Babel without DTLS
	support, and replacing any TLV previously sent over multicast with a separate		support and replacing any TLV previously sent over multicast with a separate
	TLV sent over unicast for each neighbour. TLVs previously sent over multicast		TLV sent over unicast for each neighbour. TLVs previously sent over multicast
	can be replaced with the same contents over unicast, with the exception of		can be replaced with the same contents over unicast, with the exception of
	Hellos as described above. Some implementations could also change the contents		Hellos as described above. Some implementations could also change the contents
	of IHU TLVs when converting to unicast in order to remove redundant		of IHU TLVs when converting to unicast in order to remove redundant
	information.</t>		information.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Reception</name>
	<section title="Reception">		<t>Babel over DTLS nodes can receive Babel packets either protected over
			a
	<t>Babel over DTLS nodes can receive Babel packets either protected over a		DTLS connection or unprotected directly over the "babel" port. To ensure the
	DTLS connection, or unprotected directly over the "babel" port. To ensure the
	security properties of this mechanism, unprotected packets are treated		security properties of this mechanism, unprotected packets are treated
	differently. Nodes MUST silently ignore any unprotected packet sent over		differently. Nodes <bcp14>MUST</bcp14> silently ignore any unprotected packet s
	unicast. When parsing an unprotected packet, a node MUST silently		ent over
	ignore all TLVs that are not of type Hello. Nodes MUST also silently ignore		unicast. When parsing an unprotected packet, a node <bcp14>MUST</bcp14> silentl
			y
			ignore all TLVs that are not of type Hello. Nodes <bcp14>MUST</bcp14> also sile
			ntly ignore
	any unprotected Hello with the Unicast flag set. Note that receiving an		any unprotected Hello with the Unicast flag set. Note that receiving an
	unprotected packet can still be used to discover new neighbours, even when		unprotected packet can still be used to discover new neighbours, even when
	all TLVs in that packet are silently ignored.</t>		all TLVs in that packet are silently ignored.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Neighbour Table Entry</name>
	<section title="Neighbour table entry">		<t>It is <bcp14>RECOMMENDED</bcp14> for nodes to associate the state of
			their DTLS connection
	<t>It is RECOMMENDED for nodes to associate the state of their DTLS connection
	with their neighbour table. When a neighbour entry is flushed from the		with their neighbour table. When a neighbour entry is flushed from the
	neighbour table (Appendix A of <xref target="RFC6126bis"/>), its associated		neighbour table (<xref target="RFC8966" section="A" sectionFormat="of" format="d
	DTLS state SHOULD be discarded. The node SHOULD send a DTLS close_notify alert		efault"/>), its associated
			DTLS state <bcp14>SHOULD</bcp14> be discarded. The node <bcp14>SHOULD</bcp14> s
			end a DTLS close_notify alert
	to the neighbour if it believes the link is still viable.</t>		to the neighbour if it believes the link is still viable.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Simultaneous Operation of Babel over DTLS and Unprotected Babel on
	<section title="Simultaneous operation of both Babel over DTLS and unprotected B		a Node</name>
	abel on a Node">		<t>Implementations <bcp14>MAY</bcp14> implement both Babel over DTLS and
			unprotected Babel.
	<t>Implementations MAY implement both Babel over DTLS and unprotected Babel.		Additionally, a node <bcp14>MAY</bcp14> simultaneously run both Babel over DTLS
	Additionally, a node MAY simultaneously run both Babel over DTLS and		and
	unprotected Babel. However, a node running both MUST ensure that it runs		unprotected Babel. However, a node running both <bcp14>MUST</bcp14> ensure that
			it runs
	them on separate interfaces, as the security properties of Babel over DTLS		them on separate interfaces, as the security properties of Babel over DTLS
	rely on not accepting unprotected Babel packets (other than multicast Hellos).		rely on ignoring unprotected Babel packets (other than Multicast Hellos).
	An implementation MAY offer configuration options to allow unprotected Babel on		An implementation <bcp14>MAY</bcp14> offer configuration options to allow unprot
	some interfaces but not others; this effectively gives nodes on that interface		ected Babel on
	the same access as authenticated nodes, and SHOULD NOT be done unless that		some interfaces but not others, which effectively gives nodes on that interface
			the same access as authenticated nodes; however, this <bcp14>SHOULD NOT</bcp14>
			be done unless that
	interface has a mechanism to authenticate nodes at a lower		interface has a mechanism to authenticate nodes at a lower
	layer (e.g., IPsec).</t>		layer (e.g., IPsec).</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Simultaneous Operation of Babel over DTLS and Unprotected Babel on
	<section title="Simultaneous operation of both Babel over DTLS and unprotected B		a Network</name>
	abel on a Network">		<t>If Babel over DTLS and unprotected Babel are both operated on the sam
			e
	<t>If Babel over DTLS and unprotected Babel are both operated on the same		network, the Babel over DTLS implementation will receive unprotected Multicast
	network, the Babel over DTLS implementation will receive unprotected multicast
	Hellos and attempt to initiate a DTLS connection. These connection attempts		Hellos and attempt to initiate a DTLS connection. These connection attempts
	can be sent to nodes that only run unprotected Babel, who will not		can be sent to nodes that only run unprotected Babel, who will not
	respond. Babel over DTLS implementations SHOULD therefore rate-limit their		respond. Babel over DTLS implementations <bcp14>SHOULD</bcp14> therefore rate-l imit their
	DTLS connection attempts to avoid causing undue load on the network.</t>		DTLS connection attempts to avoid causing undue load on the network.</t>
			</section>
	</section>		</section>
			<section numbered="true" toc="default">
	</section>		<name>Interface Maximum Transmission Unit Issues</name>
			<t>Compared to unprotected Babel, DTLS adds header, authentication tag, an
	<section title="Interface Maximum Transmission Unit Issues">		d
	<t>Compared to unprotected Babel, DTLS adds header, authentication tag and
	possibly block-size padding overhead to every packet. This reduces the size of		possibly block-size padding overhead to every packet. This reduces the size of
	the Babel payload that can be carried. This document does not relax the		the Babel payload that can be carried. This document does not relax the
	packet size requirements in Section 4 of <xref target="RFC6126bis"/>, but		packet size requirements in <xref target="RFC8966" sectionFormat="of" section="4 "/> but
	recommends that DTLS overhead be taken into account when computing maximum		recommends that DTLS overhead be taken into account when computing maximum
	packet size.</t>		packet size.</t>
			<t> More precisely, nodes <bcp14>SHOULD</bcp14> compute the overhead of DT
	<t> More precisely, nodes SHOULD compute the overhead of DTLS depending on		LS depending on
	the ciphersuites in use, and SHOULD NOT send Babel packets larger than the		the ciphersuites in use and <bcp14>SHOULD NOT</bcp14> send Babel packets larger
	interface maximum transmission unit (MTU) minus the overhead of IP, UDP		than the
	and DTLS. Nodes MUST NOT send Babel packets larger than the attached		interface maximum transmission unit (MTU) minus the overhead of IP, UDP,
			and DTLS. Nodes <bcp14>MUST NOT</bcp14> send Babel packets larger than the atta
			ched
	interface's MTU adjusted for known lower-layer headers (at least UDP and		interface's MTU adjusted for known lower-layer headers (at least UDP and
	IP) or 512 octets, whichever is larger, but not exceeding 2^16 -		IP) or 512 octets, whichever is larger, but not exceeding 2<sup>16</sup> -
	1 adjusted for lower-layer headers. Every Babel speaker MUST be able to		1 adjusted for lower-layer headers. Every Babel speaker <bcp14>MUST</bcp14> be
			able to
	receive packets that are as large as any attached interface's MTU adjusted		receive packets that are as large as any attached interface's MTU adjusted
	for UDP and IP headers or 512 octets, whichever is larger. Note that this		for UDP and IP headers or 512 octets, whichever is larger. Note that this
	requirement on reception does not take into account the overhead of DTLS		requirement on reception does not take into account the overhead of DTLS
	because the peer may not have the ability to compute the overhead of DTLS		because the peer may not have the ability to compute the overhead of DTLS,
	and the packet may be fragmented by lower layers.</t>		and the packet may be fragmented by lower layers.</t>
			<t>Note that distinct DTLS connections can use different ciphers, which ca
	<t>Note that distinct DTLS connections can use different ciphers, which can		n
	have different amounts of per-packet overhead. Therefore, the MTU to one		have different amounts of per-packet overhead. Therefore, the MTU to one
	neighbour can be different from the MTU to another neighbour on the same		neighbour can be different from the MTU to another neighbour on the same
	link.</t>		link.</t>
			</section>
	</section>		<section anchor="iana_considerations" numbered="true" toc="default">
			<name>IANA Considerations</name>
	<section title="IANA Considerations" anchor="iana_considerations">		<t>IANA has registered a UDP port
			number, called "babel-dtls", for use by Babel over DTLS:
	<t>If this document is approved, IANA is requested to register a UDP port
	number, called "babel-dtls", for use by Babel over DTLS. Details of the
	request to IANA are as follows:
	<list style="symbols">
	<t>Assignee: IESG, iesg@ietf.org</t>
	<t>Contact Person: IETF Chair, chair@ietf.org</t>
	<t>Transport Protocols: UDP only</t>
	<t>Service Code: None</t>
	<t>Service Name: babel-dtls</t>
	<t>Desired Port Number: 6699</t>
	<t>Description: Babel Routing Protocol over DTLS</t>
	<t>Reference: This document</t>
	<t>Defined TXT Keys: None</t>
	</list>
	</t>		</t>
			<ul empty="true"><li>
	</section>		<dl spacing="normal">
			<dt>Service Name:</dt><dd> babel-dtls</dd>
	<section title="Security Considerations">		<dt>Port Number:</dt><dd> 6699</dd>
			<dt>Transport Protocols:</dt><dd> UDP only</dd>
	<t>A malicious client might attempt to perform a high number of DTLS		<dt>Description:</dt><dd> Babel Routing Protocol over DTLS</dd>
			<dt>Assignee:</dt><dd> IESG, iesg@ietf.org</dd>
			<dt>Contact:</dt><dd> IETF Chair, chair@ietf.org</dd>
			<dt>Reference:</dt><dd> RFC 8968</dd>
			<dt>Service Code:</dt><dd> None</dd>
			</dl>
			</li>
			</ul>
			</section>
			<section numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>A malicious client might attempt to perform a high number of DTLS
	handshakes with a server. As the clients are not uniquely identified		handshakes with a server. As the clients are not uniquely identified
	by the protocol until the handshake completes and can be obfuscated with IPv6		by the protocol until the handshake completes and can be obfuscated with IPv6
	temporary addresses, a server needs to mitigate the impact of such an attack.		temporary addresses, a server needs to mitigate the impact of such an attack.
	Note that attackers might attempt to keep in-progress handshakes open for as		Note that attackers might attempt to keep in-progress handshakes open for as
	long as possible by using variants on the attack commonly known as		long as possible by using variants on the attack commonly known as
	Slowloris <xref target="SLOWLORIS"/>. Mitigating these attacks might involve		Slowloris <xref target="SLOWLORIS" format="default"/>. Mitigating these attacks
	rate limiting handshakes from a given subnet or more advanced denial of		might involve
			limiting the rate of handshakes from a given subnet or more advanced denial of
	service avoidance techniques beyond the scope of this document.</t>		service avoidance techniques beyond the scope of this document.</t>
			<t>Babel over DTLS allows sending Multicast Hellos unprotected; attackers
	<t>Babel over DTLS allows sending multicast Hellos unprotected; attackers can		can
	therefore tamper with them. For example, an attacker could send erroneous		therefore tamper with them. For example, an attacker could send erroneous
	values for the Seqno and Interval fields, causing bidirectional		values for the Seqno and Interval fields, causing bidirectional
	reachability detection to fail. While implementations MAY use multicast Hellos		reachability detection to fail. While implementations <bcp14>MAY</bcp14> use Mu
	for link quality estimation, they SHOULD also emit protected unicast Hellos to		lticast Hellos
			for link quality estimation, they <bcp14>SHOULD</bcp14> also emit protected Unic
			ast Hellos to
	prevent this class of denial-of-service attack.</t>		prevent this class of denial-of-service attack.</t>
			<t>While DTLS provides protection against an attacker that replays valid
	<t>While DTLS provides protection against an attacker that replays valid
	packets, DTLS is not able to detect when an active on-path attacker intercepts		packets, DTLS is not able to detect when an active on-path attacker intercepts
	valid packets and resends them at a later time. This attack could be used to		valid packets and resends them at a later time. This attack could be used to
	make a node believe it has bidirectional reachability to a neighbour even		make a node believe it has bidirectional reachability to a neighbour even
	though that neighbour has disconnected from the network. To prevent this		though that neighbour has disconnected from the network. To prevent this
	attack, nodes MUST discard the DTLS state associated with a neighbour after a		attack, nodes <bcp14>MUST</bcp14> discard the DTLS state associated with a neigh bour after a
	finite time of not receiving valid DTLS packets. This can be implemented by,		finite time of not receiving valid DTLS packets. This can be implemented by,
	for example, discarding a neighbour's DTLS state when its associated IHU timer		for example, discarding a neighbour's DTLS state when its associated IHU timer
	fires. Note that relying solely on the receipt of Hellos is not sufficient as		fires. Note that relying solely on the receipt of Hellos is not sufficient as
	multicast Hellos are sent unprotected. Additionally, an attacker could save		Multicast Hellos are sent unprotected. Additionally, an attacker could save
	some packets and replay them later in hopes of propagating stale routing		some packets and replay them later in hopes of propagating stale routing
	information at a later time. This can be mitigated by discarding received		information at a later time. This can be mitigated by discarding received
	packets that have been reordered by more than two IHU intervals.</t>		packets that have been reordered by more than two IHU intervals.</t>
			</section>
			</middle>
			<back>
	</section>		<displayreference target="I-D.ietf-tls-dtls-connection-id" to="DTLS-CID"/>
	</middle>		<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6347.xml"/>
	<back>		<reference anchor='BCP195' target='https://www.rfc-editor.org/info/bcp195'>
			<front>
			<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Data
			gram Transport Layer Security (DTLS)</title>
			<author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></
			author>
			<author initials='R.' surname='Holz' fullname='R. Holz'><organization /></author
			>
			<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organizat
			ion /></author>
			<date year='2015' month='May' />
			<abstract><t>Transport Layer Security (TLS) and Datagram Transport Layer Securit
			y (DTLS) are widely used to protect data exchanged over application protocols su
			ch as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several se
			rious attacks on TLS have emerged, including attacks on its most commonly used c
			ipher suites and their modes of operation. This document provides recommendatio
			ns for improving the security of deployed services that use TLS and DTLS. The re
			commendations are applicable to the majority of use cases.</t></abstract>
			</front>
			<seriesInfo name='BCP' value='195'/>
			<seriesInfo name='RFC' value='7525'/>
			</reference>
	<references title="Normative References">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.8174.xml"/>
	&RFC2119;		<reference anchor="RFC8966" target='https://www.rfc-editor.org/info/rfc8
	&RFC6347;		966'>
			<front>
			<title>The Babel Routing Protocol</title>
			<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboc
			zek"/>
			<author fullname="David Schinazi" initials="D." surname="Schinazi"/>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8966"/>
			<seriesInfo name="DOI" value="10.17487/RFC8966"/>
			</reference>
			</references>
			<references>
	<reference anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">		<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7250.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7918.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7924.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8094.xml"/>
			<reference anchor='RFC8967' target='https://www.rfc-editor.org/info/rfc8967'>
	<front>		<front>
	<title>		<title>MAC Authentication for the Babel Routing Protocol</title>
	Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Tr		<author initials='C' surname='Dô' fullname='Clara Dô'>
	ansport Layer Security (DTLS)		<organization />
	</title>
	<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
	<organization/>
	</author>		</author>
	<author initials="R." surname="Holz" fullname="R. Holz">		<author initials='W' surname='Kolodziejak' fullname='Weronika Kolodziejak'>
	<organization/>		<organization />
	</author>		</author>
	<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">		<author initials='J' surname='Chroboczek' fullname='Juliusz Chroboczek'>
	<organization/>		<organization />
	</author>		</author>
	<date year="2015" month="May"/>		<date month='January' year='2021' />
	<abstract>
	<t>
	Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are
	widely used to protect data exchanged over application protocols such as HTTP, S
	MTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks
	on TLS have emerged, including attacks on its most commonly used cipher suites a
	nd their modes of operation. This document provides recommendations for improvin
	g the security of deployed services that use TLS and DTLS. The recommendations a
	re applicable to the majority of use cases.
	</t>
	</abstract>
	</front>		</front>
	<seriesInfo name="BCP" value="195"/>		<seriesInfo name="RFC" value="8967"/>
	<seriesInfo name="RFC" value="7525"/>		<seriesInfo name="DOI" value="10.17487/RFC8967"/>
	<seriesInfo name="DOI" value="10.17487/RFC7525"/>
	</reference>
	&RFC8174;
	<reference anchor="RFC6126bis"><front>
	<title>The Babel Routing Protocol</title>
	<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
	<author fullname="David Schinazi" initials="D." surname="Schinazi"/>
	<date month="February" year="2020"/></front>
	<seriesInfo name="Internet Draft" value="draft-ietf-babel-rfc6126bis-17"/>
	</reference>
	</references>
	<references title="Informative References">
	&RFC7250;
	&RFC7918;
	&RFC7924;
	&RFC8094;
	<reference anchor="BABEL-HMAC"><front>
	<title>Babel Cryptographic Authentication</title>
	<author fullname="Clara Do" initials="C." surname="Do"/>
	<author fullname="Weronika Kolodziejak" initials="W." surname="Kolodziejak"/>
	<author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
	<date month="August" year="2019"/></front>
	<seriesInfo name="Internet Draft" value="draft-ietf-babel-hmac-10"/>
	</reference>
	<reference anchor="DTLS-CID"><front>
	<title>Connection Identifiers for DTLS 1.2</title>
	<author fullname="Eric Rescorla" initials="E." surname="Rescorla"/>
	<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig"/>
	<author fullname="Thomas Fossati" initials="T." surname="Fossati"/>
	<author fullname="Tobias Gondrom" initials="T." surname="Gondrom"/>
	<date month="October" year="2019"/></front>
	<seriesInfo name="Internet Draft" value="draft-ietf-tls-dtls-connection-id-07"/>
	</reference>
	<reference anchor="SLOWLORIS" target="https://web.archive.org/web/20150315054838
	/http://ha.ckers.org/slowloris/"><front>
	<title>Welcome to Slowloris...</title>
	<author fullname="RSnake Hansen" initials="R." surname="Hansen"/>
	<date month="June" year="2009"/></front>
	</reference>		</reference>
	</references>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D. ietf-tls-dtls-connection-id.xml"/>
	<section title="Performance Considerations">		<reference anchor="SLOWLORIS" target="https://web.archive.org/web/201503
			15054838/http://ha.ckers.org/slowloris/">
			<front>
			<title>Slowloris HTTP DoS</title>
			<author fullname="RSnake Hansen" initials="R." surname="Hansen"/>
			<date month="June" year="2009"/>
			</front>
			</reference>
			</references>
			</references>
	<t>To reduce the number of octets taken by the DTLS handshake,		<section numbered="true" toc="default">
			<name>Performance Considerations</name>
			<t>To reduce the number of octets taken by the DTLS handshake,
	especially the size of the certificate in the ServerHello (which can		especially the size of the certificate in the ServerHello (which can
	be several kilobytes), Babel peers can use raw public keys <xref		be several kilobytes), Babel peers can use raw public keys <xref target="RFC7250
	target="RFC7250"/> or the Cached Information Extension <xref		" format="default"/> or the Cached Information Extension <xref target="RFC7924"
	target="RFC7924"/>. The Cached Information Extension avoids		format="default"/>. The Cached Information Extension avoids
	transmitting the server's certificate and certificate chain if the		transmitting the server's certificate and certificate chain if the
	client has cached that information from a previous TLS handshake. TLS		client has cached that information from a previous TLS handshake. TLS
	False Start <xref target="RFC7918"/> can reduce round trips by		False Start <xref target="RFC7918" format="default"/> can reduce round trips by
	allowing the TLS second flight of messages (ChangeCipherSpec) to also		allowing the TLS second flight of messages (ChangeCipherSpec) to also
	contain the (encrypted) Babel packet.</t>		contain the (encrypted) Babel packet.</t>
			</section>
	</section>		<section numbered="false" toc="default">
			<name>Acknowledgments</name>
	<section title="Acknowledgments">		<t>The authors would like to thank
			<contact fullname="Roman Danyliw"/>,
	<t>The authors would like to thank		<contact fullname="Donald Eastlake"/>,
	Roman Danyliw,		<contact fullname="Thomas Fossati"/>,
	Donald Eastlake,		<contact fullname="Benjamin Kaduk"/>,
	Thomas Fossati,		<contact fullname="Gabriel Kerneis"/>,
	Benjamin Kaduk,		<contact fullname="Mirja Kühlewind"/>,
	Gabriel Kerneis,		<contact fullname="Antoni Przygienda"/>,
	Mirja Kuehlewind,		<contact fullname="Henning Rogge"/>,
	Antoni Przygienda,		<contact fullname="Dan Romascanu"/>,
	Henning Rogge,		<contact fullname="Barbara Stark"/>,
	Dan Romascanu,		<contact fullname="Markus Stenberg"/>,
	Barbara Stark,		<contact fullname="Dave Taht"/>,
	Markus Stenberg,		<contact fullname="Martin Thomson"/>,
	Dave Taht,		<contact fullname="Sean Turner"/>,
	Martin Thomson,		and <contact fullname="Martin Vigoureux"/>
	Sean Turner
	and Martin Vigoureux
	for their input and contributions.		for their input and contributions.
	The performance considerations in this document were inspired from the ones for		The performance considerations in this document were inspired from the ones for
	DNS over DTLS <xref target="RFC8094"/>.</t>		DNS over DTLS <xref target="RFC8094" format="default"/>.</t>
			</section>
	</section>		</back>
	</back>
	</rfc>		</rfc>
End of changes. 71 change blocks.
	368 lines changed or deleted		364 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/