idnits 2.17.1 draft-holmberg-mmusic-sdp-dtls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 15, 2015) is 3239 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REF-TO-BE-ADDED' is mentioned on line 131, but not defined ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Shpount 5 Expires: December 17, 2015 TurboBridge 6 June 15, 2015 8 DTLS Association Establishment Using the SDP Offer/Answer Mechanism 9 draft-holmberg-mmusic-sdp-dtls-00.txt 11 Abstract 13 This draft defines the criteria for when a DTLS association needs to 14 be established/re-established, based on an SDP offer/answer 15 transaction. The draft also defines how the SDP 'connection' 16 attribute is used with DTLS to signal to the remote peer whether a 17 new DTLS association needs to established/re-established. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 17, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. DTLS Association Re-Establishment Criteria . . . . . . . . . 3 57 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.2. Change of DTLS Role . . . . . . . . . . . . . . . . . . . 3 59 4.3. Change of Fingerprint . . . . . . . . . . . . . . . . . . 3 60 4.4. ICE Considerations . . . . . . . . . . . . . . . . . . . 3 61 4.5. SIP Considerations . . . . . . . . . . . . . . . . . . . 4 62 5. SDP Connection Attribute for DTLS . . . . . . . . . . . . . . 4 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 65 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 67 6.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 68 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 69 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 70 7. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 This draft defines the criteria for when a DTLS association needs to 81 be established/re-established, based on an SDP offer/answer 82 transaction. The draft also defines how the SDP 'connection' 83 attribute is used with DTLS to signal to the remote peer whether a 84 new DTLS association needs to established/re-established. 86 2. Abbreviations 88 TBD 90 3. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 4. DTLS Association Re-Establishment Criteria 98 4.1. General 100 If an endpoint changes the local transport parameters associated with 101 a DTLS association, the endpoint MUST create a new DTLS association. 102 Section 6 defines the SDP Offer/Answer procedures [RFC3264] 103 associated with that. 105 NOTE: As described in Section 4.4, when Interactive Connectivity 106 Establishment (ICE) [RFC5245] is used there are specific scenarios 107 where the change of transport parameters do not trigger a re- 108 establishment of the DTLS association. 110 This section describes other events that require re-establishment of 111 a DTLS association. If such event occur, the endpoint MUST also 112 change the local transport parameters. An endpoint MUST NOT re- 113 establish a DTLS association without also changing the local 114 transport parameters, event if the trigger as such for the re- 115 establishment is not a change of the local transport parameters. 117 NOTE: In future, if new events that require re-establishment of a 118 DTLS association are found, this section should be updated to cover 119 those events. 121 4.2. Change of DTLS Role 123 [RFC5763] defines how the DTLS roles are negotiated using an offer/ 124 answer transaction. If DTLS roles associated with the DTLS 125 association have previously been negotiated, and a subsequent offer/ 126 answer transaction changes the roles, the DTLS association MUST be 127 re-established. 129 4.3. Change of Fingerprint 131 If the certificate fingerprint [REF-TO-BE-ADDED] associated with the 132 DTLS association changes, the DTLS association MUST be re- 133 established. 135 4.4. ICE Considerations 137 If Interactive Connectivity Establishment (ICE) [RFC5245] is used, 138 the re-establishment of a DTLS association requires the ICE session 139 to be re-established. Similarly, the re-establishment of an ICE 140 session requires re-establishment of the DTLS association. 142 When an endpoint wants to re-establish the ICE session, if follows 143 the procedures in [RFC5245]. When the endpoint collects the new set 144 of ICE candidates, the host candidate(s) MUST be different from the 145 previously used host candidates. 147 An ICE restart [RFC5245] does not require re-establishment of the 148 DTLS association and the ICE session, even if new host candidates 149 might be taken into use due to the restart. 151 Note that, as defined in [RFC5763], each ICE candidate associated 152 with a component is treated as being part of the same DTLS 153 association. Therefore, from a DTLS perspective it is not considered 154 a change of local transport parameters when endpoints switch between 155 those ICE candidates, and hence such switch will not trigger re- 156 establishment of the DTLS association. 158 NOTE: The procedures defined in [RFC5763] are defined for SRTP-DTLS 159 [RFC5763]. However, this document refer the the procedures for 160 general usage with DTLS. 162 4.5. SIP Considerations 164 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 165 signal protocol for establishing a multimedia session, dialogs 166 [RFC3261] might be established between the caller and multiple 167 callees. This is referred to as forking. If forking occurs, 168 separate DTLS associations MUST be established between the caller and 169 each callee. 171 5. SDP Connection Attribute for DTLS 173 5.1. General 175 The SDP 'connection' attribute was originally defined for connection- 176 oriented protocols, e.g. TCP and TLS. This section defines how the 177 attribute is used with DTLS. 179 A 'connection' attribute value of 'new' indicates that a new DTLS 180 association MUST be established. A 'connection' attribute value of 181 'existing' indicates that the existing DTLS association MUST be used. 183 When used with DTLS, there is no default value defined for the 184 attribute. Implementations that wish to use the attribute MUST 185 explicitly include it in SDP offers and answers. If an offer or 186 answer does not contain an attribute, other means needs to be used in 187 order for endpoints to determine whether an offer or answer is 188 associated with an event that requires the DTLS association to be re- 189 established. 191 6. SDP Offer/Answer Procedures 193 6.1. General 195 This section defines the SDP offer/answer procedures for using the 196 SDP 'connection' attribute for DTLS. The section also describes how 197 the usage of the SDP 'setup' attribute and the SDP 'fingerprint' 198 attribute [RFC4572] is affected. 200 6.2. Generating the Initial SDP Offer 202 When the offerer sends the initial offer, and the offerer wants to 203 establish a DTLS association, it MUST insert an SDP 'connection' 204 attribute with a 'new' value to the offer. In addition, the offerer 205 MUST insert an SDP 'setup' attribute according to the procedures in 206 [RFC4572], and an SDP 'fingerprint' attribute according to the 207 procedures in [RFC4572], in the offer. 209 6.3. Generating the Answer 211 If an answerer receives an offer that contains an SDP 'connection' 212 attribute with a 'new' value, the answerer MUST insert a 'new' value 213 in the associated answer. The same applies if the answerer receives 214 an offer that contains an SDP 'connection' attribute with a 'new' 215 value, but the answerer determines (based on local events) that the 216 DTLS association is to be re-established. In addition, the answerer 217 MUSTbinsert an SDP 'setup' attribute according to the procedures in 218 [RFC4572], and an SDP 'fingerprint' attribute according to the 219 procedures in [RFC4572], in the answer. 221 If the answerer does not accept the establishment (or re- 222 establishment) of the DTLS association, it MUST reject the offer 223 [RFC3264]. 225 If an answerer receives an offer that contains a 'connection' 226 attribute with an 'existing' value, and if the answerer determines 227 that the DTLS association does not need to be re-established, it MUST 228 insert an 'existing' value in the associated answer. In addition, 229 the answerer MUST insert an SDP 'setup' attribute with a value that 230 does not change the previously negotiated DTLS roles, and an SDP 231 'fingerprint' attribute with a value that does not change the 232 fingerprint, in the answer. 234 If the answerer receives an offer that does not contain an SDP 235 'connection' attribute, the answerer MUST NOT insert a 'connection' 236 attribute in the answer. 238 If the DTLS association is to be established (or re-established), and 239 if the answerer becomes DTLS client, the answerer MUST initiate the 240 procedures for establishing/re-establishing the DTLS association. If 241 the answerer becomes DTLS server, it waits for the offerer to 242 establish (or re-establish) the DTLS association. 244 6.4. Offerer Processing of the SDP Answer 246 When an offerer receives an answer that contains an SDP 'connection' 247 attribute with a 'new' value, and if the offerer becomes DTLS client, 248 the offerer MUST establish/re-establish the DTLS association. If the 249 offerer becomes DTLS server, it waits for the answerer to establish/ 250 re-establish the DTLS association. 252 If the answer contains an SDP 'connection' attribute with an 253 'existing' value, the offerer will continue using the previously 254 established DTLS association. It is considered an error case if the 255 answer contains a 'connection' attribute with an 'existing' value, 256 and a DTLS association does not exist. 258 6.5. Modifying the Session 260 When the offerer sends a subsequent offer, and a previously 261 established DTLS association is to be established (or re- 262 established), the offerer MUST insert an SDP 'connection' attribute 263 with a 'new' value in the offer. In addition, the offerer MUST 264 insert an SDP 'setup' attribute according to the procedures in 265 [RFC4572], and an SDP 'fingerprint' attribute according to the 266 procedures in [RFC4572], in the offer. 268 When the offerer sends a subsequent offer, and the DTLS association 269 is not to be established (or re-established), the offerer MUST insert 270 an SDP 'connection' attribute with an 'existing' value in the offer. 271 In addition, the offerer MUST insert an SDP 'setup' attribute with a 272 value that does not change the previously negotiated DTLS roles, and 273 an SDP 'fingerprint' attribute with a value that does not change the 274 fingerprint, in the offer. 276 7. RFC Updates 278 Here we will add the RFC updates that are needed. 280 8. Security Considerations 282 TBD 284 9. IANA Considerations 286 TBD 288 10. Acknowledgements 290 TBD 292 11. Change Log 294 [RFC EDITOR NOTE: Please remove this section when publishing] 296 12. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 302 A., Peterson, J., Sparks, R., Handley, M., and E. 303 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 304 June 2002. 306 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 307 with Session Description Protocol (SDP)", RFC 3264, June 308 2002. 310 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 311 Transport Layer Security (TLS) Protocol in the Session 312 Description Protocol (SDP)", RFC 4572, July 2006. 314 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 315 (ICE): A Protocol for Network Address Translator (NAT) 316 Traversal for Offer/Answer Protocols", RFC 5245, April 317 2010. 319 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 320 for Establishing a Secure Real-time Transport Protocol 321 (SRTP) Security Context Using Datagram Transport Layer 322 Security (DTLS)", RFC 5763, May 2010. 324 Authors' Addresses 325 Christer Holmberg 326 Ericsson 327 Hirsalantie 11 328 Jorvas 02420 329 Finland 331 Email: christer.holmberg@ericsson.com 333 Roman Shpount 334 TurboBridge 335 4905 Del Ray Avenue, Suite 300 336 Bethesda, MD 20814 337 USA 339 Phone: +1 (240) 292-6632 340 Email: rshpount@turbobridge.com