draft-ietf-mmusic-dtls-sdp-27.txt   draft-ietf-mmusic-dtls-sdp-28.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: January 25, 2018 July 24, 2017 Expires: February 6, 2018 August 5, 2017
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-27.txt draft-ietf-mmusic-dtls-sdp-28.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 January 25, 2018. This Internet-Draft will expire on February 6, 2018.
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 35 skipping to change at page 2, line 35
5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 12 8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14
10.2.1. Update to section 5 . . . . . . . . . . . . . . . . 14 10.2.1. Update to section 1 . . . . . . . . . . . . . . . . 14
10.2.2. Update to section 6.6 . . . . . . . . . . . . . . . 15 10.2.2. Update to section 5 . . . . . . . . . . . . . . . . 14
10.2.3. Update to section 6.7.1 . . . . . . . . . . . . . . 16 10.2.3. Update to section 6.6 . . . . . . . . . . . . . . . 15
10.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . 16
10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16
10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 16 10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 16
10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 16 10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 16
10.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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
skipping to change at page 7, line 16 skipping to change at page 7, line 16
new DTLS association, it needs to make sure that media packets new DTLS association, it needs to make sure that media packets
associated with any previously established DTLS association and the associated with any previously established DTLS association and the
new DTLS association can be de-multiplexed. In case of an ordered new DTLS association can be de-multiplexed. In case of an ordered
transport (e.g., SCTP) this can be done simply by sending packets for transport (e.g., SCTP) this can be done simply by sending packets for
the new DTLS association after all packets associated with a the new DTLS association after all packets associated with a
previously established DTLS association has been sent. In case of an previously established DTLS association has been sent. In case of an
unordered transport, such as UDP, packets associated with a unordered transport, such as UDP, packets associated with a
previously established DTLS association can arrive after the answer previously established DTLS association can arrive after the answer
SDP was received and after the first packets associated with the new SDP was received and after the first packets associated with the new
DTLS association were received. The only way to de-multiplex packets DTLS association were received. The only way to de-multiplex packets
associated with with a previously established DTLS association and associated with a previously established DTLS association and the new
the new DTLS association is on the basis of transport 5-tuple. DTLS association is on the basis of transport 5-tuple. Because of
Because of this, if an unordered transport is used for the DTLS this, if an unordered transport is used for the DTLS association, a
association, a new transport (3-tuple) must be allocated by at least new transport (3-tuple) must be allocated by at least one of the
one of the endpoints so that DTLS packets can be de-multiplexed. endpoints so that DTLS packets 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 12, line 51 skipping to change at page 12, line 51
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.
NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is
not explicitly present, the implicit default value is 'new'. not explicitly present, the implicit default value is 'new'.
The SDP example below is based on the example in section 3.4 of The SDP example below is based on the example in section 3.4 of
[RFC4572], with the addition of the SDP 'tls-id' attribute. [RFC8122], with the addition of the SDP 'tls-id' attribute.
m=image 54111 TCP/TLS t38 m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=tls-id:abc3de65cddef001be82 a=tls-id:abc3de65cddef001be82
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=fingerprint:SHA-256 \ a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD 3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
skipping to change at page 14, line 14 skipping to change at page 14, line 14
10. RFC Updates 10. RFC Updates
10.1. General 10.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.
10.2. Update to RFC 5763 10.2. Update to RFC 5763
10.2.1. Update to section 5 10.2.1. Update to section 1
The reference to [RFC4572] is replaced with a reference to [RFC8122].
10.2.2. Update to section 5
The text in section 5 (Establishing a Secure Channel) is replaced The text in section 5 (Establishing a Secure Channel) is replaced
with the new text below: with the new text below:
NEW TEXT: NEW TEXT:
The two endpoints in the exchange present their identities as part of The two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses the DTLS handshake procedure using certificates. This document uses
certificates in the same style as described in "Connection-Oriented certificates in the same style as described in "Connection-Oriented
Media Transport over the Transport Layer Security (TLS) Protocol in Media Transport over the Transport Layer Security (TLS) Protocol in
the Session Description Protocol (SDP)" [RFC4572]. the Session Description Protocol (SDP)" [RFC8122].
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. ensured through the fingerprint attribute in the SDP.
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
skipping to change at page 15, line 36 skipping to change at page 15, line 41
secured. secured.
Note that the entire authentication and key exchange for securing Note that the entire authentication and key exchange for securing
the media traffic is handled in the media path through DTLS. The the media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
The offerer and answerer MUST follow the SDP offer/answer procedures The offerer and answerer MUST follow the SDP offer/answer procedures
defined in [RFCXXXX]. defined in [RFCXXXX].
10.2.2. Update to section 6.6 10.2.3. Update to section 6.6
The text in section 6.6 (Session Modification) is replaced with the The text in section 6.6 (Session Modification) is replaced with the
new text below: new text below:
NEW TEXT: NEW TEXT:
Once an answer is provided to the offerer, either endpoint MAY Once an answer is provided to the offerer, either endpoint MAY
request a session modification that MAY include an updated offer. request a session modification that MAY include an updated offer.
This session modification can be carried in either an INVITE or This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse an existing DTLS association, UPDATE request. The peers can reuse an existing DTLS association,
or establish a new one, following the procedures in [RFCXXXX]. or establish a new one, following the procedures in [RFCXXXX].
10.2.3. Update to section 6.7.1 10.2.4. Update to section 6.7.1
The text in section 6.7.1 (ICE Interaction) is replaced with the new The text in section 6.7.1 (ICE Interaction) is replaced with the new
text below: text below:
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
skipping to change at page 17, line 14 skipping to change at page 17, line 14
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
[RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
with the RFC number of this document.] with the RFC number of this document.]
10.3.3. Update to section 10.1
A reference to [RFC8122] is added to section 10.1 (Normative
References):
NEW TEXT:
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017,
<http://www.rfc-editor.org/info/rfc8122>.
11. Security Considerations 11. Security Considerations
This specification does not modify the security considerations This specification does not modify the security considerations
associated with DTLS, or the SDP offer/answer mechanism. In addition associated with DTLS, or the SDP offer/answer mechanism. In addition
to the introduction of the SDP 'tls-id' attribute, the specification to the introduction of the SDP 'tls-id' attribute, the specification
simply clarifies the procedures for negotiating and establishing a simply clarifies the procedures for negotiating and establishing a
DTLS association. DTLS association.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 17, line 49 skipping to change at page 18, line 25
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. Paul Kyzivat performed a gen-art review. AD review. Paul Kyzivat performed a gen-art 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-27
o Reference fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-26 Changes from draft-ietf-mmusic-sdp-dtls-26
o Editorial fixes based on Gen-ART review by Paul Kyzivat. o Editorial fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-25 Changes from draft-ietf-mmusic-sdp-dtls-25
o Minor editorial nits. 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:
skipping to change at page 18, line 25 skipping to change at page 19, line 4
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
offers based on comment from Ekr. offers based on comment from Ekr.
Changes from draft-ietf-mmusic-sdp-dtls-23 Changes from draft-ietf-mmusic-sdp-dtls-23
o Editorial change to make it clear that the document does not
o Editrial change to make it clear that the document does not modify modify the procedures in RFC 8122.
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.
skipping to change at page 23, line 42 skipping to change at page 24, line 19
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>. <http://www.rfc-editor.org/info/rfc4474>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006, DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>. <http://www.rfc-editor.org/info/rfc4572>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://www.rfc-editor.org/info/rfc5764>.
 End of changes. 18 change blocks. 
28 lines changed or deleted 45 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/