draft-ietf-mmusic-dtls-sdp-23.txt   draft-ietf-mmusic-dtls-sdp-24.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: October 20, 2017 April 18, 2017 Expires: October 22, 2017 April 20, 2017
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-23.txt draft-ietf-mmusic-dtls-sdp-24.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 October 20, 2017. This Internet-Draft will expire on October 22, 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 2, line 36 skipping to change at page 2, line 36
5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 7. Transport Protocol Considerations . . . . . . . . . . . . . . 11
7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11
8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 13 10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 13
10.2.1. Update to section 5 . . . . . . . . . . . . . . . . 13 10.2.1. Update to section 5 . . . . . . . . . . . . . . . . 13
10.2.2. Update to section 6.6 . . . . . . . . . . . . . . . 16 10.2.2. Update to section 6.6 . . . . . . . . . . . . . . . 17
10.2.3. Update to section 6.7.1 . . . . . . . . . . . . . . 17 10.2.3. Update to section 6.7.1 . . . . . . . . . . . . . . 17
10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 18 10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 18
10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 18 10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 18
10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 21 10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . 26 15.1. Normative References . . . . . . . . . . . . . . . . . . 26
skipping to change at page 11, line 46 skipping to change at page 11, line 46
NOTE: Even though the SDP 'connection' attribute can be used to NOTE: Even though the SDP 'connection' attribute can be used to
indicate whether a new TLS connection is to be established, the indicate whether a new TLS connection is to be established, the
unique combination of SDP 'tls-id' attribute values can be used to unique combination of SDP 'tls-id' attribute values can be used to
identity a TLS connection. The unique value can be used e.g., within identity a TLS connection. The unique value can be used e.g., within
TLS protocol extensions to differentiate between mulitple TLS TLS protocol extensions to differentiate between mulitple TLS
connections and correlate those connections with specific offer/ connections and correlate those connections with specific offer/
answer exchanges. answer exchanges.
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP 'connection' attribute with
a 'new' value in the offer/answer, the offerer/answerer MUST also a 'new' value in the offer/answer and also inserts an SDP 'tls-id'
insert an SDP 'tls-id' attribute with a new unique value. attribute, the value of tls-id' attribute MUST be new and unique.
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP 'connection' attribute with
a 'existing' value in the offer/answer, and if a previously a 'existing' value in the offer/answer, if a previously established
established TLS connection exists, the offerer/answerer MUST also TLS connection exists, and if the offerer/answerer previously
insert an SDP 'tls-id' attribute with the previously assigned value inserted an SDP 'tls-id' attribute associated with the same TLS
in the offer/answer. connection in an offer/answer, the offerer/answerer MUST also insert
an SDP 'tls-id' attribute with the previously assigned value in the
offer/answer.
If an offerer or answerer receives an offer/answer with conflicting If an offerer or answerer receives an offer/answer with conflicting
attribute values, the offerer/answerer MUST process the offer/answer attribute values, the offerer/answerer MUST process the offer/answer
as misformed. as misformed.
An endpoint must not make assumptions regarding the support of the An endpoint must not make assumptions regarding the support of the
SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity,
both offerers and answerers MUST always use the 'connection' both offerers and answerers MUST always use the 'connection'
attribute in conjunction with the 'tls-id' attribute. attribute in conjunction with the 'tls-id' attribute.
skipping to change at page 22, line 32 skipping to change at page 22, line 32
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-23
o Editrial change to make it clear that the document does not modify
the procedures in RFC 8122.
Changes from draft-ietf-mmusic-sdp-dtls-22 Changes from draft-ietf-mmusic-sdp-dtls-22
o Support for TLS added. o Support for TLS added.
o Editorial changes based on sec-dir review by Rich Salz. o Editorial changes based on sec-dir review by Rich Salz.
o Editorial changes based on gen-art review by Paul Kyzivat. o Editorial changes based on gen-art review by Paul Kyzivat.
o Editorial changes based on ops-dir review by Carlos Pignataro. o Editorial changes based on ops-dir review by Carlos Pignataro.
 End of changes. 7 change blocks. 
10 lines changed or deleted 17 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/