draft-ietf-mmusic-dtls-sdp-13.txt   draft-ietf-mmusic-dtls-sdp-14.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: November 26, 2016 May 25, 2016 Expires: January 19, 2017 July 18, 2016
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-13.txt draft-ietf-mmusic-dtls-sdp-14.txt
Abstract Abstract
This draft defines the SDP offer/answer procedures for negotiating This draft defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The draft also defines the and establishing a DTLS association. The draft also defines the
criteria for when a new DTLS association must be established. criteria for when a new DTLS association must be established. The
draft updates RFC 5763 and RFC 7345, by replacing common SDP offer/
answer procedures with a reference to this specification.
This draft defines a new SDP media-level attribute, 'dtls-id'. This draft defines a new SDP media-level attribute, 'dtls-id'.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 26, 2016. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 37 skipping to change at page 2, line 38
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . 22 14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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
DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The draft
updates [RFC5763] and [RFC7345], by replacing common SDP offer/answer
procedures with a reference to this specification.
As defined in [RFC5763], a new DTLS association MUST be established As defined in [RFC5763], a new DTLS association MUST be established
when transport parameters are changed. Transport parameter change is when transport parameters are changed. Transport parameter change is
not well defined when Interactive Connectivity Establishment (ICE) not well defined when Interactive Connectivity Establishment (ICE)
[RFC5245] is used. One possible way to determine a transport change [RFC5245] is used. One possible way to determine a transport change
is based on ufrag change, but the ufrag value is changed both when is based on ufrag change, but the ufrag value is changed both when
ICE is negotiated and when ICE restart [RFC5245] occurs. These ICE is negotiated and when ICE restart [RFC5245] occurs. These
events do not always require a new DTLS association to be events do not always require a new DTLS association to be
established, but currently there is no way to explicitly indicate in established, but currently there is no way to explicitly indicate in
an SDP offer or answer whether a new DTLS association is required. an SDP offer or answer whether a new DTLS association is required.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
answerer cannot initiate a new DTLS association unless the offerer answerer cannot initiate a new DTLS association unless the offerer
initiated ICE restart [RFC5245]. If the answerer wants to initiate a initiated ICE restart [RFC5245]. If the answerer wants to initiate a
new DTLS association, it needs to initiate an ICE restart on its own. new DTLS association, it needs to initiate an ICE restart on its own.
However, an ICE restart does not by default require a new DTLS However, an ICE restart does not by default require a new DTLS
association to be established. association to be established.
NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
are sent directly over UDP, not over DTLS. [RFC3261] describes how are sent directly over UDP, not over DTLS. [RFC3261] describes how
to demultiplex STUN packets from DTLS packets and SRTP packets. to demultiplex STUN packets from DTLS packets and SRTP packets.
As defined in [RFC5763], each ICE candidate associated with a Each ICE candidate associated with a component is treated as being
component is treated as being part of the same DTLS association. part of the same DTLS association. Therefore, from a DTLS
Therefore, from a DTLS perspective it is not considered a change of perspective it is not considered a change of local transport
local transport parameters when an endpoint switches between those parameters when an endpoint switches between those ICE candidates.
ICE candidates.
7. Transport Protocol Considerations 7. Transport Protocol Considerations
7.1. Transport Re-Usage 7.1. Transport Re-Usage
If DTLS is transported on top of a connection-oriented transport If DTLS is transported on top of a connection-oriented transport
protocol (e.g. TCP or SCTP), where all IP packets are acknowledged, protocol (e.g. TCP or SCTP), where all IP packets are acknowledged,
all DTLS packets associated with a previous DTLS association MUST be all DTLS packets associated with a previous DTLS association MUST be
acknowledged (or timed out) before a new DTLS association can be acknowledged (or timed out) before a new DTLS association can be
established on the same transport. established on the same transport.
skipping to change at page 10, line 42 skipping to change at page 10, line 41
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 associated with the response. include the SDP offer in a response associated with the response.
When the endpoint generates such SDP offer, if a previously When the endpoint generates such SDP offer, if a previously
established DTLS association exists, the offerer SHOULD insert an SDP established DTLS association exists, the offerer SHOULD insert an SDP
'dtls-id' attribute, and one or more SDP 'fingerprint' attributes, 'dtls-id' attribute, and one or more SDP 'fingerprint' attributes,
with previously assigned attribute values. If a previously with previously assigned attribute values. If a previously
established DTLS association did not exists offer SHOULD be generated established DTLS association did not exists offer SHOULD be generated
based on the same rules as new offer Section 5.2. Regardless of the based on the same rules as new offer Section 5.2. Regardless of the
previous existence of DTLS association, the SDP 'setup' attribute previous existence of DTLS association, the SDP 'setup' attribute
MUST be included according to rules defiend in [RFC4145] and if ICE MUST be included according to rules defiend in [RFC4145] and if ICE
is used, ICE restart MUST be initiated as defined in [RFC5763]. is used, ICE restart MUST be initiated.
9. RFC Updates 9. RFC Updates
9.1. General 9.1. General
This section updates specifications that use DTLS-protected media, in This section updates specifications that use DTLS-protected media, in
order to reflect the procedures defined in this specification. order to reflect the procedures defined in this specification.
9.2. Update to RFC 5763 9.2. Update to RFC 5763
skipping to change at page 19, line 47 skipping to change at page 19, line 47
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 draft. suggestions on the draft.
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-13
o Text about the updated RFCs added to Abstract and Introduction
o Reference to RFC 5763 removed from section 6 (ICE Considerations)
o Reference to RFC 5763 removed from section 8 (SIP Considerations)
Changes from draft-ietf-mmusic-sdp-dtls-12 Changes from draft-ietf-mmusic-sdp-dtls-12
o "unreliable" changed to "unordered" o "unreliable" changed to "unordered"
Changes from draft-ietf-mmusic-sdp-dtls-11 Changes from draft-ietf-mmusic-sdp-dtls-11
o Attribute name changed to dtls-id o Attribute name changed to dtls-id
o Additional text based on comments from Roman Shpount. o Additional text based on comments from Roman Shpount.
Changes from draft-ietf-mmusic-sdp-dtls-10 Changes from draft-ietf-mmusic-sdp-dtls-10
o Modified document to use dtls-id instead of dtls-connection o Modified document to use dtls-id instead of dtls-connection
skipping to change at page 23, line 37 skipping to change at page 24, line 7
<http://www.rfc-editor.org/info/rfc5576>. <http://www.rfc-editor.org/info/rfc5576>.
[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-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-12 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13
(work in progress), January 2016. (work in progress), June 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-29 (work in progress), April 2016. negotiation-31 (work in progress), June 2016.
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Roman Shpount Roman Shpount
TurboBridge TurboBridge
 End of changes. 13 change blocks. 
15 lines changed or deleted 27 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/