Diff: rfc8842xml2.original.xml

	rfc8842xml2.original.xml	rfc8842.xml

	<?xml version="1.0" encoding="iso-8859-1"?>	<?xml version='1.0' encoding='utf-8'?>
	<!-- comment -->	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
	<?rfc toc="yes" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
	<?rfc compact="yes" ?>	category="std" docName="draft-ietf-mmusic-dtls-sdp-32"
	<?rfc sortrefs="no" ?>	updates="5763, 7345" submissionType="IETF" xml:lang="en" obsoletes=""
	<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-dtls-sdp-32.txt	tocInclude="true" symRefs="true" sortRefs="true" version="3"
	" updates="5763,7345" submissionType="IETF" xml:lang="en">	number="8842" consensus="true">

		<!-- xml2rfc v2v3 conversion 2.35.0 -->

	<front>	<front>

	<title>	<title abbrev="SDP Offer/Answer Considerations for DTLS and TLS">Session
	Session Description Protocol (SDP) Offer/Answer Considerations for Datag	Description Protocol (SDP) Offer/Answer Considerations for Datagram
	ram Transport Layer Security (DTLS)	Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>
	and Transport Layer Security (TLS)	<seriesInfo name="RFC" value="8842"/>
	</title>	<author fullname="Christer Holmberg" initials="C." surname="Holmberg">
	<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">	<organization abbrev="Ericsson">Ericsson</organization>
	<organization abbrev="Ericsson">Ericsson</organization>	<address>
	<address>	<postal>
	<postal>	<street>Hirsalantie 11</street>
	<street>Hirsalantie 11</street>	<city>Jorvas</city>
	<city>Jorvas</city>	<region/>
	<region></region>	<code>02420</code>
	<code>02420</code>	<country>Finland</country>
	<country>Finland</country>	</postal>
	</postal>	<phone/>
	<phone></phone>	<email>christer.holmberg@ericsson.com</email>
	<email>christer.holmberg@ericsson.com</email>	</address>
	</address>
	</author>	</author>

	<author fullname="Roman Shpount" initials="R.S." surname="Shpount">	<author fullname="Roman Shpount" initials="R." surname="Shpount">
	<organization abbrev="TurboBridge">TurboBridge</organization>	<organization abbrev="TurboBridge">TurboBridge</organization>
	<address>	<address>
	<postal>	<postal>
	<street>4905 Del Ray Avenue, Suite 300</street>	<street>4905 Del Ray Avenue, Suite 300</street>
	<city>Bethesda</city>	<city>Bethesda</city>
	<region>MD</region>	<region>MD</region>
	<code>20814</code>	<code>20814</code>
	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 (240) 292-6632</phone>	<email>rshpount@turbobridge.com</email>
	<email>rshpount@turbobridge.com</email>	</address>
	</address>
	</author>	</author>

		<date month="January" year="2021"/>
	<date year="2017" />
	<area>RAI</area>	<area>RAI</area>


		<keyword>SDP</keyword>
		<keyword>DTLS</keyword>
		<keyword>tls-id</keyword>

	<abstract>	<abstract>

	<t>	<t>
	This document defines the Session Description Protocol (SDP) offer/a	This document defines the Session Description Protocol (SDP)
	nswer procedures for	offer/answer procedures for negotiating and establishing a Datagram
	negotiating and establishing a Datagram Transport Layer Security (DT	Transport Layer Security (DTLS) association. The document also
	LS) association.	defines the criteria for when a new DTLS association must be
	The document also defines the criteria for when a new DTLS associati	established. The document updates RFCs 5763 and 7345 by replacing
	on must be established.	common SDP offer/answer procedures with a reference to this
	The document updates RFC 5763 and RFC 7345, by replacing common SDP	specification.
	offer/answer procedures	</t>
	with a reference to this specification.	<t>
	</t>	This document defines a new SDP media-level attribute, "tls-id".
	<t>	</t>
	This document defines a new SDP media-level attribute, 'tls-id'.	<t>
	</t>	This document also defines how the "tls-id" attribute can be used
	<t>	for negotiating and establishing a Transport Layer Security (TLS)
	This document also defines how the 'tls-id' attribute can be used fo	connection, in conjunction with the procedures in RFCs 4145 and
	r negotiating	8122.
	and establishing a Transport Layer Security (TLS) connection, in con	</t>
	junction with
	the procedures in RFC 4145 and RFC 8122.
	</t>
	</abstract>	</abstract>

	</front>	</front>
	<middle>	<middle>
	<section title="Introduction">	<section numbered="true" toc="default">
	<t>	<name>Introduction</name>
	<xref format="default" pageno="false" target="RFC5763"/> defines	<t>
	Session Description Protocol (SDP)	<xref format="default" target="RFC5763"/> defines Session
	offer/answer procedures for Secure Realtime Transport Protocol U	Description Protocol (SDP)
	sing Datagram Transport Layer Security (DTLS-SRTP).	offer/answer procedures for Secure Real-time Transport
	<xref format="default" pageno="false" target="RFC7345"/> defines	Protocol using Datagram Transport Layer Security (DTLS-SRTP).
	SDP offer/answer procedures for	<xref format="default" target="RFC7345"/> defines SDP
	UDP Transport Layer over Datagram Transport Layer Security (UDPT	offer/answer procedures for
	L-DTLS). This specification	UDP Transport Layer over Datagram Transport Layer Security
	defines general offer/answer procedures for DTLS, based on the p	(UDPTL-DTLS). This specification
	rocedures in <xref format="default" pageno="false" target="RFC5763"/>.	defines general offer/answer procedures for DTLS, based on the
	Other specifications, defining specific DTLS usages, can then re	procedures in <xref format="default" target="RFC5763"/>.
	ference this specification,	Other specifications, defining specific DTLS usages, can then
	in order to ensure that the DTLS aspects are common among all us	reference this specification,
	ages. Having common	in order to ensure that the DTLS aspects are common among all
		usages. Having common
	procedures is essential when multiple usages share the same	procedures is essential when multiple usages share the same

	DTLS association <xref target="I-D.ietf-mmusic-sdp-bundle-negoti	DTLS association <xref target="RFC8843" format="default"/>.
	ation"/>.	This document updates <xref format="default" target="RFC5763"/>
	The document updates <xref format="default" pageno="false" targe	and <xref format="default" target="RFC7345"/> by replacing commo
	t="RFC5763"/>	n
	and <xref format="default" pageno="false" target="RFC7345"/>, by
	replacing common
	SDP offer/answer procedures with a reference to this specificati on.	SDP offer/answer procedures with a reference to this specificati on.

	</t>	</t>
	<t>	<aside>
	NOTE: Since the publication of <xref format="default" pageno="fa	<t>
	lse" target="RFC5763"/>,	NOTE: Since the publication of <xref format="default" target="RF
	<xref format="default" pageno="false" target="RFC4474"/> has bee	C5763"/>,
	n obsoleted by	<xref format="default" target="RFC4474"/> has been obsoleted by
	<xref format="default" pageno="false" target="I-D.ietf-stir-rfc4	<xref format="default" target="RFC8224"/>. The updating
	474bis"/>. The updating	of the references (and the associated procedures) within <xref
	of the references (and the associated procedures) within <xref f	format="default" target="RFC5763"/> is outside the scope of
	ormat="default" pageno="false"	this document. However, implementers of
	target="RFC5763"/> is outside the scope of this document. Howeve	<xref format="default" target="RFC5763"/> applications are encou
	r, implementers of	raged to
	<xref format="default" pageno="false" target="RFC5763"/> applica	implement <xref format="default" target="RFC8224"/> instead
	tions are encouraged to	of <xref format="default" target="RFC4474"/>.
	implement <xref format="default" pageno="false" target="I-D.ietf	</t>
	-stir-rfc4474bis"/> instead	</aside>
	of <xref format="default" pageno="false" target="RFC4474"/>.	<t>
	</t>	As defined in <xref format="default" target="RFC5763"/>, a new DTLS asso
	<t>	ciation
	As defined in <xref format="default" pageno="false" target="RFC5	<bcp14>MUST</bcp14> be established when transport parameters are
	763"/>, a new DTLS association	changed. Transport parameter change is not
	MUST be established when transport parameters are changed. Trans	well defined when Interactive Connectivity Establishment (ICE)
	port parameter change is not	<xref format="default" target="RFC8445"/> is
	well defined when Interactive Connectivity Establishment (ICE) <	used. One possible way to determine a transport change is
	xref format="default"	based on ufrag <xref format="default" target="RFC8445"/> change,
	pageno="false" target="I-D.ietf-ice-rfc5245bis"/> is used. One p	but the ufrag value is changed both when ICE is negotiated
	ossible way to determine a transport change is	and when ICE restart <xref format="default" target="RFC8445"/> occurs. T
	based on ufrag <xref format="default" pageno="false" target="I-D	hese events
	.ietf-ice-rfc5245bis"/> change,	do not always require a new DTLS association to be established, but
	but the ufrag value is changed both when ICE is negotiated	previously there was no way
	and when ICE restart <xref format="default" pageno="false" targe	to explicitly indicate in an SDP offer or answer whether a new DTLS
	t="I-D.ietf-ice-rfc5245bis"/> occurs. These events	association was required.
	do not always require a new DTLS association to be established,	To solve that problem, this document defines a new SDP attribute,
	but previously there was no way	"tls-id". The pair of
	to explicitly indicate in an SDP offer or answer whether a new D	SDP "tls-id" attribute values (the attribute values of the offerer and t
	TLS association is required.	he answerer)
	To solve that problem, this document defines a new SDP attribute	uniquely identifies the DTLS association. Providing a new value of the
	, 'tls-id'. The pair of	"tls-id" attribute in an SDP offer
	SDP 'tls-id' attribute values (the attribute values of the offer	or answer can be used to indicate whether a new DTLS association is
	er and the answerer)	to be established.
	uniquely identifies the DTLS association. Providing a new value	</t>
	of the 'tls-id' attribute in an SDP offer	<t>
	or answers can be used to indicate whether a new DTLS associatio	The SDP "tls-id" attribute can be specified when negotiating a
	n is to be established.	Transport Layer Security (TLS) connection, using
	</t>	the procedures in this document in conjunction with the procedures in
	<t>	<xref format="default" target="RFC5763"/> and <xref format="default"
	The SDP 'tls-id' attribute can be specified when negotiating a T	target="RFC8122"/>.
	ransport Layer Security (TLS) connection, using	The unique combination of SDP "tls-id" attribute values can be used to
	the procedures in this document in conjunction with the procedur	identify the negotiated
	es in <xref format="default"	TLS connection. The unique value can be used, for example, within TLS
	pageno="false" target="RFC5763"/> and <xref format="default" pag	protocol extensions to
	eno="false" target="RFC8122"/>.	differentiate between multiple TLS connections and correlate those
	The unique combination of SDP 'tls-id' attribute values can be u	connections with specific
	sed to identity the negotiated	offer/answer exchanges. The TLS-specific considerations are described
	TLS connection. The unique value can be used, for example, withi	in <xref format="default" target="sec-tls-cons"/>.
	n TLS protocol extensions to	</t>
	differentiate between multiple TLS connections and correlate tho
	se connections with specific
	offer/answer exchanges. The TLS specific considerations are des
	cribed in <xref format="default"
	pageno="false" target="sec-tls-cons"/>.
	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Conventions">	<name>Conventions</name>
	<t>	<t>

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"OPTIONAL" in this document are to be interpreted as described in	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nly	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	when, they appear in all capitals, as shown here.	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>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Establishing a new DTLS Association">	<name>Establishing a New DTLS Association</name>
	<section title="General" anchor="sec-dtls-gen">	<section anchor="sec-dtls-gen" numbered="true" toc="default">
	<t>	<name>General</name>
		<t>
	A new DTLS association must be established between two endpoints after a	A new DTLS association must be established between two endpoints after a
	successful SDP offer/answer exchange in the following cases:	successful SDP offer/answer exchange in the following cases:

	<list style="symbols">	</t>
	<t>	<ul spacing="normal">
	The negotiated DTLS setup roles change; or	<li>
	</t>	The negotiated DTLS setup roles change; or
	<t>	</li>
	One or more fingerprint values are modified, added	<li>
	or removed in either an SDP offer or answer; or	One or more fingerprint values are modified, added,
	</t>	or removed in either an SDP offer or answer; or
	<t>	</li>
	The intent to establish a new DTLS association is	<li>
	explicitly signaled using SDP, by changing the value	The intent to establish a new DTLS association is
	of the	explicitly signaled using SDP, by changing the value of the
	SDP 'tls-id' attribute defined in this document;	SDP "tls-id" attribute defined in this document;
	</t>	</li>
	</list>	</ul>
	</t>	<aside>
	<t>	<t>
	NOTE: The first two items above are based on the procedures	NOTE: The first two items above are based on the procedures
	in <xref format="default" pageno="false" target="RFC5763"/>.	in <xref format="default" target="RFC5763"/>.
	This specification adds the support for explicit signaling using	This specification adds the support for explicit signaling using the
	the SDP 'tls-id' attribute.	SDP "tls-id" attribute.
	</t>	</t>
	<t>	</aside>
	A new DTLS association can only be established as a result of th	<t>
	e successful SDP offer/answer exchange.	A new DTLS association can only be established as a result of the
	Whenever an entity determines that a new DTLS association is req	successful SDP offer/answer exchange.
	uired, the entity MUST initiate an	Whenever an entity determines that a new DTLS association is
	SDP offer/answer exchange, following the procedures in <xref tar	required, the entity <bcp14>MUST</bcp14> initiate an
	get="sec-oa"/>.	SDP offer/answer exchange, following the procedures in <xref
	</t>	target="sec-oa" format="default"/>.
	<t>	</t>
	The sections below describe typical cases where a new DTLS assoc	<t>
	iation needs to be established.	The sections below describe typical cases where a new DTLS
	</t>	association needs to be established.
	<t>	</t>
	In this document, a "new DTLS association" between two endpoints	<t>
	refers to either	In this document, a "new DTLS association" between two endpoints refer
	an initial DTLS association (when no DTLS association is current	s to either
	ly established between	an initial DTLS association (when no DTLS association is currently
	the endpoints) or an DTLS association replacing a previously est	established between
	ablished DTLS association.	the endpoints) or a DTLS association replacing a previously
	</t>	established one.
	</section>	</t>
	<section title="Change of Local Transport Parameters" anchor="sec-dtls-t	</section>
	ransport">	<section anchor="sec-dtls-transport" numbered="true" toc="default">
	<t>	<name>Change of Local Transport Parameters</name>
	If an endpoint modifies its local transport parameters (address	<t>
	and/or port), and if the modification	If an endpoint modifies its local transport parameters
	requires a new DTLS association, the endpoint MUST change its lo	(address and/or port), and if the modification
	cal SDP 'tls-id'	requires a new DTLS association, the endpoint
	attribute value (see <xref target="sec-dcon-attr"/>).	<bcp14>MUST</bcp14> change its local SDP "tls-id"
	</t>	attribute value (see <xref target="sec-dcon-attr" format="defaul
	<t>	t"/>).
		</t>
		<t>
	If the underlying transport protocol prohibits a DTLS associatio n from spanning multiple 5-tuples	If the underlying transport protocol prohibits a DTLS associatio n from spanning multiple 5-tuples
	(transport/source address/source port/destination address/destin ation port),	(transport/source address/source port/destination address/destin ation port),

	and if the 5-tuple is changed, the endpoint MUST change its loca l SDP 'tls-id' attribute value (see <xref target="sec-dcon-attr"/>).	and if the 5-tuple is changed, the endpoint <bcp14>MUST</bcp14> change its local SDP "tls-id" attribute value (see <xref target="sec-dcon-attr" format="default"/>).
	An example of such a case is when DTLS is carried over the Strea m Control Transmission Protocol (SCTP),	An example of such a case is when DTLS is carried over the Strea m Control Transmission Protocol (SCTP),

	as described in <xref format="default" pageno="false" target="RF	as described in <xref format="default" target="RFC6083"/>.
	C6083"/>.	</t>
	</t>	</section>
	</section>	<section anchor="sec-dtls-ufrag" numbered="true" toc="default">
	<section title="Change of ICE ufrag value" anchor="sec-dtls-ufrag">	<name>Change of ICE ufrag Value</name>
	<t>
	If an endpoint uses ICE, and modifies a local ufrag value, and i
	f the modification
	requires a new DTLS association, the endpoint MUST change its lo
	cal SDP 'tls-id'
	attribute value (see <xref target="sec-dcon-attr"/>).
	</t>
	</section>
	</section>
	<section title="SDP tls-id Attribute" anchor="sec-dcon-attr">
	<t>	<t>

	The pair of SDP 'tls-id' attribute values (the attribute values of t	If an endpoint uses ICE and modifies a local ufrag value, and if the m
	he offerer and the answerer)	odification
	uniquely identifies the DTLS association or TLS connection.	requires a new DTLS association, the endpoint
		<bcp14>MUST</bcp14> change its local SDP "tls-id"
		attribute value (see <xref target="sec-dcon-attr" format="default"/>).
	</t>	</t>

	<figure>	</section>
	<artwork align="left"><![CDATA[	</section>

	Name: tls-id


	Value: tls-id-value	<section anchor="sec-dcon-attr" numbered="true" toc="default">
		<name>SDP "tls-id" Attribute</name>
		<t>
		The pair of SDP "tls-id" attribute values (the attribute values of the
		offerer and the answerer)
		uniquely identifies the DTLS association or TLS connection.
		</t>


	Usage Level: media	<dl newline="false">


	Charset Dependent: no	<dt>Name:</dt>
		<dd>tls-id</dd>


	Default Value: N/A	<dt>Value:</dt>
		<dd>tls-id-value</dd>


	Syntax:	<dt>Usage Level:</dt>
		<dd>media</dd>


	tls-id-value = 20*255(tls-id-char)	<dt>Charset Dependent:</dt>
	tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"	<dd>no</dd>


	<ALPHA and DIGIT defined in [RFC4566]>	<dt>Default Value:</dt>
		<dd>N/A</dd>


	Example:	<dt>Syntax:</dt>
		<dd>
		<sourcecode type="abnf">
		tls-id-value = 20*255(tls-id-char)
		tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"
		</sourcecode>
		<t><ALPHA and DIGIT defined in RFC 4566></t>
		</dd>


	a=tls-id:abc3de65cddef001be82	<dt>Example:</dt>
		<dd>
		<sourcecode type="sdp">
		a=tls-id:abc3de65cddef001be82
		</sourcecode>
		</dd>
		</dl>


	]]></artwork>	<t>
	</figure>	Every time an endpoint requests to establish a new DTLS
	<t>	association, the endpoint <bcp14>MUST</bcp14>
	Every time an endpoint requests to establish a new DTLS association,	generate a new local "tls-id" attribute value. An unchanged local
	the endpoint MUST	"tls-id" attribute
	generate a new local 'tls-id' attribute value. A non-changed local '	value, in combination with non-changed fingerprints, indicates
	tls-id' attribute	that the endpoint
	value, in combination with non-changed fingerprints, indicates that
	the endpoint
	intends to reuse the existing DTLS association.	intends to reuse the existing DTLS association.

	</t>	</t>
	<t>	<t>
	The 'tls-id' attribute value MUST be generated using a strong random	The "tls-id" attribute value <bcp14>MUST</bcp14> be generated using
	function	a strong random function
	and include at least 120 bits of randomness.	and include at least 120 bits of randomness.

	</t>	</t>
	<t>	<t>
	No default value is defined for the SDP 'tls-id' attribute.	No default value is defined for the SDP "tls-id" attribute.
	Implementations that wish to use the attribute MUST explicitly	Implementations that wish to use the attribute <bcp14>MUST</bcp14> e
		xplicitly
	include it in SDP offers and answers. If an offer or answer does not	include it in SDP offers and answers. If an offer or answer does not

	contain a 'tls-id' attribute (this could happen if the offerer or	contain a "tls-id" attribute (this could happen if the offerer or
	answerer represents an existing implementation that has not been	answerer represents an existing implementation that has not been

	updated to support the 'tls-id' attribute), unless there is	updated to support the "tls-id" attribute), a modification of one
		or more of the following characteristics <bcp14>MUST</bcp14> be
		treated as an indication that an endpoint
		wants to establish a new DTLS association, unless there is
	another mechanism to explicitly indicate that a new DTLS association	another mechanism to explicitly indicate that a new DTLS association

	is to be established, a modification of one or more of the following	is to be established:
	characteristics MUST be treated as an indication that an endpoint	</t>
	wants to establish a new DTLS association:	<ul spacing="normal">
	<list style="symbols">	<li>
	<t>	DTLS setup role; or
	DTLS setup role; or	</li>
	</t>	<li>
	<t>	fingerprint set; or
	fingerprint set; or	</li>
	</t>	<li>
	<t>	local transport parameters
	local transport parameters	</li>
	</t>	</ul>
	</list>	<aside>
	</t>	<t>
	<t>
	NOTE: A modification of the ufrag value is not treated as an indicat ion	NOTE: A modification of the ufrag value is not treated as an indicat ion

	that an endpoint wants to establish a new DTLS assocation. In order to	that an endpoint wants to establish a new DTLS association. In order to
	indicate that a new DTLS association is to be established, one or mo re	indicate that a new DTLS association is to be established, one or mo re
	of the characteristics listed above have to be modified.	of the characteristics listed above have to be modified.

		</t>
		</aside>
		<t>
		The mux category <xref target="RFC8859" format="default"/>
		for the "tls-id" attribute is "IDENTICAL", which means that
		the attribute value applies to all media descriptions
		being multiplexed <xref target="RFC8843" format="default"/>.
		However, as described in <xref target="RFC8843" format="default"/>,
		in order to avoid duplication, the attribute is only associated with
		the "m=" line
		representing the offerer/answerer BUNDLE tag.
		</t>
		<t>
		For RTP-based media, the "tls-id" attribute applies to the whole ass
		ociated
		media description. The attribute <bcp14>MUST NOT</bcp14> be defined
		per source (using the
		SDP "ssrc" attribute <xref format="default" target="RFC5576"/>).
		</t>
		<t>
		The SDP offer/answer procedures <xref format="default" target="RFC32
		64"/>
		associated with the attribute are defined in <xref target="sec-oa" f
		ormat="default"/>.
		</t>
		</section>
		<section anchor="sec-oa" numbered="true" toc="default">
		<name>SDP Offer/Answer Procedures</name>
		<section numbered="true" toc="default">
		<name>General</name>
		<t>
		This section defines the generic SDP offer/answer procedures
		for negotiating
		a DTLS association. Additional procedures (e.g., regarding
		usage of specific SDP
		attributes) for individual DTLS usages (e.g., DTLS-SRTP)
		are outside the scope
		of this specification and need to be specified in a
		usage-specific document.
	</t>	</t>

		<aside>
	<t>	<t>

	The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>	NOTE: The procedures in this section are generalizations of procedures
	for the 'tls-id' attribute is 'IDENTICAL', which means that	first
	the attribute value applies to all media descriptions	specified in the DTLS-SRTP document <xref format="default" target="RFC
	being multiplexed <xref target="I-D.ietf-mmusic-sdp-bundle-negotiati	5763"/>,
	on"/>.	with the addition of usage of the SDP "tls-id" attribute. That documen
	However, as described in <xref target="I-D.ietf-mmusic-sdp-bundle-ne	t is
	gotiation"/>,	herein updated to make use of these new procedures.
	in order to avoid duplication the attribute is only associated with
	the "m=" line
	representing the offerer/answerer BUNDLE-tag.
	</t>	</t>

		</aside>
	<t>	<t>

	For RTP-based media, the 'tls-id' attribute applies to the whole ass	The procedures in this section apply to an SDP media description
	ociated	("m=" line) associated
	media description. The attribute MUST NOT be defined per source (usi	with DTLS-protected media/data.
	ng the
	SDP 'ssrc' attribute <xref format="default" pageno="false" target="R
	FC5576"/>).
	</t>	</t>
	<t>	<t>

	The SDP offer/answer <xref format="default" pageno="false" target="R	When an offerer or answerer indicates that it wants to establish a
	FC3264"/>	new DTLS association, it needs to make sure that
	procedures associated with the attribute are defined in <xref target	media packets associated with any previously established DTLS
	="sec-oa"/>.	association and the new DTLS association can be demultiplexed. In
		the case
		of an ordered transport (e.g., SCTP), this can be done simply by
		sending packets for the new DTLS association
		after all packets associated with a previously established DTLS
		association have been sent. In the case of an unordered transport, such
		as
		UDP, packets associated with a previously established DTLS
		association can arrive after the answer SDP and
		the first packets associated with the new DTLS association have been
		received. The
		only way to demultiplex packets associated with
		a previously established DTLS association and the new DTLS
		association is on the basis of the 5-tuple. Because of this, if an
		unordered transport
		is used for the DTLS association, a new 3-tuple (transport/source
		address/source port) <bcp14>MUST</bcp14> be allocated by at least
		one of the endpoints so that DTLS packets can be demultiplexed.
	</t>	</t>

	</section>	<t>
		When an offerer needs to establish a new DTLS association, and if an
	<section title="SDP Offer/Answer Procedures" anchor="sec-oa">	unordered transport (e.g., UDP)
	<section title="General">	is used, the offerer <bcp14>MUST</bcp14> allocate a new 3-tuple for
	<t>	the offer in such a way that the offerer can
	This section defines the generic SDP offer/answer procedures for	disambiguate any packets associated with the new DTLS association
	negotiating	from any packets associated with
	a DTLS association. Additional procedures (e.g., regarding usage	any other DTLS association. This typically means using a local
	of specific SDP	address and/or port, or a set of
	attributes etc.) for individual DTLS usages (e.g., DTLS-SRTP) ar	ICE candidates (see <xref format="default"
	e outside the scope	target="sec-dtls-reest-ice"/>), which were
	of this specification, and need to be specified in a usage speci	not recently used for any other DTLS association.
	fic specification.	</t>
	</t>	<t>
	<t>	When an answerer needs to establish a new DTLS association, if an
	NOTE: The procedures in this section are generalizations of proc	unordered transport is used, and
	edures first	the offerer did not allocate a new 3-tuple, the answerer
	specified in DTLS-SRTP <xref format="default" pageno="false" tar	<bcp14>MUST</bcp14> allocate a new 3-tuple for the
	get="RFC5763"/>,	answer in such a way that it can disambiguate any packets associated
	with the addition of usage of the SDP 'tls-id' attribute. That d	with the new DTLS association from any
	ocument is	packets associated with any other DTLS association. This typically
	herein updated to make use of these new procedures.	means using a local address and/or
	</t>	port, or a set of ICE candidates (see <xref format="default"
	<t>	target="sec-dtls-reest-ice"/>),
	The procedures in this section apply to an SDP media description	which were not recently used for any other DTLS association.
	("m=" line) associated	</t>
	with DTLS-protected media/data.	<t>
	</t>
	<t>
	When an offerer or answerer indicates that it wants to establish
	a new DTLS association, it needs to make sure that
	media packets associated with any previously established DTLS as
	sociation and the new DTLS association can be de-multiplexed. In case
	of an ordered transport (e.g., SCTP) this can be done simply by
	sending packets for the new DTLS association
	after all packets associated with a previously established DTLS
	association has been sent. In case of an unordered transport, such as
	UDP, packets associated with a previously established DTLS assoc
	iation can arrive after the answer SDP was received and after the first
	packets associated with the new DTLS association were received.
	The only way to de-multiplex packets associated with
	with a previously established DTLS association and the new DTLS
	association is on the basis of the 5-tuple. Because of this, if an unordered tra
	nsport
	is used for the DTLS association, a new 3-tuple (transport/sourc
	e address/source port) MUST be allocated by at least one
	of the endpoints so that DTLS packets can be de-multiplexed.
	</t>
	<t>
	When an offerer needs to establish a new DTLS association, and i
	f an unordered transport (e.g., UDP)
	is used, the offerer MUST allocate a new 3-tuple for the offer i
	n such a way that the offerer can
	disambiguate any packets associated with the new DTLS associatio
	n from any packets associated with
	any other DTLS association. This typically means using a local a
	ddress and/or port, or a set of
	ICE candidates (see <xref format="default" pageno="false" target
	="sec-dtls-reest-ice"/>), which were
	not recently used for any other DTLS association.
	</t>
	<t>
	When an answerer needs to establish a new DTLS association, if a
	n unordered transport is used, and if
	the offerer did not allocate a new 3-tuple, the answerer MUST al
	locate a new 3-tuple for the
	answer in such a way that it can disambiguate any packets associ
	ated with the new DTLS association from any
	packets associated with any other DTLS association. This typical
	ly means using a local address and/or
	port, or a set of ICE candidates (see <xref format="default" pag
	eno="false" target="sec-dtls-reest-ice"/>),
	which were not recently used for any other DTLS association.
	</t>
	<t>
	In order to negotiate a DTLS association, the following SDP attr ibutes are used:	In order to negotiate a DTLS association, the following SDP attr ibutes are used:

	<list style="symbols">	</t>
	<t>	<ul spacing="normal">
	The SDP 'setup' attribute, defined in <xref target="RFC4	<li>
	145" pageno="false"	The SDP "setup" attribute, defined in <xref target="RFC4
	format="default" />, is used to negotiate the DTLS roles	145" format="default"/>, is used to negotiate the DTLS roles;
	;	</li>
	</t>	<li>
	<t>	The SDP "fingerprint" attribute, defined in <xref format
	The SDP 'fingerprint' attribute, defined in <xref format	="default" target="RFC8122"/>, is used to
	="default"
	pageno="false" target="RFC8122"/>, is used to
	provide one or more fingerprint values; and	provide one or more fingerprint values; and

	</t>	</li>
	<t>	<li>
	The SDP 'tls-id' attribute, defined in this specificatio	The SDP "tls-id" attribute, defined in this specificatio
	n, is used to identity	n, is used to identity
	the DTLS association.	the DTLS association.

	</t>	</li>
	</list>	</ul>
	</t>	<t>
	<t>	This specification does not define the usage of the SDP "connect
	This specification does not define the usage of the SDP 'connect	ion" attribute
	ion' attribute	<xref target="RFC4145" format="default"/> for negotiating a DTLS
	<xref target="RFC4145" pageno="false" format="default" /> for ne	association. However, the attribute <bcp14>MAY</bcp14> be used i
	gotiating a DTLS	f the DTLS association is used
	association. However, the attribute MAY be used if the DTLS asso
	ciation is used
	together with another protocol (e.g., SCTP or TCP) for which the usage of the	together with another protocol (e.g., SCTP or TCP) for which the usage of the
	attribute has been defined.	attribute has been defined.

	</t>	</t>
	<t>	<t>
	Unlike for TCP and TLS connections, endpoints MUST NOT use the	Unlike for TCP and TLS connections, endpoints <bcp14>MUST NOT</b
	SDP 'setup' attribute 'holdconn' value when negotiating a DTLS a	cp14> use the
	ssociation.	SDP "setup" attribute "holdconn" value when negotiating a DTLS a
	</t>	ssociation.
	<t>	</t>
	Endpoints MUST support the hash functions as defined in	<t>
	<xref format="default" pageno="false" target="RFC8122"/>.	Endpoints <bcp14>MUST</bcp14> support the hash functions as defi
	</t>	ned in
	<t>	<xref format="default" target="RFC8122"/>.
	The certificate received during the DTLS handshake <xref format=	</t>
	"default"	<t>
	pageno="false" target="RFC6347"/> MUST match a certificate	The certificate received during the DTLS handshake <xref format=
	fingerprint received in SDP 'fingerprint' attributes according t	"default" target="RFC6347"/> <bcp14>MUST</bcp14> match a certificate
	o the procedures	fingerprint received in SDP "fingerprint" attributes according t
	defined in <xref format="default" pageno="false" target="RFC8122	o the procedures
	"/>.	defined in <xref format="default" target="RFC8122"/>.
	If fingerprints do not match the hashed certificate, then an end	If fingerprints do not match the hashed certificate, then an end
	point MUST tear	point <bcp14>MUST</bcp14> tear
	down the media session immediately (see <xref format="default" p	down the media session immediately (see <xref format="default" t
	ageno="false"	arget="RFC8122"/>).
	target="RFC8122"/>).	</t>
	</t>	<t>
	<t>
	SDP offerers and answerers might reuse certificates across multi ple DTLS	SDP offerers and answerers might reuse certificates across multi ple DTLS
	associations, and provide identical fingerprint values for each DTLS	associations, and provide identical fingerprint values for each DTLS

	association. The combination of the SDP 'tls-id' attribute value s of the SDP	association. The combination of the SDP "tls-id" attribute value s of the SDP
	offerer and answerer identifies each individual DTLS association .	offerer and answerer identifies each individual DTLS association .

	</t>	</t>
	<t>	<aside>
	NOTE: There are cases where the SDP 'tls-id' attribute value gen	<t>
	erated by the	NOTE: There are cases where the SDP "tls-id" attribute value generated
	offerer will end up being used for multiple DTLS associations. F	by the
	or that reason	offerer will end up being used for multiple DTLS associations. For tha
	the combination of the attribute values of the offerer and answe	t reason,
	rer is needed	the combination of the attribute values of the offerer and answerer is
	in order to identity a DTLS association. An example of such case	needed
	is where the	in order to identity a DTLS association. An example of such a case is
	offerer sends an updated offer (<xref target="sec-oa-mod"/>), wi	where the
	thout modifying its	offerer sends an updated offer (<xref target="sec-oa-mod"
	attribute value, but the answerer determines that a new DTLS ass	format="default"/>) without modifying its
	ociation is to	attribute value, but the answerer determines that a new DTLS associati
	be created. The answerer will generate a new local attribute val	on is to
	ue for the new	be created. The answerer will generate a new local attribute value for
	DTLS association (<xref target="sec-oa-answer"/>), while the off	the new
	erer will use the	DTLS association (<xref target="sec-oa-answer" format="default"/>), wh
	same attribute value that it used for the current association. A	ile the offerer will use the
	nother example is	same attribute value that it used for the current association. Another
	when the Session Initiation Protocol (SIP) <xref format="default	example is
	" pageno="false"	when the Session Initiation Protocol (SIP) <xref format="default"
	target="RFC3261"/> is used for signalling, and an offer is forke	target="RFC3261"/> is used for signaling, and an offer is forked to
	d to multiple answerers.	multiple answerers.
	The attribute value generated by the offerer will be used for DT	The attribute value generated by the offerer will be used for DTLS ass
	LS associations	ociations
	established by each answerer.	established by each answerer.
	</t>	</t>
	</section>	</aside>
		</section>
	<section title="Generating the Initial SDP Offer" anchor="sec-oa-offer">	<section anchor="sec-oa-offer" numbered="true" toc="default">
	<t>	<name>Generating the Initial SDP Offer</name>
	When an offerer sends the initial offer, the offerer MUST insert	<t>
	an SDP 'setup' attribute	When an offerer sends the initial offer, the offerer
	<xref format="default" pageno="false" target="RFC4145"/> with an	<bcp14>MUST</bcp14> insert an SDP "setup" attribute
	'actpass' attribute value, and	<xref format="default" target="RFC4145"/> with an "actpass"
	one or more SDP 'fingerprint' attributes according to the proced	attribute value, as well as
	ures in <xref format="default"	one or more SDP "fingerprint" attributes according to the procedures
	pageno="false" target="RFC8122"/>. In addition, the offerer MUST	in <xref format="default" target="RFC8122"/>. In addition, the
	insert in the offer an SDP	offerer <bcp14>MUST</bcp14> insert in the offer an SDP
	'tls-id' attribute with a unique attribute value.	"tls-id" attribute with a unique attribute value.
	</t>	</t>
	<t>	<t>
	As the offerer inserts the SDP 'setup' attribute with an 'actpas	As the offerer inserts the SDP "setup" attribute with an
	s' attribute value, the	"actpass" attribute value, the
	offerer MUST be prepared to receive a DTLS ClientHello message <	offerer <bcp14>MUST</bcp14> be prepared to receive a DTLS
	xref format="default" pageno="false"	ClientHello message <xref format="default" target="RFC6347"/>
	target="RFC6347"/> (if a new DTLS association is established by	from the answerer
	the answerer) from the answerer	(if a new DTLS association is established by the answerer)
	before the offerer receives the SDP answer.	before the offerer receives the SDP answer.
	</t>	</t>
	<t>	<t>
	If the offerer receives a DTLS ClientHello message, and a DTLS a	If the offerer receives a DTLS ClientHello message, and a DTLS
	ssociation is established,	association is established
	before the offerer receives the SDP Answer carrying the fingerpr	before the offerer receives the SDP answer carrying the
	int associated with the DTLS	fingerprint associated with the DTLS
	association, any data received on the DTLS association before th	association, any data received on the DTLS association before
	e fingerprint MUST be	the fingerprint <bcp14>MUST</bcp14> be
	considered coming from an unverified source. The processing of s	considered to be coming from an unverified source. The processing of
	uch data, and sending of data	such data and sending of data
	by the offerer to the unverified source, is outside the scope of	by the offerer to the unverified source is outside the scope
	this document.	of this document.
	</t>	</t>
	</section>	</section>
	<section title="Generating the Answer" anchor="sec-oa-answer">	<section anchor="sec-oa-answer" numbered="true" toc="default">
	<t>	<name>Generating the Answer</name>
	When an answerer sends an answer, the answerer MUST insert in th	<t>
	e answer an SDP 'setup' attribute	When an answerer sends an answer, the answerer
	according to the procedures in <xref format="default" pageno="fa	<bcp14>MUST</bcp14> insert in the answer an SDP "setup"
	lse" target="RFC4145"/>, and one	attribute
	or more SDP 'fingerprint' attributes according to the procedures	according to the procedures in <xref format="default"
	in <xref format="default"	target="RFC4145"/> and one
	pageno="false" target="RFC8122"/>.	or more SDP "fingerprint" attributes according to the
	If the answerer determines, based on the criteria specified in <	procedures in <xref format="default" target="RFC8122"/>.
	xref target="sec-dtls-gen"/>,	If the answerer determines, based on the criteria specified in
	that a new DTLS association is to be established, the answerer M	<xref target="sec-dtls-gen" format="default"/>,
	UST insert in the associated answer	that a new DTLS association is to be established, the answerer
	an SDP 'tls-id' attribute with a new unique attribute value. Not	<bcp14>MUST</bcp14> insert in the associated answer
	e that the offerer and answerer generate	an SDP "tls-id" attribute with a new unique attribute
	their own local 'tls-id' attribute values, and the combination o	value. Note that the offerer and answerer generate
	f both values identify the	their own local "tls-id" attribute values, and the combination
		of both values identifies the
	DTLS association.	DTLS association.

	</t>	</t>
	<t>	<t>
	If the answerer receives an offer that requires establishment of a new DTLS association, and if the	If the answerer receives an offer that requires establishment of a new DTLS association, and if the

	answerer does not accept the establishment of a new DTLS associa tion, the answerer MUST reject	answerer does not accept the establishment of a new DTLS associa tion, the answerer <bcp14>MUST</bcp14> reject
	the "m=" lines associated with the suggested DTLS association	the "m=" lines associated with the suggested DTLS association

	<xref format="default" pageno="false" target="RFC3264"/>.	<xref format="default" target="RFC3264"/>.
	</t>	</t>
	<t>	<t>
	If an answerer receives an offer that does not require the estab lishment of a new DTLS association,	If an answerer receives an offer that does not require the estab lishment of a new DTLS association,
	and if the answerer determines that a new DTLS association is no t to be established,	and if the answerer determines that a new DTLS association is no t to be established,

	the answerer MUST insert an SDP 'tls-id' attribute with the prev	the answerer <bcp14>MUST</bcp14> insert in the associated
	iously assigned attribute value in the	answer an SDP "tls-id"
	associated answer. In addition, the answerer MUST insert an SDP	attribute with the previously assigned attribute value. In
	'setup' attribute with an	addition, the answerer
	attribute value that does not change the previously negotiated D	<bcp14>MUST</bcp14> insert an SDP "setup" attribute with an
	TLS roles, and one or more SDP 'fingerprint'	attribute value that does not change the previously negotiated
	attributes values that do not change the previously sent fingerp	DTLS roles, as well as one or more SDP "fingerprint"
	rint set, in the associated answer.	attributes values that do not change the previously sent
	</t>	fingerprint set, in the associated answer.
	<t>	</t>
	If the answerer receives an offer that does not contain an SDP '	<t>
	tls-id' attribute,	If the answerer receives an offer that does not contain an SDP "tls-id
	the answerer MUST NOT insert a 'tls-id' attribute in the answer.	" attribute,
	</t>	the answerer <bcp14>MUST NOT</bcp14> insert a "tls-id" attribute in th
	<t>	e answer.
	If a new DTLS association is to be established, and if the answe	</t>
	rer inserts an SDP 'setup'	<t>
	attribute with an 'active' attribute value in the answer, the an	If a new DTLS association is to be established, and if the
	swerer MUST initiate a DTLS handshake	answerer inserts an SDP "setup"
	<xref format="default" pageno="false" target="RFC6347"/>) by sen	attribute with an "active" attribute value in the answer, the
	ding a DTLS ClientHello message towards the offerer.	answerer <bcp14>MUST</bcp14> initiate a DTLS handshake
	</t>	<xref format="default" target="RFC6347"/> by sending a DTLS
	<t>	ClientHello message towards the offerer.
	Even though an offerer is required to insert an 'SDP' setup attr	</t>
	ibute with an 'actpass' attribute value	<t>
	in initial offers (<xref target="sec-oa-offer"/>) and subsequent	Even though an offerer is required to insert an "SDP" setup attr
	offers (<xref target="sec-oa-mod"/>),	ibute with an "actpass" attribute value
	the answerer MUST be able to receive initial and subsequent offe	in initial offers (<xref target="sec-oa-offer" format="default"/
	rs with other attribute values, in order	>) and subsequent offers (<xref target="sec-oa-mod" format="default"/>),
		the answerer <bcp14>MUST</bcp14> be able to receive initial and
		subsequent offers with other attribute values, in order
	to be backward compatible with older implementations that might insert other attribute values in initial and	to be backward compatible with older implementations that might insert other attribute values in initial and
	subsequent offers.	subsequent offers.

	</t>	</t>
	</section>	</section>
	<section title="Offerer Processing of the SDP Answer">	<section numbered="true" toc="default">
	<t>	<name>Offerer Processing of the SDP Answer</name>
	When an offerer receives an answer that establishes a new DTLS a	<t>
	ssociation based on	When an offerer receives an answer that establishes a new DTLS
	criteria defined in <xref target="sec-dtls-gen"/>, and if the of	association based on
	ferer	criteria defined in <xref target="sec-dtls-gen"
	becomes DTLS client (based on the value of the SDP 'setup' attri	format="default"/>, if the offerer
	bute value	becomes DTLS client (based on the value of the SDP "setup" attri
	<xref format="default" pageno="false" target="RFC4145"/>), the o	bute value
	fferer MUST	<xref format="default" target="RFC4145"/>), the offerer <bcp14>M
	establish a DTLS association. If the offerer becomes DTLS server	UST</bcp14>
	, it MUST wait for the answerer	establish a DTLS association. If the offerer becomes DTLS server
		, it <bcp14>MUST</bcp14> wait for the answerer
	to establish the DTLS association.	to establish the DTLS association.

	</t>	</t>
	<t>	<t>
	If the offerer indicated a desire to reuse an existing DTLS asso	If the offerer indicated a desire to reuse an existing DTLS
	ciation and the	association, and the
	answerer does not request the establishment of a new DTLS associ	answerer does not request the establishment of a new DTLS
	ation, the offerer will	association, the offerer will
	continue to use the previously established DTLS association.	continue to use the previously established DTLS association.

	</t>	</t>
	<t>	<t>
	A new DTLS association can be established based on changes in ei	A new DTLS association can be established based on changes in either
	ther an SDP offer or answer.	an SDP offer or answer.
	When communicating with legacy endpoints, an offerer can receive	When communicating with legacy endpoints, an offerer can receive an
	an answer that includes the same	answer that includes the same
	fingerprint set and setup role. A new DTLS association will stil	fingerprint set and setup role. A new DTLS association will still be
	l be established if such an answer	established if such an answer
	was received as a response to an offer which requested the estab	is received as a response to an offer that requested the
	lishment of a new DTLS association,	establishment of a new DTLS association,
	as the transport parameters would have been changed in the offer	as the transport parameters would have been changed in the offer.
	.	</t>
	</t>	</section>
	</section>	<section anchor="sec-oa-mod" numbered="true" toc="default">
	<section title="Modifying the Session" anchor="sec-oa-mod">	<name>Modifying the Session</name>
	<t>	<t>
	When an offerer sends a subsequent offer, and if the offerer wan	When an offerer sends a subsequent offer, if the offerer
	ts to establish a new	wants to establish a new
	DTLS association, the offerer MUST insert an SDP 'setup' attribu	DTLS association, the offerer <bcp14>MUST</bcp14> insert an
	te <xref format="default"	SDP "setup" attribute <xref format="default"
	pageno="false" target="RFC4145"/> with an 'actpass' attribute va	target="RFC4145"/> with an "actpass" attribute value, as well as
	lue, and one or more SDP 'fingerprint'	or more SDP "fingerprint"
	attributes according to the procedures in <xref format="default"	attributes according to the procedures in <xref
	pageno="false" target="RFC8122"/>.	format="default" target="RFC8122"/>.
	In addition, the offerer MUST insert in the offer an SDP 'tls-id	In addition, the offerer <bcp14>MUST</bcp14> insert in the offer
	' attribute with a new unique	an SDP "tls-id" attribute with a new unique
	attribute value.	attribute value.

	</t>	</t>
	<t>	<t>
	When an offerer sends a subsequent offer, and the offerer does n	When an offerer sends a subsequent offer and does
	ot want to establish	not want to establish
	a new DTLS association, and if a previously established DTLS ass	a new DTLS association, if a previously established DTLS
	ociation exists,	association exists,
	the offerer MUST insert an SDP 'setup' attribute with an 'actpas	the offerer <bcp14>MUST</bcp14> insert in the offer an SDP "setu
	s' attribute value, and	p"
	one or more SDP 'fingerprint' attributes with attribute values t	attribute with an "actpass" attribute value, and
	hat do not change the previously	one or more SDP "fingerprint" attributes with attribute values
	sent fingerprint set, in the offer. In addition, the offerer MUS	that do not change the previously
	T insert an SDP 'tls-id'	sent fingerprint set. In addition, the offerer
		<bcp14>MUST</bcp14> insert an SDP "tls-id"
	attribute with the previously assigned attribute value in the of fer.	attribute with the previously assigned attribute value in the of fer.

	</t>	</t>
	<t>	<aside>
	NOTE: When a new DTLS association is being established, each end
	point needs to be prepared to receive
	data on both the new and old DTLS associations as long as both a
	re alive.
	</t>
	</section>
	</section>

	<section title="ICE Considerations" anchor="sec-dtls-reest-ice">
	<t>	<t>

		NOTE: When a new DTLS association is being established, each
		endpoint needs to be prepared to receive
		data on both the new and old DTLS associations as long as both are
		alive.
		</t>
		</aside>
		</section>
		</section>
		<section anchor="sec-dtls-reest-ice" numbered="true" toc="default">
		<name>ICE Considerations</name>
		<t>
	When the Interactive Connectivity Establishment (ICE) mechanism	When the Interactive Connectivity Establishment (ICE) mechanism

	<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bi s"/> is used, the	<xref format="default" target="RFC8445"/> is used, the
	ICE connectivity checks are performed before the DTLS	ICE connectivity checks are performed before the DTLS
	handshake begins. Note that if aggressive nomination mode is used,	handshake begins. Note that if aggressive nomination mode is used,
	multiple candidate pairs may be marked valid before ICE finally	multiple candidate pairs may be marked valid before ICE finally
	converges on a single candidate pair.	converges on a single candidate pair.

	</t>	</t>
	<t>	<aside>
	NOTE: Aggressive nomination has been deprecated from ICE, but must s	<t>
	till be	NOTE: Aggressive nomination has been deprecated from ICE but must still
	supported for backwards compatibility reasons <xref format="default"	be
	pageno="false"	supported for backwards compatibility reasons <xref format="default"
	target="I-D.ietf-ice-rfc5245bis"/>.	target="RFC8445"/>.
	</t>	</t>
	<t>	</aside>
	When a new DTLS association is established over an unordered transpo	<t>
	rt, in order to	When a new DTLS association is established over an unordered
	disambiguate any packets associated with the newly established DTLS	transport, in order to
	association, at least	disambiguate any packets associated with the newly established
	one of the endpoints MUST allocate a completely new set of ICE candi	DTLS association, at least
	dates which	one of the endpoints <bcp14>MUST</bcp14> allocate a completely new
		set of ICE candidates that
	were not recently used for any other DTLS association. This means th e answerer	were not recently used for any other DTLS association. This means th e answerer
	cannot initiate a new DTLS association unless the offerer initiated ICE restart	cannot initiate a new DTLS association unless the offerer initiated ICE restart

	<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bi s"/>. If the answerer wants	<xref format="default" target="RFC8445"/>. If the answerer wants
	to initiate a new DTLS association, it needs to initiate an ICE rest art	to initiate a new DTLS association, it needs to initiate an ICE rest art
	and a new offer/answer exchange on its own. However, an ICE restart does not by	and a new offer/answer exchange on its own. However, an ICE restart does not by
	default require a new DTLS association	default require a new DTLS association
	to be established.	to be established.

	</t>	</t>
	<t>	<aside>
	NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packet	<t>
	s are sent directly	NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
	over UDP, not over DTLS. <xref format="default" pageno="false" targe	are sent directly
	t="RFC7983"/> describes	over UDP, not over DTLS. <xref format="default" target="RFC7983"/> descr
	how to demultiplex STUN packets from DTLS packets and SRTP packets.	ibes
	</t>	how to demultiplex STUN packets from DTLS packets and SRTP packets.
	<t>	</t>
		</aside>
		<t>
	Each ICE candidate associated with a component is treated as being p art of the	Each ICE candidate associated with a component is treated as being p art of the

	same DTLS association. Therefore, from a DTLS perspective it is not considered	same DTLS association. Therefore, from a DTLS perspective, it is not considered
	a change of local transport parameters when an endpoint switches bet ween those	a change of local transport parameters when an endpoint switches bet ween those
	ICE candidates.	ICE candidates.

	</t>	</t>
	</section>	</section>

		<section anchor="sec-tls-cons" numbered="true" toc="default">
	<section title="TLS Considerations" anchor="sec-tls-cons">	<name>TLS Considerations</name>
	<t>	<t>
	The procedures in this document can also be used for negotiating and	The procedures in this document can also be used for negotiating and
	establishing a TLS connection, with the restriction described below.	establishing a TLS connection, with the restriction described below.

	</t>	</t>
	<t>	<t>
	As specified in <xref format="default" pageno="false" target="RFC414	As specified in <xref format="default" target="RFC4145"/>,
	5"/>,	the SDP "connection" attribute is used to indicate whether to establ
	the SDP 'connection' attribute is used to indicate whether to establ	ish a new
	ish a new	TLS connection. An offerer and answerer <bcp14>MUST</bcp14> ensure
	TLS connection. An offerer and answerer MUST ensure that the 'connec	that the "connection"
	tion'	attribute value and the "tls-id" attribute value do not cause a conf
	attribute value and the 'tls-id' attribute value does not cause a co	lict
	nflict
	regarding whether a new TLS connection is to be established or not.	regarding whether a new TLS connection is to be established or not.

	</t>	</t>
	<t>	<aside>
	NOTE: Even though the SDP 'connection' attribute can be used to indi	<t>
	cate	NOTE: Even though the SDP "connection" attribute can be used to indi
		cate
	whether a new TLS connection is to be established, the unique combin ation	whether a new TLS connection is to be established, the unique combin ation

	of SDP 'tls-id' attribute values can be used to identity a TLS conne ction.	of SDP "tls-id" attribute values can be used to identity a TLS conne ction.
	The unique value can be used e.g., within TLS protocol extensions to differentiate	The unique value can be used e.g., within TLS protocol extensions to differentiate
	between multiple TLS connections and correlate those connections wit h specific	between multiple TLS connections and correlate those connections wit h specific
	offer/answer exchanges. One such extension is defined in	offer/answer exchanges. One such extension is defined in

	<xref format="default" pageno="false" target="I-D.ietf-mmusic-sdp-uk	<xref format="default" target="RFC8844"/>.
	s"/>.	</t>
		</aside>
	</t>	<t>
	<t>	If an offerer or answerer inserts an SDP "connection" attribute with
	If an offerer or answerer inserts an SDP 'connection' attribute with	a "new"
	a 'new'	value in the offer/answer and also inserts an SDP "tls-id" attribute
	value in the offer/answer and also inserts an SDP 'tls-id' attribute	,
	,	the value of the "tls-id" attribute <bcp14>MUST</bcp14> be new and u
	the value of tls-id' attribute MUST be new and unique.	nique.
	</t>	</t>
	<t>	<t>
	If an offerer or answerer inserts an SDP 'connection' attribute with	If an offerer or answerer inserts an SDP "connection" attribute with an
	a 'existing'	"existing"
	value in the offer/answer, if a previously established TLS connectio	value in the offer/answer, if a previously established TLS connection ex
	n exists, and	ists, and
	if the offerer/answerer previously inserted an SDP 'tls-id' attribut	if the offerer/answerer previously inserted an SDP "tls-id" attribute as
	e associated with	sociated with
	the same TLS connection in an offer/answer, the offerer/answerer MUS	the same TLS connection in an offer/answer, the offerer/answerer
	T also insert	<bcp14>MUST</bcp14> also insert
	an SDP 'tls-id' attribute with the previously assigned value in the	an SDP "tls-id" attribute with the previously assigned value in the offe
	offer/answer.	r/answer.
	</t>	</t>
	<t>	<t>
	If an offerer or answerer receives an offer/answer with conflicting attribute values,	If an offerer or answerer receives an offer/answer with conflicting attribute values,

	the offerer/answerer MUST process the offer/answer as misformed.	the offerer/answerer <bcp14>MUST</bcp14> process the offer/answer as
	</t>	misformed.
	<t>	</t>
	An endpoint MUST NOT make assumptions regarding the support of the S	<t>
	DP 'tls-id'	An endpoint <bcp14>MUST NOT</bcp14> make assumptions regarding the
	attribute by the peer. Therefore, to avoid ambiguity, both offerers	support of the SDP "tls-id"
	and answerers	attribute by the peer. Therefore, to avoid ambiguity, both
	MUST always use the 'connection' attribute in conjunction with the '	offerers and answerers
	tls-id' attribute.	<bcp14>MUST</bcp14> always use the "connection" attribute in
	</t>	conjunction with the "tls-id" attribute.
	<t>	</t>
	NOTE: As defined in <xref format="default" pageno="false" target="RF	<aside>
	C4145"/>, if the	<t>
	SDP 'connection' attribute is not explicitly present, the implicit d	NOTE: As defined in <xref format="default" target="RFC4145"/>, if th
	efault value is 'new'.	e
	</t>	SDP "connection" attribute is not explicitly present, the implicit
	<t>	default value is "new".
	The SDP example below is based on the example in section 3.4 of	</t>
	<xref format="default" pageno="false" target="RFC8122"/>, with the a	</aside>
	ddition of	<t>
	the SDP 'tls-id' attribute.	The SDP example below is based on the example in
	</t>	<xref format="default" target="RFC8122" sectionFormat="of"
	<figure>	section="3.4"/>, with the addition of
	<artwork align="left"><![CDATA[	the SDP "tls-id" attribute.
		</t>


	m=image 54111 TCP/TLS t38	<sourcecode type="sdp" >
	c=IN IP4 192.0.2.2	m=image 54111 TCP/TLS t38
	a=tls-id:abc3de65cddef001be82	c=IN IP4 192.0.2.2
	a=setup:passive	a=tls-id:abc3de65cddef001be82
	a=connection:new	a=setup:passive
	a=fingerprint:SHA-256 \	a=connection:new
	12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \	a=fingerprint:SHA-256 \
	3E:5D:49:6B:19:E5:7C:AB:4A:AD	12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
	a=fingerprint:SHA-1 \	3E:5D:49:6B:19:E5:7C:AB:4A:AD
	4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB	a=fingerprint:SHA-1 \
		4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
		</sourcecode>


	]]></artwork>
	</figure>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="SIP Considerations">	<name>SIP Considerations</name>
	<t>	<t>
	When the Session Initiation Protocol (SIP) <xref format="default" pa	When the Session Initiation Protocol (SIP) <xref format="default"
	geno="false"	target="RFC3261"/> is used as the signal protocol for establishing
	target="RFC3261"/> is used as the signal protocol for establishing a	a multimedia
	multimedia	session, dialogs <xref format="default" target="RFC3261"/> might be
	session, dialogs <xref format="default" pageno="false" target="RFC32	established between the caller and multiple callees. This is referred to
	61"/> might be	as forking.
	established between the caller and multiple callees. This is referre	If forking occurs, separate DTLS associations will be established betwee
	d to as forking.	n the caller
	If forking occurs, separate DTLS associations will be established be	and each callee.
	tween the caller	</t>
	and each callee.	<t>
	</t>	When forking occurs, an SDP offerer can receive DTLS ClientHello
	<t>	messages and SDP
	When forking occurs, an SDP offerer can receive DTLS ClientHello mes	answers from multiple remote locations. Because of this, the
	sages and SDP	offerer might have to
	answerers from multiple remote locations. Because of this, the offer	wait for multiple SDP answers (from different remote locations)
	er might have to	until it receives
	wait for multiple SDP answers (from different remote locations) unti	a certificate fingerprint that matches the certificate associated
	l it receives	with a specific
	a certificate fingerprint that matches the certificate associated wi	DTLS handshake. The offerer <bcp14>MUST NOT</bcp14> declare a
	th a specific	fingerprint mismatch until it
	DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch	determines that it will not receive SDP answers from any
	until it	additional remote locations.
	determines that it will not receive SDP answers from any additional	</t>
	remote locations.	<t>
	</t>	It is possible to send an INVITE request that does not contain an SD
	<t>	P offer. Such
	It is possible to send an INVITE request which does not contain an S	an INVITE request is often referred to as an "empty INVITE" or an
	DP offer. Such	"offerless INVITE".
	an INVITE request is often referred to as an 'empty INVITE', or an '
	offer-less INVITE'.
	The receiving endpoint will include the SDP offer in a response to t he request.	The receiving endpoint will include the SDP offer in a response to t he request.

	When the endpoint generates such SDP offer, if a previously establis	When the endpoint generates such an SDP offer, if a previously estab
	hed	lished
	DTLS association exists, the offerer MUST insert an SDP 'tls-id'	DTLS association exists, the offerer <bcp14>MUST</bcp14> insert an S
	attribute, and one or more SDP 'fingerprint' attributes, with previo	DP "tls-id"
	usly assigned	attribute and one or more SDP "fingerprint" attributes, with previou
	attribute values. If a previously established DTLS association did n	sly assigned
	ot exist,	attribute values. If a previously established DTLS association does
	the offer MUST be generated based on the same rules as a new offer (	not exist,
	see <xref target="sec-oa-offer"/>).	the offer <bcp14>MUST</bcp14> be generated based on the same rules a
	Regardless of the previous existence of a DTLS association, the SDP	s a new offer (see <xref target="sec-oa-offer" format="default"/>).
	'setup' attribute	Regardless of the previous existence of a DTLS association, the
	MUST be included according to the rules defined in <xref format="def	SDP "setup" attribute
	ault" pageno="false"	<bcp14>MUST</bcp14> be included according to the rules defined in
	target="RFC4145"/>. Furthermore, if ICE is used, according to the th	<xref format="default" target="RFC4145"/>. Furthermore, if ICE is
	ird party call control	used, ICE restart <bcp14>MUST</bcp14> be initiated, according to
	considerations described in <xref target="I-D.ietf-mmusic-ice-sip-sd	the third-party call-control
	p"/>, ICE restart	considerations described in <xref
	MUST be initiated.	target="RFC8839" format="default"/>.
	</t>	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="RFC Updates">	<name>RFC Updates</name>
	<section title="General">	<section numbered="true" toc="default">
	<t>	<name>General</name>
		<t>
	This section updates specifications that use DTLS-protected medi a, in	This section updates specifications that use DTLS-protected medi a, in
	order to reflect the procedures defined in this specification.	order to reflect the procedures defined in this specification.

	</t>	</t>
		</section>
		<section numbered="true" toc="default">
		<name>Update to RFC 5763</name>
		<section numbered="true" toc="default">
		<name>Update to Section 1</name>
		<t>The reference to <xref format="default" target="RFC4572"/> is repla
		ced
		with a reference to <xref format="default" target="RFC8122"/>.</t>
	</section>	</section>

	<section title="Update to RFC 5763">	<section numbered="true" toc="default">
	<section title="Update to section 1">	<name>Update to Section 5</name>
	<t>The reference to <xref format="default" pageno="false" target="RF	<t>The text in <xref target="RFC5763" section="5" sectionFormat="comma
	C4572"/> is replaced	"/> ("Establishing a Secure Channel") is modified
	with a reference to <xref format="default" pageno="false" target="RF	by replacing generic
	C8122"/>.</t>	SDP offer/answer procedures for DTLS with a reference to this
	</section>	specification:
	<section title="Update to section 5">	</t>
	<t>The text in section 5 (Establishing a Secure Channel) is modified
	by replacing generic
	SDP offer/answer procedures for DTLS with a reference to this specif
	ication:
	</t>
	<figure>
	<artwork align="left" alt="" height="" name="" type="" width=""
	xml:space="preserve"><![CDATA[

	NEW TEXT:


		<t>NEW TEXT:</t>
		<blockquote>
		<t>
	The two endpoints in the exchange present their identities as part of	The two endpoints in the exchange present their identities as part of
	the DTLS handshake procedure using certificates. This document uses	the DTLS handshake procedure using certificates. This document uses
	certificates in the same style as described in "Connection-Oriented	certificates in the same style as described in "Connection-Oriented
	Media Transport over the Transport Layer Security (TLS) Protocol in	Media Transport over the Transport Layer Security (TLS) Protocol in

	the Session Description Protocol (SDP)" [RFC8122].	the Session Description Protocol (SDP)" <xref target="RFC8122" />.
		</t>
		<t>
	If self-signed certificates are used, the content of the	If self-signed certificates are used, the content of the

	subjectAltName attribute inside the certificate MAY use the uniform	"subjectAltName" attribute inside the certificate <bcp14>MAY</bcp14> use the uniform
	resource identifier (URI) of the user. This is useful for debugging	resource identifier (URI) of the user. This is useful for debugging
	purposes only and is not required to bind the certificate to one of	purposes only and is not required to bind the certificate to one of
	the communication endpoints. The integrity of the certificate is	the communication endpoints. The integrity of the certificate is

	ensured through the fingerprint attribute in the SDP.	ensured through the "fingerprint" attribute in the SDP.
		</t>
		<t>
	The generation of public/private key pairs is relatively expensive.	The generation of public/private key pairs is relatively expensive.
	Endpoints are not required to generate certificates for each session.	Endpoints are not required to generate certificates for each session.

		</t>
	The offer/answer model, defined in [RFC3264], is used by protocols	<t>
	like the Session Initiation Protocol (SIP) [RFC3261] to set up	The offer/answer model, defined in <xref target="RFC3264"/>, is used by proto
		cols
		like the Session Initiation Protocol (SIP) <xref target="RFC3261" /> to set u
		p
	multimedia sessions.	multimedia sessions.

		</t>
		<t>
	When an endpoint wishes to set up a secure media session with another	When an endpoint wishes to set up a secure media session with another
	endpoint, it sends an offer in a SIP message to the other endpoint.	endpoint, it sends an offer in a SIP message to the other endpoint.
	This offer includes, as part of the SDP payload, a fingerprint of	This offer includes, as part of the SDP payload, a fingerprint of

	a certificate that the endpoint wants to use. The endpoint SHOULD	a certificate that the endpoint wants to use. The endpoint <bcp14>SHOULD</bcp 14>
	send the SIP message containing the offer to the offerer's SIP proxy	send the SIP message containing the offer to the offerer's SIP proxy

	over an integrity protected channel. The proxy SHOULD add an	over an integrity-protected channel. The proxy <bcp14>SHOULD</bcp14> add an
	Identity header field according to the procedures outlined in	Identity header field according to the procedures outlined in

	[RFC4474]. When the far endpoint receives the SIP message, it can	<xref target="RFC4474" />. When the far endpoint receives the SIP message, it can
	verify the identity of the sender using the Identity header field.	verify the identity of the sender using the Identity header field.
	Since the Identity header field is a digital signature across several	Since the Identity header field is a digital signature across several
	SIP header fields, in addition to the body of the SIP message, the	SIP header fields, in addition to the body of the SIP message, the
	receiver can also be certain that the message has not been tampered	receiver can also be certain that the message has not been tampered
	with after the digital signature was applied and added to the SIP	with after the digital signature was applied and added to the SIP
	message.	message.

		</t>
		<t>
	The far endpoint (answerer) may now establish a DTLS association with	The far endpoint (answerer) may now establish a DTLS association with
	the offerer. Alternately, it can indicate in its answer that the	the offerer. Alternately, it can indicate in its answer that the
	offerer is to initiate the DTLS association. In either case, mutual	offerer is to initiate the DTLS association. In either case, mutual
	DTLS certificate-based authentication will be used. After completing	DTLS certificate-based authentication will be used. After completing
	the DTLS handshake, information about the authenticated identities,	the DTLS handshake, information about the authenticated identities,

	including the certificates, are made available to the endpoint	including the certificates, is made available to the endpoint
	application. The answerer is then able to verify that the offerer's	application. The answerer is then able to verify that the offerer's
	certificate used for authentication in the DTLS handshake can be	certificate used for authentication in the DTLS handshake can be

	associated to a certificate fingerprint contained in the offer in	associated with a certificate fingerprint contained in the offer in
	the SDP. At this point, the answerer may indicate to the end user	the SDP. At this point, the answerer may indicate to the end user
	that the media is secured. The offerer may only tentatively accept	that the media is secured. The offerer may only tentatively accept

	the answerer's certificate since it may not yet have the answerer's	the answerer's certificate, since it may not yet have the answerer's
	certificate fingerprint.	certificate fingerprint
		</t>
		<t>
	When the answerer accepts the offer, it provides an answer back to	When the answerer accepts the offer, it provides an answer back to
	the offerer containing the answerer's certificate fingerprint. At	the offerer containing the answerer's certificate fingerprint. At

	this point, the offerer can accept or reject the peer's certificate	this point, the offerer can accept or reject the peer's certificate,
	and the offerer can indicate to the end user that the media is	and the offerer can indicate to the end user that the media is
	secured.	secured.

		</t>
		<t>
	Note that the entire authentication and key exchange for securing	Note that the entire authentication and key exchange for securing
	the media traffic is handled in the media path through DTLS. The	the media traffic is handled in the media path through DTLS. The
	signaling path is only used to verify the peers' certificate	signaling path is only used to verify the peers' certificate
	fingerprints.	fingerprints.

		</t>
	The offerer and answerer MUST follow the SDP offer/answer procedures	<t>
	defined in [RFCXXXX].	The offerer and answerer <bcp14>MUST</bcp14> follow the SDP offer/answer proc
		edures
	]]></artwork>	defined in RFC 8842.
	</figure>	</t>
	</section>	</blockquote>
	<section title="Update to section 6.6">	</section>
	<t>The text in section 6.6 (Session Modification) is modified by replac	<section numbered="true" toc="default">
	ing generic	<name>Update to Section 6.6</name>
		<t>The text in <xref target="RFC5763" section="6.6" sectionFormat="com
		ma"/> ("Session Modification") is modified by replacing generic
	SDP offer/answer procedures for DTLS with a reference to this specif ication:	SDP offer/answer procedures for DTLS with a reference to this specif ication:

	</t>	</t>
	<figure>
	<artwork align="left" alt="" height="" name="" type="" width="" xml:s
	pace="preserve"><![CDATA[


		<t>
	NEW TEXT:	NEW TEXT:

		</t>
	Once an answer is provided to the offerer, either endpoint MAY	<blockquote>
	request a session modification that MAY include an updated offer.	<t>
		Once an answer is provided to the offerer, either endpoint <bcp14>MAY</bcp14>
		request a session modification that <bcp14>MAY</bcp14> include an updated off
		er.
	This session modification can be carried in either an INVITE or	This session modification can be carried in either an INVITE or

	UPDATE request. The peers can reuse an existing DTLS association,	UPDATE request. The peers can reuse an existing DTLS association
	or establish a new one, following the procedures in [RFCXXXX].	or establish a new one, following the procedures in RFC 8842.
		</t></blockquote>
	]]></artwork>	</section>
	</figure>	<section numbered="true" toc="default">
	</section>	<name>Update to Section 6.7.1</name>
	<section title="Update to section 6.7.1">	<t>The text in <xref target="RFC5763" section="6.7.1" sectionFormat="c
	<t>The text in section 6.7.1 (ICE Interaction) is modified by replacing the	omma"/> ("ICE Interaction") is modified by
	ICE procedures with	replacing the ICE procedures with
	a reference to this specification:	a reference to this specification:
	</t>	</t>
	<figure>
	<artwork align="left" alt="" height="" name="" type="" width="" xml:space="p
	reserve"><![CDATA[


		<t>
	NEW TEXT:	NEW TEXT:

		</t>
		<blockquote>
	The Interactive Connectivity Establishment (ICE)	The Interactive Connectivity Establishment (ICE)

	[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media	<xref target="RFC8445" /> considerations for DTLS-protected media
	are described in [RFCXXXX].	are described in RFC 8842.
	]]></artwork>	</blockquote>
	</figure>
	</section>
	</section>	</section>

	<section title="Update to RFC 7345">	</section>
	<section title="Update to section 4">	<section numbered="true" toc="default">
	<t>The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer	<name>Update to RFC 7345</name>
	Procedures) are removed, and replaced with the new text below:</t>	<section numbered="true" toc="default">
	<figure>	<name>Update to Section 4</name>
	<artwork align="left" alt="" height="" name="" type="" width=""	<t>The subsections (4.1 - 4.5) in <xref target="RFC7345" section="4"
	xml:space="preserve"><![CDATA[	sectionFormat="comma"/> ("SDP Offerer/Answerer
		Procedures") are removed and replaced with the new text below:</t>


	NEW TEXT:	<t>NEW TEXT:</t>
		<blockquote>


	An endpoint (i.e., both the offerer and the answerer) MUST create an	<t>
		An endpoint (i.e., both the offerer and the answerer) <bcp14>MUST</bcp14> cre
		ate an
	SDP media description ("m=" line) for each UDPTL-over-DTLS media	SDP media description ("m=" line) for each UDPTL-over-DTLS media

	stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the	stream and <bcp14>MUST</bcp14> assign a UDP/TLS/UDPTL value (see Table 1) to the
	"proto" field of the "m=" line.	"proto" field of the "m=" line.

		</t>
	The offerer and answerer MUST follow the SDP offer/answer procedures	<t>
	defined in [RFCXXXX] in order to negotiate the DTLS association	The offerer and answerer <bcp14>MUST</bcp14> follow the SDP offer/answer proc
		edures
		defined in RFC 8842 in order to negotiate the DTLS association
	associated with the UDPTL-over-DTLS media stream. In addition,	associated with the UDPTL-over-DTLS media stream. In addition,

	the offerer and answerer MUST use the SDP attributes defined for	the offerer and answerer <bcp14>MUST</bcp14> use the SDP attributes defined f
	UDPTL over UDP, as defined in [ITU.T38.2010].	or
		UDPTL over UDP, as defined in <xref target="ITU.T38" />.
		</t>
		</blockquote>


	]]></artwork>	</section>
	</figure>	<section numbered="true" toc="default">
	</section>	<name>Update to Section 5.2.1</name>
	<section title="Update to section 5.2.1">	<t>The text in <xref target="RFC7345" section="5.2.1"
	<t>The text in section 5.2.1 (ICE Usage) is modified by replacing the ICE pr	sectionFormat="comma"/> ("ICE Usage") is modified by replacing the
	ocedures with	ICE procedures with a reference to this specification:
	a reference to this specification:	</t>
	</t>
	<figure>
	<artwork align="left" alt="" height="" name="" type="" width="" xml:space="p
	reserve"><![CDATA[


		<t>
	NEW TEXT:	NEW TEXT:

		</t>
		<blockquote>
	The Interactive Connectivity Establishment (ICE)	The Interactive Connectivity Establishment (ICE)

	[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media	<xref target="RFC8445" /> considerations for DTLS-protected media
	are described in [RFCXXXX].	are described in RFC 8842.
		</blockquote>
	[RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
	with the RFC number of this document.]


	]]></artwork>	</section>
	</figure>	<section numbered="true" toc="default">
	</section>	<name>Update to Section 9.1</name>
	<section title="Update to section 10.1">	<t>A reference to <xref format="default" target="RFC8122"/> is added
	<t>A reference to <xref format="default" pageno="false" target="RF	to <xref target="RFC7345" section="9.1"
	C8122"/> is added to section 10.1 (Normative References):</t>	sectionFormat="comma"/> ("Normative References"):</t>
	<figure>
	<artwork align="left" alt="" height="" name="" type="" width=""
	xml:space="preserve"><![CDATA[


		<t>
	NEW TEXT:	NEW TEXT:

		</t>
		<blockquote>
		<dl indent="12">
		<dt>[RFC8122]</dt>
		<dd>Lennox, J. and C. Holmberg, "Connection-Oriented Media
		Transport over the Transport Layer Security (TLS)
		Protocol in the Session Description Protocol (SDP)",
		RFC 8122, DOI 10.17487/RFC8122, March 2017,
		<eref brackets="angle" target="https://www.rfc-editor.org/info/rfc8122"/>.
		</dd>
		</dl>
		</blockquote>


	[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
	Transport over the Transport Layer Security (TLS) Protocol
	in the Session Description Protocol (SDP)", RFC 8122,
	DOI 10.17487/RFC8122, March 2017,
	<http://www.rfc-editor.org/info/rfc8122>.

	]]></artwork>
	</figure>
	</section>
	</section>	</section>

		</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Security Considerations">	<name>Security Considerations</name>
	<t>	<t>
	This specification does not modify the security considerations assoc	This specification does not modify the security considerations
	iated with DTLS, or	associated with DTLS or
	the SDP offer/answer mechanism. In addition to the introduction of t he SDP	the SDP offer/answer mechanism. In addition to the introduction of t he SDP

	'tls-id' attribute, the specification simply clarifies the procedure s for	"tls-id" attribute, this document simply clarifies the procedures fo r
	negotiating and establishing a DTLS association.	negotiating and establishing a DTLS association.

	</t>	</t>
	<t>	<t>
	This specification does not modify the actual TLS connection setup p rocedures. The	This specification does not modify the actual TLS connection setup p rocedures. The

	SDP 'tls-is' attribute as such cannot be used to correlate an SDP Of	SDP "tls-is" attribute as such cannot be used to correlate an SDP
	fer/Answer exchange with a	offer/answer exchange with a
	TLS connection setup. Thus, this draft does not introduce new securi	TLS connection setup. Thus, this document does not introduce new
	ty considerations	security considerations
	related to correlating an SDP Offer/Answer exchange with a TLS conne	related to correlating an SDP offer/answer exchange with a TLS conne
	ction setup.	ction setup.
	</t>	</t>
	</section>	</section>

		<section anchor="section.iana" numbered="true" toc="default">
	<section anchor="section.iana" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>	<t>
	This document updates the "Session Description Protocol Parameters" registry	This document updates the "Session Description Protocol Parameters" registry

	as specified in Section 8.2.2 of <xref target="RFC4566" pageno="fals	as specified in <xref target="RFC4566"
	e" format="default"/>.	format="default" sectionFormat="of" section="8.2.2" />.
	Specifically, it adds the SDP 'tls-id' attribute to the table for SD	Specifically, it adds the SDP "tls-id" attribute to the table for SD
	P	P
	media level attributes.	media-level attributes as follows.
	</t>	</t>
	<figure>
	<artwork align="left"><![CDATA[


	Attribute name: tls-id	<dl>
	Type of attribute: media-level
	Subject to charset: no
	Purpose: Indicates whether a new DTLS association or TLS connection
	is to be established/re-established.
	Appropriate Values: see Section 4
	Contact name: Christer Holmberg
	Mux Category: IDENTICAL


	]]></artwork>	<dt>Attribute name:</dt>
	</figure>	<dd>tls-id</dd>
	</section>


	<section title="Acknowledgements">	<dt>Type of attribute:</dt>
	<t>	<dd>Media-level</dd>
	Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
	Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing commen	<dt>Subject to charset:</dt>
	ts and	<dd>No</dd>
	suggestions on the document. Ben Campbell performed an AD review. Pa
	ul	<dt>Purpose:</dt>
	Kyzivat performed a gen-art review.	<dd>Indicates whether a new DTLS association or TLS connection is to be
	</t>	established/re-established.</dd>
	</section>
	<section title="Change Log">	<dt>Appropriate Values:</dt>
	<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>	<dd>See <xref target="sec-dcon-attr" /></dd>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-31
	<list style="symbols">	<dt>Contact name:</dt>
	<t>Changes based on IESG comments from Eric R</t>	<dd>Christer Holmberg</dd>
	</list>
	</t>	<dt>Mux Category:</dt>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-30	<dd>IDENTICAL</dd>
	<list style="symbols">
	<t>Changes based on IESG comments from Mirja K</t>	</dl>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-29
	<list style="symbols">
	<t>Removal of ufrag value change as a trigger for a new DTLS ass
	ociation</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-28
	<list style="symbols">
	<t>Changes based on IESG review by Adam Roach, Eric Rescorla, Al
	exey Melnikov and Mirja Kuhlewind:</t>
	<t>- Document title changed</t>
	<t>- Transport Protocol Considerations section removed</t>
	<t>- Additional text to Security Considerations section</t>
	<t>- Editorial changes</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-27
	<list style="symbols">
	<t>Reference fixes based on Gen-ART review by Paul Kyzivat.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-26
	<list style="symbols">
	<t>Editorial fixes based on Gen-ART review by Paul Kyzivat.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-25
	<list style="symbols">
	<t>Minor editorial nits.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-24
	<list style="symbols">
	<t>Changes based on 2nd WGLC comments from Roman S and Martin T:
	</t>
	<t>- RFC update structure shortened (old text removed).</t>
	<t>- Guidance regarding receiving ClientHello before SDP answer
	added.</t>
	<t>- Additional SIP considerations regarding forking.</t>
	<t>- SDP setup attribute value restriction in initial and subseq
	uent offers based on comment from Ekr.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-23
	<list style="symbols">
	<t>Editorial change to make it clear that the document does not
	modify the procedures in RFC 8122.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-22
	<list style="symbols">
	<t>Support for TLS added.</t>
	<t>Editorial changes based on sec-dir review by Rich Salz.</t>
	<t>Editorial changes based on gen-art review by Paul Kyzivat.</t
	>
	<t>Editorial changes based on ops-dir review by Carlos Pignataro
	.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-21
	<list style="symbols">
	<t>Changes based on AD review by Ben Campbell.</t>
	<t>(https://www.ietf.org/mail-archive/web/mmusic/current/msg1770
	7.html)</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-20
	<list style="symbols">
	<t>Change to length and randomness of tls-id attribute value.</t
	>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-19
	<list style="symbols">
	<t>Change based on comment from Roman.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-18
	<list style="symbols">
	<t>Changes based on comments from Flemming.</t>
	<t>- Change in tls-id value definition.</t>
	<t>- Editorial fixes.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-17
	<list style="symbols">
	<t>Reference fix.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-16
	<list style="symbols">
	<t>Editorial changes based on 2nd WGLC comments
	from Christian Groves and Nevenka Biondic.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-15
	<list style="symbols">
	<t>tls-id attribute value made globally unique</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-14
	<list style="symbols">
	<t>Changes based on comments from Flemming:</t>
	<t>- Additional dtls-is clarifications</t>
	<t>- Editorial fixes</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-13
	<list style="symbols">
	<t>Text about the updated RFCs added to Abstract and Introductio
	n</t>
	<t>Reference to RFC 5763 removed from section 6 (ICE Considerati
	ons)</t>
	<t>Reference to RFC 5763 removed from section 8 (SIP Considerati
	ons)</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-12
	<list style="symbols">
	<t>"unreliable" changed to "unordered"</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-11
	<list style="symbols">
	<t>Attribute name changed to tls-id</t>
	<t>Additional text based on comments from Roman Shpount.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-10
	<list style="symbols">
	<t>Modified document to use tls-id instead of dtls-connection</t
	>
	<t>Changes are based on comments from Eric Rescorla, Justin Uber
	ti, and Paul Kyzivat.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-08
	<list style="symbols">
	<t>Offer/Answer section modified in order to allow sending of mu
	ltiple SDP 'fingerprint' attributes.</t>
	<t>Terminology made consistent: 'DTLS connection' replaced with
	'DTLS association'.</t>
	<t>Editorial changes based on comments from Paul Kyzivat.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-07
	<list style="symbols">
	<t>Reference to RFC 7315 replaced with reference to RFC 7345.</t
	>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-06
	<list style="symbols">
	<t>Text on restrictions regarding spanning a DTLS association ov
	er multiple transports added.</t>
	<t>Mux category added to IANA Considerations.</t>
	<t>Normative text regarding mux category and source-specific app
	licability added.</t>
	<t>Reference to RFC 7315 added.</t>
	<t>Clarified that offerer/answerer that has not been updated to
	support this specification will
	not include the tls-id attribute in offers and answers.</t>
	<t>Editorial corrections based on WGLC comments from Charles Eck
	el.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-05
	<list style="symbols">
	<t>Text on handling offer/answer error conditions added.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-04
	<list style="symbols">
	<t>Editorial nits fixed based on comments from Paul Kyzivat:</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-03
	<list style="symbols">
	<t>Changes based on comments from Paul Kyzivat:</t>
	<t>- Modification of tls-id attribute section.</t>
	<t>- Removal of IANA considerations subsection.</t>
	<t>- Making note into normative text in o/a section.</t>
	<t>Changes based on comments from Martin Thompson:</t>
	<t>- Abbreviations section removed.</t>
	<t>- Clarify that a new DTLS association requires a new o/a tran
	saction.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-02
	<list style="symbols">
	<t>- Updated RFCs added to boilerplate.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-01
	<list style="symbols">
	<t>- Annex regarding 'tls-id-id' attribute removed.</t>
	<t>- Additional SDP offer/answer procedures, related to certific
	ates, added.</t>
	<t>- Updates to RFC 5763 and RFC 7345 added.</t>
	<t>- Transport protocol considerations added.</t>
	</list>
	</t>
	<t>Changes from draft-ietf-mmusic-sdp-dtls-00
	<list style="symbols">
	<t>- SDP 'connection' attribute replaced with new 'tls-id' attri
	bute.</t>
	<t>- IANA Considerations added.</t>
	<t>- E-mail regarding 'tls-id-id' attribute added as Annex.</t>
	</list>
	</t>
	<t>Changes from draft-holmberg-mmusic-sdp-dtls-01
	<list style="symbols">
	<t>- draft-ietf-mmusic version of draft submitted.</t>
	<t>- Draft file name change (sdp-dtls -> dtls-sdp) due to collis
	ion with another expired draft.</t>
	<t>- Clarify that if ufrag in offer is unchanged, it must be unc
	hanged in associated answer.</t>
	<t>- SIP Considerations section added.</t>
	<t>- Section about multiple SDP fingerprint attributes added.</t
	>
	</list>
	</t>
	<t>Changes from draft-holmberg-mmusic-sdp-dtls-00
	<list style="symbols">
	<t>- Editorial changes and clarifications.</t>
	</list>
	</t>

	</section>	</section>

	</middle>	</middle>
		<back>


	<back>	<references>
	<references title="Normative References">	<name>References</name>
	<?rfc include="reference.RFC.2119"?>	<references>
	<?rfc include="reference.RFC.3261"?>	<name>Normative References</name>
	<?rfc include="reference.RFC.3264"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.4145"?>	ence.RFC.2119.xml"/>
	<?rfc include="reference.RFC.4566"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.5763"?>	ence.RFC.3261.xml"/>
	<?rfc include="reference.RFC.6347"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.7345"?>	ence.RFC.3264.xml"/>
	<?rfc include="reference.RFC.8122"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.8174"?>	ence.RFC.4145.xml"/>
	<?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-13"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?>	ence.RFC.4566.xml"/>
	<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-39	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	"?>	ence.RFC.5763.xml"/>
	</references>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<references title="Informative References">	ence.RFC.6347.xml"/>
	<?rfc include="reference.RFC.4474"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.4572"?>	ence.RFC.7345.xml"/>
	<?rfc include="reference.RFC.5576"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<?rfc include="reference.RFC.6083"?>	ence.RFC.8122.xml"/>
	<?rfc include="reference.RFC.7983"?>	<xi:include
	<?rfc include="reference.I-D.draft-ietf-stir-rfc4474bis-16"?>	href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
	<?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-14"?>	8174.xml"/>
	<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-uks-00"?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
	<reference anchor="ITU.T38.2010">	ence.RFC.8445.xml"/>

		<!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
		<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
		859">
	<front>	<front>

	<title>Procedures for real-time Group 3 facsimile communication over I	<title>A Framework for Session Description Protocol (SDP)
	P networks</title>	Attributes When Multiplexing</title>
	<author>	<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
	<organization>International Telecommunications Union</organization>	">
	</author>	<organization/>
	<date year="2010" month="September"/>	</author>
		<date month="January" year="2021"/>
	</front>	</front>

	<seriesInfo value="Recommendation T.38" name="ITU-T"/>	<seriesInfo name="RFC" value="8859"/>
		<seriesInfo name="DOI" value="10.17487/RFC8859"/>

	</reference>	</reference>

	</references>


	</back>	<!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) C238 -->
		<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
		>
		<front>
		<title>Negotiating Media Multiplexing Using the Session Description Prot
		ocol (SDP)</title>
		<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
		<organization/>
		</author>
		<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
		<organization/>
		</author>
		<author initials="C" surname="Jennings" fullname="Cullen Jennings">
		<organization/>
		</author>
		<date month="January" year="2021"/>
		</front>
		<seriesInfo name="RFC" value="8843"/>
		<seriesInfo name="DOI" value="10.17487/RFC8843"/>
		</reference>

		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4474.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4572.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5576.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.6083.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		7983.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		8224.xml"/>

		<!-- draft-ietf-mmusic-ice-sip-sdp-39 RFC-to-be 8839 C238 -->

		<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
		<front>
		<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactiv
		e Connectivity Establishment (ICE)</title>

		<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
		<organization />
		</author>

		<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
		<organization />
		</author>

		<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
		<organization />
		</author>

		<author initials='A' surname='Keränen' fullname='Ari Keränen'>
		<organization />
		</author>

		<author initials='R' surname='Shpount' fullname='Roman Shpount'>
		<organization />
		</author>

		<date month="January" year="2021"/>

		</front>
		<seriesInfo name="RFC" value="8839"/>
		<seriesInfo name="DOI" value="10.17487/RFC8839"/>

		</reference>

		<!-- draft-ietf-mmusic-sdp-uks in C238 -->
		<reference anchor='RFC8844' target="https://www.rfc-editor.org/info/rfc8844">
		<front>
		<title>Unknown Key-Share Attacks on Uses of TLS with the Session Description Pro
		tocol (SDP)</title>
		<author initials='M' surname='Thomson' fullname='Martin Thomson'>
		<organization />
		</author>
		<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
		<organization />
		</author>
		<date month="January" year="2021"/>
		</front>
		<seriesInfo name="RFC" value="8844"/>
		<seriesInfo name="DOI" value="10.17487/RFC8844"/>
		</reference>

		<reference anchor="ITU.T38" target="https://www.itu.int/rec/T-REC-T.38/e
		n">
		<front>
		<title>Procedures for real-time Group 3 facsimile communication over
		IP networks</title>
		<seriesInfo name="Recommendation" value="T.38"/>
		<author>
		<organization>ITU-T</organization>
		</author>
		<date year="2010" month="September"/>
		</front>
		</reference>
		</references>
		</references>
		<section numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>
		Thanks to <contact fullname="Justin Uberti"/>, <contact
		fullname="Martin Thomson"/>, <contact fullname="Paul Kyzivat"/>,
		<contact fullname="Jens Guballa"/>, <contact fullname="Charles
		Eckel"/>, <contact fullname="Gonzalo Salgueiro"/>, and <contact
		fullname="Paul Jones"/> for providing comments and suggestions on
		the document. <contact fullname="Ben Campbell"/> performed an Area
		Director review. <contact fullname="Paul Kyzivat"/> performed a
		Gen-ART review.
		</t>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 128 change blocks.
	1225 lines changed or deleted	1151 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/