draft-ietf-mmusic-dtls-sdp-25.txt   draft-ietf-mmusic-dtls-sdp-26.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: December 23, 2017 June 21, 2017 Expires: December 24, 2017 June 22, 2017
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-25.txt draft-ietf-mmusic-dtls-sdp-26.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, 'tls-id'. This document defines a new SDP media-level attribute, 'tls-id'.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 23, 2017. This Internet-Draft will expire on December 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
permissible to wait until the other side's fingerprint(s) has been permissible to wait until the other side's fingerprint(s) 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. The combination of the SDP 'tls-id' attribute DTLS association. The combination of the SDP 'tls-id' attribute
values of the SDP offerer and answerer identifies each individual values of the SDP offerer and answerer identifies each individual
DTLS association. DTLS association.
NOTE: There are cases where the SDP a€˜tls-ida€™ NOTE: There are cases where the SDP 'tls-id' attribute value
attribute value generated by the offerer will end up being used for generated by the offerer will end up being used for multiple DTLS
multiple DTLS associations. For that reason the combination of the associations. For that reason the combination of the attribute
attribute values of the offerer and answerer is needed in order to values of the offerer and answerer is needed in order to identity a
identity a DTLS association. An example of such case is where the DTLS association. An example of such case is where the offerer sends
offerer sends an updated offer (Section 5.5), without modifying its an updated offer (Section 5.5), without modifying its attribute
attribute value, but the answerer determines that a new DTLS value, but the answerer determines that a new DTLS association is to
association is to be created. The answerer will generate a new local be created. The answerer will generate a new local attribute value
attribute value for the new DTLS association (Section 5.3), while the for the new DTLS association (Section 5.3), while the offerer will
offerer will use the same attribute value that it used for the use the same attribute value that it used for the current
current association. Another example is when the Session Initiation association. Another example is when the Session Initiation Protocol
Protocol (SIP) [RFC3261] is used for signalling, and an offer is (SIP) [RFC3261] is used for signalling, and an offer is forked to
forked to multiple answerers. The attribute value generated by the multiple answerers. The attribute value generated by the offerer
offerer will be used for DTLS associations established by each will be used for DTLS associations established by each answerer.
answerer.
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 [RFC4145] with an 'actpass' attribute value, SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value,
and one or more SDP 'fingerprint' attributes according to the and one or more SDP 'fingerprint' attributes according to the
procedures in [RFC8122]. In addition, the offerer MUST insert in the procedures in [RFC8122]. In addition, the offerer MUST insert in the
offer an SDP 'tls-id' attribute with a unique attribute value. offer an SDP 'tls-id' attribute with a unique attribute value.
As the offerer inserts the SDP 'setup' attribute with an 'actpass' As the offerer inserts the SDP 'setup' attribute with an 'actpass'
skipping to change at page 10, line 26 skipping to change at page 10, line 26
5.4. Offerer Processing of the SDP Answer 5.4. Offerer Processing of the SDP Answer
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 offerer indiciated a desire to reuse an existing DTLS If the offerer indicated a desire to reuse an existing DTLS
association and the answerer does not request the establishment of a association and the answerer does not request the establishment of a
new DTLS assocation, the offerer will continue to use the previously new DTLS association, the offerer will continue to use the previously
established DTLS association. established DTLS association.
NOTE: A new DTLS association can be established based on changes in NOTE: A new DTLS association can be established based on changes in
either an SDP offer or answer. When communicating with legacy either an SDP offer or answer. When communicating with legacy
endpoints, an offerer can receive an answer that includes the same endpoints, an offerer can receive an answer that includes the same
fingerprint set and setup role. A new DTLS association MUST still be fingerprint set and setup role. A new DTLS association MUST still be
established if such an answer was received as a response to an offer established if such an answer was received as a response to an offer
which requested the establishment of a new DTLS association. which requested the establishment of a new DTLS association.
5.5. Modifying the Session 5.5. Modifying the Session
skipping to change at page 13, line 30 skipping to change at page 13, line 30
[RFC3261] might be established between the caller and multiple [RFC3261] might be established between the caller and multiple
callees. This is referred to as forking. If forking occurs, callees. This is referred to as forking. If forking occurs,
separate DTLS associations will be established between the caller and separate DTLS associations will be established between the caller and
each callee. each callee.
When forking occurs, an SDP offerer can receive DTLS ClientHello When forking occurs, an SDP offerer can receive DTLS ClientHello
messages and SDP answerers from multiple remote locations. Because messages and SDP answerers from multiple remote locations. Because
of this, the offerer might have to wait for multiple SDP answers of this, the offerer might have to wait for multiple SDP answers
(from different remote locations) until it receives a certificate (from different remote locations) until it receives a certificate
fingerprint that matches the certificate associated with a specific fingerprint that matches the certificate associated with a specific
DTLS handshake. The offerer MUST NOT decleare a fingerprint mismatch DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch
until it determines that it will not receive SDP answers from any until it determines that it will not receive SDP answers from any
additional remote locations. additional remote locations.
It is possible to send an INVITE request which does not contain an It is possible to send an INVITE request which does not contain an
SDP offer. Such an INVITE request is often referred to as an 'empty SDP offer. Such an INVITE request is often referred to as an 'empty
INVITE', or an 'offer-less INVITE'. The receiving endpoint will INVITE', or an 'offer-less INVITE'. The receiving endpoint will
include the SDP offer in a response to the request. When the include the SDP offer in a response to the request. When the
endpoint generates such SDP offer, if a previously established DTLS endpoint generates such SDP offer, if a previously established DTLS
association exists, the offerer MUST insert an SDP 'tls-id' association exists, the offerer MUST insert an SDP 'tls-id'
attribute, and one or more SDP 'fingerprint' attributes, with attribute, and one or more SDP 'fingerprint' attributes, with
skipping to change at page 17, line 49 skipping to change at page 17, line 49
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing
comments and suggestions on the document. Ben Campbell performed an comments and suggestions on the document. Ben Campbell performed an
AD review. AD review.
14. Change Log 14. 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-25
o Minor editorial nits.
Changes from draft-ietf-mmusic-sdp-dtls-24 Changes from draft-ietf-mmusic-sdp-dtls-24
o Changes based on 2nd WGLC comments from Roman S and Martin T: o Changes based on 2nd WGLC comments from Roman S and Martin T:
o - RFC update structure shortened (old text removed). o - RFC update structure shortened (old text removed).
o - Guidance regarding receiving ClientHello before SDP answer o - Guidance regarding receiving ClientHello before SDP answer
added. added.
o - Additional SIP condierations regarding forking. o - Additional SIP condierations regarding forking.
o - SDP setup attribute value restriction in initial and subsequent o - SDP setup attribute value restriction in initial and subsequent
 End of changes. 9 change blocks. 
21 lines changed or deleted 24 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/