idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-20.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 30, 2016) is 2674 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: 'Section 5' is mentioned on line 470, but not defined == Missing Reference: 'Section 6' is mentioned on line 579, but not defined == Missing Reference: 'Section 7' is mentioned on line 714, but not defined == Missing Reference: 'Section 8' is mentioned on line 717, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 808, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-4572-update-08 == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-15 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-10 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Shpount 5 Expires: July 3, 2017 TurboBridge 6 S. Loreto 7 G. Camarillo 8 Ericsson 9 December 30, 2016 11 Session Description Protocol (SDP) Offer/Answer Procedures For Stream 12 Control Transmission Protocol (SCTP) over Datagram Transport Layer 13 Security (DTLS) Transport. 14 draft-ietf-mmusic-sctp-sdp-20 16 Abstract 18 The Stream Control Transmission Protocol (SCTP) is a transport 19 protocol used to establish associations between two endpoints. 20 draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used 21 on top of the Datagram Transport Layer Security (DTLS) protocol, 22 referred to as SCTP-over-DTLS. 24 This specification defines the following new Session Description 25 Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' 26 and 'TCP/DTLS/SCTP'. This specification also specifies how to use 27 the new proto values with the SDP Offer/Answer mechanism for 28 negotiating SCTP-over-DTLS associations. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 3, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 67 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4 68 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5 70 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5 71 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.4.2. SDP Media Description values . . . . . . . . . . . . 6 74 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6 76 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 7 79 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 8 80 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 6.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 9 83 7. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 9 84 8. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 10 85 9. Association And Connection Management . . . . . . . . . . . . 10 86 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute . . . . 10 88 9.3. SCTP Association . . . . . . . . . . . . . . . . . . . . 10 89 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) . . . 11 90 9.5. TCP Connection (TCP/DTLS/SCTP) . . . . . . . . . . . . . 12 91 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 12 92 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 12 93 10.2. Generating the Initial SDP Offer . . . . . . . . . . . . 13 94 10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 13 95 10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 14 96 10.5. Modifying the Session . . . . . . . . . . . . . . . . . 15 97 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 16 98 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 16 100 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 16 101 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 17 103 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 104 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 105 15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 18 106 15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 18 107 15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 18 108 15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 18 109 15.3. association-usage Name Registry . . . . . . . . . . . . 19 110 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 111 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 113 18.1. Normative References . . . . . . . . . . . . . . . . . . 22 114 18.2. Informative References . . . . . . . . . . . . . . . . . 24 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 117 1. Introduction 119 SDP (Session Description Protocol) [RFC4566] provides a general- 120 purpose format for describing multimedia sessions in announcements or 121 invitations. TCP-Based Media Transport in the Session Description 122 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 123 and establishing TCP [RFC0793] streams. Connection-Oriented Media 124 Transport over the Transport Layer Security (TLS) Protocol in SDP 125 [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based media 126 streams that are protected using TLS. 128 The Stream Control Transmission Protocol (SCTP) [RFC4960] is a 129 transport protocol used to establish associations between two 130 endpoints. 132 [I-D.ietf-tsvwg-sctp-dtls-encaps] specifies how SCTP can be used on 133 top of the Datagram Transport Layer Security (DTLS) protocol, 134 referred to as SCTP-over-DTLS. 136 This specification defines the following new Session Description 137 Protocol (SDP) [RFC4566] protocol identifiers (proto 138 values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also 139 specifies how to use the new proto values with the SDP Offer/Answer 140 mechanism [RFC3264] for negotiating SCTP-over-DTLS associations. 142 NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP' 143 will always force ordered and reliable delivery of the SCTP packets, 144 which limits the usage of the SCTP options. Therefore, it is 145 strongly RECOMMENDED that TCP is only used in situations where UDP 146 traffic is blocked. 148 2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. SCTP Terminology 156 SCTP Association: A protocol relationship between SCTP endpoints, 157 composed of the two SCTP endpoints and protocol state information 158 including Verification Tags and the currently active set of 159 Transmission Sequence Numbers (TSNs), etc. An association can be 160 uniquely identified by the transport addresses used by the endpoints 161 in the association. 163 SCTP Stream: A unidirectional logical channel established from one to 164 another associated SCTP endpoint, within which all user messages are 165 delivered in sequence except for those submitted to the unordered 166 delivery service. 168 SCTP-over-DTLS: SCTP used on top of DTLS, as specified in 169 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 171 4. SDP Media Descriptions 173 4.1. General 175 This section defines the following new SDP Media Description (m- 176 line) protocol identifiers (proto values) for describing an SCTP 177 association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section also 178 describes how an m- line, associated with the proto values, is 179 created. 181 The following is the format for an 'm' line, as specified in RFC4566 182 [RFC4566]: 184 m= ... 186 The 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are similar to 187 both the 'UDP' and 'TCP' proto values in that they only describe the 188 transport-layer protocol and not the upper-layer protocol. 190 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are 191 used, the underlying transport protocol is respectively UDP and TCP; 192 SCTP is carried on top of DTLS which is on top of those transport- 193 layer protocols. 195 The m- line fmt value, identifying the application-layer protocol, 196 MUST be registered by IANA. 198 4.2. Protocol Identifiers 200 The new proto values are defined as below: 202 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 203 top of a DTLS association on top of UDP, as defined in Section 7. 205 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 206 top of a DTLS association on top of TCP, as defined in Section 8. 208 4.3. Media Format Management 210 [RFC4566] defines that specifications defining new proto values must 211 define the rules by which their media format (fmt) namespace is 212 managed. 214 An m- line with a proto value of 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP' 215 always describes a single SCTP association. 217 In addition, such m- line MUST further indicate the application-layer 218 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 219 value per m- line associated with the proto values defined in this 220 specification. The "fmt" namespace associated with those proto 221 values describes the generic application usage of the entire SCTP 222 association, including the associated SCTP streams. 224 Section 15.3 defines the IANA registry for the media format 225 namespace. 227 NOTE: A mechanism on how to describe, and manage, individual SCTP 228 streams within an SCTP association, is outside the scope of this 229 specification. [I-D.ietf-mmusic-data-channel-sdpneg] defines a 230 mechanism for negotiating individual SCTP streams used to realize 231 WebRTC data channels [I-D.ietf-rtcweb-data-channel]. 233 4.4. Syntax 234 4.4.1. General 236 This section defines the values that can be used within an SDP media 237 description ("m=" line) associated with an SCTP-over-DTLS 238 association. 240 This specification creates an IANA registry for 'association-usage' 241 values. 243 4.4.2. SDP Media Description values 245 m= line parameter parameter value(s) 246 ------------------------------------------------------------------ 247 : "application" 248 : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" 249 : UDP port number (for "UDP/DTLS/SCTP") 250 TCP port number (for ""UDP/DTLS/SCTP") 251 : a string denoting the association-usage, 252 limited to the syntax of a 'token' as 253 defined in RFC4566. 255 4.5. Example 257 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 258 a=max-message-size:100000 260 5. SDP 'sctp-port' Attribute 262 5.1. General 264 This section defines a new SDP media-level attribute, 'sctp-port'. 265 The attribute can be associated with an SDP media description (m- 266 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In 267 that case the m- line port value indicates the port of the underlying 268 transport layer protocol (UDP or TCP), and the 'sctp-port' value 269 indicates the SCTP port. 271 No default value is defined for the SDP sctp-port attribute. 272 Therefore, if the attribute is not present, the associated m- line 273 MUST be considered invalid. 275 NOTE: This specification only defines the usage of the SDP 'sctp- 276 port' attribute when associated with an m- line containing one of the 277 following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. Usage of 278 the attribute with other proto values needs to be defined in a 279 separate specification. 281 5.2. Syntax 283 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 284 document.] 286 The definition of the SDP 'sctp-port' attribute is: 288 Attribute name: sctp-port 289 Type of attribute: media 290 Mux category: SPECIAL 291 Subject to charset: No 292 Purpose: Indicate the SCTP port value associated with 293 the SDP Media Description. 294 Appropriate values: Integer 295 Contact name: Christer Holmberg 296 Contact e-mail: christer.holmberg@ericsson.com 297 Reference: RFCXXXX 299 Syntax: 301 sctp-port-value = 1*5 303 The SCTP port range is between 0 and 65535 (both included). 304 Leading zeroes MUST NOT be used. 306 Example: 308 a=sctp-port:5000 310 5.3. Mux Category 312 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the SDP 313 'sctp-port' attribute is SPECIAL. 315 As the usage of multiple SCTP associations on top of a single DTLS 316 association is outside the scope of this specification, no mux rules 317 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 318 values. Future extensions, that define how to negotiate multiplexing 319 of multiple SCTP associations of top of a single DTLS association, 320 need to also define the mux rules for the attribute. 322 6. SDP 'max-message-size' Attribute 324 6.1. General 326 This section defines a new SDP media-level attribute, 'max-message- 327 size'. The attribute can be associated with an m- line to indicate 328 the maximum SCTP user message size (indicated in bytes) that an SCTP 329 endpoint is willing to receive on the SCTP association associated 330 with the m- line. Different attribute values can be used in each 331 direction. 333 An SCTP endpoint MUST assume that larger SCTP user message sizes will 334 be rejected by the peer SCTP endpoint. SCTP endpoints need to decide 335 on appropriate behavior in case a message needs to be sent in which 336 the SCTP user message size exceeds thevmaximum SCTP user message 337 size. 339 If the SDP 'max-message-size' attribute contains a maximum message 340 size value of zero, it indicates the SCTP endpoint will handle 341 messages of any size, subject to memory capacity etc. 343 If the SDP 'max-message-size' attribute is not present, the default 344 value is 64K. 346 NOTE: This specification only defines the usage of the SDP 'max- 347 message-size' attribute when associated with an m- line containing 348 one of the following proto values: 'UDP/DTLS/SCTP' or 'TCP/DTLS/ 349 SCTP'. Usage of the attribute with other proto values needs to be 350 defined in a separate specification. 352 6.2. Syntax 354 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 355 document.] 357 The definition of the SDP 'max-message-size' attribute is: 359 Attribute name: max-message-size 360 Type of attribute: media 361 Mux category: SPECIAL 362 Subject to charset: No 363 Purpose: Indicate the maximum message size that 364 an SCTP endpoint is willing to receive 365 on the SCTP association associated 366 with the SDP Media Description. 367 Appropriate values: Integer 368 Contact name: Christer Holmberg 369 Contact e-mail: christer.holmberg@ericsson.com 370 Reference: RFCXXXX 372 Syntax: 374 max-message-size-value = 1* 376 Leading zeroes MUST NOT be used. 378 Example: 380 a=max-message-size:100000 382 6.3. Mux Category 384 The mux category for the SDP 'max-message-size' attribute is SPECIAL. 386 As the usage of multiple SCTP associations on top of a single DTLS 387 association is outside the scope of this specification, no mux rules 388 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 389 values. 391 7. UDP/DTLS/SCTP Transport Realization 393 The UDP/DTLS/SCTP transport is realized as described below: 395 o SCTP on top of DTLS is realized according to the procedures 396 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 398 o DTLS on top of UDP is realized according to the procedures in 399 defined in [RFC6347]. 401 NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP 402 associations on top of a single DTLS association, the procedures in 403 this specification only support the negotiation of a single SCTP 404 association on top of any given DTLS association. 406 8. TCP/DTLS/SCTP Transport Realization 408 The TCP/DTLS/SCTP transport is realized as described below: 410 o SCTP on top of DTLS is realized according to the procedures 411 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 413 o DTLS on top of TCP is realized using the framing method defined in 414 [RFC4571], with DTLS packets being sent instead of RTP/RTCP 415 packets, and SDP signaling according to the procedures defined in 416 this specification. 418 NOTE: DTLS on top of TCP, without using the framing method defined in 419 [RFC4571] is outside the scope of this specification. A separate 420 proto value would need to be registered for such transport 421 realization. 423 9. Association And Connection Management 425 9.1. General 427 This section describes how to mange an SCTP association, DTLS 428 association and TCP connection using SDP attributes. 430 The SCTP association, the DTLS association and the TCP connection are 431 managed independently from each other. Each can be established and 432 closed without impacting others. 434 The detailed SDP Offer/Answer [RFC3264] procedures for the SDP 435 attributes are described in Section 10. 437 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute 439 This specification does not define semantics for the SDP direction 440 attributes [RFC4566]. Unless semantics of these attributes for an 441 SCTP association usage have been defined, SDP direction attributes 442 MUST be ignored if present. 444 9.3. SCTP Association 446 When an SCTP association is established, both SCTP endpoints MUST 447 initiate the SCTP association (i.e. both SCTP endpoints take the 448 'active' role), and MUST use the same SCTP port as client port and 449 server port (in order to prevent two separate SCTP associations from 450 being established). 452 As both SCTP endpoints take the 'active' role, the SDP 'setup' 453 attribute [RFC4145] does not apply to SCTP association establishment. 455 However the 'setup' attribute does apply to establishment of the 456 underlying DTLS association and TCP connection. 458 NOTE: The procedure above is different from TCP, where one endpoint 459 takes the 'active' role, the other endpoint takes the 'passive' role, 460 and only the 'active' endpoint initiates the TCP connection 461 [RFC4145]. 463 NOTE: When the SCTP association is established it is assumed that any 464 NAT traversal procedures for the underlying transport protocol (UDP 465 or TCP) have successfully been performed. 467 The SDP 'connection' attribute [RFC4145] does not apply to the SCTP 468 association. In order to trigger the closure of an existing SCTP 469 association, and establishment of a new SCTP association, the SDP 470 'sctp-port' attribute [Section 5] is used to indicate a new 471 (different than the ones currently used) SCTP port. The existing 472 SCTP association is closed, and the new SCTP association is 473 established, if one or both endpoints signal a new SCTP port. The 474 'connection' attribute does apply to establishment of underlying TCP 475 connections. 477 Alternatively, an SCTP association can be closed using the SDP 'sctp- 478 port' attribute with a zero attribute value. Later, a new SCTP 479 association can be established using the procedures in this section 480 for establishing an SCTP association. 482 SCTP associations might be closed without SDP signalling, e.g, in 483 case of a failure. The procedures in this section MUST be followed 484 to establish a new SCTP association. This requires a new SDP Offer/ 485 Answer exchange. New (different than the ones currently used) SCTP 486 ports MUST be used by both endpoints. 488 NOTE: Closing and establishing a new SCTP association using the SDP 489 'sctp-port' attribute will not impact the underlying DTLS 490 association. 492 9.4. DTLS Association (UDP/DTLS/SCTP And TCP/DTLS/SCTP) 494 A DTLS association is managed according to the procedures in 495 [I-D.ietf-mmusic-dtls-sdp]. Hence, the SDP 'setup' attribute is used 496 to negotiate the (D)TLS roles ('client' and 'server') [RFC4572]. 498 NOTE: The SDP 'setup' attribute is used to negotiate both the DTLS 499 roles and the TCP roles (Section 9.5). 501 NOTE: As described in [RFC5245], if the Interactive Connectivity 502 Establishment (ICE) mechanism [RFC5245] is used, all ICE candidates 503 associated with a DTLS association are considered part of the same 504 DTLS association. Thus, a switch from one candidate pair to another 505 candidate pair will not trigger the establishment of a new DTLS 506 association. 508 9.5. TCP Connection (TCP/DTLS/SCTP) 510 The TCP connection is managed according to the procedures in 511 [RFC4145]. Hence, the SDP 'setup' attribute is used to negotiate the 512 TCP roles ('active' and 'passive'), and the SDP 'connection' 513 attribute is used to indicate whether to use an existing TCP 514 connection, or create a new one. The SDP 'setup' attribute 515 'holdconn' value MUST NOT be used. 517 NOTE: A change of the TCP roles will also trigger a closure of the 518 DTLS association, and establishment of a new DTLS association, 519 according to the procedures in [I-D.ietf-mmusic-dtls-sdp]. 521 NOTE: As specified in [I-D.ietf-mmusic-dtls-sdp], usage of the SDP 522 'setup' attribute 'holdconn' value is not allowed. Therefore this 523 specification also forbids usage of the attribute value for TCP, as 524 DTLS is transported on top of TCP. 526 10. SDP Offer/Answer Procedures 528 10.1. General 530 This section defines the SDP Offer/Answer [RFC3264] procedures for 531 negotiating and establishing an SCTP-over-DTLS association. Unless 532 explicitly stated, the procedures apply to both the 'UDP/DTLS/SCTP' 533 and 'TCP/DTLS/SCTP' m- line proto values. 535 Each endpoint MUST associate one or more certificate fingerprints, 536 using the SDP 'fingerprint' attribute with the m- line, following the 537 procedures in [I-D.ietf-mmusic-4572-update]. 539 The authentication certificates are interpreted and validated as 540 defined in [I-D.ietf-mmusic-4572-update]. Self-signed certificates 541 can be used securely, provided that the integrity of the SDP 542 description is assured as defined in [I-D.ietf-mmusic-4572-update]. 544 Each endpoint MUST associate an SDP 'dtls-id' attribute with the m- 545 line, following the procedures in [I-D.ietf-mmusic-dtls-sdp]. 547 10.2. Generating the Initial SDP Offer 549 When the offerer creates an initial offer, the offerer: 551 o MUST associate an SDP setup attribute with the m- line; 553 o MUST associate an SDP 'sctp-port' attribute with the m- line; 555 o MUST, in the case of TCP/DTLS/SCTP, associate an SDP 'connection' 556 attribute, with a 'new' attribute value, with the m- line; and 558 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 559 the m- line. 561 10.3. Generating the SDP Answer 563 When the answerer receives an offer, which contains an m- line 564 describing an SCTP-over-DTLS association, if the answerer accepts the 565 association, the answerer: 567 o MUST insert a corresponding m- line in the answer, with an 568 identical m- line proto value [RFC3264]; 570 o MUST associate an SDP 'setup' attribute with the m- line; 572 o MUST associate an SDP 'sctp-port' attribute with the m- line. If 573 the offer contained a new (different than the one currently used) 574 SCTP port value the answerer MUST also associate a new SCTP port 575 value. If the offer contained a zero SCTP port value, or if the 576 answerer does not accept the SCTP association, the answerer MUST 577 also associate a zero SCTP port value; and 579 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 580 the m- line. The attribute value in the answer is independent 581 from the value (if present) in the corresponding m- line of the 582 offer. 584 Once the answerer has sent the answer the answerer: 586 o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not 587 yet been established, or if an existing TCP connection is to be 588 closed and replaced by a new TCP connection, follow the procedures 589 in [RFC4145] for closing and establishing a TCP connection; 591 o MUST, if a DTLS association has not yet been established, or if an 592 existing DTLS association is to be closed and replaced by a new 593 DTLS association, follow the procedures in 595 [I-D.ietf-mmusic-dtls-sdp] for closing establishing a DTLS 596 association; and 598 o MUST, if an SCTP association has not yet been established, or if 599 an existing SCTP association is to be closed and replaced by a new 600 SCTP association, initiate the closing of the existing SCTP 601 association (if applicable) and establishment of the SCTP 602 association. 604 If the SDP 'sctp-port' attribute in the answer contains a zero 605 attribute value, the answerer MUST NOT establish an SCTP association. 606 If an SCTP association exists, the offerer MUST close it. 608 If the answerer does not accept the m- line in the offer, it MUST 609 assign a zero port value to the corresponding m- line in the answer, 610 following the procedures in [RFC3264]. In addition, the answerer 611 MUST NOT initiate the establishment of a TCP connection, a DTLS 612 association or a DTLS association associated with the m- line. 614 10.4. Offerer Processing of the SDP Answer 616 Once the offerer has received the answer the offerer: 618 o MUST, in the case of TCP/DTLS/SCTP, if a TCP connection has not 619 yet been established, or if an existing TCP connection is to be 620 closed and replaced by a new TCP connection, follow the procedures 621 in [RFC4145] for closing and establishing a TCP connection; 623 o MUST, if a DTLS association has not yet been established, or if an 624 existing DTLS association is to be closed and replaced by a new 625 DTLS association, follow the procedures in 626 [I-D.ietf-mmusic-dtls-sdp] for closing and establishing a DTLS 627 association; and 629 o MUST, if an SCTP association has not yet been established, or if 630 an existing SCTP association is to be closed and replaced by a new 631 SCTP association, initiate the closing of the existing SCTP 632 association (if applicable) and establishment of the SCTP 633 association. 635 If the SDP 'sctp-port' attribute in the answer contains a zero 636 attribute value, the offerer MUST NOT establish an SCTP association. 637 If an SCTP association exists in that case, the offerer MUST close 638 it. 640 If the m- line in the answer contains a zero port value, the offerer 641 MUST NOT initiate the establishment a TCP connection, a DTLS 642 association or an SCTP association associated with the m- line. If a 643 TCP connection, or a DTLS association or an SCTP association exists 644 in that case, the offerer MUST close it. 646 10.5. Modifying the Session 648 When an offerer sends an updated offer, in order to modify a 649 previously established SCTP association, it follows the procedures in 650 Section 10.2, with the following exceptions: 652 o If the offerer wants to close an SCTP association, and immediately 653 establish a new SCTP association, the offerer MUST associate an 654 SDP 'sctp-port' attribute with a new (different than the one 655 currently used) attribute value. This will not impact the 656 underlying DTLS association (and TCP connection in case of 657 TCP/DTLS/SCTP). 659 o If the offerer wants to close an SCTP association, without 660 immediately establishing a new SCTP association, the offerer MUST 661 associate an SDP 'sctp-port' attribute with a zero attribute 662 value. This will not impact the underlying DTLS association (and 663 TCP connection in case of TCP/DTLS/SCTP). 665 o If the offerer wants to establish an SCTP association, and another 666 SCTP association was previously closed, the offerer MUST associate 667 an SDP 'sctp-port' attribute with a new attribute value (different 668 than the value associated with the previous SCTP association). If 669 the previous SCTP association was closed successfully following 670 use of an SDP 'sctp-port' attribute with a zero attribute value, 671 the offerer MAY use the same attribute value for the new SCTP 672 association that was used with the previous SCTP association 673 before it was closed. This will not impact the underlying DTLS 674 association (and TCP connection in case of TCP/DTLS/SCTP). 676 o If the offerer wants to close an existing SCTP association, and 677 the underlying DTLS association (and the underlying TCP connection 678 in case of TCP/DTLS/SCTP) it MUST assign a zero port value to the 679 m- line associated with the SCTP and DTLS associations (and TCP 680 connection in case of TCP/DTLS/SCTP), following the procedures in 681 [RFC3264]. 683 o NOTE: This specification does not define a mechanism for 684 explicitly closing a DTLS association while maintaining the 685 overlying SCTP association. However, if a DTLS association is 686 closed and replaced with a new DTLS association, as a result of 687 some other action [I-D.ietf-mmusic-dtls-sdp], the SCTP association 688 is not affected. 690 The offer follows the procedures in [I-D.ietf-mmusic-dtls-sdp] 691 regarding the DTLS association impacts when modifying a session. 693 In the case of TCP/DTLS/SCTP, the offerer follows the procedures in 694 [RFC4145] regarding the TCP connection impacts when modifying a 695 session. 697 11. Multihoming Considerations 699 Multihoming is not supported when sending SCTP on top of DTLS, as 700 DTLS does not expose address management of the underlying transport 701 protocols (UDP or TCP) to its upper layer. 703 12. NAT Considerations 705 12.1. General 707 When SCTP-over-DTLS is used in NAT environment, it relies on the NAT 708 traversal procedures for the underlying transport protocol (UDP or 709 TCP). 711 12.2. ICE Considerations 713 When SCTP-over-DTLS is used with UDP based ICE candidates [RFC5245] 714 then the procedures for UDP/DTLS/SCTP [Section 7] are used. 716 When SCTP-over-DTLS is used with TCP based ICE candidates [RFC6544] 717 then the procedures for TCP/DTLS/SCTP [Section 8] are used. 719 Implementations MUST treat all ICE candidate pairs associated with an 720 SCTP association on top of a DTLS association as part of the same 721 DTLS association. Thus, there will only be one SCTP handshake and 722 one DTLS handshake even if there are multiple valid candidate pairs, 723 and shifting from one candidate pair to another will not impact the 724 SCTP or DTLS associations. If new candidates are added, they will 725 also be part of the same SCTP and DTLS associations. When 726 transitioning between candidate pairs, different candidate pairs can 727 be currently active in different directions and implementations MUST 728 be ready to receive data on any of the candidates, even if this means 729 sending and receiving data using UDP/DTLS/SCTP and TCP/DTLS/SCTP at 730 the same time in different directions. 732 When an SDP offer or answer is sent, the proto value MUST match the 733 transport protocol associated with the default candidate. Hence, if 734 UDP transport is used for the default candidate the 'UDP/DTLS/SCTP' 735 proto value MUST be used. If TCP transport is used for the default 736 candidate the 'TCP/DTLS/SCTP' proto value MUST be used. However, if 737 an endpoint switches between TCP-based and UDP-based candidates 738 during a session the endpoint is not required to send an SDP offer in 739 order to modify that proto value of the associated m- line. 741 NOTE: The text in the paragraph above only applies when the usage of 742 ICE has been negotiated. If ICE is not used, the proto value MUST 743 always reflect the transport protocol used at any given time. 745 13. Examples 747 13.1. Establishment of UDP/DTLS/SCTP association 749 SDP Offer: 751 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 752 c=IN IP4 192.0.2.1 753 a=dtls-id:abc3dl 754 a=setup:actpass 755 a=sctp-port:5000 756 a=max-message-size:100000 758 - The offerer indicates that the usage of the 759 UDP/DTLS/SCTP association will be as defined 760 for the 'webrtc-datachannel' format value. 761 - The offerer UDP port value is 54111. 762 - The offerer SCTP port value is 5000. 763 - The offerer indicates that it can take either the 764 client or the server DTLS role. 766 SDP Answer: 768 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel 769 c=IN IP4 192.0.2.2 770 a=dtls-id:ggr4rd 771 a=setup:passive 772 a=sctp-port:6000 773 a=max-message-size:100000 775 - The answerer UDP port value is 64300. 776 - The answerer SCTP port value is 6000. 777 - The answerer takes the server DTLS role. 779 14. Security Considerations 781 [RFC4566] defines general SDP security considerations, while 782 [RFC3264], [RFC4145] and [RFC4572] define security considerations 783 when using the SDP offer/answer mechanism to negotiate media streams. 785 [RFC4960] defines general SCTP security considerations and 786 [I-D.ietf-tsvwg-sctp-dtls-encaps] defines security considerations 787 when using SCTP on top of DTLS. 789 This specification does not introduce new security considerations in 790 addition to those defined in the specifications listed above. 792 15. IANA Considerations 794 15.1. New SDP proto values 796 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 797 document.] 799 This document updates the "Session Description Protocol (SDP) 800 Parameters" registry, following the procedures in [RFC4566], by 801 adding the following values to the table in the SDP "proto" field 802 registry: 804 +-------+---------------+-----------+ 805 | Type | SDP Name | Reference | 806 +-------+---------------+-----------+ 807 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 808 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 809 +-------+---------------+-----------+ 811 Table 1: SDP "proto" field values 813 15.2. New SDP Attributes 815 15.2.1. sctp-port 817 This document defines a new SDP media-level attribute,'sctp-port'. 818 The details of the attribute are defined in Section 5.2. 820 15.2.2. max-message-size 822 This document defines a new SDP media-level attribute,'max-message- 823 size'. The details of the attribute are defined in Section 6.2. 825 15.3. association-usage Name Registry 827 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 828 document.] 830 This specification creates a new IANA registry, following the 831 procedures in [RFC5226], for the "fmt" namespace associated with the 832 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol identifiers. Each "fmt" 833 value describes the usage of an entire SCTP association, including 834 all SCTP streams associated with the SCTP association. 836 NOTE: Usage indication of individual SCTP streams is outside the 837 scope of this specification. 839 The "fmt" value, "association-usage", used with these "proto" values 840 is required. It is defined in Section 4. 842 As part of this registry, IANA maintains the following information: 844 association-usage name: The identifier of the subprotocol, as will 845 be used as the "fmt" value. 847 association-usage reference: A reference to the document in which 848 the association-usage is defined. 850 association-usage names are to be subject to the "First Come First 851 Served" IANA registration policy [RFC5226]. 853 IANA is asked to add initial values to the registry. 855 |----------------------------------------------------------| 856 | name | Reference | 857 |----------------------------------------------------------| 858 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx, | 859 | | RFCXXX | 860 |----------------------------------------------------------| 862 [RFC EDITOR NOTE: Please hold the publication of this draft 863 until draft-ietf-rtcweb-data-protocol has been published as an RFC. 864 Then, replace the reference to draft-ietf-rtcweb-data-protocol 865 with the RFC number.] 867 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number 868 of this document.] 870 Figure 1 872 16. Acknowledgments 874 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 875 Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen 876 and Ari Keranen for their comments and useful feedback. 878 17. 880 [RFC EDITOR NOTE: Please remove this section when publishing] 882 Changes from draft-ietf-mmusic-sctp-sdp-19 884 o Changes based on WG chair comments from Flemming Andreasen. 886 Changes from draft-ietf-mmusic-sctp-sdp-18 888 o Changes based on WGLC comments from Paul Kyzivat. 890 Changes from draft-ietf-mmusic-sctp-sdp-17 892 o Removal of 'SCTP'. 894 o Document title changed. 896 o Disallow usage of SDP 'setup' attribute 'holdconn' value. 898 o Roman Shpount added as co-editor. 900 Changes from draft-ietf-mmusic-sctp-sdp-15 902 o Chapter about SCTP, DTLS and TCP association/connection management 903 modified. 905 o Removal of SCTP/DTLS. 907 Changes from draft-ietf-mmusic-sctp-sdp-14 909 o Changes based on WGLC comments from Magnus Westerlund. 911 o - ABNF clarification that token and port are defined in RFC4566. 913 o - Specify 40 as maximum digit character length for the SDP max- 914 message-size value. 916 o - Editorial clarification. 918 o Changes based on discussions at IETF#92. 920 o - Specify that all ICE candidate pairs belong to the same DTLS 921 association. 923 Changes from draft-ietf-mmusic-sctp-sdp-13 925 o Changes based on comments from Paul Kyzivat. 927 o - Text preventing usage of well-known ports removed. 929 o - Editorial clarification. 931 Changes from draft-ietf-mmusic-sctp-sdp-12 933 o Mux category rules added for new SDP attributes. 935 o Reference to draft-ietf-mmusic-sdp-mux-attributes added. 937 o Changes based on comments from Roman Shpount: 939 o - Specify that fingerprint or setup roles must not be modified, 940 unless underlying transport protocol is also modified. 942 o Changes based on comments from Ari Keranen: 944 o - Editorial corrections. 946 o Changes based on comments from Flemming Andreasen: 948 o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the 949 DTLS association is established before the SCTP association. 951 o - Clarify that max-message-size value is given in bytes, and that 952 different values can be used per direction. 954 o - Section on fmtp attribute removed. 956 o - Editorial corrections. 958 Changes from draft-ietf-mmusic-sctp-sdp-11 960 o Example added. 962 Changes from draft-ietf-mmusic-sctp-sdp-10 964 o SDP max-message-size attribute added to IANA considerations. 966 o Changes based on comments from Paul Kyzivat: 968 o - Text about max message size removed from fmtp attribute section. 970 Changes from draft-ietf-mmusic-sctp-sdp-09 972 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 974 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 975 transports added. 977 Changes from draft-ietf-mmusic-sctp-sdp-08 979 o Default SCTP port removed: 981 o - Usage of SDP sctp-port attribute mandatory. 983 o SDP max-message-size attribute defined: 985 o - Attribute definition. 987 o - SDP Offer/Answer procedures. 989 o Text about SDP direction attributes added. 991 o Text about TLS role determination added. 993 18. References 995 18.1. Normative References 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", BCP 14, RFC 2119, 999 DOI 10.17487/RFC2119, March 1997, 1000 . 1002 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1003 with Session Description Protocol (SDP)", RFC 3264, 1004 DOI 10.17487/RFC3264, June 2002, 1005 . 1007 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1008 the Session Description Protocol (SDP)", RFC 4145, 1009 DOI 10.17487/RFC4145, September 2005, 1010 . 1012 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1013 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 1014 July 2006, . 1016 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1017 and RTP Control Protocol (RTCP) Packets over Connection- 1018 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 1019 2006, . 1021 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1022 Transport Layer Security (TLS) Protocol in the Session 1023 Description Protocol (SDP)", RFC 4572, 1024 DOI 10.17487/RFC4572, July 2006, 1025 . 1027 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1028 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1029 . 1031 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1032 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1033 DOI 10.17487/RFC5226, May 2008, 1034 . 1036 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1037 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1038 January 2012, . 1040 [I-D.ietf-mmusic-4572-update] 1041 Lennox, J. and C. Holmberg, "Connection-Oriented Media 1042 Transport over TLS in SDP", draft-ietf-mmusic- 1043 4572-update-08 (work in progress), November 2016. 1045 [I-D.ietf-mmusic-dtls-sdp] 1046 Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 1047 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-15 (work 1048 in progress), October 2016. 1050 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1051 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1052 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 1053 dtls-encaps-09 (work in progress), January 2015. 1055 [I-D.ietf-mmusic-sdp-mux-attributes] 1056 Nandakumar, S., "A Framework for SDP Attributes when 1057 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1058 (work in progress), December 2016. 1060 18.2. Informative References 1062 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1063 RFC 793, DOI 10.17487/RFC0793, September 1981, 1064 . 1066 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1067 (ICE): A Protocol for Network Address Translator (NAT) 1068 Traversal for Offer/Answer Protocols", RFC 5245, 1069 DOI 10.17487/RFC5245, April 2010, 1070 . 1072 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1073 "TCP Candidates with Interactive Connectivity 1074 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 1075 March 2012, . 1077 [I-D.ietf-rtcweb-data-channel] 1078 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 1079 Channels", draft-ietf-rtcweb-data-channel-13 (work in 1080 progress), January 2015. 1082 [I-D.ietf-mmusic-data-channel-sdpneg] 1083 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 1084 and (. (Unknown), "SDP-based Data Channel Negotiation", 1085 draft-ietf-mmusic-data-channel-sdpneg-10 (work in 1086 progress), September 2016. 1088 Authors' Addresses 1090 Christer Holmberg 1091 Ericsson 1092 Hirsalantie 11 1093 Jorvas 02420 1094 Finland 1096 Email: christer.holmberg@ericsson.com 1098 Roman Shpount 1099 TurboBridge 1100 4905 Del Ray Avenue, Suite 300 1101 Bethesda, MD 20814 1102 USA 1104 Phone: +1 (240) 292-6632 1105 Email: rshpount@turbobridge.com 1106 Salvatore Loreto 1107 Ericsson 1108 Hirsalantie 11 1109 Jorvas 02420 1110 Finland 1112 Email: Salvatore.Loreto@ericsson.com 1114 Gonzalo Camarillo 1115 Ericsson 1116 Hirsalantie 11 1117 Jorvas 02420 1118 Finland 1120 Email: Gonzalo.Camarillo@ericsson.com