rfc9146.original.xml		rfc9146.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.15 -->		<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.15 -->
	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc rfcedstyle="yes"?>		<!DOCTYPE rfc [
	<?rfc toc="yes"?>		<!ENTITY nbsp "&#160;">
	<?rfc tocindent="yes"?>		<!ENTITY zwsp "&#8203;">
	<?rfc sortrefs="yes"?>		<!ENTITY nbhy "&#8209;">
	<?rfc symrefs="yes"?>		<!ENTITY wj "&#8288;">
	<?rfc strict="yes"?>		]>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName
	<?rfc text-list-symbols="-o*+"?>		="draft-ietf-tls-dtls-connection-id-13" number="9146" updates="6347" obsoletes="
	<?rfc docmapping="yes"?>		" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName		="true" sortRefs="true" symRefs="true" version="3">
	="draft-ietf-tls-dtls-connection-id-13" category="std" updates="6347" obsoletes=
	"" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs
	="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.8.0 -->		<!-- xml2rfc v2v3 conversion 3.8.0 -->
	<front>		<front>
	<title abbrev="DTLS 1.2 Connection ID">Connection Identifiers for DTLS 1.2</		<title abbrev="DTLS 1.2 Connection ID">Connection Identifier for DTLS 1.2</t
	title>		itle>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-connection-id-1		<seriesInfo name="RFC" value="9146"/>
	3"/>
	<author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="edit or">		<author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="edit or">
	<organization>RTFM, Inc.</organization>		<organization>Mozilla</organization>
	<address>		<address>
	<email>ekr@rtfm.com</email>		<email>ekr@rtfm.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role ="editor">		<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig" role ="editor">
	<organization>Arm Limited</organization>		<organization>Arm Limited</organization>
	<address>		<address>
	<email>hannes.tschofenig@arm.com</email>		<email>hannes.tschofenig@arm.com</email>
	</address>		</address>
	</author>		</author>
	skipping to change at line 44 ¶		skipping to change at line 42 ¶
	<address>		<address>
	<email>thomas.fossati@arm.com</email>		<email>thomas.fossati@arm.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="A." surname="Kraus" fullname="Achim Kraus">		<author initials="A." surname="Kraus" fullname="Achim Kraus">
	<organization>Bosch.IO GmbH</organization>		<organization>Bosch.IO GmbH</organization>
	<address>		<address>
	<email>achim.kraus@bosch.io</email>		<email>achim.kraus@bosch.io</email>
	</address>		</address>
	</author>		</author>
	<date year="2021" month="June" day="22"/>		<date year="2022" month="March"/>
	<area>Security</area>		<area>Security</area>
	<workgroup>TLS</workgroup>		<workgroup>TLS</workgroup>
	<keyword>Internet-Draft</keyword>
			<keyword>NAT rebinding</keyword>
	<abstract>		<abstract>
	<t>This document specifies the Connection ID (CID) construct for the Datag ram Transport		<t>This document specifies the Connection ID (CID) construct for the Datag ram Transport
	Layer Security (DTLS) protocol version 1.2.</t>		Layer Security (DTLS) protocol version 1.2.</t>
	<t>A CID is an identifier carried in the record layer header that gives th e		<t>A CID is an identifier carried in the record layer header that gives th e
	recipient additional information for selecting the appropriate security associat ion.		recipient additional information for selecting the appropriate security associat ion.
	In "classical" DTLS, selecting a security association of an incoming DTLS record		In "classical" DTLS, selecting a security association of an incoming DTLS record
	is accomplished with the help of the 5-tuple. If the source IP address and/or		is accomplished with the help of the 5-tuple. If the source IP address and/or
	source port changes during the lifetime of an ongoing DTLS session then the		source port changes during the lifetime of an ongoing DTLS session, then the
	receiver will be unable to locate the correct security context.</t>		receiver will be unable to locate the correct security context.</t>
	<t>The new ciphertext record format with CID also provides content type en		<t>The new ciphertext record format with the CID also provides content typ
	cryption		e encryption
	and record-layer padding.</t>		and record layer padding.</t>
			<t>This document updates RFC 6347.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The Datagram Transport Layer Security (DTLS) <xref target="RFC6347" for		<t>The Datagram Transport Layer Security (DTLS) protocol <xref target="RFC
	mat="default"/> protocol was designed for		6347" format="default"/> was designed for
	securing connection-less transports, like UDP. DTLS, like TLS, starts		securing data sent over datagram transports (e.g., UDP). DTLS, like TLS, starts
	with a handshake, which can be computationally demanding (particularly		with a handshake, which can be computationally demanding (particularly
	when public key cryptography is used). After a successful handshake,		when public key cryptography is used). After a successful handshake,
	symmetric key cryptography is used to apply data origin		symmetric key cryptography is used to apply data origin
	authentication, integrity and confidentiality protection. This		authentication, integrity, and confidentiality protection. This
	two-step approach allows endpoints to amortize the cost of the initial		two-step approach allows endpoints to amortize the cost of the initial
	handshake across subsequent application data protection. Ideally, the		handshake across subsequent application data protection. Ideally, the
	second phase where application data is protected lasts over a long		second phase where application data is protected lasts over a long
	period of time since the established keys will only need to be updated		period of time, since the established keys will only need to be updated
	once the key lifetime expires.</t>		once the key lifetime expires.</t>
	<t>In DTLS as specified in RFC 6347, the IP address and port of the peer a re used to		<t>In DTLS as specified in RFC 6347, the IP address and port of the peer a re used to
	identify the DTLS association. Unfortunately, in some cases, such as NAT rebindi ng,		identify the DTLS association. Unfortunately, in some cases, such as NAT rebindi ng,
	these values are insufficient. This is a particular issue in the Internet of Thi ngs		these values are insufficient. This is a particular issue in the Internet of Thi ngs
	when devices enter extended sleep periods to increase their battery lifetime. Th e		when devices enter extended sleep periods to increase their battery lifetime. Th e
	NAT rebinding leads to connection failure, with the resulting cost of a new hand shake.</t>		NAT rebinding leads to connection failure, with the resulting cost of a new hand shake.</t>
	<t>This document defines an extension to DTLS 1.2 to add a Connection ID ( CID) to the		<t>This document defines an extension to DTLS 1.2 to add a Connection ID ( CID) to the
	DTLS record layer. The presence of the CID is negotiated via a DTLS		DTLS record layer. The presence of the CID is negotiated via a DTLS
	extension.</t>		extension.</t>
	<t>Adding a CID to the ciphertext record format presents an opportunity to make		<t>Adding a CID to the ciphertext record format presents an opportunity to make
	other changes to the record format. In keeping with the best practices		other changes to the record format. In keeping with the best practices
	established by TLS 1.3, the type of the record is encrypted, and		established by TLS 1.3, the type of the record is encrypted, and
	a mechanism provided for adding padding to obfuscate the plaintext length.</t>		a mechanism is provided for adding padding to obfuscate the plaintext length.</t >
	</section>		</section>
	<section anchor="conventions-and-terminology" numbered="true" toc="default">		<section anchor="conventions-and-terminology" numbered="true" toc="default">
	<name>Conventions and Terminology</name>		<name>Conventions and Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref target=		"<bcp14>SHOULD NOT</bcp14>",
	"RFC8174" format="default"/> when, and only when, they		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.</t>		"<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>
	<t>This document assumes familiarity with DTLS 1.2 <xref target="RFC6347" format="default"/>. The presentation language		<t>This document assumes familiarity with DTLS 1.2 <xref target="RFC6347" format="default"/>. The presentation language
	used in this document is described in Section 3 of <xref target="RFC8446" format ="default"/>.</t>		used in this document is described in <xref target="RFC8446" sectionFormat="of" section="3"/>.</t>
	</section>		</section>
	<section anchor="the-connectionid-extension" numbered="true" toc="default">		<section anchor="the-connectionid-extension" numbered="true" toc="default">
	<name>The "connection_id" Extension</name>		<name>The "connection_id" Extension</name>
	<t>This document defines the "connection_id" extension, which		<t>This document defines the "connection_id" extension, which
	is used in ClientHello and ServerHello messages.</t>		is used in ClientHello and ServerHello messages.</t>
	<t>The extension type is specified as follows.</t>		<t>The extension type is specified as follows.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<sourcecode name="" type="tls-presentation"><![CDATA[
	enum {		enum {
	connection_id(TBD1), (65535)		connection_id(54), (65535)
	} ExtensionType;		} ExtensionType;
	]]></artwork>		]]></sourcecode>
	<t>The extension_data field of this extension, when included in the		<t>The extension_data field of this extension, when included in the
	ClientHello, MUST contain the ConnectionId structure. This structure		ClientHello, <bcp14>MUST</bcp14> contain the ConnectionId structure. This struct ure
	contains the CID value the client wishes the server to use when sending		contains the CID value the client wishes the server to use when sending
	messages to the client. A zero-length CID value indicates that the client		messages to the client. A zero-length CID value indicates that the client
	is prepared to send using a CID but does not wish the server to use one when		is prepared to send using a CID but does not wish the server to use one when
	sending.</t>		sending.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	struct {		struct {
	opaque cid<0..2^8-1>;		opaque cid<0..2^8-1>;
	} ConnectionId;		} ConnectionId;
	]]></artwork>		]]></sourcecode>
	<t>A server willing to use CIDs will respond with a "connection_id"		<t>A server willing to use CIDs will respond with a "connection_id"
	extension in the ServerHello, containing the CID it wishes the		extension in the ServerHello, containing the CID it wishes the
	client to use when sending messages towards it. A zero-length value		client to use when sending messages towards it. A zero-length value
	indicates that the server will send using the client's CID but does not		indicates that the server will send using the client's CID but does not
	wish the client to include a CID when sending.</t>		wish the client to include a CID when sending.</t>
	<t>Because each party sends the value in the "connection_id" extension it wants to		<t>Because each party sends the value in the "connection_id" extension it wants to
	receive as a CID in encrypted records, it is possible		receive as a CID in encrypted records, it is possible
	for an endpoint to use a deployment-specific constant length for such connection		for an endpoint to use a deployment-specific constant length for such connection
	identifiers. This can in turn ease parsing and connection lookup,		identifiers. This can in turn ease parsing and connection lookup --
	for example by having the length in question be a compile-time constant.		for example, by having the length in question be a compile-time constant.
	Such implementations MUST still be able to send		Such implementations <bcp14>MUST</bcp14> still be able to send
	CIDs of different length to other parties.		CIDs of different lengths to other parties.
	Since the CID length information is not included in the record itself,		Since the CID length information is not included in the record itself,
	implementations that want to use variable-length CIDs are responsible		implementations that want to use variable-length CIDs are responsible
	for constructing the CID in such a way that its length can be determined		for constructing the CID in such a way that its length can be determined
	on reception.</t>		on reception.</t>
	<t>In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS		<t>In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS
	session only. There is no dedicated "CID update" message		session only. There is no dedicated "CID update" message
	that allows new CIDs to be established mid-session, because		that allows new CIDs to be established mid-session, because
	DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages		DTLS 1.2 in general does not allow TLS 1.3-style post-handshake messages
	that do not themselves begin other handshakes. When a DTLS session is		that do not themselves begin other handshakes. When a DTLS session is
	resumed or renegotiated, the "connection_id" extension is negotiated afresh.</t>		resumed or renegotiated, the "connection_id" extension is negotiated afresh.</t>
	<t>If DTLS peers have not negotiated the use of CIDs, or a zero-length		<t>If DTLS peers have not negotiated the use of CIDs, or a zero-length
	CID has been advertised for a given direction, then the RFC		CID has been advertised for a given direction, then the record format and conten
	6347-defined record format and content type MUST be used to send in		t type defined in RFC 6347 <bcp14>MUST</bcp14> be used to send in
	the indicated direction(s).</t>		the indicated direction(s).</t>
	<t>If DTLS peers have negotiated the use of a non-zero-length CID for a		<t>If DTLS peers have negotiated the use of a non-zero-length CID for a
	given direction, then once encryption is enabled they MUST send with		given direction, then once encryption is enabled, they <bcp14>MUST</bcp14> send
	the record format defined in <xref target="dtls-ciphertext" format="default"/> w		with
	ith the		the record format defined in <xref target="dtls-ciphertext" format="default"/> (
	new MAC computation defined in <xref target="mac" format="default"/> and the con		see <xref target="record-layer-extensions"/>) with the
	tent type tls12_cid.		new Message Authentication Code (MAC) computation defined in <xref target="mac"
			format="default"/> and the content type tls12_cid.
	Plaintext payloads never use the new record format or the CID content		Plaintext payloads never use the new record format or the CID content
	type.</t>		type.</t>
	<t>When receiving, if the tls12_cid content type is set, then the CID is		<t>When receiving, if the tls12_cid content type is set, then the CID is
	used to look up the connection and the security association. If the		used to look up the connection and the security association. If the
	tls12_cid content type is not set, then the connection and security		tls12_cid content type is not set, then the connection and the security
	association is looked up by the 5-tuple and a check MUST be made to		association are looked up by the 5-tuple and a check <bcp14>MUST</bcp14> be made
	determine whether a non-zero length CID is expected.		to
			determine whether a non-zero-length CID is expected.
	If a non-zero-length CID is expected for the retrieved association,		If a non-zero-length CID is expected for the retrieved association,
	then the datagram MUST be treated as invalid, as described		then the datagram <bcp14>MUST</bcp14> be treated as invalid, as described
	in Section 4.1.2.1 of <xref target="RFC6347" format="default"/>.</t>		in <xref target="RFC6347" sectionFormat="of" section="4.1.2.1"/>.</t>
	<t>When receiving a datagram with the tls12_cid content type,		<t>When receiving a datagram with the tls12_cid content type,
	the new MAC computation defined in <xref target="mac" format="default"/> MUST be		the new MAC computation defined in <xref target="mac" format="default"/> <bcp14>
	used. When receiving a datagram		MUST</bcp14> be used. When receiving a datagram
	with the RFC 6347-defined record format, the MAC calculation defined in Section		with the record format defined in RFC 6347, the MAC calculation defined in <xref
	4.1.2		target="RFC6347" sectionFormat="of" section="4.1.2"/> <bcp14>MUST</bcp14> be us
	of <xref target="RFC6347" format="default"/> MUST be used.</t>		ed.</t>
	</section>		</section>
	<section anchor="record-layer-extensions" numbered="true" toc="default">		<section anchor="record-layer-extensions" numbered="true" toc="default">
	<name>Record Layer Extensions</name>		<name>Record Layer Extensions</name>
	<t>This specification defines the DTLS 1.2 record layer format and		<t>This specification defines the CID-enhanced record layer format for DTL
	<xref target="I-D.ietf-tls-dtls13" format="default"/> specifies how to carry the		S 1.2, and
	CID in DTLS 1.3.</t>		<xref target="RFC9147" format="default"/> specifies how to carry the CID in DTLS
			1.3.</t>
	<t>To allow a receiver to determine whether a record has a CID or not,		<t>To allow a receiver to determine whether a record has a CID or not,
	connections which have negotiated this extension use a distinguished		connections that have negotiated this extension use a distinguished
	record type tls12_cid(TBD2). Use of this content type has the following		record type tls12_cid(25). The use of this content type has the following
	three implications:</t>		three implications:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The CID field is present and contains one or more bytes.</li>		<li>The CID field is present and contains one or more bytes.</li>
	<li>The MAC calculation follows the process described in <xref target="m ac" format="default"/>.</li>		<li>The MAC calculation follows the process described in <xref target="m ac" format="default"/>.</li>
	<li>The real content type is inside the encryption envelope, as describe d		<li>The real content type is inside the encryption envelope, as describe d
	below.</li>		below.</li>
	</ul>		</ul>
	<t>Plaintext records are not impacted by this extension. Hence, the format		<t>Plaintext records are not impacted by this extension. Hence, the format
	of the DTLSPlaintext structure is left unchanged, as shown in <xref target="dtls -plaintext" format="default"/>.</t>		of the DTLSPlaintext structure is left unchanged, as shown in <xref target="dtls -plaintext" format="default"/>.</t>
	<figure anchor="dtls-plaintext">		<figure anchor="dtls-plaintext">
	<name>DTLS 1.2 Plaintext Record Payload.</name>		<name>DTLS 1.2 Plaintext Record Payload</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	struct {		struct {
	ContentType type;		ContentType type;
	ProtocolVersion version;		ProtocolVersion version;
	uint16 epoch;		uint16 epoch;
	uint48 sequence_number;		uint48 sequence_number;
	uint16 length;		uint16 length;
	opaque fragment[DTLSPlaintext.length];		opaque fragment[DTLSPlaintext.length];
	} DTLSPlaintext;		} DTLSPlaintext;
	]]></artwork>		]]></sourcecode>
	</figure>		</figure>
	<t>When CIDs are being used, the content to be sent		<t>When CIDs are being used, the content to be sent
	is first wrapped along with its content type and optional padding into a		is first wrapped along with its content type and optional padding into a
	DTLSInnerPlaintext structure. This newly introduced structure is shown in		DTLSInnerPlaintext structure. This newly introduced structure is shown in
	<xref target="dtls-innerplaintext" format="default"/>.</t>		<xref target="dtls-innerplaintext" format="default"/>.</t>
	<figure anchor="dtls-innerplaintext">		<figure anchor="dtls-innerplaintext">
	<name>New DTLSInnerPlaintext Payload Structure.</name>		<name>New DTLSInnerPlaintext Payload Structure</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	struct {		struct {
	opaque content[length];		opaque content[length];
	ContentType real_type;		ContentType real_type;
	uint8 zeros[length_of_padding];		uint8 zeros[length_of_padding];
	} DTLSInnerPlaintext;		} DTLSInnerPlaintext;
	]]></artwork>		]]></sourcecode>
	</figure>		</figure>
	<dl>		<dl>
	<dt>		<dt>
	content </dt>		content:</dt>
	<dd>		<dd>
	<t>Corresponds to the fragment of a given length.</t>		<t>Corresponds to the fragment of a given length.</t>
	</dd>		</dd>
	<dt>		<dt>
	real_type </dt>		real_type:</dt>
	<dd>		<dd>
	<t>The content type describing the cleartext payload.</t>		<t>The content type describing the cleartext payload.</t>
	</dd>		</dd>
	<dt>		<dt>
	zeros </dt>		zeros:</dt>
	<dd>		<dd>
	<t>An arbitrary-length run of zero-valued bytes may appear in		<t>An arbitrary-length run of zero-valued bytes may appear in
	the cleartext after the type field. This provides an opportunity		the cleartext after the type field. This provides an opportunity
	for senders to pad any DTLS record by a chosen amount as long as		for senders to pad any DTLS record by a chosen amount as long as
	the total stays within record size limits. See Section 5.4 of		the total stays within record size limits. See <xref target="RFC8446" sectionFo
	<xref target="RFC8446" format="default"/> for more details. (Note that the term		rmat="of" section="5.4"/> for more details. (Note that the term TLSInnerPlaintex
	TLSInnerPlaintext in		t in
	RFC 8446 refers to DTLSInnerPlaintext in this specification.)</t>		RFC 8446 refers to DTLSInnerPlaintext in this specification.)</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>The DTLSInnerPlaintext byte sequence is then encrypted. To create the		<t>The DTLSInnerPlaintext byte sequence is then encrypted. To create the
	DTLSCiphertext structure shown in <xref target="dtls-ciphertext" format="default "/> the CID is added.</t>		DTLSCiphertext structure shown in <xref target="dtls-ciphertext" format="default "/>, the CID is added.</t>
	<figure anchor="dtls-ciphertext">		<figure anchor="dtls-ciphertext">
	<name>DTLS 1.2 CID-enhanced Ciphertext Record.</name>		<name>DTLS 1.2 CID-Enhanced Ciphertext Record</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	struct {		struct {
	ContentType outer_type = tls12_cid;		ContentType outer_type = tls12_cid;
	ProtocolVersion version;		ProtocolVersion version;
	uint16 epoch;		uint16 epoch;
	uint48 sequence_number;		uint48 sequence_number;
	opaque cid[cid_length]; // New field		opaque cid[cid_length]; // New field
	uint16 length;		uint16 length;
	opaque enc_content[DTLSCiphertext.length];		opaque enc_content[DTLSCiphertext.length];
	} DTLSCiphertext;		} DTLSCiphertext;
	]]></artwork>		]]></sourcecode>
	</figure>		</figure>
	<dl>		<dl>
	<dt>		<dt>
	outer_type </dt>		outer_type:</dt>
	<dd>		<dd>
	<t>The outer content type of a DTLSCiphertext record carrying a CID		<t>The outer content type of a DTLSCiphertext record carrying a CID
	is always set to tls12_cid(TBD2). The real content		is always set to tls12_cid(25). The real content
	type of the record is found in DTLSInnerPlaintext.real_type after		type of the record is found in DTLSInnerPlaintext.real_type after
	decryption.</t>		decryption.</t>
	</dd>		</dd>
	<dt>		<dt>
	cid </dt>		cid:</dt>
	<dd>		<dd>
	<t>The CID value, cid_length bytes long, as agreed at the time the ext ension		<t>The CID value, cid_length bytes long, as agreed at the time the ext ension
	has been negotiated. Recall that (as discussed previously) each peer chooses		has been negotiated. Recall that each peer chooses
	the CID value it will receive and use to identify the connection, so an		the CID value it will receive and use to identify the connection, so an
	implementation can choose to always receive CIDs of a fixed length. If,		implementation can choose to always receive CIDs of a fixed length. If,
	however, an implementation chooses to receive different lengths of CID,		however, an implementation chooses to receive CIDs of different lengths,
	the assigned CID values must be self-delineating since there is no other		the assigned CID values must be self-delineating, since there is no other
	mechanism available to determine what connection (and thus, what CID length)		mechanism available to determine what connection (and thus, what CID length)
	is in use.</t>		is in use.</t>
	</dd>		</dd>
	<dt>		<dt>
	enc_content </dt>		enc_content:</dt>
	<dd>		<dd>
	<t>The encrypted form of the serialized DTLSInnerPlaintext structure.< /t>		<t>The encrypted form of the serialized DTLSInnerPlaintext structure.< /t>
	</dd>		</dd>
	</dl>		</dl>
	<t>All other fields are as defined in RFC 6347.</t>		<t>All other fields are as defined in RFC 6347.</t>
	</section>		</section>
	<section anchor="mac" numbered="true" toc="default">		<section anchor="mac" numbered="true" toc="default">
	<name>Record Payload Protection</name>		<name>Record Payload Protection</name>
	<t>Several types of ciphers have been defined for use with TLS and DTLS an d the		<t>Several types of ciphers have been defined for use with TLS and DTLS, a nd the
	MAC calculations for those ciphers differ slightly.</t>		MAC calculations for those ciphers differ slightly.</t>
	<t>This specification modifies the MAC calculation as defined in <xref tar get="RFC6347" format="default"/> and		<t>This specification modifies the MAC calculation as defined in <xref tar get="RFC6347" format="default"/> and
	<xref target="RFC7366" format="default"/>, as well as the definition of the addi tional data used with AEAD		<xref target="RFC7366" format="default"/>, as well as the definition of the addi tional data used with Authenticated Encryption with Associated Data (AEAD)
	ciphers provided in <xref target="RFC6347" format="default"/>, for records with content type tls12_cid. The		ciphers provided in <xref target="RFC6347" format="default"/>, for records with content type tls12_cid. The
	modified algorithm MUST NOT be applied to records that do not carry a CID, i.e.,		modified algorithm <bcp14>MUST NOT</bcp14> be applied to records that do not car ry a CID, i.e.,
	records with content type other than tls12_cid.</t>		records with content type other than tls12_cid.</t>
	<t>The following fields are defined in this document; all other fields are as		<t>The following fields are defined in this document; all other fields are as
	defined in the cited documents.</t>		defined in the cited documents.</t>
	<dl>		<dl>
	<dt>		<dt>
	cid </dt>		cid:</dt>
	<dd>		<dd>
	<t>Value of the negotiated CID (variable length).</t>		<t>Value of the negotiated CID (variable length).</t>
	</dd>		</dd>
	<dt>		<dt>
	cid_length </dt>		cid_length:</dt>
	<dd>		<dd>
	<t>1 byte field indicating the length of the negotiated CID.</t>		<t>The length (in bytes) of the negotiated CID (one-byte integer).</t>
	</dd>		</dd>
	<dt>		<dt>
	length_of_DTLSInnerPlaintext </dt>		length_of_DTLSInnerPlaintext:</dt>
	<dd>		<dd>
	<t>The length (in bytes) of the serialized DTLSInnerPlaintext (two-byt e integer).		<t>The length (in bytes) of the serialized DTLSInnerPlaintext (two-byt e integer).
	The length MUST NOT exceed 2^14.</t>		The length <bcp14>MUST NOT</bcp14> exceed 2^14.</t>
	</dd>		</dd>
	<dt>		<dt>
	seq_num_placeholder </dt>		seq_num_placeholder:</dt>
	<dd>		<dd>
	<t>8 bytes of 0xff</t>		<t>8 bytes of 0xff.</t>
	</dd>		</dd>
	</dl>		</dl>
	<t>Note "+" denotes concatenation.</t>		<t>Note that "+" denotes concatenation.</t>
	<section anchor="block-ciphers" numbered="true" toc="default">		<section anchor="block-ciphers" numbered="true" toc="default">
	<name>Block Ciphers</name>		<name>Block Ciphers</name>
	<t>The following MAC algorithm applies to block ciphers		<t>The following MAC algorithm applies to block ciphers
	that do not use the Encrypt-then-MAC processing		that do not use the Encrypt-then-MAC processing
	described in <xref target="RFC7366" format="default"/>.</t>		described in <xref target="RFC7366" format="default"/>.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	MAC(MAC_write_key,		MAC(MAC_write_key,
	seq_num_placeholder +		seq_num_placeholder +
	tls12_cid +		tls12_cid +
	cid_length +		cid_length +
	tls12_cid +		tls12_cid +
	DTLSCiphertext.version +		DTLSCiphertext.version +
	epoch +		epoch +
	sequence_number +		sequence_number +
	cid +		cid +
	length_of_DTLSInnerPlaintext +		length_of_DTLSInnerPlaintext +
	DTLSInnerPlaintext.content +		DTLSInnerPlaintext.content +
	DTLSInnerPlaintext.real_type +		DTLSInnerPlaintext.real_type +
	DTLSInnerPlaintext.zeros		DTLSInnerPlaintext.zeros
	);		);
	]]></artwork>		]]></sourcecode>
	<t>The rationale behind this construction is to separate the MAC input		<t>The rationale behind this construction is to separate the MAC input
	for DTLS without the connection ID from the MAC input with the		for DTLS without the connection ID from the MAC input with the
	connection ID. The former always consists of a sequence number		connection ID. The former always consists of a sequence number
	followed by some other content type than tls12_cid; the latter		followed by some content type other than tls12_cid; the latter
	always consists of the seq_num_placeholder followed by tls12_cid.		always consists of the seq_num_placeholder followed by tls12_cid.
	Although 2^64-1 is potentially a valid sequence number, tls12_cid		Although 2^64-1 is potentially a valid sequence number, tls12_cid
	will never be a valid content type when the connection ID is not in use.		will never be a valid content type when the connection ID is not in use.
	In addition, the epoch and sequence_number are now fed into		In addition, the epoch and sequence_number are now fed into
	the MAC in the same order as they appear on the wire.</t>		the MAC in the same order as they appear on the wire.</t>
	</section>		</section>
	<section anchor="block-ciphers-with-encrypt-then-mac-processing" numbered= "true" toc="default">		<section anchor="block-ciphers-with-encrypt-then-mac-processing" numbered= "true" toc="default">
	<name>Block Ciphers with Encrypt-then-MAC processing</name>		<name>Block Ciphers with Encrypt-then-MAC Processing</name>
	<t>The following MAC algorithm applies to block ciphers		<t>The following MAC algorithm applies to block ciphers
	that use the Encrypt-then-MAC processing		that use the Encrypt-then-MAC processing
	described in <xref target="RFC7366" format="default"/>.</t>		described in <xref target="RFC7366" format="default"/>.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	MAC(MAC_write_key,		MAC(MAC_write_key,
	seq_num_placeholder +		seq_num_placeholder +
	tls12_cid +		tls12_cid +
	cid_length +		cid_length +
	tls12_cid +		tls12_cid +
	DTLSCiphertext.version +		DTLSCiphertext.version +
	epoch +		epoch +
	sequence_number +		sequence_number +
	cid +		cid +
	DTLSCiphertext.length +		DTLSCiphertext.length +
	IV +		IV +
	ENC(content + padding + padding_length));		ENC(content + padding + padding_length)
	]]></artwork>		);
			]]></sourcecode>
	</section>		</section>
	<section anchor="aead-ciphers" numbered="true" toc="default">		<section anchor="aead-ciphers" numbered="true" toc="default">
	<name>AEAD Ciphers</name>		<name>AEAD Ciphers</name>
	<t>For ciphers utilizing authenticated encryption with additional		<t>For ciphers utilizing AEAD,
	data the following modification is made to the additional data calculation.</t>		the following modification is made to the additional data calculation.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode name="" type="tls-presentation"><![CDATA[
	additional_data = seq_num_placeholder +		additional_data = seq_num_placeholder +
	tls12_cid +		tls12_cid +
	cid_length +		cid_length +
	tls12_cid +		tls12_cid +
	DTLSCiphertext.version +		DTLSCiphertext.version +
	epoch +		epoch +
	sequence_number +		sequence_number +
	cid +		cid +
	length_of_DTLSInnerPlaintext;		length_of_DTLSInnerPlaintext;
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="peer-address-update" numbered="true" toc="default">		<section anchor="peer-address-update" numbered="true" toc="default">
	<name>Peer Address Update</name>		<name>Peer Address Update</name>
	<t>When a record with a CID is received that has a source address		<t>When a record with a CID is received that has a source address
	different from the one currently associated with the DTLS connection,		different from the one currently associated with the DTLS connection,
	the receiver MUST NOT replace the address it uses for sending records		the receiver <bcp14>MUST NOT</bcp14> replace the address it uses for sending rec ords
	to its peer with the source address specified in the received datagram,		to its peer with the source address specified in the received datagram,
	unless the following three conditions are met:</t>		unless the following three conditions are met:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The received datagram has been cryptographically verified using		<li>The received datagram has been cryptographically verified using
	the DTLS record layer processing procedures.</li>		the DTLS record layer processing procedures.</li>
	<li>The received datagram is "newer" (in terms of both epoch and sequenc e		<li>The received datagram is "newer" (in terms of both epoch and sequenc e
	number) than the newest datagram received. Reordered datagrams that are		number) than the newest datagram received. Reordered datagrams that are
	sent prior to a change in a peer address might otherwise cause a valid		sent prior to a change in a peer address might otherwise cause a valid
	address change to be reverted. This also limits the ability of an attacker		address change to be reverted. This also limits the ability of an attacker
	to use replayed datagrams to force a spurious address change, which		to use replayed datagrams to force a spurious address change, which
	could result in denial of service. An attacker might be able to succeed		could result in denial of service. An attacker might be able to succeed
	in changing a peer address if they are able to rewrite source addresses		in changing a peer address if they are able to rewrite source addresses
	and if replayed packets are able to arrive before any original.</li>		and if replayed packets are able to arrive before any original.</li>
	<li>There is a strategy for ensuring that the new peer address is able t o		<li>There is a strategy for ensuring that the new peer address is able t o
	receive and process DTLS records. No strategy is mandated by this specification		receive and process DTLS records. No strategy is mandated by this specification,
	but see note (*) below.</li>		but see note (*) below.</li>
	</ul>		</ul>
	<t>The conditions above are necessary to protect against attacks that use datagrams with		<t>The conditions above are necessary to protect against attacks that use datagrams with
	spoofed addresses or replayed datagrams to trigger attacks. Note that there		spoofed addresses or replayed datagrams to trigger attacks. Note that there
	is no requirement for use of the anti-replay window mechanism defined in		is no requirement for the use of the anti-replay window mechanism defined in
	Section 4.1.2.6 of DTLS 1.2. Both solutions, the "anti-replay window" or		<xref target="RFC6347" sectionFormat="of" section="4.1.2.6"/>. Both solutions, t
			he "anti-replay window" or
	"newer" algorithm, will prevent address updates from replay attacks while the		"newer" algorithm, will prevent address updates from replay attacks while the
	latter will only apply to peer address updates and the former applies to any		latter will only apply to peer address updates and the former applies to any
	application layer traffic.</t>		application layer traffic.</t>
	<t>Note that datagrams that pass the DTLS cryptographic verification proce dures		<t>Note that datagrams that pass the DTLS cryptographic verification proce dures
	but do not trigger a change of peer address are still valid DTLS records and		but do not trigger a change of peer address are still valid DTLS records and
	are still to be passed to the application.</t>		are still to be passed to the application.</t>
	<t>(*) Note: Application protocols that implement protection against spoof ed addresses		<t indent="3">(*) Note: Application protocols that implement protection ag ainst spoofed addresses
	depend on being aware of changes in peer addresses so that they can engage the n ecessary		depend on being aware of changes in peer addresses so that they can engage the n ecessary
	mechanisms. When delivered such an event, an application layer-specific		mechanisms. When delivered such an event, an address validation mechanism specif
	address validation mechanism can be triggered, for example one that is based on		ic to the application layer can be triggered -- for example, one that is based o
			n
	successful exchange of a minimal amount of ping-pong traffic with the peer.		successful exchange of a minimal amount of ping-pong traffic with the peer.
	Alternatively, an DTLS-specific mechanism may be used, as described in		Alternatively, a DTLS-specific mechanism may be used, as described in
	<xref target="I-D.ietf-tls-dtls-rrc" format="default"/>.</t>		<xref target="DTLS-RRC" format="default"/>.</t>
	<t>DTLS implementations MUST silently discard records with bad MACs or tha		<t>DTLS implementations <bcp14>MUST</bcp14> silently discard records with
	t are		bad MACs or that are
	otherwise invalid.</t>		otherwise invalid.</t>
	</section>		</section>
	<section anchor="examples" numbered="true" toc="default">		<section anchor="examples" numbered="true" toc="default">
	<name>Examples</name>		<name>Example</name>
	<t><xref target="dtls-example2" format="default"/> shows an example exchan ge where a CID is		<t><xref target="dtls-example2" format="default"/> shows an example exchan ge where a CID is
	used uni-directionally from the client to the server. To indicate that		used unidirectionally from the client to the server. To indicate that
	a zero-length CID is present in the "connection_id" extension		a zero-length CID is present in the "connection_id" extension,
	we use the notation 'connection_id=empty'.</t>		we use the notation 'connection_id=empty'.</t>
	<figure anchor="dtls-example2">		<figure anchor="dtls-example2">
	<name>Example DTLS 1.2 Exchange with CID</name>		<name>Example DTLS 1.2 Exchange with CID</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	Client Server		Client Server
	------ ------		------ ------
	ClientHello -------->		ClientHello -------->
	(connection_id=empty)		(connection_id=empty)
	skipping to change at line 465 ¶		skipping to change at line 468 ¶
	[ChangeCipherSpec]		[ChangeCipherSpec]
	<-------- Finished		<-------- Finished
	Application Data ========>		Application Data ========>
	<CID=100>		<CID=100>
	<======== Application Data		<======== Application Data
	Legend:		Legend:
	<...> indicates that a connection id is used in the record layer		<...> indicates that a connection ID is used in the record layer
	(...) indicates an extension		(...) indicates an extension
	[...] indicates a payload other than a handshake message		[...] indicates a payload other than a handshake message
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Note: In the example exchange the CID is included in the record layer		<t indent="3">Note: In the example exchange, the CID is included in the re
	once encryption is enabled. In DTLS 1.2 only one handshake message is		cord layer
			once encryption is enabled. In DTLS 1.2, only one handshake message is
	encrypted, namely the Finished message. Since the example shows how to		encrypted, namely the Finished message. Since the example shows how to
	use the CID for payloads sent from the client to the server, only the		use the CID for payloads sent from the client to the server, only the
	record layer payloads containing the Finished message or application data		record layer payloads containing the Finished message or application data
	include a CID.</t>		include a CID.</t>
	</section>		</section>
	<section anchor="priv-cons" numbered="true" toc="default">		<section anchor="priv-cons" numbered="true" toc="default">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>The CID replaces the previously used 5-tuple and, as such, introduces		<t>The CID replaces the previously used 5-tuple and, as such, introduces
	an identifier that remains persistent during the lifetime of a DTLS connection.		an identifier that remains persistent during the lifetime of a DTLS connection.
	Every identifier introduces the risk of linkability, as explained in <xref targe t="RFC6973" format="default"/>.</t>		Every identifier introduces the risk of linkability, as explained in <xref targe t="RFC6973" format="default"/>.</t>
	<t>An on-path adversary observing the DTLS protocol exchanges between the		<t>An on-path adversary observing the DTLS protocol exchanges between the
	DTLS client and the DTLS server is able to link the observed payloads to all		DTLS client and the DTLS server is able to link the observed payloads to all
	subsequent payloads carrying the same ID pair (for bi-directional		subsequent payloads carrying the same ID pair (for bidirectional
	communication). Without multi-homing or mobility, the use of the CID		communication). Without multihoming or mobility, the use of the CID
	exposes the same information as the 5-tuple.</t>		exposes the same information as the 5-tuple.</t>
	<t>With multi-homing, a passive attacker is able to correlate the communic ation		<t>With multihoming, a passive attacker is able to correlate the communica tion
	interaction over the two paths. The lack of a CID update mechanism		interaction over the two paths. The lack of a CID update mechanism
	in DTLS 1.2 makes this extension unsuitable for mobility scenarios where		in DTLS 1.2 makes this extension unsuitable for mobility scenarios where
	correlation must be considered. Deployments that use DTLS in multi-homing		correlation must be considered. Deployments that use DTLS in multihoming
	environments and are concerned about these aspects SHOULD refuse to use CIDs in		environments and are concerned about these aspects <bcp14>SHOULD</bcp14> refuse
			to use CIDs in
	DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and		DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and
	sequence number encryption is available.</t>		sequence number encryption is available.</t>
	<t>The specification introduces record padding for the CID-enhanced record layer,		<t>This specification introduces record padding for the CID-enhanced recor d layer,
	which is a privacy feature not available with the original DTLS 1.2 specificatio n.		which is a privacy feature not available with the original DTLS 1.2 specificatio n.
	Padding allows to inflate the size of the ciphertext making traffic analysis		Padding allows the size of the ciphertext to be inflated, making traffic analysi
	more difficult. More details about record padding can be found in Section 5.4		s
	and Appendix E.3 of RFC 8446.</t>		more difficult. More details about record padding can be found in
			Section&nbsp;<xref target="RFC8446" section="5.4"
			sectionFormat="bare"/> and Appendix&nbsp;<xref target="RFC8446" section="E.3"
			sectionFormat="bare"/> of <xref target="RFC8446"/>.</t>
	<t>Finally, endpoints can use the CID to attach arbitrary per-connection m etadata		<t>Finally, endpoints can use the CID to attach arbitrary per-connection m etadata
	to each record they receive on a given connection. This may be used as a mechani sm to communicate		to each record they receive on a given connection. This may be used as a mechani sm to communicate
	per-connection information to on-path observers. There is no straightforward way to		per-connection information to on-path observers. There is no straightforward way to
	address this concern with CIDs that contain arbitrary values. Implementations		address this concern with CIDs that contain arbitrary values. Implementations
	concerned about this aspect SHOULD refuse to use CIDs.</t>		concerned about this aspect <bcp14>SHOULD</bcp14> refuse to use CIDs.</t>
	</section>		</section>
	<section anchor="sec-cons" numbered="true" toc="default">		<section anchor="sec-cons" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>An on-path adversary can create reflection attacks		<t>An on-path adversary can create reflection attacks
	against third parties because a DTLS peer has no means to distinguish a		against third parties because a DTLS peer has no means to distinguish a
	genuine address update event (for example, due to a NAT rebinding) from one		genuine address update event (for example, due to a NAT rebinding) from one
	that is malicious. This attack is of particular concern when the request is smal l		that is malicious. This attack is of particular concern when the request is smal l
	and the response large. See <xref target="peer-address-update" format="default"/ > for more		and the response large. See <xref target="peer-address-update" format="default"/ > for more
	on address updates.</t>		on address updates.</t>
	<t>Additionally, an attacker able to observe the data traffic exchanged be tween		<t>Additionally, an attacker able to observe the data traffic exchanged be tween
	two DTLS peers is able to replay datagrams with modified IP address/port numbers .</t>		two DTLS peers is able to replay datagrams with modified IP addresses / port num bers.</t>
	<t>The topic of peer address updates is discussed in <xref target="peer-ad dress-update" format="default"/>.</t>		<t>The topic of peer address updates is discussed in <xref target="peer-ad dress-update" format="default"/>.</t>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document requests three actions from IANA.</t>		<t>This document implements three IANA updates.</t>
	<section anchor="extra-column-to-tls-extensiontype-values-registry" number ed="true" toc="default">		<section anchor="extra-column-to-tls-extensiontype-values-registry" number ed="true" toc="default">
	<name>Extra Column to TLS ExtensionType Values Registry</name>		<name>Extra Column Added to the TLS ExtensionType Values Registry</name>
	<t>IANA is requested to add an extra column named "DTLS-Only" to the		<t>IANA has added an extra column named "DTLS-Only" to the
	"TLS ExtensionType Values" registry to indicate whether an extension is only		"TLS ExtensionType Values" registry to indicate whether an extension is only
	applicable to DTLS and to include this document as an additional reference		applicable to DTLS and to include this document as an additional reference
	for the registry.</t>		for the registry.</t>
	</section>		</section>
	<section anchor="entry-to-the-tls-extensiontype-values-registry" numbered= "true" toc="default">		<section anchor="entry-to-the-tls-extensiontype-values-registry" numbered= "true" toc="default">
	<name>Entry to the TLS ExtensionType Values Registry</name>		<name>New Entry in the TLS ExtensionType Values Registry</name>
	<t>IANA is requested to allocate an entry to the existing "TLS Extension		<t>IANA has allocated an entry in the existing "TLS ExtensionType
	Type		Values" registry for connection_id(54), as described
	Values" registry, for connection_id(TBD1) as described		in the table below. Although the value 53 had been allocated by early allocation
	in the table below. Although the value 53 has been allocated by early allocation		for a previous version of this document, it
	for a previous version of this document, it
	is incompatible with this document.		is incompatible with this document.
	Once this document is approved for publication, the early allocation will be dep recated		Therefore, the early allocation has been deprecated
	in favor of this assignment.</t>		in favor of this assignment.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table anchor="iana-tls-ext-entry">
	Value Extension Name TLS 1.3 DTLS-Only Recommended Reference		<name></name>
	TBD1 connection_id CH, SH Y N [[This doc]]		<thead>
	]]></artwork>		<tr>
	<t>A new column "DTLS-Only" is added to the registry.		<th>Value</th>
			<th>Extension Name</th>
			<th>TLS 1.3</th>
			<th>DTLS-Only</th>
			<th>Recommended</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>54</td>
			<td>connection_id</td>
			<td>CH, SH</td>
			<td>Y</td>
			<td>N</td>
			<td>RFC 9146</td>
			</tr>
			</tbody>
			</table>
			<t>A new column, "DTLS-Only", has been added to the registry.
	The valid entries are "Y" if the extension is only applicable to DTLS, "N" other wise.		The valid entries are "Y" if the extension is only applicable to DTLS, "N" other wise.
	All the pre-existing entries are given the value "N".</t>		All the pre-existing entries are given the value "N".</t>
	<t>Note: The value "N" in the Recommended column is set because this		<t indent="3">Note: The value "N" in the "Recommended" column is set bec ause this
	extension is intended only for specific use cases. This document describes		extension is intended only for specific use cases. This document describes
	the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, a nd		the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, a nd
	its usage for DTLS 1.3 is described in <xref target="I-D.ietf-tls-dtls13" format ="default"/>.</t>		its usage for DTLS 1.3 is described in <xref target="RFC9147" format="default"/> .</t>
	</section>		</section>
	<section anchor="entry-to-the-tls-contenttype-registry" numbered="true" to c="default">		<section anchor="entry-to-the-tls-contenttype-registry" numbered="true" to c="default">
	<name>Entry to the TLS ContentType Registry</name>		<name>New Entry in the TLS ContentType Registry</name>
	<t>IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType		<t>IANA has allocated tls12_cid(25) in the "TLS ContentType"
	"		registry. The tls12_cid content type is only applicable to DTLS 1.2.</t>
	registry. The tls12_cid ContentType is only applicable to DTLS 1.2.</t>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner">
	<organization/>
	</author>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
	347">
	<front>
	<title>Datagram Transport Layer Security Version 1.2</title>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla">
	<organization/>
	</author>
	<author fullname="N. Modadugu" initials="N." surname="Modadugu">
	<organization/>
	</author>
	<date month="January" year="2012"/>
	<abstract>
	<t>This document specifies version 1.2 of the Datagram Transport L
	ayer Security (DTLS) protocol. The DTLS protocol provides communications privac
	y for datagram protocols. The protocol allows client/server applications to com
	municate in a way that is designed to prevent eavesdropping, tampering, or messa
	ge forgery. The DTLS protocol is based on the Transport Layer Security (TLS) pr
	otocol and provides equivalent security guarantees. Datagram semantics of the u
	nderlying transport are preserved by the DTLS protocol. This document updates D
	TLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6347"/>
	<seriesInfo name="DOI" value="10.17487/RFC6347"/>
	</reference>
	<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
	446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<author fullname="E. Rescorla" initials="E." surname="Rescorla">
	<organization/>
	</author>
	<date month="August" year="2018"/>
	<abstract>
	<t>This document specifies version 1.3 of the Transport Layer Secu
	rity (TLS) protocol. TLS allows client/server applications to communicate over
	the Internet in a way that is designed to prevent eavesdropping, tampering, and
	message forgery.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
	mplementations.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8446"/>
	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba">
	<organization/>
	</author>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	<reference anchor="RFC7366" target="https://www.rfc-editor.org/info/rfc7
	366">
	<front>
	<title>Encrypt-then-MAC for Transport Layer Security (TLS) and Datag
	ram Transport Layer Security (DTLS)</title>
	<author fullname="P. Gutmann" initials="P." surname="Gutmann">
	<organization/>
	</author>
	<date month="September" year="2014"/>
	<abstract>
	<t>This document describes a means of negotiating the use of the e
	ncrypt-then-MAC security mechanism in place of the existing MAC-then-encrypt mec
	hanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (
	DTLS). The MAC-then-encrypt mechanism has been the subject of a number of secur
	ity vulnerabilities over a period of many years.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="7366"/>
	<seriesInfo name="DOI" value="10.17487/RFC7366"/>
	</reference>
	</references>
	<references>
	<name>Informative References</name>
	<reference anchor="RFC6973" target="https://www.rfc-editor.org/info/rfc6
	973">
	<front>
	<title>Privacy Considerations for Internet Protocols</title>
	<author fullname="A. Cooper" initials="A." surname="Cooper">
	<organization/>
	</author>
	<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
	<organization/>
	</author>
	<author fullname="B. Aboba" initials="B." surname="Aboba">
	<organization/>
	</author>
	<author fullname="J. Peterson" initials="J." surname="Peterson">
	<organization/>
	</author>
	<author fullname="J. Morris" initials="J." surname="Morris">
	<organization/>
	</author>
	<author fullname="M. Hansen" initials="M." surname="Hansen">
	<organization/>
	</author>
	<author fullname="R. Smith" initials="R." surname="Smith">
	<organization/>
	</author>
	<date month="July" year="2013"/>
	<abstract>
	<t>This document offers guidance for developing privacy considerat
	ions for inclusion in protocol specifications. It aims to make designers, imple
	menters, and users of Internet protocols aware of privacy-related design choices
	. It suggests that whether any individual RFC warrants a specific privacy consi
	derations section will depend on the document's content.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6973"/>
	<seriesInfo name="DOI" value="10.17487/RFC6973"/>
	</reference>
	<reference anchor="I-D.ietf-tls-dtls13" target="https://www.ietf.org/arc
	hive/id/draft-ietf-tls-dtls13-43.txt">
	<front>
	<title>The Datagram Transport Layer Security (DTLS) Protocol Version
	1.3</title>
	<author fullname="Eric Rescorla">
	<organization>RTFM, Inc.</organization>
	</author>
	<author fullname="Hannes Tschofenig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Nagendra Modadugu">
	<organization>Google, Inc.</organization>
	</author>
	<date day="30" month="April" year="2021"/>
	<abstract>
	<t> This document specifies Version 1.3 of the Datagram Transpor
	t Layer
	Security (DTLS) protocol. DTLS 1.3 allows client/server applications
	to communicate over the Internet in a way that is designed to prevent
	eavesdropping, tampering, and message forgery.
	The DTLS 1.3 protocol is intentionally based on the Transport Layer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
	Security (TLS) 1.3 protocol and provides equivalent security		xml"/>
	guarantees with the exception of order protection/non-replayability.		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.
	Datagram semantics of the underlying transport are preserved by the		xml"/>
	DTLS protocol.		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
			xml"/>
	This document obsoletes RFC 6347.		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
			xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7366.
			xml"/>
	</t>		</references>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-43"/>
	</reference>
	<reference anchor="I-D.ietf-tls-dtls-rrc" target="https://www.ietf.org/a
	rchive/id/draft-ietf-tls-dtls-rrc-00.txt">
	<front>
	<title>Return Routability Check for DTLS 1.2 and DTLS 1.3</title>
	<author fullname="Hannes Tschofenig">
	<organization>Arm Limited</organization>
	</author>
	<author fullname="Thomas Fossati">
	<organization>Arm Limited</organization>
	</author>
	<date day="9" month="June" year="2021"/>
	<abstract>
	<t> This document specifies a return routability check for use i
	n context
	of the Connection ID (CID) construct for the Datagram Transport Layer
	Security (DTLS) protocol versions 1.2 and 1.3.
	Discussion Venues		<references>
	This note is to be removed before publishing as an RFC.		<name>Informative References</name>
	Discussion of this document takes place on the Transport Layer		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6973.
	Security Working Group mailing list (tls@ietf.org), which is archived		xml"/>
	at https://mailarchive.ietf.org/arch/browse/tls/.
	Source for this draft and an issue tracker can be found at		<!-- draft-ietf-tls-dtls13 (RFC 9147) -->
	https://github.com/tlswg/dtls-rrc.		<reference anchor='RFC9147' target="https://www.rfc-editor.org/info/rfc9147">
			<front>
			<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
			<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
			<organization />
			</author>
			<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
			<organization />
			</author>
			<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
			<organization />
			</author>
			<date year='2022' month='March' />
			</front>
			<seriesInfo name="RFC" value="9147"/>
			<seriesInfo name="DOI" value="10.17487/RFC9147"/>
			</reference>
	</t>		<!-- draft-ietf-tls-dtls-rrc (I-D Exists) ("long way"; one author is editor) -->
	</abstract>		<reference anchor='DTLS-RRC'>
	</front>		<front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls-rrc-00"/>		<title>Return Routability Check for DTLS 1.2 and DTLS 1.3</title>
	</reference>		<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig' role="edi
			tor">
			<organization />
			</author>
			<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
			<organization />
			</author>
			<date month='March' day='7' year='2022'/>
			</front>
			<seriesInfo name='Internet-Draft' value='draft-ietf-tls-dtls-rrc-05' />
			</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="history" numbered="true" toc="default">		<section anchor="acknowledgements" numbered="false" toc="default">
	<name>History</name>		<name>Acknowledgements</name>
	<t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t>		<t>We would like to thank <contact fullname="Hanno Becker"/>, <contact ful
	<t>draft-ietf-tls-dtls-connection-id-12</t>		lname="
	<ul spacing="normal">		Martin Duke"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Ben Kaduk"
	<li>Improved peer address update text</li>		/>, <contact fullname="Warren Kumari"/>,
	<li>Editorial improvements</li>		<contact fullname="Francesca Palombini"/>, <contact fullname="Tom Petch"/>, <con
	<li>Clarification regarding the use of the TLS ExtensionType Values Regi		tact fullname="John Scudder"/>, <contact fullname="Sean Turner"/>, <contact full
	stry</li>		name="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/>
	</ul>		for their review comments.</t>
	<t>draft-ietf-tls-dtls-connection-id-11</t>		<t>Finally, we want to thank the IETF TLS Working Group chairs, <contact f
	<ul spacing="normal">		ullname="Chris Wood"/>, <contact fullname="Joseph Salowey"/>, and
	<li>Enhanced IANA considerations section</li>		<contact fullname="Sean Turner"/>, for their patience, support, and feedback.</t
	<li>Clarifications regarding CID negotiation and zero-length CIDs</li>		>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-10</t>
	<ul spacing="normal">
	<li>Clarify privacy impact.</li>
	<li>Have security considerations point to <xref target="peer-address-upd
	ate" format="default"/>.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-09</t>
	<ul spacing="normal">
	<li>Changed MAC/additional data calculation.</li>
	<li>Disallow sending MAC failure fatal alerts to non-validated peers.</l
	i>
	<li>Incorporated editorial review comments by Ben Kaduk.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-08</t>
	<ul spacing="normal">
	<li>RRC draft moved from normative to informative.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-07</t>
	<ul spacing="normal">
	<li>Wording changes in the security and privacy
	consideration and the peer address update
	sections.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-06</t>
	<ul spacing="normal">
	<li>Updated IANA considerations</li>
	<li>Enhanced security consideration section to describe a potential
	man-in-the-middle attack concerning address validation.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-05</t>
	<ul spacing="normal">
	<li>Restructed Section 5 "Record Payload Protection"</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-04</t>
	<ul spacing="normal">
	<li>Editorial simplifications to the 'Record Layer Extensions' and the '
	Record Payload Protection' sections.</li>
	<li>Added MAC calculations for block ciphers with and without Encrypt-th
	en-MAC processing.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-03</t>
	<ul spacing="normal">
	<li>Updated list of contributors</li>
	<li>Updated list of contributors and acknowledgements</li>
	<li>Updated example</li>
	<li>Changed record layer design</li>
	<li>Changed record payload protection</li>
	<li>Updated introduction and security consideration section</li>
	<li>Author- and affiliation changes</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-02</t>
	<ul spacing="normal">
	<li>Move to internal content types a la DTLS 1.3.</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-01</t>
	<ul spacing="normal">
	<li>Remove 1.3 based on the WG consensus at IETF 101</li>
	</ul>
	<t>draft-ietf-tls-dtls-connection-id-00</t>
	<ul spacing="normal">
	<li>Initial working group version
	(containing a solution for DTLS 1.2 and 1.3)</li>
	</ul>
	<t>draft-rescorla-tls-dtls-connection-id-00</t>
	<ul spacing="normal">
	<li>Initial version</li>
	</ul>
	</section>
	<section anchor="working-group-information" numbered="true" toc="default">
	<name>Working Group Information</name>
	<t>RFC EDITOR: PLEASE REMOVE THE THIS SECTION</t>
	<t>The discussion list for the IETF TLS working group is located at the e-
	mail
	address <eref target="mailto:tls@ietf.org">tls@ietf.org</eref>. Information on t
	he group and information on how to
	subscribe to the list is at <eref target="https://www1.ietf.org/mailman/listinfo
	/tls">https://www1.ietf.org/mailman/listinfo/tls</eref></t>
	<t>Archives of the list can be found at:
	<eref target="https://www.ietf.org/mail-archive/web/tls/current/index.html">http
	s://www.ietf.org/mail-archive/web/tls/current/index.html</eref></t>
	</section>		</section>
	<section anchor="contributors" numbered="true" toc="default">		<section anchor="contributors" numbered="false" toc="default">
	<name>Contributors</name>		<name>Contributors</name>
	<t>Many people have contributed to this specification, and we would like t o thank		<t>Many people have contributed to this specification, and we would like t o thank
	the following individuals for their contributions:</t>		the following individuals for their contributions:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	* Yin Xinxing		<contact fullname="Yin Xinxing">
	Huawei		<organization>Huawei</organization>
	yinxinxing@huawei.com		<address>
	]]></artwork>		<email>yinxinxing@huawei.com</email>
	<artwork name="" type="" align="left" alt=""><![CDATA[		</address>
	* Nikos Mavrogiannopoulos		</contact>
	RedHat
	nmav@redhat.com		<contact fullname="Nikos Mavrogiannopoulos">
	]]></artwork>		<organization>RedHat</organization>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<address>
	* Tobias Gondrom		<email>nmav@redhat.com</email>
	tobias.gondrom@gondrom.org		</address>
	]]></artwork>		</contact>
			<contact fullname="Tobias Gondrom">
			<organization></organization>
			<address>
			<email>tobias.gondrom@gondrom.org</email>
			</address>
			</contact>
	<t>Additionally, we would like to thank the Connection ID task force team members:</t>		<t>Additionally, we would like to thank the Connection ID task force team members:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Martin Thomson (Mozilla)</li>		<li><t><contact fullname="Martin Thomson"/> (Mozilla)</t></li>
	<li>Christian Huitema (Private Octopus Inc.)</li>		<li><t><contact fullname="Christian Huitema"/> (Private Octopus Inc.)</t
	<li>Jana Iyengar (Google)</li>		></li>
	<li>Daniel Kahn Gillmor (ACLU)</li>		<li><t><contact fullname="Jana Iyengar"/> (Google)</t></li>
	<li>Patrick McManus (Mozilla)</li>		<li><t><contact fullname="Daniel Kahn Gillmor"/> (ACLU)</t></li>
	<li>Ian Swett (Google)</li>		<li><t><contact fullname="Patrick McManus"/> (Mozilla)</t></li>
	<li>Mark Nottingham (Fastly)</li>		<li><t><contact fullname="Ian Swett"/> (Google)</t></li>
			<li><t><contact fullname="Mark Nottingham"/> (Fastly)</t></li>
	</ul>		</ul>
	<t>The task force team discussed various design ideas, including cryptogra phically generated session		<t>The task force team discussed various design ideas, including cryptogra phically generated session
	ids using hash chains and public key encryption, but dismissed them due to their		IDs using hash chains and public key encryption, but dismissed them due to their
	inefficiency. The approach described in this specification is the		inefficiency. The approach described in this specification is the
	simplest possible design that works given the limitations of DTLS 1.2. DTLS 1.3		simplest possible design that works, given the limitations of DTLS 1.2. DTLS 1.3
	provides		provides
	better privacy features and developers are encouraged to switch to the new versi		better privacy features, and developers are encouraged to switch to the new vers
	on of DTLS.</t>		ion of DTLS.</t>
	</section>
	<section anchor="acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>
	<t>We would like to thank Hanno Becker, Martin Duke, Lars Eggert, Ben Kadu
	k, Warren Kumari,
	Francesca Palombini, Tom Petch, John Scudder, Sean Turner, Eric Vyncke, and Robe
	rt Wilton
	for their review comments.</t>
	<t>Finally, we want to thank the IETF TLS working group chairs, Chris Wood
	, Joseph Salowey, and
	Sean Turner, for their patience, support and feedback.</t>
	</section>		</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAB1U0mAAA+0923IbN5bv+Aqs8hBphqQt23ES5VJRJDnWxLe15HinUlkX
	yAZJlJrd3Ea3ZMaV/Zb9lv2yPTdcukk58szWPi2rZiKyG8DBud8Aj8dj1bq2
	tEf6pK4qO2tdXenzwlatmzvbeD2vG316+exCH04eKDOdNvb6KP7QG3SqinpW
	mRXMVTRm3o6dbefjtvTjAv9vFl8du2J8+FDNTGsXdbM50r4tVLcu4Ls/0o8f
	PvpSKbdujvS6sV88/PKry6bz7YP797++DxA01hzpCzvrGtdu1E3dXC2aulsf
	aQBJXdkN/FIc6fOqtU1l2/EpQqKUb01VvDNlXQF0G+vV2h0prZv5zBa+3ZTy
	q9ZtPcv+dBViIvzg66Zt7NzH75tV72vbuFl8eVavVjA2PnVV6aq0jH3fjkvn
	2zFMMq1LeG1c/+Wv8ARwuDLrtasW/K7p2mXdALBjeEgfV8HbZxP92vpZ3ZQm
	/M6oPwMgth7VzcJU7neD2D/Sry+fPB8BimaT8LypEQO2cG3dhN/syrgSfrxq
	fmja+WoCG1JDKJ5O9KWfLeu5rdyiD8dTA+T2Ox73YTluVvqZW7nWFncAZkmT
	Tto46Q+mYcgGgF1O9JPae1ikD9Xlsl4ZP3z2pyDJ8i2Nnsx59G1rH0/0z43p
	fH/l49nSrfoP+sv+WMOuJucv9U+r6dPBwgYHT65w8A9Tes/VSlV1s4LB1xZZ
	+fWTkweHh1/LnyhE8udXjx49PgKBquaD1x9//eVD/PN8fDrpierh7p/HTTOD
	icbjsTZTYHYzA8G6XDqPPNshs2u/tjPUGx5QZfvKQe+fnJ8egFhUMLSbtaRY
	8K1T05pFY1b6sjGVX4OMqWdmY5so5Hof1c0BaIMaRLIu9TXoJZwUFNBEqWMN
	E2uAwlTaRcWlZ6ZpnC2AJLRKY0EgCl3SzEtrCourm1YvACEEroJX3NrhNkwB
	zAcrmFJHtMF6CLG3JW6pWtCsIKhNvW4caC54IuAa70Fz0JCJOq/03qyEn9zM
	lHukOEfZJGbnMF3PaTcVcBe+ReqWd6BwozP4fQ3aYwn7u3HtkmBZ2nKNA/Hv
	L8Ztty7tRJ/zd193zczq81e4tcZ6RFZxD8RLHiDW9QykawG4KAAe2V/p5rZ1
	KysA1dWijvB4mAZhhfeqgD8LyGwApLLUU6u7ykxLC3pUlzUqe5oSNgEvtmnf
	wBGoDSfIS1ZX9kYDGZa2wR8D2ZgGvFektil9jfxwDQT3PAOQrd2srbbVrNms
	EYsK9igTjJnuayRstZgwE69cUZRWKfWZRnvR1EVHzMqAbLOl3s2WHz6IvP3x
	R2LRG1AyAJpbVJagV7xdwF1mBkskRBum9yNA95XVb05fTYRP6DtzTGvgDUUI
	MKgGC780V3akb5ZutgRmrxDhyBZda5h1yw1AsII3cdX9NYx3s640TQlWE0m2
	7qYlmAowmZowVsNu18sNSlLnbXEw0cdzMKLIot1sBqDOuzJbWYHhWlk0ebdO
	gZQHCUFAAJmg7tzCVWTQUEpnBOcIuBzcAJYAoBegZ85SbEr8DTHK6AJTA7pG
	tTf12Ld2zbIHihGYoaxvPBC+WAN3tp6WXQFG3e+B5XwbJMNVDqdWcSMgTQ3o
	c9jk1Nv/6Ej8AWYBjyHPgQDfCHE7IpYHqtYA9HppvAVS2MZuDwZkyHiL+scD
	gPU14RW8kYVa28bVBYGHguZB6BlqCzSfipADhj2LVV0BOivLyEUZI7epUHUY
	hsSIYmvfrx2IOzA86CGSWuDLoKRJNwLvksdF+xkoCFYLgri1RZhhg0JZJbp2
	w0qc506KT79BxdmCCmgtYguW8jVANANMAacDSy0RlhfHlyCiU0dcOlIwFSDy
	2pQdiDUuBga1m8/dDNUyMwBpep3YGb77zgY1H/w+hBrerhaemb2w1w54GJgE
	WRo0C3ALbMOXFjiJSUB8A9gHB9MTKl2jp6aF9xNCEQSrekDrEowJjU2Sredg
	tbsGxTNoZ8BpV7asAJgbDem6yIeToS0t7NyhBwWiTfCysq2T741sXhQwzy47
	Cw+RQTPLwbaPdoCOtbfIMUJcsaAV+OMtGrNCXzsDM+NwFVdHY0sKFNeEEbzG
	7eqaV2lpC/V6TeyAMg3jVrBjVcPoJpodma03xQQ1M7C0RX84IXMKsgGzgwOC
	RFW5pEw3mvHzkDmabILsUqZ2PhgJW4yQz5XRK4tgOL8KVoUg0Gwvgt1AEOvp
	vPPRmK1L48h6ARdUi3Y5QWMC5LhG0QBPh6To0jZgxeuyXmzYtKCIYpji9d7z
	NxeXeyP+r37xkv5+ffavb85fn53i3xdPj589i38oeePi6cs3z07TX2nkycvn
	z89enPJg+FX3flJ7z4//vkd71nsvX12ev3xx/GyPZSdnPZQ8Vi+4uwboiCxh
	vAKTNmvclFXHjyev/vu/Dh+BAfwXcT7BAvKXrw6/fARfUPR4NVJb/BXwtlGg
	JS3KboXaG5TC2rVg00eknpb1TaVRlwI2BzIBGgb+gKDUrFzpDFkN4oooFJk1
	zlmdjSKIQLXozMJqRVpsa+OOrHba4oWI1UNkIZoavWmYGumMs+8loX/nij19
	FmTlNmludwyKAibmXAX7CRCclKj6nlqwcYTIC9uA8eDvgAkPm/HiOmVaApne
	5ZreYCBPdhJe/k/4gINvq26lP3Ck0YNo//LH08ODkd5//MUXD784gDf+SBu7
	hLm/4Sn6q74jawerlWzNcPu9nVnyaMuuiF65ynY30iQD6MsZUeZJr50XmqMG
	UKpiBuJ3JUN81GRkP1g10fzAIqAb+Lkn/CF3d2yywS5ZUuQqoDPqtZKtzrH+
	3Tb1mCU8WwD1P2oCz4FEGqLI5FuwUWymcQFYLinOaQcMUcPAqmbgdoBWVwye
	EvAS3SR+EsqBZjXgtoAWLr69P5k8+Pevxofff0M0y/EXSHYclkFvQnQaLgdg
	iYcB8rJGp0Z8zQGzJmsQTG7GkaNAvhA/kF3J8a+EIjvwrzP83xjUjm4L+YR4
	tQPx2aZydCeafO63MK8i5hNQwqBCpxw8wP+PdmYQaoteJ3ogG3rIjBV44uMS
	Ttgw7KSGgAmFk9eD0dEyibUCnehIL63BSXUQTimyS1V0dwMqDaiYdVlvUNuM
	RfBnHG7DemKfOIRF3ysBqFLQ7MHeknDNDJO3a2AhdIdgt8y/7KIHd6Os66tu
	PSKY7HsDQalFC7w01zGC5HVhMmBST4OmCCyGKq60Y3JTA5QTdYGwOZxnFZS2
	Z8UAYzmqDDElol4R24K2Kdx8DhYjbRRNNbkX5CmijryInjWiOsKVwnvH8jjQ
	UdFraCFqn4/UEDhiQSRpIMQ1mCWEMVMY7MuyYCUixlRIT1oq8Y1hzg1PDisH
	cCXOK8Aeo09Bfj8CaNecbYhuPpjCUVrZvmcnC+xAKw4URGIkpeIakaMXIno0
	1mQ8G8tIgQVZ4sBtQCA56NgLEqsITAnD0KmlhdmByH0zCLjHssYInpEwqWi5
	YecLW9nGlEk30pzBoRtTohYFoR2n8C1oDQaiqGkcbGkF5MLMDm1VeCGOAkZ/
	i7Jt+qkMCC/RT18BrEAfYKfoD4/+TKx7zrOZwzToDJ7PeQEMnjyKhSXwsldx
	WlL3c8LaCBc2uc5DFoeRuBEEuAA11zof/FNKX0F44xoGaxTTMRjZKXSExux6
	FAPnXCQ5JU5IyqYxvmM1CvE6R82B/nGlfX9wywZ3bg6inboaDw0p7UHt3gNF
	tCmbw247ChbNuxGtYMVSqa3YQYd9A/k/fOASRIxU0DmVaEIhxz4/PsmzJ/2x
	KzOD9xFhnE3IkIbZ0gfvwPZO1KsYC6zNpqwxKKwsGqWOw0mSjD6EkgFFTMis
	CmcFvBJ3sn3AwFg7FtO4XB8KdIdsm9Ge4zkVSIlqGoQ2gB+0d9jRzsylpA7V
	7UsiJ/eXHcwd5lV5ahMGIjgAGAA03eTpShoEpmFpZ1eRHVemQHWvos5Dq0zS
	nFhKZyxFXueasi0TZM/djJe9FRPRDWazgGJFjgfKSfDuipARDKC1jWVxB1el
	AvvvCgpgYgShsgji0QSz1YcxjpAQZUhpNONhmRju7iYBQabvyLy5cIvu27Wm
	imuGvNBu7cHqkNY1JaZhhuv2tq36m+4Dg5HUa56b86sx0vASQwVnJl/Ep6wT
	2o5edj8pOPXhw47iBkCQ6hQQbFLuxjTNJjfCMvVDjK1qsUNGxxR3W+tdDClw
	LKNHB6wFYjJSSTK8pGy3dWUeLwWXznn0Djqyn0pm7yseDNYeHEz0G29j2NWT
	VAQGN8bxHwY67bKxlrwsQarHsg7Fs6SUKYTjGMZT1C2mgoIsjEtgV6u6QVev
	Rc+Khw65QeJNzpM0NWaQ+8G18GYYD8JUbukYWNEVkg9NpsBW17asQQT64qaB
	qWBJIFnSxeJFkxtE3t1qbUjqSfXkKJ/op5gSGwmykIdU5h2lKWPkSbrMzlvd
	VeJfZQmMZHVikojknWM4vRXGweeEN39J9KUwOz56JYWFX6T0JSWw7I0O1jh8
	rO26ni0HPz/6SnNqe2bfQcw/tc32ONaN2e8SVs4bs0Bv99ceDib8+m/y/h99
	DFGsqT4c6c/6+9fUafDdXhTbhFPRAK/Yck72/hDFGF3YqUVNhRpj1LfC5GV6
	ibrnrvHgjTeYXgK9jAl2VqPoQ/d4i5JSaynyhfweAAOyTi7pOchrs4Pmkn0A
	tVtu8H2qGtmizxSBA5RwgMPJ7swGIaBncH/to3rIJyg17wbMgiT9inxIL6Pf
	1fN3ssk+zfrbHBCuD3ag3guwODswJKTTFxFTSMTg1mB7SSOZhZhgCbzF/iF7
	gTGPGjemjkg99KgnMp9CfGua3PWC8bR9GKuPwRlppq5tTLMJLkDTUY2VvAIK
	3AvWZeBtbHTMTSKi+tMbqojFvDJpyhAzx3JkP9uNk3DhuCrQR4a9AyXgpU1e
	1kV1hJ5P7dHJX9UdJTupQoR5VwGkrVvgVoioqBoE6qsKwz3WukpsWsAY/sLa
	aIG/mDyCreIMWf6SICIVDlbMuBIG7b+oKaktESLaNr1NZUYKOgc4Eaw+lz3t
	4IiQXe3Z78mBlFe330cKREWFYkSeV0yIgOSBnSaXK5Y2TlLpIQngUP/2vP6s
	2gHyQP7HHTVy3QFOiCP1d8n8/p/o6JTi+xX+9y5oBN3/3LunUTaJKe+s32HB
	d0HT9DG6U8enx5JQjMoiqwIN1Tzge2wrsJCoKDOSsdInPZGQiyKLDEK/9KWe
	1MSA7ML/5L/FBCtCjAQub1BSIEYhjTP0mIZOB0nZznLRHOSxCF5hn2snUU+x
	csBJChs8FeAuWDBsKaaORzqRURQPSjp5D+CH25SoofRYm6fZcYGYDkj+I0g9
	oBOLKSTC++gYOT/rPIaA4Mhdu7rz5eZAkpeWCm81qJuoXLLEdhsywZKfpHwq
	Jd16Rd/k1I60x/IE4b2XH6OMFS9E9UqmSJg4ZO+wbPAeq+Os/DXEniPaZ32D
	EfSImmEG8zLwOGmYbZgD9JJUGYUdYhcONWTErYLC78BhIA+inEOsgz16hhJy
	sRAfk2CUQ8K5UrHQXIPyDAnJPCAAEmTB8D5H2p0f8aOUgDwQVnXk8QO7ZPIY
	2CalhNErDdzpbYMtEr/Dzx/1V5Q6xrYBClBINbA/RY5zDNdCtJdHY8Ggv4rN
	D/rDZ+ixK3WBVAHBQbYnLLPwSwKIODNMjoaGMv3ohVGTQFVItwBnH9QgbvAS
	jyPHhGmZstqXbrFsy81kZ2C4qovUejYMRvrbzYNRDhOxaPnlw8dgGkkIbyzg
	TOImGudCWxbxUWoPo5oXpVlog8dnx6cqQB0ryf0VR7TBEJfQsFtSSkR+JftC
	d3ZRN/C6JCCwujuVfhNO84Q580woB7akFUfaTexkpG5fmrkEhld5YovsdYwe
	cybKUNqro35DVd0dPKd6I5DAlFOUYT6qy19IDwm6syAZBWc/JNiDCPEoUacw
	+JA9CQljOXM5KEfsnBnmSd7ytkyJHyoz7MMOSHMf3E0g97FvieCififbHGDz
	bTZhpKl9P0MD8ODfDx8BROAUoD/wDtzwmV3WJfiQAMhXYjVg6fvv53OlyHnb
	++sekASozj1xmLCtpA1RffaZ/rGsZ1dif/2QqigwicGYqTiHT6OEp3tJ9pDX
	PGP9NEZ3bYzzSLSPqYZBwB+lLHO7YMQ+/O/dDSxt313ZzSg6KTs2r/8an6a0
	WPots6sff3Hg64SW0vQCOWnZ94F31l8z+/YxFhqsP/Akgih+9KXkbnz0NY5+
	8OEBB3VE7kZaA1FHQ/BQxGyR1KE4PUu5/7VpQpMLktRV665V8SwAqg5w0IZJ
	X0weNfWqPyol2ntvsv+FFg0zZ+wXICSOGuTm1BkroQBjXDGzcuqGesmkf6in
	PHu66xuWeWriUjvWYLHd5rF8pUwRHpe468USZPPxo/EhV2Vb7lUsUclSDngI
	9yhNocit4qoAVUF5QG8HNzuS6dKdRcVJ9hPOq2iFOB/C7MpZ9z6jcuYL4gIS
	wrZWiTqMAIOobHDfbPFiBMzNvUA/ciOGGoTp+jHh/ydUzP/rll26ZWeAlj0/
	/yX7cvbiZD+qlJjiin/JVg6CfgDyoveS7MMTLFELqbvWgWWj+Cp17wLis5ws
	t4tEz0iRZ9TLO4uHNot1ICnt7PSpMucto2d6i7uNvvsTMvY/u2jV/+wk8adO
	8qfk73+GzND/3M4aW5Df+uxjJilQX7/CkPBYmn/fUIEf/H0MFMfSEjzmsn9I
	zcZqhzQKSVZForGCvVCuhMgpA5lHpUAtWgusKsy6Bn8sUx0yP95AdieLOEPB
	l+sx0XtqLHFC4CnajSN94mMaDnlRnGCFMS0YAwqI41p9ePsN09myRaybjVRX
	cTd/j+G50IIt4k7aQRtsWGhjuWVrohTaZw31eHQEsAL7ZCiot0lFpPSKX0k/
	8p9Fx/3ft60HFNur7I1t9silxQiWTOMUjOsOo6KYDQ/E0HIBErtx44RhCTyf
	RlYlW01CE8CCosLSunE11dKMdAFTQ6i0mgvyVxjzsam/cRgTGi6NkelU4S0Z
	ztWABg0sZwyXlAbyteRGmS2mjo4W8JkWcA7M7Ar8A2nfIQba9IGukXWQIYAV
	ugYzKbq/cGjcnNVdWUivN+4FvHHwDXAlbFBzMzuhdLQsKXvLe5rwpAUXjmli
	zmj18MGdABsOqGRYY8nADfgWDw9i2mqe9rTGdVvfG4znpChqn2M+GPPSfFDD
	lIFtOANiMKmARzY3JEi28uGckOSqsBTdB9WHRVSeSgrFwIx5/US/qNP8ZBsq
	OtgQ63T9YF9hI5+3VNOzev8vB1L60+x05CI3rXFddIIsLmsaakCXIxnaLLCq
	2QpNhEGRDxL5qb3Er+saPaiIW+4Q2sUrLaBvgWjgKXFrWWYdeJ/TSQ2IFHhW
	VAAJWZKQYAADO+bJYfWqAO8t5ZxSCK36zQWPcXhIuk70jyjBvi47woM0MG3P
	vAcbUUEFRPdsxBlATBzKgTiiqBzSZb0t0wTMgQSUnJlnhzs7r8KHgBDrOXuE
	yUIbSogFkmMIzKjy8zSs4oBL8EjIRKJeDkn7GmZtfNYh0FOlokZlxqQjFbeG
	cvtYoGDQK4DYHujITtyQyB58zsp8oiC+wCoJAeIkDdE37Ql2gdyLOznSx9le
	w1Ey2VFMf2aHkSLzbjMnOMdrS333Ujk1NwgSpurkuAWomHxL8IuvI5NuKG8L
	bgP2yrNsi+yoyIihhw6Tptek5rlxEcYhz1DSdot4sTM1am5CoGTwIo9Ln6PQ
	AWu+eYcpOguMFLCVBvFaVyo7pBbaHTmMXLnKrUAJS1UNSQkIGa+xtCaslCw/
	ooQCPdtUdFYWzy4ZTvynrtoEKNYLpZOl34zA1d+dZ2gpQiGO2d3oCmJEXhDm
	701T9FOFU1NgVOO5d0yMabKO0odEedwzRhe48lIIE/w9wAaYJbZm0NEixmnE
	mZxi67WQdZUbx/Y88kWi45Zap9vYhk2VutAySFAqs9VDn/WX/FnTtLqxqYmu
	lgLA5723v7Ordbv5PDTJ87mC3d7wLR9uY8eDoXg29FM+PETlhxlueWc8/l7t
	74D7QKlbXHf+fBuG81da4hdUY5vXltqqPzr61g+AUl85e/DPgZ5m+XQIsrMD
	nzB6AMfh/fsH/8DaJ9hIS4bAftJohvlnuzkTkfmU0dmidyHdgPC6h7FT0INA
	umwbTMYctOwpM4z69YSecIB6ARrtN/UENCQ1aO/4JOp/C1KLuP7+kwi9Y7lP
	27B8AowgKbmVxFPa+WvfyefO4H4bRoQfhrMr9cwuwJRCzPbtZDL5fnjsx+SJ
	OlfEs8877h1Q+zDBQTZBfrRT/QoPf8sfhmaWvCyTnf2O3ff9OnxQ8qEKL1Yg
	9UqeRU0vp+mx/s7+x3klteaBTciaJm45HcH7u71le6KzkwnsFKIV39oMmpzs
	cCZenVFysTkyqbw50elARwCYrRq3dKpgMUKfeezK9r3Mwy4DNmIIW77UIAuu
	wxSDY05D2KiJf3AOXPWOFpGB1q8g8jKzDbaZYJtjI27Ah88gML7GC3P8HxzP
	4B4ksxEaKkNFn7kt66DmHkRwxUapPw0jwfxyDOLcBi8XqTD30WBGnE4p3nL1
	wzD7MlFn13guOpsyrcV84fwVDi1ddSUBNwFm31NDWV4V/frLh+QSHWPP/3ht
	KI+IWTMM1eopRc4CFJ81CJcsBP7EjEl7Y+UaCgaVqRpCCznlQWfEUlRKwHH6
	iVahAFkoTM0KpcpuBUjED70mMXsO1Fkb1+h95LNpz1dSeA8Q+E/MCQcTrd9K
	7WSF58HHS77hg9qxApradGxCGFgB2rjdISyZH1ySQnW49EMpXKI3/4i0ifcU
	gofsQ4YIupSjTFd0ZCArOgJsWL/RxQXUl3KDbWzt0nMZBxjzihklHQ9KXrJy
	mezjyW+/1e1c+c61BM08Q4X2M9Afjas9u6UqwEnRgnRuzER4UMmcxiNwWSTP
	rnbVQwgomWvX1NVKzqcXFNJh0RSvDygwa8DlLcw1od8Pb8lZ68bOpRkmnpsE
	Xz/uj7JloFpny+yw/sOeWz3Ej3ZZswBGj4MK0kClxqYTKc33MyOZHIruCqn/
	eTpuktqxcv02UtyazjcsiG6aW0NddXQcK7a7xIAp5IoSgfvtfuqVrC7Hw+iM
	5TyyGvUtCp9nHWTAJC4LzwwssAEdpbhl0eGPQMyJfp61MArNBpuWSDJ2cGVt
	kZQdA3OPGeH3+mxCh7xDayPg9omr+KaPdLMIzpbbFdQSKE7L1GKK6jS76wzT
	vYb0P7xLvVehix+j7JAWQyGWBthMyXL6Mgsx+aRo4huS3CCrVg1WzlUEHocU
	3Sq6rvH9I36YfMN0JIzB07d8/LCOYXqoFKN8RM9BhCyc2U444OYqMPr9AFdt
	CxjyGsnX7eLFtjJeu7NlLL2dBVu504RQCxr3jcLkZcidcNpKhRwKgEJsQ6dF
	w+nEYPkoU4Kp+QpP3ZuK+Dg7nIGH2GzVYe9XP7vFuRA2DOKljMDKcuK1f/vJ
	Afsk6NSH5MYKYvkZmvmQySaY8QlmMdIVKJEuoXbccGxBvegrtGPBEMoZVNTY
	DflQ1oIV3lXlST3CeMZ0kLOTm0BCOmCUJ9KjURFG4yYqqgaKOKfjqGK38VKf
	/BxhZpkkydjPxurYE5UurLlHl9Wwwgw3IrT1GpYbJu9C3tHlLZLkjezEA7Pf
	+fGL4wHrDa94EKR7KfsYOe5DVMXhXEM/ew9ogJnKbkViibvuXa7AzU9ev7YL
	YLBmoxStTaU1WkAuVsKrXyh+aDAEoenQXS40Nd6OX4IHuxeugdm7bZU9mJSX
	Yc0sOZt4oqnqn3FFtzhkZIVAqZcvnZ4f3CZCgU5W4KWucaompaN3DISgqBJ4
	8NE/jJ9SLh2jRGY2oX3Pcqu3kaKGSOG8447LMbbO+ZFTRDiRQkRsFsEn3Ff7
	xcPsIK+ARwUOi7dyhZ+c3DRnopMfL7wL57sCavFuAMVBWb0Crecy05y9NlEv
	OVIaXHVCN2hdS5MmXwdmso6SIVDhWrfCAmAEO258bq5hdICMW2x5UQ5MuZVP
	J0TrF+i/hkPdXC4nbqUOZro1E/0g+BK4ZPy/8FFINozve8SE7ydPR2B64I+/
	p6TAizyB8WuQ8t9+i3do0C11LHO5tIVDBekuo8DWl8wEriBedHK71d7f98LJ
	3i0x09tihlf67KVS6IQ6eyUaHEe2zhdglyJxIIyfhGD/Mv81hPM5BWSDfLg4
	WkQks+pBiwECDSCwqcgeEuWdlxu/xIBl1+Gw7HgqY08t3hiRsVGaP79+lhb4
	Ru7DIH+0hyLCELrPWOjtKA7PRj/cutznlsOht+ig/CjIXVXP4MhBTHQP5ttT
	kVGIKqnFJF/0dr6QizAxazYFE4z26ilMVyOA6M+enZ5fvnx9pF89Ozu+ONOv
	z56//OVMXz7F/51f6IuzE7wJSqk73Nr7gLJpY3TsWHXssKx0uS2/dkaXuGIJ
	3PEAirf42Qm4IClsAQyA1xmi6iz6vYP+vwPchwL3WYh7iHCzvivp5UKUbfB8
	Bh/6/aFxOJx0HxQ3/J1guq/ylTYx4uIjqhN++BQ76vO7MnOA4wUwt7sufw7H
	/a8DHOKUPT8+uffRdix6+9R5PhUdOmqwO0/uvYP/4kE1U0I4R64yHsGXQp/w
	jJdpzsF0NeC6cTtZZBe0fKRj+RJlNJI/gib72RTd1d129ZXsSr9+fcL3UYPX
	SMYO/bF4da4EpOHr3eb+Msz9tmaeyIqqnEUMFypQuwORVbLQPQrG/NQOKZL3
	hSf93QB7jICNpX1rJ5OrnhTsZqywKB9qYY2J7kjodSXQVgaWrLAxc8wXqYbo
	RIIRivm3arx328YXvI3XlvuSbZHCdr136/GUvTvN/YjnTprJ00H4JOmi8z+/
	5VKCzyPRPr8Vks8zsuFix+QU7Dzo0ut9lVY6udIEA+SP9L/eDZUP+xyBV45T
	F0CNXsK0Axz4P32B82Ozq6q+KW2xiEo8jZLQVuVqpJc557twdz0PRY7U1tCb
	2WUX8/YuFdnNsoxuujJ9zGBDxFm6cGaMpPROeHvAeHteBxVBHQH9CwowGVOa
	/KqIO0x8GHgbtRH5JaGFgZjq7U+0Meyuwnhfn59dPtGHOOoOc9/nuc/5jlu8
	Y5LSaHRBfggiSHj3swKGiU1CfWcLsQfgHYSVG7lT/q6rh/XAG3krgPxEgJyn
	vNSn+SfoG0nETg0lyKohgiQ80dGE3qbpthmOs6RLDdQVGKmY1/oWNvIDInVS
	N4vvJzlwgSQ8E7XS9R9KoQlrBKwjRXUQYJSu0d8u23btj+7du7m5OZyEde4h
	CKBA75Xks8/rewDF9xBYNLMlXUcuvg9N1MtgmvZI5XP2pxwbnuDejZ3ilPek
	pfYe/jsG7yfLdlV+LzeUJulXz7Hnb21rrB/RAb4o+yGSGbbf8Z2eNxBrUr8j
	XVNNL5rqSvVbYDGlcO2KzpThYB/eqxtXcHz5CIZVf9F/B/P5b656j/l5rZ92
	5sbiFf0b+gl//WFJv9Gl+xSJ8bgX7qr2+rm5buqFM1VVrwEsOv7y2hZPDfqi
	1cpc/9DYYmna4ejLeuogKv+prooGL/OHneAPkwX/8IP8F5HMw/qZr91Y4Axx
	7wRHa/yV9JG21qz0ylKqinqBn2Mur6J/ncDjedHn9e8QbJsDheqyQSYBJnja
	udaujN6nsiH42S9nbb0GNYH/kgO++jdTGX2+wbatRu//VNeL0uLvp6ZytgTn
	aVnpn2DeFdBh//jk2Rt8+MrgHd5X+vkM+AAmy9c+h1Uvbmzb5rMBrFfYr4bB
	5hL2sf/E+LbcyLn+4S5Thg2P7WEyg00Blg4NXm5IKSPyobYanvk6uJb8FBJ5
	5QovNzsujV+iQndyyW52m3mqloz4vkfnV47b75Z2FbKvxIjKVVaul55J8BWv
	Fe/FijtaUPmCAkXuA91HLBc0hg3yxYCgjXwWhlMbspj/XrdmjFLDNRJqaqmL
	clCH4d0Wli/AaeR+P3Ciu8Ys5OK2WH0KXblZ/gjXoYzm8dCeq7e7ORn/IY8a
	vG/M7Y4Cp552ePn8MwMAnGGLXjtK/vlIvzWodvTP3QpoPtLqSYPupp8Z4Lay
	Xk3B8IxA7lb6lW2xTv23GjjzYtaBmwRLXFhgu8uuqfAL/XMmv2yqGa6HW39d
	g9S0+q0rW+wDTjplEDLkBRyUUROK/EE6b7EYyFMNMCbJHViuukD4vF0v9YXB
	U2EbTjL0oExQYBaOrxHyHV0CQkDPrS0wNJ+o/wG8zRidcWcAAA==
	</rfc>		</rfc>
End of changes. 105 change blocks.
	715 lines changed or deleted		298 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/