Network Working Group C. Holmberg Internet-Draft Ericsson Intended status: Standards Track R. Shpount Expires: December 17, 2015 TurboBridge June 15, 2015 DTLS Association Establishment Using the SDP Offer/Answer Mechanism draft-holmberg-mmusic-sdp-dtls-00.txt Abstract This draft defines the criteria for when a DTLS association needs to be established/re-established, based on an SDP offer/answer transaction. The draft also defines how the SDP 'connection' attribute is used with DTLS to signal to the remote peer whether a new DTLS association needs to established/re-established. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 17, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Holmberg & Shpount Expires December 17, 2015 [Page 1] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. DTLS Association Re-Establishment Criteria . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Change of DTLS Role . . . . . . . . . . . . . . . . . . . 3 4.3. Change of Fingerprint . . . . . . . . . . . . . . . . . . 3 4.4. ICE Considerations . . . . . . . . . . . . . . . . . . . 3 4.5. SIP Considerations . . . . . . . . . . . . . . . . . . . 4 5. SDP Connection Attribute for DTLS . . . . . . . . . . . . . . 4 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 6.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 7. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This draft defines the criteria for when a DTLS association needs to be established/re-established, based on an SDP offer/answer transaction. The draft also defines how the SDP 'connection' attribute is used with DTLS to signal to the remote peer whether a new DTLS association needs to established/re-established. 2. Abbreviations TBD 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Holmberg & Shpount Expires December 17, 2015 [Page 2] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 4. DTLS Association Re-Establishment Criteria 4.1. General If an endpoint changes the local transport parameters associated with a DTLS association, the endpoint MUST create a new DTLS association. Section 6 defines the SDP Offer/Answer procedures [RFC3264] associated with that. NOTE: As described in Section 4.4, when Interactive Connectivity Establishment (ICE) [RFC5245] is used there are specific scenarios where the change of transport parameters do not trigger a re- establishment of the DTLS association. This section describes other events that require re-establishment of a DTLS association. If such event occur, the endpoint MUST also change the local transport parameters. An endpoint MUST NOT re- establish a DTLS association without also changing the local transport parameters, event if the trigger as such for the re- establishment is not a change of the local transport parameters. NOTE: In future, if new events that require re-establishment of a DTLS association are found, this section should be updated to cover those events. 4.2. Change of DTLS Role [RFC5763] defines how the DTLS roles are negotiated using an offer/ answer transaction. If DTLS roles associated with the DTLS association have previously been negotiated, and a subsequent offer/ answer transaction changes the roles, the DTLS association MUST be re-established. 4.3. Change of Fingerprint If the certificate fingerprint [REF-TO-BE-ADDED] associated with the DTLS association changes, the DTLS association MUST be re- established. 4.4. ICE Considerations If Interactive Connectivity Establishment (ICE) [RFC5245] is used, the re-establishment of a DTLS association requires the ICE session to be re-established. Similarly, the re-establishment of an ICE session requires re-establishment of the DTLS association. When an endpoint wants to re-establish the ICE session, if follows the procedures in [RFC5245]. When the endpoint collects the new set Holmberg & Shpount Expires December 17, 2015 [Page 3] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 of ICE candidates, the host candidate(s) MUST be different from the previously used host candidates. An ICE restart [RFC5245] does not require re-establishment of the DTLS association and the ICE session, even if new host candidates might be taken into use due to the restart. Note that, as defined in [RFC5763], each ICE candidate associated with a component is treated as being part of the same DTLS association. Therefore, from a DTLS perspective it is not considered a change of local transport parameters when endpoints switch between those ICE candidates, and hence such switch will not trigger re- establishment of the DTLS association. NOTE: The procedures defined in [RFC5763] are defined for SRTP-DTLS [RFC5763]. However, this document refer the the procedures for general usage with DTLS. 4.5. SIP Considerations When the Session Initiation Protocol (SIP) [RFC3261] is used as the signal protocol for establishing a multimedia session, dialogs [RFC3261] might be established between the caller and multiple callees. This is referred to as forking. If forking occurs, separate DTLS associations MUST be established between the caller and each callee. 5. SDP Connection Attribute for DTLS 5.1. General The SDP 'connection' attribute was originally defined for connection- oriented protocols, e.g. TCP and TLS. This section defines how the attribute is used with DTLS. A 'connection' attribute value of 'new' indicates that a new DTLS association MUST be established. A 'connection' attribute value of 'existing' indicates that the existing DTLS association MUST be used. When used with DTLS, there is no default value defined for the attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain an attribute, other means needs to be used in order for endpoints to determine whether an offer or answer is associated with an event that requires the DTLS association to be re- established. Holmberg & Shpount Expires December 17, 2015 [Page 4] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 6. SDP Offer/Answer Procedures 6.1. General This section defines the SDP offer/answer procedures for using the SDP 'connection' attribute for DTLS. The section also describes how the usage of the SDP 'setup' attribute and the SDP 'fingerprint' attribute [RFC4572] is affected. 6.2. Generating the Initial SDP Offer When the offerer sends the initial offer, and the offerer wants to establish a DTLS association, it MUST insert an SDP 'connection' attribute with a 'new' value to the offer. In addition, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4572], and an SDP 'fingerprint' attribute according to the procedures in [RFC4572], in the offer. 6.3. Generating the Answer If an answerer receives an offer that contains an SDP 'connection' attribute with a 'new' value, the answerer MUST insert a 'new' value in the associated answer. The same applies if the answerer receives an offer that contains an SDP 'connection' attribute with a 'new' value, but the answerer determines (based on local events) that the DTLS association is to be re-established. In addition, the answerer MUSTbinsert an SDP 'setup' attribute according to the procedures in [RFC4572], and an SDP 'fingerprint' attribute according to the procedures in [RFC4572], in the answer. If the answerer does not accept the establishment (or re- establishment) of the DTLS association, it MUST reject the offer [RFC3264]. If an answerer receives an offer that contains a 'connection' attribute with an 'existing' value, and if the answerer determines that the DTLS association does not need to be re-established, it MUST insert an 'existing' value in the associated answer. In addition, the answerer MUST insert an SDP 'setup' attribute with a value that does not change the previously negotiated DTLS roles, and an SDP 'fingerprint' attribute with a value that does not change the fingerprint, in the answer. If the answerer receives an offer that does not contain an SDP 'connection' attribute, the answerer MUST NOT insert a 'connection' attribute in the answer. Holmberg & Shpount Expires December 17, 2015 [Page 5] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 If the DTLS association is to be established (or re-established), and if the answerer becomes DTLS client, the answerer MUST initiate the procedures for establishing/re-establishing the DTLS association. If the answerer becomes DTLS server, it waits for the offerer to establish (or re-establish) the DTLS association. 6.4. Offerer Processing of the SDP Answer When an offerer receives an answer that contains an SDP 'connection' attribute with a 'new' value, and if the offerer becomes DTLS client, the offerer MUST establish/re-establish the DTLS association. If the offerer becomes DTLS server, it waits for the answerer to establish/ re-establish the DTLS association. If the answer contains an SDP 'connection' attribute with an 'existing' value, the offerer will continue using the previously established DTLS association. It is considered an error case if the answer contains a 'connection' attribute with an 'existing' value, and a DTLS association does not exist. 6.5. Modifying the Session When the offerer sends a subsequent offer, and a previously established DTLS association is to be established (or re- established), the offerer MUST insert an SDP 'connection' attribute with a 'new' value in the offer. In addition, the offerer MUST insert an SDP 'setup' attribute according to the procedures in [RFC4572], and an SDP 'fingerprint' attribute according to the procedures in [RFC4572], in the offer. When the offerer sends a subsequent offer, and the DTLS association is not to be established (or re-established), the offerer MUST insert an SDP 'connection' attribute with an 'existing' value in the offer. In addition, the offerer MUST insert an SDP 'setup' attribute with a value that does not change the previously negotiated DTLS roles, and an SDP 'fingerprint' attribute with a value that does not change the fingerprint, in the offer. 7. RFC Updates Here we will add the RFC updates that are needed. 8. Security Considerations TBD Holmberg & Shpount Expires December 17, 2015 [Page 6] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 9. IANA Considerations TBD 10. Acknowledgements TBD 11. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, May 2010. Authors' Addresses Holmberg & Shpount Expires December 17, 2015 [Page 7] Internet-DraDTLS Association Establishment Using the SDP Offe June 2015 Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Roman Shpount TurboBridge 4905 Del Ray Avenue, Suite 300 Bethesda, MD 20814 USA Phone: +1 (240) 292-6632 Email: rshpount@turbobridge.com Holmberg & Shpount Expires December 17, 2015 [Page 8]