idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-15.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 7, 2015) is 3152 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: 'RFCXXXX' is mentioned on line 762, but not defined == Missing Reference: 'Section 4' is mentioned on line 825, 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 (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-10 -- 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) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC C. Holmberg 3 Internet-Draft S. Loreto 4 Intended status: Standards Track G. Camarillo 5 Expires: March 10, 2016 Ericsson 6 September 7, 2015 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-15 12 Abstract 14 The Stream Control Transmission Protocol (SCTP) is a transport 15 protocol used to establish associations between two endpoints. 17 This specification describes how to describe SCTP associations using 18 the Session Description Protocol (SDP), and defines the following new 19 SDP Media Description protocol identifiers (proto values):'SCTP', 20 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. 22 The specification also describes how to use the new proto values 23 together with the SDP Offer/Answer mechanism in order to negotiate 24 and establish SCTP associations, and how to indicate the SCTP 25 application usage. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 10, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4 64 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4 65 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5 67 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5 68 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.4.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 7 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 7 76 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 8 77 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 8 80 7. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 9 81 8. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 9 82 9. SCTP Association Management . . . . . . . . . . . . . . . . . 9 83 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute . . . . 10 85 9.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . . 10 86 9.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 87 9.3.2. SCTP Association Initiation . . . . . . . . . . . . . 10 88 9.3.3. TLS Role Determination . . . . . . . . . . . . . . . 10 89 9.4. SDP connection Attribute . . . . . . . . . . . . . . . . 11 90 10. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 11 91 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 11 92 10.2. Generating the Initial SDP Offer . . . . . . . . . . . . 12 93 10.3. Generating the SDP Answer . . . . . . . . . . . . . . . 12 94 10.4. Offerer Processing of the SDP Answer . . . . . . . . . . 13 95 10.5. Modifying the Session . . . . . . . . . . . . . . . . . 14 96 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 14 97 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 15 99 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 15 100 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 16 102 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 104 15.1. New SDP proto values . . . . . . . . . . . . . . . . . . 17 105 15.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 17 106 15.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 17 107 15.2.2. max-message-size . . . . . . . . . . . . . . . . . . 18 108 15.3. association-usage Name Registry . . . . . . . . . . . . 18 109 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 110 17. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 112 18.1. Normative References . . . . . . . . . . . . . . . . . . 21 113 18.2. Informative References . . . . . . . . . . . . . . . . . 23 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 116 1. Introduction 118 SDP (Session Description Protocol) [RFC4566] provides a general- 119 purpose format for describing multimedia sessions in announcements or 120 invitations. TCP-Based Media Transport in the Session Description 121 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 122 and establishing TCP [RFC0793] streams. Connection-Oriented Media 123 Transport over the Transport Layer Security (TLS) Protocol in SDP 124 [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based media 125 streams that are protected using TLS. 127 The Stream Control Transmission Protocol (SCTP) [RFC4960] is a 128 transport protocol used to establish associations between two 129 endpoints. 131 This specification defines how to describe SCTP associations using 132 the Session Description Protocol (SDP) [RFC4566], and defines the 133 following new SDP Media Description [RFC4566] protocol identifiers 134 (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 135 SCTP'. 137 The specification also describes how to use the new proto values 138 together with the SDP Offer/Answer mechanism [RFC3264] in order to 139 negotiate and establish SCTP associations, and how to indicate the 140 SCTP application usage. 142 NOTE: TLS is designed to run on top of a byte-stream oriented 143 transport protocol providing a reliable, in-sequence delivery like 144 TCP. [RFC6083] presents serious limitations with transporting TLS on 145 top of SCTP. Therefore, defining a mechanism to negotiate media 146 streams transported using TLS on top of SCTP, i.e. 'SCTP/TLS', is 147 outside the scope of this specification. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 153 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 154 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 155 levels for compliant implementations. 157 3. SCTP Terminology 159 SCTP Association: A protocol relationship between SCTP endpoints, 160 composed of the two SCTP endpoints and protocol state information 161 including Verification Tags and the currently active set of 162 Transmission Sequence Numbers (TSNs), etc. An association can be 163 uniquely identified by the transport addresses used by the endpoints 164 in the association. 166 SCTP Stream: A unidirectional logical channel established from one to 167 another associated SCTP endpoint, within which all user messages are 168 delivered in sequence except for those submitted to the unordered 169 delivery service. 171 SCTP Transport address: A transport address is traditionally defined 172 by a network-layer address, a transport-layer protocol, and a 173 transport-layer port number. In the case of SCTP running over IP, a 174 transport address is defined by the combination of an IP address and 175 an SCTP port number (where SCTP is the transport protocol). 177 4. SDP Media Descriptions 179 4.1. General 181 This section defines the following new SDP Media Description (m- 182 line) protocol identifiers (proto values) for describing an SCTP 183 association: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 184 SCTP'. The section also describes how an m- line, associated with 185 the proto values, is created. 187 The following is the format for an 'm' line, as specified in RFC4566 188 [RFC4566]: 190 m= ... 192 The 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 193 values are similar to both the 'UDP' and 'TCP' proto values in that 194 they only describe the transport-layer protocol and not the upper- 195 layer protocol. 197 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are 198 used, the underlying transport protocol is respectively UDP and TCP; 199 SCTP is carried on top of DTLS which is on top of those transport- 200 layer protocols. 202 The m- line fmt value, identifying the application-layer protocol, 203 MUST be registered by IANA. 205 4.2. Protocol Identifiers 207 The new proto values are defined as below: 209 o The 'SCTP' proto value describes an SCTP association, as defined 210 in [RFC4960]. 212 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 213 Security (DTLS) [RFC6347] connection on top of an SCTP 214 association, as defined in [RFC6083]. 216 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 217 top of a DTLS connection on top of UDP, as defined in Section 7. 219 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 220 top of a DTLS connection on top of TCP, as defined in Section 8. 222 4.3. Media Format Management 224 [RFC4566] defines that specifications defining new proto values must 225 define the rules by which their media format (fmt) namespace is 226 managed. Use of an existing MIME subtype for the format is 227 encouraged. If no MIME subtype exists, it is recommended that a 228 suitable one is registered through the IETF process [RFC6838] 229 [RFC4289] by production of, or reference to, a standards-track RFC 230 that defines the transport protocol for the format. 232 An m- line with a proto value of 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' 233 or 'TCP/DTLS/SCTP' always describe a single SCTP association. 235 In addition, such m- line MUST further indicate the application-layer 236 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 237 value per m- line associated with the proto values defined in this 238 specification. The "fmt" namespace associated with those proto 239 values describes the generic application usage of the entire SCTP 240 association, including the associated SCTP streams. 242 NOTE: A mechanism on how to describe, and manage, individual SCTP 243 streams within an SCTP association, is outside the scope of this 244 specification. 246 4.4. Syntax 248 4.4.1. General 250 This section defines the ABNF [RFC5234] for the SDP media description 251 when associated with any of the proto values defined in this 252 document. 254 This specification creates an IANA registry for 'association-usage' 255 values. 257 4.4.2. ABNF 259 sctp-m-line = %x6d "=" 260 ("application" SP sctp-port SP "SCTP" SP fmt CRLF) / 261 ("application" SP sctp-port SP "SCTP/DTLS" SP fmt CRLF) / 262 ("application" SP udp-port SP "UDP/DTLS/SCTP" SP fmt CRLF) / 263 ("application" SP tcp-port SP "TCP/DTLS/SCTP" SP fmt CRLF) 265 sctp-port = port 267 udp-port = port 269 tcp-port = port 271 fmt = association-usage 273 association-usage = token 275 token and port as defined in RFC4566 277 4.5. Example 279 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 280 a=max-message-size: 100000 282 5. SDP 'sctp-port' Attribute 284 5.1. General 286 This section defines a new SDP media-level attribute, 'sctp-port'. 287 The attribute can be associated with an SDP media description (m- 288 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In 289 that case the m- line port value indicates the port of the underlying 290 transport layer protocol (UDP or TCP), and the 'sctp-port' value 291 indicates the SCTP port. 293 No default value is defined for the SDP sctp-port attribute. 294 Therefore, if the attribute is not present, the associated m- line 295 MUST be considered invalid. 297 Usage of the SDP sctp-port attribute with other proto values is not 298 specified, and MUST be discarded if received. 300 5.2. Syntax 302 The ABNF for the SDP 'sctp-port' attribute is: 304 sctp-port-attr = "a=sctp-port:" port 305 port = (1*5)DIGIT 307 The SCTP port range is between 0 and 65535 (both included). 308 Leading zeroes MUST NOT be used. 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. Usage of the attribute is only 314 applicable when associated with 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 315 proto value m- lines. 317 As the usage of multiple SCTP associations on top of a single DTLS 318 connection is outside the scope of this specification, no mux rules 319 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 320 values. Future extensions, that define how to negotiate multiplexing 321 of multiple SCTP associations of top of a single DTLS connection, 322 need to also define the mux rules for the attribute. 324 6. SDP 'max-message-size' Attribute 326 6.1. General 328 This section defines a new SDP media-level attribute, 'max-message- 329 size'. The attribute can be associated with an m- line to indicate 330 the maximum message size (indicated in bytes) that an SCTP endpoint 331 is willing to receive on the SCTP association associated with the m- 332 line. Different attribute values can be used in each direction. 334 The remote peer MUST assume that larger messages will be rejected by 335 the SCTP endpoint. SCTP endpoints need to decide on appropriate 336 behavior in case a message that exceeds the maximum size needs to be 337 sent. 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: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/ 349 SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto 350 values needs to be defined in a separate specification. 352 6.2. Syntax 354 The ABNF for the SDP 'max-message-size' attribute is: 356 max-message-size-attr = "a=max-message-size:" max-message-size 357 max-message-size = 1*40DIGIT 359 Leading zeroes MUST NOT be used. 361 6.3. Mux Category 363 The mux category for the SDP 'max-message-size' attribute is SPECIAL. 364 The mux rules depends on the proto value of the associated m- line. 365 If the proto value is 'SCTP' or 'SCTP/DTLS' the rules are identical 366 to the rules associated with the TRANSPORT mux category. 368 As the usage of multiple SCTP associations on top of a single DTLS 369 connection is outside the scope of this specification, no mux rules 370 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 371 values. 373 7. UDP/DTLS/SCTP Transport Realization 375 The UDP/DTLS/SCTP transport is realized as described below: 377 o SCTP on top of DTLS is realized according to the procedures 378 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 380 o DTLS on top of UDP is realized according to the procedures in 381 defined in [RFC6347]. 383 NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP 384 associations on top of a single DTLS connection, the procedures in 385 this specification only supports the negotiation of a single SCTP 386 association on top of any given DTLS connection. 388 8. TCP/DTLS/SCTP Transport Realization 390 The TCP/DTLS/SCTP transport is realized as described below: 392 o SCTP on top of DTLS is realized according to the procedures 393 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 395 o DTLS on top of TCP is realized using the framing method defined in 396 [RFC4571], with DTLS packets being sent instead of RTP/RTCP 397 packets, and SDP signaling according to the procedures defined in 398 this specification. 400 NOTE: DTLS on top of TCP, without using the framing method defined in 401 [RFC4571] is outside the scope of this specification. A separate 402 proto value would need to be registered for such transport 403 realization. 405 9. SCTP Association Management 407 9.1. General 409 The management of an SCTP association is identical to the management 410 of a TCP connection. An SCTP endpoint MUST follow the rules in 411 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 412 the SCTP ordered or unordered delivery service is up to the 413 applications using the SCTP association, and this specification does 414 not define a mechanism to indicate the type of delivery service using 415 SDP. 417 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute 419 This specification does not define semantics for the SDP direction 420 attributes [RFC4566]. Unless semantics of these attributes for an 421 SCTP association usage have been defined, SDP direction attributes 422 MUST be discarded if present. 424 9.3. SDP setup Attribute 426 9.3.1. General 428 The SDP setup attribute is used to determine the 'active/passive' 429 status of the endpoints, following the procedures for TCP in 430 [RFC4145]. 432 9.3.2. SCTP Association Initiation 434 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 435 association, and MUST use the same SCTP port as client port and 436 server port (in order to prevent two separate SCTP associations from 437 being established). 439 NOTE: The procedure above is different from TCP, where only the 440 'active' endpoint initiates the TCP connection [RFC4145]. 442 NOTE: If the underlying transport protocol is UDP or TCP (e.g. if the 443 m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'), when the 444 SCTP association is established it is assumed that any NAT traversal 445 procedures for the underlying transport protocol has successfully 446 been performed. 448 If the m- line proto value is 'TCP/DTLS/SCTP', the 'active' endpoint 449 only MUST initiate the TCP connection, following the procedures in 450 [RFC4145]. Both endpoints MUST still initiate the SCTP association 451 on top of the TCP connection. 453 9.3.3. TLS Role Determination 455 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 456 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 457 (D)TLS roles of the endpoints. Following the procedures in 458 [RFC4572], the 'active' endpoint will take the (D)TLS client role. 460 Once the DTLS connection has been established, the endpoints MUST NOT 461 modify (as result of an offer/answer exchange) the TLS roles, or the 462 'active/passive' status, of the endpoints, unless the underlying 463 transport protocol is also modified (e.g. if an IP address- or port 464 value associated with the transport protocol is modified). 466 If the underlying transport protocol is modified, the endpoints MUST 467 establish a new DTLS connection. In such case the 'active/passive' 468 status of the endpoints will again be determined following the 469 procedures in [RFC4145], and the new status will be used to determine 470 the (D)TLS roles of the endpoints associated with the new DTLS 471 connection. 473 NOTE: The procedure above is identical to the one defined for SRTP- 474 DTLS in [RFC5763]. 476 NOTE: As described in [add-reference], if the Interactive 477 Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE 478 candidates associated with an SCTP association on top of a DTLS 479 connection as part of the same DTLS connection. Thus, a switch from 480 one candidate pair to another candidate pair will not trigger the 481 establishment of a new DTLS connection. 483 9.4. SDP connection Attribute 485 The SDP connection attribute is used following the procedures in 486 [RFC4145], with the additional SCTP specific considerations described 487 in this section. 489 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 490 attribute associated with that m- line applies to both the SCTP 491 association and the TCP connection. Therefore, an attribute 'new' 492 value indicates that both a new SCTP association and new TCP 493 connection have to be established, following the procedures in 494 [RFC4145]. 496 NOTE: This specification does not define a mechanism which allows re- 497 establishing of a new SCTP association, while maintaining the 498 underlying TCP connection. 500 The SDP connection attribute value does not automatically impact an 501 existing DTLS connection. Section 9.3.3 describes in which cases a 502 new DTLS connections will have to be re-established. 504 10. SDP Offer/Answer Procedures 506 10.1. General 508 This section defines the SDP Offer/Answer [RFC3264] procedures for 509 negotiating and establishing an SCTP association. Unless explicitly 510 stated, the procedures apply to all m- line proto values ('SCTP', 511 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 512 specification. 514 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 515 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 516 fingerprint, using the SDP 'fingerprint' attribute [RFC4572], if the 517 endpoint supports, and is willing to use, a cipher suite with an 518 associated certificate. 520 The authentication certificates are interpreted and validated as 521 defined in [RFC4572]. Self-signed certificates can be used securely, 522 provided that the integrity of the SDP description is assured as 523 defined in [RFC4572]. 525 NOTE: The procedures apply to a specific m- line describing an SCTP 526 association. If an offer or answer contains multiple m- lines 527 describing SCTP associations, the procedures are applied separately 528 to each m- line. 530 10.2. Generating the Initial SDP Offer 532 When the offerer creates an initial offer, the offerer: 534 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 535 or 'TCP/DTLS/SCTP', associate an SDP setup attribute, with an 536 'actpass' value, with the m- line (see Section 9.3); 538 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 539 associate an SDP 'sctp-port' attribute with the m- line (see 540 Section 5); 542 o MUST associate an SDP 'connection' attribute, with a 'new' value, 543 with the m- line (see Section 9.4); and 545 o MAY associate an SDP 'max-message-size' attribute with the m- line 546 (see Section 6). 548 10.3. Generating the SDP Answer 550 When the answerer receives an offer, which contains an m- line 551 describing an SCTP association, if the answerer accepts the m- line 552 it: 554 o MUST insert a corresponding m- line in the answer, with an 555 identical m- line proto value [RFC3264]; 557 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 558 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute, with an 559 'active' or 'passive' value, with the m- line (see Section 9.3); 561 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 562 associate an SDP 'sctp-port' attribute with the m- line (see 563 Section 5); and 565 o MAY associate an SDP 'max-message-size' attribute with the m- line 566 (see Section 6). The attribute value in the answer is independent 567 from the value (if present) in the corresponding m- line of the 568 offer. 570 Once the answerer has sent the answer, the answerer: 572 o MUST, if an SCTP association associated with the m- line has yet 573 not been established, or if an existing SCTP association is to be 574 re-established, initiate the establishing of the SCTP association; 575 and 577 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 578 connection associated with the m- line is to be established (or 579 re-established), initiate the establishing of the DTLS connection 580 (by sending a ClientHello message). 582 If the answerer does not accept the m- line in the offer, it MUST 583 assign a zero port value to the corresponding m- line in the answer. 584 In addition, the answerer MUST NOT establish an SCTP association, or 585 a DTLS connection, associated with the m- line. 587 10.4. Offerer Processing of the SDP Answer 589 When the offerer receives an answer, which contains an m- line with a 590 non-zero port value, describing an SCTP association, the offerer: 592 o MUST, if the offerer is the 'active' endpoint, if the m- line 593 proto value is 'TCP/DTLS/SCTP', and if a TCP connection used to 594 carry the SCTP association has not yet been established (or if an 595 existing TCP connection is to be re-established), initiate the 596 establishing of the TCP connection; 598 o MUST, if an SCTP association associated with the m- line has not 599 yet been established (or if an existing SCTP association is to be 600 re-established), initiate the establishing of the SCTP 601 association; and 603 o MUST, if the offerer is the 'active' endpoint, and if a DTLS 604 connection associated with the m- line is to be established (or if 605 an existing DTLS connection is to be re-established), initiate the 606 establishing of the DTLS connection (by sending a ClientHello 607 message). 609 o NOTE: If the m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/ 610 SCTP', the underlying DTLS connection needs to be established 611 before the SCTP association can be established. 613 If the m- line in the answer contains a zero port value, the offerer 614 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 615 connection, associated with the m- line. 617 10.5. Modifying the Session 619 When an offerer sends an updated offer, in order to modify a 620 previously established SCTP association, it follows the procedures in 621 Section 10.2, with the following exceptions: 623 o Unless the offerer wants to re-establish an existing SCTP 624 association, the offerer MUST associate an SDP connection 625 attribute, with an 'existing' value, with the m- line; and 627 o If the offerer wants to disable a previously established SCTP 628 association, it MUST assign a zero port value to the m- line 629 associated with the SCTP association, following the procedures in 630 [RFC3264]. 632 11. Multihoming Considerations 634 SCTP supports multihoming. An SCTP endpoint is considered multihomed 635 if it has more than one IP address on which SCTP can be used. An 636 SCTP endpoint inform the remote peer about its IP addresses using the 637 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 638 is used to describe an SCTP association, while the "c=" line contains 639 the address which was used to negotiate the SCTP association, 640 multihomed SCTP endpoints might end up using other IP addresses. 642 If an endpoint removes the IP address [RFC5061] that it offered in 643 the SDP "c=" line associated with the SCTP association, it MUST send 644 a new Offer, in which the "c=" line contains an IP address which is 645 valid within the SCTP association. 647 NOTE: In some network environments, intermediaries performing gate- 648 and firewall control using the address information in the SDP "c=" 649 and "m=" lines to authorize media, and will not pass media sent using 650 other addresses. In such network environments, if an SCTP endpoints 651 wants to change the address information on which media is sent and 652 received, it needs to send an updated Offer, in which the SDP "c=" 653 and "m=" lines contain the new address information. 655 Multihoming is not supported when sending SCTP on top of DTLS, as 656 DTLS does not expose address management of the underlying transport 657 protocols (UDP or TCP) to its upper layer. 659 12. NAT Considerations 661 12.1. General 663 SCTP features not present in UDP or TCP, including the checksum 664 (CRC32c) value calculated on the whole packet (rather than just the 665 header), and multihoming, introduce new challenges for NAT traversal. 666 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 667 which provides similar features of Network Address and Port 668 Translation (NAPT). 670 Current NATs typically do not support SCTP. [RFC6951] defines a 671 mechanism for sending SCTP on top of UDP, which makes it possible to 672 use SCTP with NATs and firewalls that do not support SCTP. 674 12.2. ICE Considerations 676 At the time of writing this specification, no procedures have been 677 defined for using ICE [RFC5245] together with SCTP as transport layer 678 protocol. Such procedures, including the associated SDP Offer/Answer 679 procedures, are outside the scope of this specification, and might be 680 defined in a future specification. 682 When the transport layer protocol is UDP (in case of an SCTP 683 association on top of a DTLS connection on top of UDP), if ICE is 684 used, the ICE procedures defined in [RFC5245] are used. 686 When the transport layer protocol is TCP (in case of an SCTP 687 association on top of a DTLS connection on top of TCP), if ICE is 688 used, the ICE procedures defined in [RFC6544] are used. 690 Implementations MUST treat all ICE candidate pairs associated with a 691 an SCTP association on top of a DTLS connection as part of the same 692 DTLS connection. Thus, there will only be one DTLS handshake even if 693 there are multiple valid candidate pairs, and shifting from one 694 candidate pair to another will not impact the DTLS connection. If 695 new candidates are added, they will also be part of the same DTLS 696 connection. 698 13. Examples 699 13.1. Establishment of UDP/DTLS/SCTP association 701 SDP Offer: 703 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 704 c=IN IP4 192.0.2.1 705 a=setup:actpass 706 a=connection:new 707 a=sctp-port:5000 708 a=max-message-size:100000 710 - The offerer indicates that the usage of the 711 UDP/DTLS/SCTP association will be as defined 712 for the 'webrtc-datachannel' format value. 713 - The offerer UDP port value is 54111. 714 - The offerer SCTP port value is 5000. 715 - The offerer indicates that it can take either the 716 active or the passive role. 718 SDP Answer: 720 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel 721 c=IN IP4 192.0.2.2 722 a=setup:passive 723 a=sctp-port:6000 724 a=max-message-size:100000 726 - The answerer UDP port value is 64300. 727 - The answerer SCTP port value is 6000. 728 - The answerer takes the passive role. 730 14. Security Considerations 732 [RFC4566] defines general SDP security considerations, while 733 [RFC3264], [RFC4145] and [RFC4572] define security considerations 734 when using the SDP offer/answer mechanism to negotiate media streams. 736 [RFC4960] defines general SCTP security considerations, while 737 [RFC6083] defines security considerations when using DTLS on top of 738 SCTP, and [I-D.ietf-tsvwg-sctp-dtls-encaps] defines security 739 considerations when using SCTP on top of DTLS. 741 This specification does not introduce new security considerations in 742 addition to those defined in the specifications listed above. 744 15. IANA Considerations 746 15.1. New SDP proto values 748 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 749 document.] 751 This document updates the "Session Description Protocol (SDP) 752 Parameters" registry, following the procedures in [RFC4566], by 753 adding the following values to the table in the SDP "proto" field 754 registry: 756 +-------+---------------+-----------+ 757 | Type | SDP Name | Reference | 758 +-------+---------------+-----------+ 759 | proto | SCTP | [RFCXXXX] | 760 | proto | SCTP/DTLS | [RFCXXXX] | 761 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 762 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 763 +-------+---------------+-----------+ 765 Table 1: SDP "proto" field values 767 15.2. New SDP Attributes 769 15.2.1. sctp-port 771 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 772 document.] 774 This document defines a new SDP media-level attribute,'sctp-port', as 775 follows: 777 Attribute name: sctp-port 778 Type of attribute: media 779 Mux category: SPECIAL 780 Subject to charset: No 781 Purpose: Indicate the SCTP port value associated 782 with the SDP Media Description. 783 Appropriate values: Integer 784 Contact name: Christer Holmberg 785 Contact e-mail: christer.holmberg@ericsson.com 786 Reference: RFCXXXX 788 15.2.2. max-message-size 790 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 791 document.] 793 This document defines a new SDP media-level attribute,'max-message- 794 size', as follows: 796 Attribute name: max-message-size 797 Type of attribute: media 798 Mux category: SPECIAL 799 Subject to charset: No 800 Purpose: Indicate the maximum message size that 801 an SCTP endpoint is willing to receive 802 on the SCTP association associated 803 with the SDP Media Description. 804 Appropriate values: Integer 805 Contact name: Christer Holmberg 806 Contact e-mail: christer.holmberg@ericsson.com 807 Reference: RFCXXXX 809 15.3. association-usage Name Registry 811 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 812 document.] 814 This specification creates a new IANA registry, following the 815 procedures in [RFC5226], for the "fmt" namespace associated with the 816 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 817 identifiers. Each "fmt" value describes the usage of an entire SCTP 818 association, including all SCTP streams associated with the SCTP 819 association. 821 NOTE: Usage indication of individual SCTP streams is outside the 822 scope of this specification. 824 The "fmt" value, "association-usage", used with these "proto" is 825 required. It is defined in [Section 4]. 827 As part of this registry, IANA maintains the following information: 829 association-usage name: The identifier of the subprotocol, as will 830 be used as the "fmt" value. 832 association-usage reference: A reference to the document in which 833 the association-usage is defined. 835 association-usage names are to be subject to the "First Come First 836 Served" IANA registration policy [RFC5226]. 838 IANA is asked to add initial values to the registry. 840 |----------------------------------------------------------| 841 | name | Reference | 842 |----------------------------------------------------------| 843 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 844 |----------------------------------------------------------| 846 [RFC EDITOR NOTE: Please hold the publication of this draft 847 until draft-ietf-rtcweb-data-protocol has been published as an RFC. 848 Then, replace the reference to draft-ietf-rtcweb-data-protocol 849 with the RFC number.] 851 Figure 1 853 16. Acknowledgments 855 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 856 Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen 857 and Ari Keranen for their comments and useful feedback. 859 17. Change Log 861 [RFC EDITOR NOTE: Please remove this section when publishing] 863 Changes from draft-ietf-mmusic-sctp-sdp-14 865 o Changes based on WGLC comments from Magnus Westerlund. 867 o - ABNF clarification that token and port are defined in RFC4566. 869 o - Specify 40 as maximum digit character length for the SDP max- 870 message-size value. 872 o - Editorial clarification. 874 o Changes based on discussions at IETF#92. 876 o - Specify that all ICE candidate pairs belong to the same DTLS 877 connection. 879 Changes from draft-ietf-mmusic-sctp-sdp-13 880 o Changes based on comments from Paul Kyzivat. 882 o - Text preventing usage of well-known ports removed. 884 o - Editorial clarification. 886 Changes from draft-ietf-mmusic-sctp-sdp-12 888 o Mux category rules added for new SDP attributes. 890 o Reference to draft-ietf-mmusic-sdp-mux-attributes added. 892 o Changes based on comments from Roman Shpount: 894 o - Specify that fingerprint or setup roles must not be modified, 895 unless underlying transport protocol is also modified. 897 o Changes based on comments from Ari Keranen: 899 o - Editorial corrections. 901 o Changes based on comments from Flemming Andreasen: 903 o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the 904 DTLS connection is established before the SCTP association. 906 o - Clarify that max-message-size value is given in bytes, and that 907 different values can be used per direction. 909 o - Section on fmtp attribute removed. 911 o - Editorial corrections. 913 Changes from draft-ietf-mmusic-sctp-sdp-11 915 o Example added. 917 Changes from draft-ietf-mmusic-sctp-sdp-10 919 o SDP max-message-size attribute added to IANA considerations. 921 o Changes based on comments from Paul Kyzivat: 923 o - Text about max message size removed from fmtp attribute section. 925 Changes from draft-ietf-mmusic-sctp-sdp-09 927 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 928 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 929 transports added. 931 Changes from draft-ietf-mmusic-sctp-sdp-08 933 o Default SCTP port removed: 935 o - Usage of SDP sctp-port attribute mandatory. 937 o SDP max-message-size attribute defined: 939 o - Attribute definition. 941 o - SDP Offer/Answer procedures. 943 o Text about SDP direction attributes added. 945 o Text about TLS role determination added. 947 18. References 949 18.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", BCP 14, RFC 2119, 953 DOI 10.17487/RFC2119, March 1997, 954 . 956 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 957 with Session Description Protocol (SDP)", RFC 3264, 958 DOI 10.17487/RFC3264, June 2002, 959 . 961 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 962 the Session Description Protocol (SDP)", RFC 4145, 963 DOI 10.17487/RFC4145, September 2005, 964 . 966 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 967 Extensions (MIME) Part Four: Registration Procedures", 968 BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, 969 . 971 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 972 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 973 July 2006, . 975 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 976 and RTP Control Protocol (RTCP) Packets over Connection- 977 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 978 2006, . 980 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 981 Transport Layer Security (TLS) Protocol in the Session 982 Description Protocol (SDP)", RFC 4572, 983 DOI 10.17487/RFC4572, July 2006, 984 . 986 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 987 RFC 4960, DOI 10.17487/RFC4960, September 2007, 988 . 990 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 991 Kozuka, "Stream Control Transmission Protocol (SCTP) 992 Dynamic Address Reconfiguration", RFC 5061, 993 DOI 10.17487/RFC5061, September 2007, 994 . 996 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 997 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 998 DOI 10.17487/RFC5226, May 2008, 999 . 1001 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1002 Specifications: ABNF", STD 68, RFC 5234, 1003 DOI 10.17487/RFC5234, January 2008, 1004 . 1006 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1007 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1008 January 2012, . 1010 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1011 Specifications and Registration Procedures", BCP 13, 1012 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1013 . 1015 [I-D.ietf-tsvwg-sctp-dtls-encaps] 1016 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 1017 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 1018 dtls-encaps-09 (work in progress), January 2015. 1020 [I-D.ietf-mmusic-sdp-mux-attributes] 1021 Nandakumar, S., "A Framework for SDP Attributes when 1022 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10 1023 (work in progress), July 2015. 1025 18.2. Informative References 1027 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1028 RFC 793, DOI 10.17487/RFC0793, September 1981, 1029 . 1031 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1032 (ICE): A Protocol for Network Address Translator (NAT) 1033 Traversal for Offer/Answer Protocols", RFC 5245, 1034 DOI 10.17487/RFC5245, April 2010, 1035 . 1037 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1038 for Establishing a Secure Real-time Transport Protocol 1039 (SRTP) Security Context Using Datagram Transport Layer 1040 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1041 2010, . 1043 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 1044 Transport Layer Security (DTLS) for Stream Control 1045 Transmission Protocol (SCTP)", RFC 6083, 1046 DOI 10.17487/RFC6083, January 2011, 1047 . 1049 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1050 "TCP Candidates with Interactive Connectivity 1051 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 1052 March 2012, . 1054 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1055 Control Transmission Protocol (SCTP) Packets for End-Host 1056 to End-Host Communication", RFC 6951, 1057 DOI 10.17487/RFC6951, May 2013, 1058 . 1060 [I-D.ietf-behave-sctpnat] 1061 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1062 Transmission Protocol (SCTP) Network Address Translation", 1063 draft-ietf-behave-sctpnat-09 (work in progress), September 1064 2013. 1066 Authors' Addresses 1068 Christer Holmberg 1069 Ericsson 1070 Hirsalantie 11 1071 Jorvas 02420 1072 Finland 1074 Email: christer.holmberg@ericsson.com 1076 Salvatore Loreto 1077 Ericsson 1078 Hirsalantie 11 1079 Jorvas 02420 1080 Finland 1082 Email: Salvatore.Loreto@ericsson.com 1084 Gonzalo Camarillo 1085 Ericsson 1086 Hirsalantie 11 1087 Jorvas 02420 1088 Finland 1090 Email: Gonzalo.Camarillo@ericsson.com