draft-ietf-mmusic-dtls-sdp-15.txt   draft-ietf-mmusic-dtls-sdp-16.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5763,7345 (if approved) R. Shpount Updates: 5763,7345 (if approved) R. Shpount
Intended status: Standards Track TurboBridge Intended status: Standards Track TurboBridge
Expires: May 4, 2017 October 31, 2016 Expires: July 14, 2017 January 10, 2017
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-15.txt draft-ietf-mmusic-dtls-sdp-16.txt
Abstract Abstract
This document defines the SDP offer/answer procedures for negotiating This document defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The document also defines the and establishing a DTLS association. The document also defines the
criteria for when a new DTLS association must be established. The criteria for when a new DTLS association must be established. The
document updates RFC 5763 and RFC 7345, by replacing common SDP document updates RFC 5763 and RFC 7345, by replacing common SDP
offer/answer procedures with a reference to this specification. offer/answer procedures with a reference to this specification.
This document defines a new SDP media-level attribute, 'dtls-id'. This document defines a new SDP media-level attribute, 'dtls-id'.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on July 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Establishing a new DTLS Association . . . . . . . . . . . . . 3 3. Establishing a new DTLS Association . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Change of Local Transport Parameters . . . . . . . . . . 4 3.2. Change of Local Transport Parameters . . . . . . . . . . 4
3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4
4. SDP dtls-id Attribute . . . . . . . . . . . . . . . . . . . . 4 4. SDP dtls-id Attribute . . . . . . . . . . . . . . . . . . . . 4
5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 8 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 7
5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 8
5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 9 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 8
5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 9
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 7. Transport Protocol Considerations . . . . . . . . . . . . . . 10
7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 10
8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 12 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.
[RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This [RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This
specification defines general offer/answer procedures for DTLS, based specification defines general offer/answer procedures for DTLS, based
on the procedures in [RFC5763]. Other specifications, defining on the procedures in [RFC5763]. Other specifications, defining
specific DTLS usages, can then reference this specification, in order specific DTLS usages, can then reference this specification, in order
to ensure that the DTLS aspects are common among all usages. Having to ensure that the DTLS aspects are common among all usages. Having
common procedures is essential when multiple usages share the same common procedures is essential when multiple usages share the same
skipping to change at page 4, line 12 skipping to change at page 4, line 12
initiate an SDP offer/answer transaction, following the procedures in initiate an SDP offer/answer transaction, following the procedures in
Section 5. Section 5.
The sections below describe typical cases where a new DTLS The sections below describe typical cases where a new DTLS
association needs to be established. association needs to be established.
3.2. Change of Local Transport Parameters 3.2. Change of Local Transport Parameters
If an endpoint modifies its local transport parameters (address and/ If an endpoint modifies its local transport parameters (address and/
or port), and if the modification requires a new DTLS association, or port), and if the modification requires a new DTLS association,
the endpoint MUST change its set of fingerprints and SDP 'dtls-id' the endpoint MUST change its local SDP 'dtls-id' attribute value
attribute so that together they represent a new unique set of values
Section 4. Section 4.
If the underlying transport explicitly prohibits a DTLS association If the underlying transport explicitly prohibits a DTLS association
to span multiple transports, and if the transport is changed, the to span multiple transports, and if the transport is changed, the
endpoint MUST change its set of fingerprints and SDP 'dtls-id' endpoint MUST change its local SDP 'dtls-id' attribute value
attribute so that together they represent a new unique set of values
Section 4. An example of such case is when DTLS is carried over Section 4. An example of such case is when DTLS is carried over
SCTP, as described in [RFC6083]. SCTP, as described in [RFC6083].
3.3. Change of ICE ufrag value 3.3. Change of ICE ufrag value
If an endpoint uses ICE, and modifies a local ufrag value, and if the If an endpoint uses ICE, and modifies a local ufrag value, and if the
modification requires a new DTLS association, the endpoint MUST modification requires a new DTLS association, the endpoint MUST
change its set of fingerprints and SDP 'dtls-id' attribute so that change its local SDP 'dtls-id' attribute value Section 4.
together they represent a new unique set of values Section 4.
4. SDP dtls-id Attribute 4. SDP dtls-id Attribute
The 'dtls-id' attribute pair in combination with 'fingerprint' The pair of SDP 'dtls-id' attribute values (the attribute values of
attribute values from offer and answer SDP uniquely identifies the the offerer and the answerer) uniquely identifies the DTLS
DTLS association. association.
Name: dtls-id Name: dtls-id
Value: dtls-id-value Value: dtls-id-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Default Value: empty value Default Value: empty value
Syntax: Syntax:
dtls-id-value = 0*256 <alpha-numeric defined in [RFC4566]> dtls-id-value = 0*256 <alpha-numeric defined in [RFC4566]>
Example: Example:
a=dtls-id:abc3dl a=dtls-id:abc3dl
Every time end point requests to establish a new DTLS association Every time an endpoint requests to establish a new DTLS association,
using the same set of fingerprints, a new unique value of 'dtls-id' the endpoint MUST generate a new unique local 'dtls-id' attribute
attribute is allocated. A combination of the previously used 'dtls- value. A non-changed local 'dtls-id' attribute value, in combination
id' attribute in combination with the same fingerprint set indicates with non-changed fingerprints, indicates that the endpoint intends to
an intention to reuse the existing association. reuse the existing DTLS association.
The default value for the SDP 'dtls-id' attribute is an empty value. The mechanism to generate the unique local 'dtls-id' attribute value
MUST guarantee global uniqueness of the value for the lifetime of the
DTLS association associated with the attribute value.
No default value is defined for the SDP 'dtls-id' attribute.
Implementations that wish to use the attribute MUST explicitly Implementations that wish to use the attribute MUST explicitly
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 an attribute (this could happen if the offerer or answerer contain an attribute (this could happen if the offerer or answerer
represents an existing implementation that has not been updated to represents an existing implementation that has not been updated to
support the attribute defined in this specification or an support the 'dtls-id' attribute), the offer or answer MUST be treated
implementation which allocates a new temporary certificate for each as if no 'dtls-id' attribute is included. Unless there is another
association and uses change in fingerprint to indicate new mechanism to explicitly indiciate that a new DTLS association is to
association), it should be treated as if 'dtls-id' attribute with an be established, a modification of one or more of the following
empty value value were included in SDP and procedures defined in this characteristics MUST be treated as an indication that an endpoint
specification should be used to determine if new DTLS association wants to establish a new DTLS association:
should be established.
o DTLS setup role; or
o fingerprint set; or
o local transport parameters; or
o ICE ufrag value
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'dtls- The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'dtls-
id' attribute is 'IDENTICAL', which means that the attribute value id' attribute is 'IDENTICAL', which means that the attribute value
must be identical across all media descriptions being multiplexed must be identical across all media descriptions being multiplexed
[I-D.ietf-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation].
For RTP-based media, the 'dtls-id' attribute apply to whole For RTP-based media, the 'dtls-id' attribute apply to whole
associated media description. The attribute MUST NOT be defined per associated media description. The attribute MUST NOT be defined per
source (using the SDP 'ssrc' attribute [RFC5576]). source (using the SDP 'ssrc' attribute [RFC5576]).
skipping to change at page 6, line 38 skipping to change at page 6, line 32
existing DTLS association and new DTLS association can be de- existing DTLS association and new DTLS association can be de-
multiplexed. In case of ordered transport (e.g., SCTP) this can be multiplexed. In case of ordered transport (e.g., SCTP) this can be
done simply by sending packets for new DTLS association after all done simply by sending packets for new DTLS association after all
packets for existing DTLS association have been sent. In case of packets for existing DTLS association have been sent. In case of
unordered transport, such as UDP, packets for the old DTLS unordered transport, such as UDP, packets for the old DTLS
association can arrive after the answer SDP was received and after association can arrive after the answer SDP was received and after
first packets for the new DTLS association were received. The only first packets for the new DTLS association were received. The only
way to de-multiplex packets belonging to old and new DTLS association way to de-multiplex packets belonging to old and new DTLS association
is on the basis of transport 5-tuple. Because of this, if unordered is on the basis of transport 5-tuple. Because of this, if unordered
transport is used for DTLS association, new transport (3-tuple) MUST transport is used for DTLS association, new transport (3-tuple) MUST
be allocated by at least on the end points so that DTLS packets can be allocated by at least one of the end points so that DTLS packets
be de-multiplexed. can be de-multiplexed.
When an offerer needs to establish a new DTLS association, and if an When an offerer needs to establish a new DTLS association, and if an
unordered transport (e.g., UDP) is used, the offerer MUST allocate a unordered transport (e.g., UDP) is used, the offerer MUST allocate a
new transport (3-tuple) for the offer in such a way that the offerer new transport (3-tuple) for the offer in such a way that the offerer
can disambiguate any packets associated with the new DTLS association can disambiguate any packets associated with the new DTLS association
from any packets associated with any other DTLS association. This from any packets associated with any other DTLS association. This
typically means using a local address and/or port, or a set of ICE typically means using a local address and/or port, or a set of ICE
candidates (see Section 6), which were not recently used for any candidates (see Section 6), which were not recently used for any
other DTLS association. other DTLS association.
skipping to change at page 7, line 16 skipping to change at page 7, line 11
DTLS association. This typically means using a local address and/or DTLS association. This typically means using a local address and/or
port, or a set of ICE candidates (see Section 6), which were not port, or a set of ICE candidates (see Section 6), which were not
recently used for any other DTLS association. recently used for any other DTLS association.
In order to negotiate a DTLS association, the following SDP In order to negotiate a DTLS association, the following SDP
attributes are used: attributes are used:
o The SDP 'setup' attribute, defined in [RFC4145], is used to o The SDP 'setup' attribute, defined in [RFC4145], is used to
negotiate the DTLS roles; negotiate the DTLS roles;
o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to o The SDP 'fingerprint' attribute, defined in
provide a fingerprint values; and [I-D.ietf-mmusic-4572-update], is used to provide one or more
fingerprint values; and
o The SDP 'dtls-id' attribute, defined in this specification, which, o The SDP 'dtls-id' attribute, defined in this specification.
if fingerprints are reused, can be assigned a new value to
explicitly indicate the intention to establishing a new DTLS
association.
This specification does not define the usage of the SDP 'connection' This specification does not define the usage of the SDP 'connection'
attribute [RFC4145] for negotiating a DTLS connection. However, the attribute [RFC4145] for negotiating a DTLS connection. However, the
attribute MAY be used if the DTLS association is used together with attribute MAY be used if the DTLS association is used together with
another protocol (e.g., SCTP or TCP) for which the usage of the another protocol (e.g., SCTP or TCP) for which the usage of the
attribute has been defined. attribute has been defined.
Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP
'setup' attribute 'holdconn' value when negotiating a DTLS 'setup' attribute 'holdconn' value when negotiating a DTLS
association. association.
Endpoints MUST support SHA-256 for generating and verifying any Endpoints MUST support the cipher suites as defined in
fingerprint value associated with the DTLS association. The use of [I-D.ietf-mmusic-4572-update].,
SHA-256 is preferred.
Endpoints MUST, at a minimum, support
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward
Secrecy (PFS) cipher suites over non-PFS cipher suites.
Implementations SHOULD disable TLS-level compression.
The certificate received during the DTLS handshake MUST match the The certificate received during the DTLS handshake MUST match the
certificate fingerprints received in SDP 'fingerprint' attributes certificate fingerprints received in SDP 'fingerprint' attributes
according to procedures defined in [I-D.ietf-mmusic-4572-update]. If according to procedures defined in [I-D.ietf-mmusic-4572-update]. If
fingerprints do not match the hashed certificate, then an endpoint fingerprints do not match the hashed certificate, then an endpoint
MUST tear down the media session immediately. Note that it is MUST tear down the media session immediately. Note that it is
permissible to wait until the other side's fingerprint has been permissible to wait until the other side's fingerprint has been
received before establishing the connection; however, this may have received before establishing the connection; however, this may have
undesirable latency effects. undesirable latency effects.
SDP offerers and answerers might reuse certificates across multiple SDP offerers and answerers might reuse certificates across multiple
DTLS associations, and provide identical fingerprint values for each DTLS associations, and provide identical fingerprint values for each
DTLS association. It MUST be ensured that the combination of the DTLS association. It MUST be ensured that the combination of SDP the
fingerprint values and the SDP 'dtls-id' attribute value is unique 'dtls-id' attribute values of the SDP offerer and answerer is unique
across all DTLS associations. across all DTLS associations that might be handled by the SDP offerer
and answerer.
If an SDP offerer or answerer generates a new temporary self-signed
certificate for each new DTLS association, they can omit the SDP
'dtls-id' attribute.
5.2. Generating the Initial SDP Offer 5.2. Generating the Initial SDP Offer
When an offerer sends the initial offer, the offerer MUST insert an When an offerer sends the initial offer, the offerer MUST insert an
SDP 'setup' attribute according to the procedures in [RFC4145], and SDP 'setup' attribute according to the procedures in [RFC4145], and
one or more SDP 'fingerprint' attributes according to the procedures one or more SDP 'fingerprint' attributes according to the procedures
in [RFC4572] and [I-D.ietf-mmusic-4572-update]. In addition, the in [I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST
offerer MUST insert in the offer an SDP 'dtls-id' attribute with a insert in the offer an SDP 'dtls-id' attribute with a unique value.
unique value for the offer fingerprint set. If the fingerprint set
is not unique due the certificate reuse across multiple SDP sessions
or endpoints, the 'dtls-id' attribute value MUST be generated in a
way that guarantees uniqueness across all current DTLS association
established using this fingerprint set, including DTLS association
established by other SDP sessions or other endpoints.
If the offerer inserts the SDP 'setup' attribute with an 'actpass' or If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
'passive' attribute value, the offerer MUST be prepared to receive a 'passive' attribute value, the offerer MUST be prepared to receive a
DTLS ClientHello message (if a new DTLS association is established by DTLS ClientHello message (if a new DTLS association is established by
the answerer) from the answerer before the offerer receives the SDP the answerer) from the answerer before the offerer receives the SDP
answer. answer.
5.3. Generating the Answer 5.3. Generating the Answer
When an answerer sends an answer, the answerer MUST insert in the When an answerer sends an answer, the answerer MUST insert in the
answer an SDP 'setup' attribute according to the procedures in answer an SDP 'setup' attribute according to the procedures in
[RFC4145], and one or more SDP 'fingerprint' attributes according to [RFC4145], and one or more SDP 'fingerprint' attributes according to
the procedures in [RFC4572] and [I-D.ietf-mmusic-4572-update]. If the procedures in [I-D.ietf-mmusic-4572-update]. If the answerer
the answerer determines, based on the criteria specified in determines, based on the criteria specified in Section 3.1, that a
Section 3.1, that a new DTLS association is to be established, the new DTLS association is to be established, the answerer MUST insert
answerer MUST insert in the associated answer an SDP 'dtls-id' in the associated answer an SDP 'dtls-id' attribute with a unique
attribute with a unique value for the answer fingerprint set. If the value. Note that the offerer and answerer generate their own local
fingerprint set is not unique due the certificate reuse across 'dtls-id' attribute values, and the combination of both values
multiple SDP sessions or endpoints, 'dtls-id' value MUST be generated identify the DTLS assocation.
in a way that guarantees uniqueness across all current DTLS
association established using this fingerprint set, including DTLS
association established by other SDP sessions or other endpoints.
If the answerer receives an offer that requires establishing a new If the answerer receives an offer that requires establishing a new
DTLS association, and if the answerer does not accept the DTLS association, and if the answerer does not accept the
establishment of a new DTLS association, the answerer MUST reject the establishment of a new DTLS association, the answerer MUST reject the
"m=" lines associated with the suggested DTLS association [RFC3264]. "m=" lines associated with the suggested DTLS association [RFC3264].
If an answerer receives an offer that does not require to establish a If an answerer receives an offer that does not require the
new DTLS association, and if the answerer determines that a new DTLS establishment of a new DTLS association, and if the answerer
association is not to be established, the answerer MUST insert an SDP determines that a new DTLS association is not to be established, the
'dtls-id' attribute with the previously assigned value in the answerer MUST insert an SDP 'dtls-id' attribute with the previously
associated answer. In addition, the answerer MUST insert an SDP assigned value in the associated answer. In addition, the answerer
'setup' attribute with a value that does not change the previously MUST insert an SDP 'setup' attribute with a value that does not
negotiated DTLS roles, and one or more SDP 'fingerprint' attributes change the previously negotiated DTLS roles, and one or more SDP
values that do not change the previously sent fingerprints, in the 'fingerprint' attributes values that do not change the previously
answer. sent fingerprint set, in the answer.
If the answerer receives an offer that does not contain an SDP 'dtls- If the answerer receives an offer that does not contain an SDP 'dtls-
id' attribute, the answerer MUST NOT insert a 'dtls-id' attribute in id' attribute, the answerer MUST NOT insert a 'dtls-id' attribute in
the answer. the answer.
If a new DTLS association is to be established, and if the answerer If a new DTLS association is to be established, and if the answerer
inserts an SDP 'setup' attribute with an 'active' value in the inserts an SDP 'setup' attribute with an 'active' value in the
answer, the answerer MUST initiate a DTLS handshake by sending a DTLS answer, the answerer MUST initiate a DTLS handshake by sending a DTLS
ClientHello message towards the offerer. ClientHello message towards the offerer.
skipping to change at page 9, line 41 skipping to change at page 9, line 11
When an offerer receives an answer that establishes a new DTLS When an offerer receives an answer that establishes a new DTLS
association based on criteria defined in Section 3.1, and if the association based on criteria defined in Section 3.1, and if the
offerer becomes DTLS client (based on the value of the SDP 'setup' offerer becomes DTLS client (based on the value of the SDP 'setup'
attribute value [RFC4145]), the offerer MUST establish a DTLS attribute value [RFC4145]), the offerer MUST establish a DTLS
association. If the offerer becomes DTLS server, it MUST wait for association. If the offerer becomes DTLS server, it MUST wait for
the answerer to establish the DTLS association. the answerer to establish the DTLS association.
If the answer does not establish a new DTLS association, the offerer If the answer does not establish a new DTLS association, the offerer
will continue using the previously established DTLS association. will continue using the previously established DTLS association.
NOTE: New DTLS association can be established based on changes in NOTE: A new DTLS association can be established based on changes in
either offer or answer SDP. When communicating with legacy end either an SDP offer or answer. When communicating with legacy
points, offerer can receive the answer that uses the same fingerprint endpoints, an offerer can receive an answer that include the same
values and negotiate the same setup roles. The new DTLS association fingerprint set and setup role. A new DTLS association MUST still be
MUST still be established if such an answer was received as a established if such an answer was received as a response to an offer
response to an offer which requested to establish a new DTLS which requested the establishment of a new DTLS association.
association.
5.5. Modifying the Session 5.5. Modifying the Session
When the offerer sends a subsequent offer, and if the offerer wants When the offerer sends a subsequent offer, and if the offerer wants
to establish a new DTLS association, the offerer MUST insert an SDP to establish a new DTLS association, the offerer MUST insert an SDP
'setup' attribute according to the procedures in [RFC4145], and one 'setup' attribute according to the procedures in [RFC4145], and one
or more SDP 'fingerprint' attributes according to the procedures in or more SDP 'fingerprint' attributes according to the procedures in
[RFC4572] and [I-D.ietf-mmusic-4572-update]. In addition, offerer [I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST insert
MUST insert in the offer an SDP 'dtls-id' attribute with a new unique in the offer an SDP 'dtls-id' attribute with a new unique value.
value for the offer fingerprint set. If the fingerprint set is not
unique due the certificate reuse across multiple SDP sessions or
endpoints, the 'dtls-id' attribute value MUST be generated in a way
that guarantees uniqueness across all current DTLS association
established using this fingerprint set, including DTLS association
established by other SDP sessions or other endpoints.
When the offerer sends a subsequent offer, and the offerer does not When the offerer sends a subsequent offer, and the offerer does not
want to establish a new DTLS association, and if a previously want to establish a new DTLS association, and if a previously
established DTLS association exists, the offerer MUST insert an SDP established DTLS association exists, the offerer MUST insert an SDP
'dtls-id' attribute with the previously assigned value in the offer. 'dtls-id' attribute with the previously assigned value in the offer.
In addition, the offerer MUST insert an SDP 'setup' attribute with a In addition, the offerer MUST insert an SDP 'setup' attribute with a
value that does not change the previously negotiated DTLS roles, and value that does not change the previously negotiated DTLS roles, and
one or more SDP 'fingerprint' attributes with values that do not one or more SDP 'fingerprint' attributes with values that do not
change the previously sent fingerprints, in the offer. change the previously sent fingerprint set, in the offer.
NOTE: When a new DTLS association is being established, each endpoint 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 needs to be prepared to receive data on both the new and old DTLS
associations as long as both are alive. associations as long as both are alive.
6. ICE Considerations 6. ICE Considerations
When the Interactive Connectivity Establishment (ICE) mechansim When the Interactive Connectivity Establishment (ICE) mechansim
[I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are
performed before the DTLS handshake begins. Note that if aggressive performed before the DTLS handshake begins. Note that if aggressive
skipping to change at page 20, line 47 skipping to change at page 20, line 15
12. Acknowledgements 12. Acknowledgements
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel and Gonzalo Salgueiro for providing comments and Charles Eckel and Gonzalo Salgueiro for providing comments and
suggestions on the document. suggestions on the document.
13. Change Log 13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-dtls-15
o dtls-id attribute value made globally unique
Changes from draft-ietf-mmusic-sdp-dtls-14 Changes from draft-ietf-mmusic-sdp-dtls-14
o Changes based on comments from Flemming: o Changes based on comments from Flemming:
o - Additional dtls-is clarifiations o - Additional dtls-is clarifiations
o - Editorial fixes o - Editorial fixes
Changes from draft-ietf-mmusic-sdp-dtls-13 Changes from draft-ietf-mmusic-sdp-dtls-13
skipping to change at page 24, line 19 skipping to change at page 23, line 34
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005, DOI 10.17487/RFC4145, September 2005,
<http://www.rfc-editor.org/info/rfc4145>. <http://www.rfc-editor.org/info/rfc4145>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP
Transport Layer (UDPTL) over Datagram Transport Layer Transport Layer (UDPTL) over Datagram Transport Layer
Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August
2014, <http://www.rfc-editor.org/info/rfc7345>. 2014, <http://www.rfc-editor.org/info/rfc7345>.
[I-D.ietf-mmusic-4572-update] [I-D.ietf-mmusic-4572-update]
Holmberg, C., "SDP Fingerprint Attribute Usage Lennox, J. and C. Holmberg, "Connection-Oriented Media
Clarifications", draft-ietf-mmusic-4572-update-07 (work in Transport over TLS in SDP", draft-ietf-mmusic-
progress), September 2016. 4572-update-10 (work in progress), January 2017.
14.2. Informative References 14.2. Informative References
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
skipping to change at page 25, line 15 skipping to change at page 24, line 28
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011, DOI 10.17487/RFC6083, January 2011,
<http://www.rfc-editor.org/info/rfc6083>. <http://www.rfc-editor.org/info/rfc6083>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-04 (work in progress), June 2016. rfc5245bis-08 (work in progress), December 2016.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), September 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-36 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
 End of changes. 31 change blocks. 
121 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/