idnits 2.17.1 draft-ietf-mmusic-dtls-sdp-01.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 (October 19, 2015) is 3111 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 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 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: April 21, 2016 TurboBridge 6 October 19, 2015 8 Using the SDP Offer/Answer Mechanism for DTLS 9 draft-ietf-mmusic-dtls-sdp-01.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 This draft defines a new SDP media-level attribute, 'dtls- 18 connection'. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Establishing a new DTLS Association . . . . . . . . . . . . . 3 58 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.2. Change of Local Transport Parameters . . . . . . . . . . 3 60 4.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 61 4.4. Multiple SDP fingerprint attributes . . . . . . . . . . . 4 62 5. SDP DTLS-Connection Attribute . . . . . . . . . . . . . . . . 4 63 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 66 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.2. Generating the Initial SDP Offer . . . . . . . . . . . . 5 68 6.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 69 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 6 70 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 71 7. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 11.1. Registration of New SDP Attribute . . . . . . . . . . . 7 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 14. Normative References . . . . . . . . . . . . . . . . . . . . 9 80 Appendix A. Design Considerations . . . . . . . . . . . . . . . 10 81 A.1. dtls-connection versus dtls-connection-id . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. This 87 draft defines the SDP Offer/Answer [RFC3264] procedures for 88 negotiation DTLS in general, based on the procedures in [RFC5763]. 90 This draft also defines a new SDP attribute, 'dtls-connection'. The 91 attribute is used in SDP offers and answers to explicitly indicate 92 whether a new DTLS association is to be established. 94 As defined in [RFC5763], a new DTLS association MUST be established 95 when transport parameters are changed. Transport parameter change is 96 not well defined when Interactive Connectivity Establishment (ICE) 98 [RFC5245] is used. One possible way to determine a transport change 99 is based on ufrag change, but the ufrag value is changed both when 100 ICE is negotiated and when ICE restart [RFC5245] occurs. These 101 events do not always require a new DTLS association to be 102 established, but currently there is no way to explicitly indicate in 103 an SDP offer or answer whether a new DTLS association is required. 104 To solve that problem, this draft defines a new SDP attribute, 'dtls- 105 connection'. The attribute is used in SDP offers and answers to 106 explicitly indicate whether a new DTLS association is to be 107 established/re-established. The attribute can be used both with and 108 without ICE. 110 2. Abbreviations 112 TBD 114 3. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 4. Establishing a new DTLS Association 122 4.1. General 124 A new DTLS association MUST be established in the following cases: 126 o The DTLS roles change; 128 o The fingerprint (certificate) value changes; or 130 o The establishment of a new DTLS association is explicitly 131 signaled; 133 NOTE: The first two items list above are based on the procedures in 134 [RFC5763]. This draft adds the support for explicit signaling. 136 The sections below describe typical cases where a new DTLS 137 association needs to be established. 139 4.2. Change of Local Transport Parameters 141 If an endpoint modifies its local transport parameters (IP address 142 and/or port), and if the modification requires a new DTLS 143 association, the endpoint MUST either change its DTLS role, its 144 fingerprint value and/or use the SDP 'dtls-connection' attribute with 145 a 'new' value Section 5. 147 4.3. Change of ICE ufrag value 149 If an endpoint uses ICE, and modifies a local ufrag value, and if the 150 modification requires a new DTLS association, the endpoint MUST 151 either change its DTLS role, its fingerprint value and/or use the SDP 152 'dtls-connection' attribute with a 'new' value Section 5. 154 4.4. Multiple SDP fingerprint attributes 156 It is possible to associate multiple SDP fingerprint attribute values 157 to an 'm-' line. If any of the attribute values associated with an 158 'm-' line are removed, or if any new attribute values are added, it 159 is considered a fingerprint value change. 161 5. SDP DTLS-Connection Attribute 163 5.1. General 165 The SDP 'connection' attribute [RFC4145] was originally defined for 166 connection-oriented protocols, e.g. TCP and TLS. This section 167 defines a similar attribute, 'dtls-connection', to be used with DTLS. 169 A 'dtls-connection' attribute value of 'new' indicates that a new 170 DTLS association MUST be established. A 'dtls-connection' attribute 171 value of 'existing' indicates that a new DTLS association MUST NOT be 172 established. 174 Unlike the SDP 'connection' attribute for TLS, there is no default 175 value defined for the 'dtls-connection' attribute. Implementations 176 that wish to use the attribute MUST explicitly include it in SDP 177 offers and answers. If an offer or answer does not contain an 178 attribute, other means needs to be used in order for endpoints to 179 determine whether an offer or answer is associated with an event that 180 requires the DTLS association to be re-established. 182 The SDP Offer/Answer [RFC3264] procedures associated with the 183 attribute are defined in Section 6 185 5.2. ABNF 187 The ABNF [RFC5234] grammar for the SDP 'dtls-connection' attributes 188 is: 190 dtls-connection-attr = "a=dtls-connection:" conn-value 191 conn-value = "new" / "existing" 193 6. SDP Offer/Answer Procedures 195 6.1. General 197 This section defines the SDP offer/answer procedures for using the 198 SDP 'dtls-connection' attribute for DTLS. The section also describes 199 how the usage of the SDP 'setup' attribute and the SDP 'fingerprint' 200 attribute [RFC4572] is affected. 202 The procedures in this section are based on the procedures for SRTP- 203 DTLS [RFC5763], with the addition of usage of the SDP 'dtls- 204 connection' attribute. 206 6.2. Generating the Initial SDP Offer 208 When the offerer sends the initial offer, and the offerer wants to 209 establish a DTLS association, it MUST insert an SDP 'dtls-connection' 210 attribute with a 'new' value in the offer. In addition, the offerer 211 MUST insert an SDP 'setup' attribute according to the procedures in 212 [RFC4145], and an SDP 'fingerprint' attribute according to the 213 procedures in [RFC4572], in the offer. 215 Unlike for TCP and TLS connections, in case of DTLS associations the 216 SDP 'setup' attribute 'holdconn' value MUST NOT be used. 218 6.3. Generating the Answer 220 If an answerer receives an offer that contains an SDP 'dtls- 221 connection' attribute with a 'new' value, the answerer MUST insert a 222 'new' value in the associated answer. The same applies if the 223 answerer receives an offer that contains an SDP 'dtls-connection' 224 attribute with a 'new' value, but the answerer determines (based on 225 the criteria for establishing a new DTLS association) that a new DTLS 226 association is to be established. In addition, the answerer MUST 227 insert an SDP 'setup' attribute according to the procedures in 228 [RFC4145], and an SDP 'fingerprint' attribute according to the 229 procedures in [RFC4572], in the answer. 231 If the answerer does not accept the establishment of the DTLS 232 association, it MUST reject the "m=" lines associated with the 233 suggested DTLS association [RFC3264]. 235 If an answerer receives an offer that contains a 'dtls-connection' 236 attribute with an 'existing' value, and if the answerer determines 237 that a new DTLS association does not need to be established, it MUST 238 insert a connection attribute with an 'existing' value in the 239 associated answer. In addition, the answerer MUST insert an SDP 240 'setup' attribute with a value that does not change the previously 241 negotiated DTLS roles, and an SDP 'fingerprint' attribute with a 242 value that does not change the fingerprint, in the answer. 244 If the answerer receives an offer that does not contain an SDP 'dtls- 245 connection' attribute, the answerer MUST NOT insert a 'dtls- 246 connection' attribute in the answer. 248 If a new DTLS association is to be established, and if the answerer 249 becomes DTLS client, the answerer MUST initiate the procedures for 250 establishing the DTLS association. If the answerer becomes DTLS 251 server, it MUST wait for the offerer to establish the DTLS 252 association. 254 6.4. Offerer Processing of the SDP Answer 256 When an offerer receives an answer that contains an SDP 'dtls- 257 connection' attribute with a 'new' value, and if the offerer becomes 258 DTLS client, the offerer MUST establish a DTLS association. If the 259 offerer becomes DTLS server, it MUST wait for the answerer to 260 establish the DTLS association. 262 If the answer contains an SDP 'dtls-connection' attribute with an 263 'existing' value, the offerer will continue using the previously 264 established DTLS association. It is considered an error case if the 265 answer contains a 'dtls-connection' attribute with an 'existing' 266 value, and a DTLS association does not exist. 268 6.5. Modifying the Session 270 When the offerer sends a subsequent offer, and the offerer wants to 271 establish a new DTLS association, the offerer MUST insert an SDP 272 'dtls-connection' attribute with a 'new' value in the offer. In 273 addition, the offerer MUST insert an SDP 'setup' attribute according 274 to the procedures in [RFC4145], and an SDP 'fingerprint' attribute 275 according to the procedures in [RFC4572], in the offer. 277 when the offerer sends a subsequent offer, and the offerer does not 278 want to establish a new DTLS association, if a previously established 279 DTLS association exists, the offerer MUST insert an SDP 'dtls- 280 connection' attribute with an 'existing' value in the offer. In 281 addition, the offerer MUST insert an SDP 'setup' attribute with a 282 value that does not change the previously negotiated DTLS roles, and 283 an SDP 'fingerprint' attribute with a value that does not change the 284 fingerprint, in the offer. 286 7. ICE Considerations 288 An ICE restart [RFC5245] does not by default require a new DTLS 289 association to be established. 291 As defined in [RFC5763], each ICE candidate associated with a 292 component is treated as being part of the same DTLS association. 293 Therefore, from a DTLS perspective it is not considered a change of 294 local transport parameters when an endpoint switches between those 295 ICE candidates. 297 8. SIP Considerations 299 When the Session Initiation Protocol (SIP) [RFC3261] is used as the 300 signal protocol for establishing a multimedia session, dialogs 301 [RFC3261] might be established between the caller and multiple 302 callees. This is referred to as forking. If forking occurs, 303 separate DTLS associations MUST be established between the caller and 304 each callee. 306 It is possible to send an INVITE request which does not contain an 307 SDP offer. Such INVITE request is often referred to as an 'empty 308 INVITE', or an 'offerless INVITE'. The receiving endpoint will 309 include the SDP offer in a response associated with the response. 310 When the endpoint generates such SDP offer, it MUST assign an SDP 311 connection attribute, with a 'new' value, to each 'm-' line that 312 describes DTLS protected media. If ICE is used, the endpoint MUST 313 allocate a new set of ICE candidates, in order to ensure that two 314 DTLS association would not be running over the same transport. 316 9. RFC Updates 318 Here we will add the RFC updates that are needed. 320 10. Security Considerations 322 This draft does not modify the security considerations associated 323 with DTLS, or the SDP offer/answer mechanism. The draft simply 324 clarifies the procedures for negotiating and establishing a DTLS 325 association. 327 11. IANA Considerations 329 11.1. Registration of New SDP Attribute 331 This document updates the "Session Description Protocol Parameters" 332 registry as specified in Section 8.2.2 of [RFC4566]. Specifically, 333 it adds the SDP attributes in Section 11.1 to the table for SDP media 334 level attributes. 336 Attribute name: dtls-connection 337 Type of attribute: media-level 338 Subject to charset: no 339 Purpose: TBD 340 Appropriate Values: see Section X 341 Contact name: Christer Holmberg 343 12. Acknowledgements 345 Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat and Jens 346 Guballa for providing comments and suggestions on the draft. 348 13. Change Log 350 [RFC EDITOR NOTE: Please remove this section when publishing] 352 Changes from draft-ietf-mmusic-sdp-dtls-00 354 o - SDP 'connection' attribute replaced with new 'dtls-connection' 355 attribute. 357 o - IANA Considerations added. 359 o - E-mail regarding 'dtls-connection-id' attribute added as Annex. 361 Changes from draft-holmberg-mmusic-sdp-dtls-01 363 o - draft-ietf-mmusic version of draft submitted. 365 o - Draft file name change (sdp-dtls -> dtls-sdp) due to collision 366 with another expired draft. 368 o - Clarify that if ufrag in offer is unchanged, it must be 369 unchanged in associated answer. 371 o - SIP Considerations section added. 373 o - Section about multiple SDP fingerprint attributes added. 375 Changes from draft-holmberg-mmusic-sdp-dtls-00 377 o - Editorial changes and clarifications. 379 14. Normative References 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 387 A., Peterson, J., Sparks, R., Handley, M., and E. 388 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 389 DOI 10.17487/RFC3261, June 2002, 390 . 392 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 393 with Session Description Protocol (SDP)", RFC 3264, 394 DOI 10.17487/RFC3264, June 2002, 395 . 397 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 398 the Session Description Protocol (SDP)", RFC 4145, 399 DOI 10.17487/RFC4145, September 2005, 400 . 402 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 403 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 404 July 2006, . 406 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 407 Transport Layer Security (TLS) Protocol in the Session 408 Description Protocol (SDP)", RFC 4572, 409 DOI 10.17487/RFC4572, July 2006, 410 . 412 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 413 Specifications: ABNF", STD 68, RFC 5234, 414 DOI 10.17487/RFC5234, January 2008, 415 . 417 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 418 (ICE): A Protocol for Network Address Translator (NAT) 419 Traversal for Offer/Answer Protocols", RFC 5245, 420 DOI 10.17487/RFC5245, April 2010, 421 . 423 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 424 for Establishing a Secure Real-time Transport Protocol 425 (SRTP) Security Context Using Datagram Transport Layer 426 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 427 2010, . 429 Appendix A. Design Considerations 431 A.1. dtls-connection versus dtls-connection-id 433 The text below is from an e-mail sent by Roman to the MMUSIC mailing 434 list, 1st October 2015. It is intended to serve as background 435 reading when discussing the way forward regarding the SDP attribute. 437 The "dtls-ufrag" has little to do with ICE and exists 438 in a completely different layer. We can call this 439 attribute "dtls-connection-id" if this will makes it 440 less spooky. The problem that I am trying to resolve 441 with new attribute is related to when new DTLS association 442 needs to be established. I would argue that original 443 intent was, that new DTLS association needs to be 444 established on change of one of the end points or 445 DTLS association setup attributes (setup role or 446 fingerprint). 448 Originally, end point change was detected based on 449 transport 5-tuple change. This, of cause, does not 450 work for ICE, where 5-tuple is not known in advance 451 and all 5-tuples associated with the same ICE component 452 should be treated as the same connection. One option was 453 to detect end point change when ICE is used based on 454 ICE ufrag change, but this does not work either since 455 ufrag can change due to ICE restart, but the same 456 endpoints will continue to communicate. 458 I would also argue that setting up new DTLS association 459 on 5-tuple change does not always work for non-ICE case 460 either, since we can have an end point which can initiate 461 a re-INVITE when it detects the local IP changes due to 462 DHCP lease expiration or any other reason. This transport 463 change does not necessarily require DTLS association 464 change, and new DTLS handshake is undesirable since it 465 will delay the media flow re-establishment but several 466 network round trips. 468 So, we need to detect when two new end-points are 469 communicating and new DTLS association needs to be 470 setup. What we originally proposed is that end point 471 will simply tell that it is setting up a new session 472 by using SDP connection attribute or some renamed 473 version of it. 475 What I am saying here is that end point cannot always 476 identify if it needs to setup a new DTLS association. 477 The problem arises when new offer is generated in 478 response to an offerless INVITE. In such case, an end 479 point does not know if it is continuing to communicate 480 with the same end-point or if this offer is intended 481 to be sent to a new end point. 483 There are two solution possible to this: 485 1. We specify that if an end points generates an offer in 486 response to an offer-less INVITE it should always assume 487 it is communicating with a new end point, it MUST add 488 "connection:new" and MUST make sure that none of the 489 existing transports can be possibly reused for this new 490 DTLS association by allocating new IP:port for non ICE 491 or a complete new set of ICE candidates in case of ICE. 492 This will work, but it is wasteful when offer-less INVITE 493 re-establishes connection between two existing end points. 494 In such cases additional ports will be consumed, TURN 495 tunnels will be allocated, and time spent on creating a 496 DTLS session when all of this can be simply reused. 498 2. Instead of asking the end point which generates the 499 offer to determine if it is establishing a new DTLS 500 association, we will ask the end point to identify itself. 501 So, instead of SDP connection attribute, an end point 502 will provide some sort of randomly generated end point 503 identifier in the new attribute (dtls-ufrag or 504 dtls-connection-id). When the connection ID pair stays 505 the same, the existing DTLS association continues to run 506 over the negotiated transport. If one of the connection 507 IDs changes, this would mean new DTLS association would 508 need to be established. This nicely uncouples end point 509 change identification from transport and makes negotiation 510 follow the original intent. 512 In case of response to an offer-less INVITE, an offer with 513 the existing connection ID will be generated. If this offer 514 is sent to a new end point, both end points will detect 515 that new DTLS association is required due to connection ID 516 change of the answering end point. If this offer will be 517 sent to an end point which is already a part of the existing 518 DTLS association, no new DTLS association will be necessary, 519 since both connection IDs will stay the same. 521 This also gives us path to a more "strategic" solution in the 522 future. DTLS handshake can be extended to include the 523 connection ID. Each DTLS handshake can negotiate a association 524 identifier similar to SSRC which can be used in the all 525 subsequent DTLS messages for this association. This way 526 multiple DTLS associations can be multiplexed over the single 527 transport and each of them can be tied to an m= line in 528 offer/answer. This, of cause, is not part of the current 529 draft and is outside of MMUSIC chapter, but does provide a 530 natural extension path for DTLS in the future. 532 In general Christer and I are trying to understand if there 533 is interest in formalizing the dtls-connection-id option 534 (more complex) or if we should stick with SDP 535 connection:new/existing attribute and force new DTLS association 536 always be established in response to offer-less INVITE (simpler 537 option but can waste resources). 539 Please let us know if these options need further clarification 540 or if you have any additional questions or opinions. 542 Authors' Addresses 544 Christer Holmberg 545 Ericsson 546 Hirsalantie 11 547 Jorvas 02420 548 Finland 550 Email: christer.holmberg@ericsson.com 552 Roman Shpount 553 TurboBridge 554 4905 Del Ray Avenue, Suite 300 555 Bethesda, MD 20814 556 USA 558 Phone: +1 (240) 292-6632 559 Email: rshpount@turbobridge.com