One document matched: draft-holmberg-mmusic-sdp-dtls-00.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-holmberg-mmusic-sdp-dtls-00.txt" submissionType="IETF" xml:lang="en">
<front>
<title>
DTLS Association Establishment Using the SDP Offer/Answer Mechanism
</title>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<region></region>
<code>02420</code>
<country>Finland</country>
</postal>
<phone></phone>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<author fullname="Roman Shpount" initials="R.S." surname="Shpount">
<organization abbrev="TurboBridge">TurboBridge</organization>
<address>
<postal>
<street>4905 Del Ray Avenue, Suite 300</street>
<city>Bethesda</city>
<region>MD</region>
<code>20814</code>
<country>USA</country>
</postal>
<phone>+1 (240) 292-6632</phone>
<email>rshpount@turbobridge.com</email>
</address>
</author>
<date year="2015" />
<area>RAI</area>
<abstract>
<t>
This draft defines the criteria for when a DTLS association needs to be established/re-established,
based on an SDP offer/answer transaction. The draft also defines how the SDP 'connection'
attribute is used with DTLS to signal to the remote peer whether a new DTLS association needs to
established/re-established.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This draft defines the criteria for when a DTLS association needs to be established/re-established,
based on an SDP offer/answer transaction. The draft also defines how the SDP 'connection'
attribute is used with DTLS to signal to the remote peer whether a new DTLS association needs to
established/re-established.
</t>
</section>
<section title="Abbreviations" toc="default">
<t>
TBD
</t>
</section>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"></xref>.
</t>
</section>
<section title="DTLS Association Re-Establishment Criteria" anchor="sec-dtls-reest">
<section title="General">
<t>
If an endpoint changes the local transport parameters associated with a DTLS association,
the endpoint MUST create a new DTLS association. <xref target="sec-oa"/> defines
the SDP Offer/Answer procedures <xref format="default" pageno="false" target="RFC3264"/>
associated with that.
</t>
<t>
NOTE: As described in <xref target="sec-dtls-reest-ice"/>, when Interactive Connectivity
Establishment (ICE) <xref format="default" pageno="false" target="RFC5245"/> is used
there are specific scenarios where the change of transport parameters do not trigger
a re-establishment of the DTLS association.
</t>
<t>
This section describes other events that require re-establishment of a DTLS association. If
such event occur, the endpoint MUST also change the local transport parameters. An endpoint
MUST NOT re-establish a DTLS association without also changing the local transport parameters,
event if the trigger as such for the re-establishment is not a change of the local transport
parameters.
</t>
<t>
NOTE: In future, if new events that require re-establishment of a DTLS association are found,
this section should be updated to cover those events.
</t>
</section>
<section title="Change of DTLS Role">
<t>
<xref format="default" pageno="false" target="RFC5763"/> defines how the DTLS roles are negotiated
using an offer/answer transaction. If DTLS roles associated with the DTLS association have
previously been negotiated, and a subsequent offer/answer transaction changes the roles, the
DTLS association MUST be re-established.
</t>
</section>
<section title="Change of Fingerprint">
<t>
If the certificate fingerprint [REF-TO-BE-ADDED] associated with the
DTLS association changes, the DTLS association MUST be re-established.
</t>
</section>
<section title="ICE Considerations" anchor="sec-dtls-reest-ice">
<t>
If Interactive Connectivity Establishment (ICE) <xref format="default"
pageno="false" target="RFC5245"/> is used, the re-establishment of a DTLS
association requires the ICE session to be re-established. Similarly,
the re-establishment of an ICE session requires re-establishment of the
DTLS association.
</t>
<t>
When an endpoint wants to re-establish the ICE session, if follows the
procedures in <xref format="default" pageno="false" target="RFC5245"/>.
When the endpoint collects the new set of ICE candidates, the host
candidate(s) MUST be different from the previously used host candidates.
</t>
<t>
An ICE restart <xref format="default" pageno="false" target="RFC5245"/>
does not require re-establishment of the DTLS association and the ICE
session, even if new host candidates might be taken into use due to the
restart.
</t>
<t>
Note that, as defined in <xref format="default" pageno="false" target="RFC5763"/>,
each ICE candidate associated with a component is treated as being part of the
same DTLS association. Therefore, from a DTLS perspective it is not considered
a change of local transport parameters when endpoints switch between those ICE
candidates, and hence such switch will not trigger re-establishment of the DTLS
association.
</t>
<t>
NOTE: The procedures defined in <xref format="default" pageno="false" target="RFC5763"/>
are defined for SRTP-DTLS <xref format="default" pageno="false" target="RFC5763"/>.
However, this document refer the the procedures for general usage with DTLS.
</t>
</section>
<section title="SIP Considerations">
<t>
When the Session Initiation Protocol (SIP) <xref format="default" pageno="false"
target="RFC3261"/> is used as the signal protocol for establishing a multimedia
session, dialogs <xref format="default" pageno="false" target="RFC3261"/> might be
established between the caller and multiple callees. This is referred to as forking.
If forking occurs, separate DTLS associations MUST be established between the caller
and each callee.
</t>
</section>
</section>
<section title="SDP Connection Attribute for DTLS">
<section title="General">
<t>
The SDP 'connection' attribute was originally defined for connection-oriented
protocols, e.g. TCP and TLS. This section defines how the attribute is used with DTLS.
</t>
<t>
A 'connection' attribute value of 'new' indicates that a new DTLS association MUST be
established. A 'connection' attribute value of 'existing' indicates that the existing
DTLS association MUST be used.
</t>
<t>
When used with DTLS, there is no default value defined for the attribute.
Implementations that wish to use the attribute MUST explicitly include it in
SDP offers and answers. If an offer or answer does not contain an attribute,
other means needs to be used in order for endpoints to determine whether an
offer or answer is associated with an event that requires the DTLS association
to be re-established.
</t>
</section>
</section>
<section title="SDP Offer/Answer Procedures" anchor="sec-oa">
<section title="General">
<t>
This section defines the SDP offer/answer procedures for using the SDP 'connection'
attribute for DTLS. The section also describes how the usage of the SDP 'setup'
attribute and the SDP 'fingerprint' attribute <xref format="default" pageno="false"
target="RFC4572"/> is affected.
</t>
</section>
<section title="Generating the Initial SDP Offer">
<t>
When the offerer sends the initial offer, and the offerer wants to establish a
DTLS association, it MUST insert an SDP 'connection' attribute with a 'new' value
to the offer. In addition, the offerer MUST insert an SDP 'setup' attribute according
to the procedures in <xref format="default" pageno="false" target="RFC4572"/>, and
an SDP 'fingerprint' attribute according to the procedures in <xref format="default"
pageno="false" target="RFC4572"/>, in the offer.
</t>
</section>
<section title="Generating the Answer">
<t>
If an answerer receives an offer that contains an SDP 'connection' attribute with a 'new'
value, the answerer MUST insert a 'new' value in the associated answer. The same applies
if the answerer receives an offer that contains an SDP 'connection' attribute with a 'new'
value, but the answerer determines (based on local events) that the DTLS association is to be
re-established. In addition, the answerer MUSTbinsert an SDP 'setup' attribute according
to the procedures in <xref format="default" pageno="false" target="RFC4572"/>, and an
SDP 'fingerprint' attribute according to the procedures in <xref format="default"
pageno="false" target="RFC4572"/>, in the answer.
</t>
<t>
If the answerer does not accept the establishment (or re-establishment)
of the DTLS association, it MUST reject the offer <xref format="default"
pageno="false" target="RFC3264"/>.
</t>
<t>
If an answerer receives an offer that contains a 'connection' attribute with an 'existing' value,
and if the answerer determines that the DTLS association does not need to be re-established,
it MUST insert an 'existing' value in the associated answer. In addition, the answerer
MUST insert an SDP 'setup' attribute with a value that does not change the previously negotiated
DTLS roles, and an SDP 'fingerprint' attribute with a value that does not change the fingerprint,
in the answer.
</t>
<t>
If the answerer receives an offer that does not contain an SDP 'connection' attribute,
the answerer MUST NOT insert a 'connection' attribute in the answer.
</t>
<t>
If the DTLS association is to be established (or re-established), and if the answerer
becomes DTLS client, the answerer MUST initiate the procedures for establishing/re-establishing
the DTLS association. If the answerer becomes DTLS server, it waits for the offerer to
establish (or re-establish) the DTLS association.
</t>
</section>
<section title="Offerer Processing of the SDP Answer">
<t>
When an offerer receives an answer that contains an SDP 'connection' attribute with
a 'new' value, and if the offerer becomes DTLS client, the offerer MUST establish/re-establish
the DTLS association. If the offerer becomes DTLS server, it waits for the answerer to
establish/re-establish the DTLS association.
</t>
<t>
If the answer contains an SDP 'connection' attribute with an 'existing' value, the offerer
will continue using the previously established DTLS association. It is considered an error
case if the answer contains a 'connection' attribute with an 'existing' value, and a DTLS
association does not exist.
</t>
</section>
<section title="Modifying the Session">
<t>
When the offerer sends a subsequent offer, and a previously established DTLS association
is to be established (or re-established), the offerer MUST insert an SDP 'connection'
attribute with a 'new' value in the offer. In addition, the offerer MUST
insert an SDP 'setup' attribute according to the procedures in <xref format="default"
pageno="false" target="RFC4572"/>, and an SDP 'fingerprint' attribute according to the
procedures in <xref format="default" pageno="false" target="RFC4572"/>, in the offer.
</t>
<t>
When the offerer sends a subsequent offer, and the DTLS association is not to
be established (or re-established), the offerer MUST insert an SDP 'connection'
attribute with an 'existing' value in the offer. In addition, the offerer MUST
insert an SDP 'setup' attribute with a value that does not change the previously
negotiated DTLS roles, and an SDP 'fingerprint' attribute with a value that does
not change the fingerprint, in the offer.
</t>
</section>
</section>
<section title="RFC Updates">
<t>
Here we will add the RFC updates that are needed.
</t>
</section>
<section title="Security Considerations">
<t>
TBD
</t>
</section>
<section title="IANA Considerations">
<t>
TBD
</t>
</section>
<section title="Acknowledgements">
<t>
TBD
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3261"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4572"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.5763"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:17 |