idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-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 (September 7, 2015) is 3147 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) ** 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 (~~), 1 warning (==), 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: March 10, 2016 TurboBridge 6 September 7, 2015 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-00.txt 11 Abstract 13 This draft defines the SDP offer/answer procedures for negotiating 14 and establishing a DTLS association. The draft also defines the 15 criteria for when a new DTLS association must be established. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 10, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Establishing a new DTLS Association . . . . . . . . . . . . . 3 53 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 3 55 2.3. SIP Considerations . . . . . . . . . . . . . . . . . . . 3 56 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. SDP Connection Attribute for DTLS . . . . . . . . . . . . . . 4 59 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 61 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 63 6.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 64 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 65 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 66 7. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 12. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. This 77 draft defines the SDP Offer/Answer [RFC3264] procedures for 78 negotiation DTLS in general, based on the procedures in [RFC5763]. 80 This draft also defines the usage of the SDP 'connection' attribute 81 with DTLS. The attribute is used in SDP offers and answers to 82 explicitly indicate whether a new DTLS association is to be 83 established. 85 As defined in [RFC5245], when Interactive Connectivity Establishment 86 (ICE) [RFC5245] is used, the ufrag value is changed both when ICE is 87 negotiated, and when ICE restart [RFC5245] occurs. These events do 88 not always require a new DTLS association to be established, but 89 currently there is no way to explicitly indicate in an SDP offer or 90 answer whether a new DTLS association is required. To solve that 91 problem, this draft defines the usage of the SDP 'connection' 92 attribute with DTLS. The attribute is used in SDP offers and answers 93 to explicitly indicate whether a new DTLS association is to be 94 established/re-established. The attribute can be used both with and 95 without ICE. 97 2. Establishing a new DTLS Association 99 2.1. General 101 As defined in [RFC5763], an endpoint MUST indicate (in an offer or 102 answer) that a new DTLS association to established in the following 103 cases: 105 o The DTLS roles change; 107 o The fingerprint (certificate) value changes; 109 o The local transport parameters (IP address and/or port) of at 110 least one endpoint change; or 112 o If ICE is used and the ufrag value changes, and there is no 113 explicit indication (SDP 'connection' attribute) that a new DTLS 114 association shall not be established; 116 When a new DTLS association is established, an endpoint MUST use a 117 new set of transport parameters (IP address and port combination). 119 2.2. ICE Considerations 121 An ICE restart [RFC5245] does not by default require a new DTLS 122 association to be established. A new DTLS association needs to be 123 established only if or more of the criteria listed in Section 2.1 is 124 fulfilled (e.g. if the local transport paramters change). 126 As defined in [RFC5763], each ICE candidate associated with a 127 component is treated as being part of the same DTLS association. 128 Therefore, from a DTLS perspective it is not considered a change of 129 local transport parameters when an endpoint switches between those 130 ICE candidates. 132 2.3. SIP Considerations 134 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 135 signal protocol for establishing a multimedia session, dialogs 136 [RFC3261] might be established between the caller and multiple 137 callees. This is referred to as forking. If forking occurs, 138 separate DTLS associations MUST be established between the caller and 139 each callee. 141 3. Abbreviations 143 TBD 145 4. Conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 5. SDP Connection Attribute for DTLS 153 5.1. General 155 The SDP 'connection' attribute [RFC4145] was originally defined for 156 connection-oriented protocols, e.g. TCP and TLS. This section 157 defines how the attribute is used with DTLS. 159 A 'connection' attribute value of 'new' indicates that a new DTLS 160 association MUST be established. A 'connection' attribute value of 161 'existing' indicates that a new DTLS association MUST NOT be 162 established. 164 When used with DTLS, there is no default value defined for the 165 attribute. Implementations that wish to use the attribute MUST 166 explicitly include it in SDP offers and answers. If an offer or 167 answer does not contain an attribute, other means needs to be used in 168 order for endpoints to determine whether an offer or answer is 169 associated with an event that requires the DTLS association to be re- 170 established. 172 6. SDP Offer/Answer Procedures 174 6.1. General 176 This section defines the SDP offer/answer procedures for using the 177 SDP 'connection' attribute for DTLS. The section also describes how 178 the usage of the SDP 'setup' attribute and the SDP 'fingerprint' 179 attribute [RFC4572] is affected. 181 The procedures in this section are based on the procedures for SRTP- 182 DTLS [RFC5763], with the addition of usage of the SDP 'connection' 183 attribute. 185 6.2. Generating the Initial SDP Offer 187 When the offerer sends the initial offer, and the offerer wants to 188 establish a DTLS association, it MUST insert an SDP 'connection' 189 attribute with a 'new' value in the offer. In addition, the offerer 190 MUST insert an SDP 'setup' attribute according to the procedures in 191 [RFC4572], and an SDP 'fingerprint' attribute according to the 192 procedures in [RFC4572], in the offer. 194 If ICE is used, the offerer MUST insert the SDP 'ice-ufrag' and 'ice- 195 pwd' attributes according to the procedures in [RFC5245] in the 196 offer. 198 6.3. Generating the Answer 200 If an answerer receives an offer that contains an SDP 'connection' 201 attribute with a 'new' value, the answerer MUST insert a 'new' value 202 in the associated answer. The same applies if the answerer receives 203 an offer that contains an SDP 'connection' attribute with a 'new' 204 value, but the answerer determines (based on the criteria for 205 establishing a new DTLS association) that a new DTLS association is 206 to be established. In addition, the answerer MUST insert an SDP 207 'setup' attribute according to the procedures in [RFC4572], and an 208 SDP 'fingerprint' attribute according to the procedures in [RFC4572], 209 in the answer. 211 If the answerer does not accept the establishment of the DTLS 212 association, it MUST reject the "m=" lines associated with the 213 suggested DTLS association [RFC3264]. 215 If an answerer receives an offer that contains a 'connection' 216 attribute with an 'existing' value, and if the answerer determines 217 that a new DTLS association does not need to be established, it MUST 218 insert a connection attribute with an 'existing' value in the 219 associated answer. In addition, the answerer MUST insert an SDP 220 'setup' attribute with a value that does not change the previously 221 negotiated DTLS roles, and an SDP 'fingerprint' attribute with a 222 value that does not change the fingerprint, in the answer. 224 If the answerer receives an offer that does not contain an SDP 225 'connection' attribute, the answerer MUST NOT insert a 'connection' 226 attribute in the answer. 228 If ICE is used, the answerer MUST insert the SDP 'ice-ufrag' and 229 'ice-pwd' attributes according to the procedures in [RFC5245] in the 230 answer. 232 If a new DTLS association is to be established, and if the answerer 233 becomes DTLS client, the answerer MUST initiate the procedures for 234 establishing the DTLS association. If the answerer becomes DTLS 235 server, it MUST wait for the offerer to establish the DTLS 236 association. 238 6.4. Offerer Processing of the SDP Answer 240 When an offerer receives an answer that contains an SDP 'connection' 241 attribute with a 'new' value, and if the offerer becomes DTLS client, 242 the offerer MUST establish a DTLS association. If the offerer 243 becomes DTLS server, it MUST wait for the answerer to establish the 244 DTLS association. 246 If the answer contains an SDP 'connection' attribute with an 247 'existing' value, the offerer will continue using the previously 248 established DTLS association. It is considered an error case if the 249 answer contains a 'connection' attribute with an 'existing' value, 250 and a DTLS association does not exist. 252 6.5. Modifying the Session 254 When the offerer sends a subsequent offer, and the offerer wants to 255 establish a new DTLS association, the offerer MUST insert an SDP 256 'connection' attribute with a 'new' value in the offer. In addition, 257 the offerer MUST insert an SDP 'setup' attribute according to the 258 procedures in [RFC4572], and an SDP 'fingerprint' attribute according 259 to the procedures in [RFC4572], in the offer. 261 when the offerer sends a subsequent offer, and the offerer does not 262 want to establish a new DTLS association, if a previously established 263 DTLS association exists, the offerer MUST insert an SDP 'connection' 264 attribute with an 'existing' value in the offer. In addition, the 265 offerer MUST insert an SDP 'setup' attribute with a value that does 266 not change the previously negotiated DTLS roles, and an SDP 267 'fingerprint' attribute with a value that does not change the 268 fingerprint, in the offer. 270 If ICE is used, the offerer MUST insert the SDP 'ice-ufrag' and 'ice- 271 pwd' attributes according to the procedures in [RFC5245] in the 272 subsequent offer. 274 7. RFC Updates 276 Here we will add the RFC updates that are needed. 278 8. Security Considerations 280 This draft does not modify the security considerations associated 281 with DTLS, or the SDP offer/answer mechanism. The draft simply 282 clarifies the procedures for negotiating and establishing a DTLS 283 association. 285 9. IANA Considerations 287 TBD 289 10. Acknowledgements 291 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens 292 Guballa for providing comments and suggestions on the draft. 294 11. Change Log 296 [RFC EDITOR NOTE: Please remove this section when publishing] 298 Changes from draft-holmberg-mmusic-sdp-dtls-01 300 o - draft-ietf-mmusic version of draft submitted. 302 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 303 with another expired draft. 305 Changes from draft-holmberg-mmusic-sdp-dtls-00 307 o - Editorial changes and clarifications. 309 12. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 317 A., Peterson, J., Sparks, R., Handley, M., and E. 318 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 319 DOI 10.17487/RFC3261, June 2002, 320 . 322 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 323 with Session Description Protocol (SDP)", RFC 3264, 324 DOI 10.17487/RFC3264, June 2002, 325 . 327 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 328 the Session Description Protocol (SDP)", RFC 4145, 329 DOI 10.17487/RFC4145, September 2005, 330 . 332 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 333 Transport Layer Security (TLS) Protocol in the Session 334 Description Protocol (SDP)", RFC 4572, 335 DOI 10.17487/RFC4572, July 2006, 336 . 338 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 339 (ICE): A Protocol for Network Address Translator (NAT) 340 Traversal for Offer/Answer Protocols", RFC 5245, 341 DOI 10.17487/RFC5245, April 2010, 342 . 344 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 345 for Establishing a Secure Real-time Transport Protocol 346 (SRTP) Security Context Using Datagram Transport Layer 347 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 348 2010, . 350 Authors' Addresses 352 Christer Holmberg 353 Ericsson 354 Hirsalantie 11 355 Jorvas 02420 356 Finland 358 Email: christer.holmberg@ericsson.com 360 Roman Shpount 361 TurboBridge 362 4905 Del Ray Avenue, Suite 300 363 Bethesda, MD 20814 364 USA 366 Phone: +1 (240) 292-6632 367 Email: rshpount@turbobridge.com