idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-14.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 (March 5, 2015) is 3341 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 744, but not defined == Missing Reference: 'Section 4' is mentioned on line 807, but not defined == Unused Reference: 'RFC5246' is defined on line 960, but no explicit reference was found in the text ** 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-08 -- 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: 6 errors (**), 0 flaws (~~), 6 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: September 6, 2015 Ericsson 6 March 5, 2015 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-14 12 Abstract 14 SCTP (Stream Control Transmission Protocol) is a transport protocol 15 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 September 6, 2015. 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 . . . . . . . . . . . . . . . . . . 6 73 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 7 76 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 7 77 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 6.3. Mux Category . . . . . . . . . . . . . . . . . . . . . . 8 80 7. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 8 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 . . . . 9 85 9.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . . 9 86 9.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 13 96 11. Multihoming Considerations . . . . . . . . . . . . . . . . . 14 97 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 14 98 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14 99 12.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 15 100 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 13.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 22 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 SCTP (Stream Control Transmission Protocol) [RFC4960] is a transport 128 protocol used to establish associations between two endpoints. 130 This specification defines how to describe SCTP associations using 131 the Session Description Protocol (SDP) [RFC4566], and defines the 132 following new SDP Media Description [RFC4566] protocol identifiers 133 (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 134 SCTP'. 136 The specification also describes how to use the new proto values 137 together with the SDP Offer/Answer mechanism [RFC3264] in order to 138 negotiate and establish SCTP associations, and how to indicate the 139 SCTP application usage. 141 NOTE: TLS is designed to run on top of a byte-stream oriented 142 transport protocol providing a reliable, in-sequence delivery like 143 TCP. [RFC6083] presents serious limitations with transporting SCTP 144 on top of TLS. Therefore, defining a mechanism to negotiate media 145 streams transported using SCTP on top of TLS is outside the scope of 146 this specification. 148 2. Terminology 150 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 151 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 152 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 153 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 154 levels for compliant implementations. 156 3. SCTP Terminology 158 SCTP Association: A protocol relationship between SCTP endpoints, 159 composed of the two SCTP endpoints and protocol state information 160 including Verification Tags and the currently active set of 161 Transmission Sequence Numbers (TSNs), etc. An association can be 162 uniquely identified by the transport addresses used by the endpoints 163 in the association. 165 SCTP Stream: A unidirectional logical channel established from one to 166 another associated SCTP endpoint, within which all user messages are 167 delivered in sequence except for those submitted to the unordered 168 delivery service. 170 SCTP Transport address: A transport address is traditionally defined 171 by a network-layer address, a transport-layer protocol, and a 172 transport-layer port number. In the case of SCTP running over IP, a 173 transport address is defined by the combination of an IP address and 174 an SCTP port number (where SCTP is the transport protocol). 176 4. SDP Media Descriptions 178 4.1. General 180 This section defines the following new SDP Media Description (m- 181 line) protocol identifiers (proto values) for describing an SCTP 182 association: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 183 SCTP'. The section also describes how an m- line, associated with 184 the proto values, is created. 186 The following is the format for an 'm' line, as specified in RFC4566 187 [RFC4566]: 189 m= ... 191 The 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 192 values are similar to both the 'UDP' and 'TCP' proto values in that 193 they only describe the transport-layer protocol and not the upper- 194 layer protocol. 196 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are 197 used, the underlying transport protocol is respectively UDP and TCP; 198 SCTP is carried on top of DTLS which is on top of those transport- 199 layer protocols. 201 The m- line fmt value, identifying the application-layer protocol, 202 MUST be registered by IANA. 204 4.2. Protocol Identifiers 206 The new proto values are defined as below: 208 o The 'SCTP' proto value describes an SCTP association, as defined 209 in [RFC4960]. 211 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 212 Security (DTLS) [RFC6347] connection on top of an SCTP 213 association, as defined in [RFC6083]. 215 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 216 top of a DTLS connection on top of UDP, as defined in Section 7. 218 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 219 top of a DTLS connection on top of TCP, as defined in Section 8. 221 4.3. Media Format Management 223 [RFC4566] defines that specifications defining new proto values must 224 define the rules by which their media format (fmt) namespace is 225 managed. Use of an existing MIME subtype for the format is 226 encouraged. If no MIME subtype exists, it is recommended that a 227 suitable one is registered through the IETF process [RFC6838] 228 [RFC4289] by production of, or reference to, a standards-track RFC 229 that defines the transport protocol for the format. 231 An m- line with a proto value of 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' 232 or 'TCP/DTLS/SCTP' always describe a single SCTP association. 234 In addition, such m- line MUST further indicate the application-layer 235 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 236 value per m- line associated with the proto values defined in this 237 specification. The "fmt" namespace associated with those proto 238 values describes the generic application usage of the entire SCTP 239 association, including the associated SCTP streams. 241 NOTE: A mechanism on how to describe, and manage, individual SCTP 242 streams within an SCTP association, is outside the scope of this 243 specification. 245 4.4. Syntax 247 4.4.1. General 249 This section defines the ABNF [RFC5234] for the SDP media description 250 when associated with any of the proto values defined in this 251 document. 253 This specification creates an IANA registry for 'association-usage' 254 values. 256 4.4.2. ABNF 258 sctp-m-line = %x6d "=" 259 ("application" SP sctp-port SP "SCTP" SP fmt CRLF) / 260 ("application" SP sctp-port SP "SCTP/DTLS" SP fmt CRLF) / 261 ("application" SP udp-port SP "UDP/DTLS/SCTP" SP fmt CRLF) / 262 ("application" SP tcp-port SP "TCP/DTLS/SCTP" SP fmt CRLF) 264 sctp-port = port 266 udp-port = port 268 tcp-port = port 270 fmt = association-usage 272 association-usage = token 274 4.5. Example 276 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 277 a=max-message-size: 100000 279 5. SDP 'sctp-port' Attribute 281 5.1. General 283 This section defines a new SDP media-level attribute, 'sctp-port'. 284 The attribute can be associated with an SDP media description (m- 285 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in 286 which case the m- line port value indicates the port of the 287 underlying transport-layer protocol (UDP or TCP), on which SCTP is 288 carried, and the 'sctp-port' value indicates the SCTP port. 290 No default value is defined for the SDP sctp-port attribute. 291 Therefore, if the attribute is not present, the associated m- line 292 MUST be considered invalid. 294 Usage of the SDP sctp-port attribute with other proto values is not 295 specified, and MUST be discarded if received. 297 5.2. Syntax 299 The ABNF for the SDP 'sctp-port' attribute is: 301 sctp-port-attr = "a=sctp-port:" port 302 port = (1*5)DIGIT 304 The SCTP port range is between 0 and 65535 (both included). 305 Leading zeroes MUST NOT be used. 307 5.3. Mux Category 309 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the SDP 310 sctp-port' attribute is SPECIAL. Usage of the attribute is only 311 applicable when associated with 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 312 proto value m- lines. 314 As the usage of multiple SCTP associations on top of a single DTLS 315 connection is outside the scope of this specification, no mux rules 316 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 317 values. Future extensions, that define how to negotiate multiplexing 318 of multiple SCTP associations of top of a single DTLS connection, 319 need to also define the mux rules for the attribute. 321 6. SDP 'max-message-size' Attribute 323 6.1. General 325 This section defines a new SDP media-level attribute, 'max-message- 326 size'. The attribute can be associated with an m- line to indicate 327 the maximum message size (indicated in bytes) that an SCTP endpoint 328 is willing to receive on the SCTP association associated with the m- 329 line. Different attribute values can be used in each direction. 331 The remote peer MUST assume that larger messages will be rejected by 332 the SCTP endpoint. SCTP endpoints need to decide on appropriate 333 behavior in case a message that exceeds the maximum size needs to be 334 sent. 336 If the SDP 'max-message-size' attribute contains a maximum message 337 size value of zero, it indicates the SCTP endpoint will handle 338 messages of any size, subject to memory capacity etc. 340 If the SDP 'max-message-size' attribute is not present, the default 341 value is 64K. 343 NOTE: This specification only defines the usage of the SDP 'max- 344 message-size' attribute when associated with an m- line containing 345 one of the following proto values: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/ 346 SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto 347 values needs to be defined in a separate specification. 349 6.2. Syntax 351 The ABNF for the SDP 'max-message-size' attribute is: 353 max-message-size-attr = "a=max-message-size:" max-message-size 354 max-message-size = 1*DIGIT 356 Leading zeroes MUST NOT be used. 358 6.3. Mux Category 360 The mux category for the SDP 'max-message-size' attribute is SPECIAL. 361 The mux rules depends on the proto value of the associated m- line. 362 If the proto value is 'SCTP' or 'SCTP/DTLS' the rules are identical 363 to the rules associated with the TRANSPORT mux category. 365 As the usage of multiple SCTP associations on top of a single DTLS 366 connection is outside the scope of this specification, no mux rules 367 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 368 values. 370 7. UDP/DTLS/SCTP Transport Realization 372 The UDP/DTLS/SCTP transport is realized as described below: 374 o SCTP on top of DTLS is realized according to the procedures 375 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 377 o DTLS on top of UDP is realized according to the procedures in 378 defined in [RFC6347]. 380 NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP 381 associations on top of a single DTLS connection, the procedures in 382 this specification only supports the negotiation of a single SCTP 383 association on top of any given DTLS connection. 385 8. TCP/DTLS/SCTP Transport Realization 387 The TCP/DTLS/SCTP transport is realized as described below: 389 o SCTP on top of DTLS is realized according to the procedures 390 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 392 o DTLS on top of TCP is realized using the framing method defined in 393 [RFC4571], with DTLS packets being sent instead of RTP/RTCP 394 packets, and SDP signaling according to the procedures defined in 395 this specification. 397 NOTE: DTLS on top of TCP, without using the framing method defined in 398 [RFC4571] is outside the scope of this specification. A separate 399 proto value would need to be registered for such transport 400 realization. 402 9. SCTP Association Management 404 9.1. General 406 The management of an SCTP association is identical to the management 407 of a TCP connection. An SCTP endpoint MUST follow the rules in 408 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 409 the SCTP ordered or unordered delivery service is up to the 410 applications using the SCTP association, and this specification does 411 not define a mechanism to indicate the type of delivery service using 412 SDP. 414 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute 416 This specification does not define semantics for the SDP direction 417 attributes [RFC4566]. Unless semantics of these attributes for an 418 SCTP association usage have been defined, SDP direction attributes 419 MUST be discarded if present. 421 9.3. SDP setup Attribute 423 9.3.1. General 425 The SDP setup attribute is used to determine the 'active/passive' 426 status of the endpoints, following the procedures for TCP in 427 [RFC4145]. 429 9.3.2. SCTP Association Initiation 431 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 432 association, and MUST use the same SCTP port as client port and 433 server port (in order to prevent two separate SCTP associations from 434 being established). 436 NOTE: The procedure above is different from TCP, where only the 437 'active' endpoint initiates the TCP connection [RFC4145]. 439 NOTE: If the underlying transport protocol is UDP or TCP (e.g. if the 440 m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'), when the 441 SCTP association is established it is assumed that any NAT traversal 442 procedures for the underlying transport protocol has successfully 443 been performed. 445 If the m- line proto value is 'TCP/DTLS/SCTP', the 'active' endpoint 446 only MUST initiate the TCP connection, following the procedures in 447 [RFC4145]. Both endpoints MUST still initiate the SCTP association 448 on top of the TCP connection. 450 9.3.3. TLS Role Determination 452 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 453 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 454 (D)TLS roles of the endpoints. Following the procedures in 455 [RFC4572], the 'active' endpoint will take the (D)TLS client role. 457 Once the DTLS connection has been established, the endpoints MUST NOT 458 modify (as result of an offer/answer exchange) the TLS roles, or the 459 'active/passive' status, of the endpoints, unless the underlying 460 transport protocol is also modified (e.g. if an IP address- or port 461 value associated with the transport protocol is modified). 463 If the underlying transport protocol is modified, the endpoints MUST 464 establish a new DTLS connection. In such case the 'active/passive' 465 status of the endpoints will again be determined following the 466 procedures in [RFC4145], and the new status will be used to determine 467 the (D)TLS roles of the endpoints associated with the new DTLS 468 connection. 470 NOTE: The procedure above is identical to the one defined for SRTP- 471 DTLS in [RFC5763]. 473 9.4. SDP connection Attribute 475 The SDP connection attribute is used following the procedures in 476 [RFC4145], with the additional SCTP specific considerations described 477 in this section. 479 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 480 attribute associated with that m- line applies to both the SCTP 481 association and the TCP connection. Therefore, an attribute 'new' 482 value indicates that both a new SCTP association and new TCP 483 connection have to be established, following the procedures in 484 [RFC4145]. 486 NOTE: This specification does not define a mechanism which allows re- 487 establishing of a new SCTP association, while maintaining the 488 underlying TCP connection. 490 The SDP connection attribute value does not automatically impact an 491 existing DTLS connection. Section 9.3.3 describes in which cases a 492 new DTLS connections will have to be re-established. 494 10. SDP Offer/Answer Procedures 496 10.1. General 498 This section defines the SDP Offer/Answer [RFC3264] procedures for 499 negotiating and establishing an SCTP association. Unless explicitly 500 stated, the procedures apply to all m- line proto values ('SCTP', 501 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 502 specification. 504 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 505 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 506 fingerprint, using the SDP 'fingerprint' attribute [RFC4572], if the 507 endpoint supports, and is willing to use, a cipher suite with an 508 associated certificate. 510 The authentication certificates are interpreted and validated as 511 defined in [RFC4572]. Self-signed certificates can be used securely, 512 provided that the integrity of the SDP description is assured as 513 defined in [RFC4572]. 515 NOTE: The procedures apply to a specific m- line describing an SCTP 516 association. If an offer or answer contains multiple m- lines 517 describing SCTP associations, the procedures are applied separately 518 to each m- line. 520 10.2. Generating the Initial SDP Offer 522 When the offerer creates an initial offer, the offerer: 524 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 525 or 'TCP/DTLS/SCTP', associate an SDP setup attribute, with an 526 'actpass' value, with the m- line (see Section 9.3); 528 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 529 associate an SDP 'sctp-port' attribute with the m- line (see 530 Section 5); 532 o MUST associate an SDP 'connection' attribute, with a 'new' value, 533 with the m- line (see Section 9.4); and 535 o MAY associate an SDP 'max-message-size' attribute with the m- line 536 (see Section 6). 538 10.3. Generating the SDP Answer 540 When the answerer receives an offer, which contains an m- line 541 describing an SCTP association, if the answerer accepts the m- line 542 it: 544 o MUST insert a corresponding m- line in the answer, with an 545 identical m- line proto value [RFC3264]; 547 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 548 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute, with an 549 'active' or 'passive' value, with the m- line (see Section 9.3); 551 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 552 associate an SDP 'sctp-port' attribute with the m- line (see 553 Section 5); and 555 o MAY associate an SDP 'max-message-size' attribute with the m- line 556 (see Section 6). The attribute value in the answer is independent 557 from the value (if present) in the corresponding m- line of the 558 offer. 560 Once the answerer has sent the answer, the answerer: 562 o MUST, if an SCTP association associated with the m- line has yet 563 not been established, or if an existing SCTP association is to be 564 re-established, initiate the establishing of the SCTP association; 565 and 567 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 568 connection associated with the m- line is to be established (or 569 re-established), initiate the establishing of the DTLS connection 570 (by sending a ClientHello message). 572 If the answerer does not accept the m- line in the offer, it MUST 573 assign a zero port value to the corresponding m- line in the answer. 574 In addition, the answerer MUST NOT establish an SCTP association, or 575 a DTLS connection, associated with the m- line. 577 10.4. Offerer Processing of the SDP Answer 579 When the offerer receives an answer, which contains an m- line with a 580 non-zero port value, describing an SCTP association, the offerer: 582 o MUST, if the offerer is the 'active' endpoint, if the m- line 583 proto value is 'TCP/DTLS/SCTP', and if a TCP connection used to 584 carry the SCTP association has not yet been established (or if an 585 existing TCP connection is to be re-established), initiate the 586 establishing of the TCP connection; 588 o MUST, if an SCTP association associated with the m- line has not 589 yet been established (or if an existing SCTP association is to be 590 re-established), initiate the establishing of the SCTP 591 association; and 593 o MUST, if the offerer is the 'active' endpoint, and if a DTLS 594 connection associated with the m- line is to be established (or if 595 an existing DTLS connection is to be re-established), initiate the 596 establishing of the DTLS connection (by sending a ClientHello 597 message). 599 o NOTE: If the m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/ 600 SCTP', the underlying DTLS connection needs to be established 601 before the SCTP association can be established. 603 If the m- line in the answer contains a zero port value, the offerer 604 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 605 connection, associated with the m- line. 607 10.5. Modifying the Session 609 When an offerer sends an updated offer, in order to modify a 610 previously established SCTP association, it follows the procedures in 611 Section 10.2, with the following exceptions: 613 o Unless the offerer wants to re-establish an existing SCTP 614 association, the offerer MUST associate an SDP connection 615 attribute, with an 'existing' value, with the m- line; and 617 o If the offerer wants to disable a previously established SCTP 618 association, it MUST assign a zero port value to the m- line 619 associated with the SCTP association, following the procedures in 620 [RFC3264]. 622 11. Multihoming Considerations 624 SCTP supports multihoming. An SCTP endpoint is considered multihomed 625 if it has more than one IP address on which SCTP can be used. An 626 SCTP endpoint inform the remote peer about its IP addresses using the 627 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 628 is used to describe an SCTP association, while the "c=" line contains 629 the address which was used to negotiate the SCTP association, 630 multihomed SCTP endpoints might end up using other IP addresses. 632 If an endpoint removes the IP address [RFC5061] that it offered in 633 the SDP "c=" line associated with the SCTP association, it MUST send 634 a new Offer, in which the "c=" line contains an IP address which is 635 valid within the SCTP association. 637 NOTE: In some network environments, intermediaries performing gate- 638 and firewall control using the address information in the SDP "c=" 639 and "m=" lines to authorize media, and will not pass media sent using 640 other addresses. In such network environments, if an SCTP endpoints 641 wants to change the address information on which media is sent and 642 received, it needs to send an updated Offer, in which the SDP "c=" 643 and "m=" lines contain the new address information. 645 Multihoming is not supported when sending SCTP on top of DTLS, as 646 DTLS does not expose address management of the underlying transport 647 protocols (UDP or TCP) to its upper layer. 649 12. NAT Considerations 651 12.1. General 653 SCTP features not present in UDP or TCP, including the checksum 654 (CRC32c) value calculated on the whole packet (rather than just the 655 header), and multihoming, introduce new challenges for NAT traversal. 656 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 657 which provides similar features of Network Address and Port 658 Translation (NAPT). 660 Current NATs typically do not support SCTP. [RFC6951] defines a 661 mechanism for sending SCTP on top of UDP, which makes it possible to 662 use SCTP with NATs and firewalls that do not support SCTP. 664 12.2. ICE Considerations 666 At the time of writing this specification, no procedures have been 667 defined for using ICE (Interactive Connectivity Establishment) 668 [RFC5245] together with SCTP as transport layer protocol. Such 669 procedures, including the associated SDP Offer/Answer procedures, are 670 outside the scope of this specification, and might be defined in a 671 future specification. 673 When the transport layer protocol is UDP (in case of an SCTP 674 association on top of a DTLS connection on top of UDP), if ICE is 675 used, the ICE procedures defined in [RFC5245] are used. 677 When the transport layer protocol is TCP (in case of an SCTP 678 association on top of a DTLS connection on top of TCP), if ICE is 679 used, the ICE procedures defined in [RFC6544] are used. 681 13. Examples 683 13.1. Establishment of UDP/DTLS/SCTP association 684 SDP Offer: 686 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 687 c=IN IP4 192.0.2.1 688 a=setup:actpass 689 a=connection:new 690 a=sctp-port:5000 691 a=max-message-size:100000 693 - The offerer indicates that the usage of the 694 UDP/DTLS/SCTP association will be as defined 695 for the 'webrtc-datachannel' format value. 696 - The offerer UDP port value is 54111. 697 - The offerer SCTP port value is 5000. 698 - The offerer indicates that it can take either the 699 active or the passive role. 701 SDP Answer: 703 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel 704 c=IN IP4 192.0.2.2 705 a=setup:passive 706 a=sctp-port:6000 707 a=max-message-size:100000 709 - The answerer UDP port value is 64300. 710 - The answerer SCTP port value is 6000. 711 - The answerer takes the passive role. 713 14. Security Considerations 715 [RFC4566] defines general SDP security considerations, while 716 [RFC3264], [RFC4145] and [RFC4572] define security considerations 717 when using the SDP offer/answer mechanism to negotiate media streams. 719 [RFC4960] defines general SCTP security considerations, while 720 [RFC6083] defines security considerations when using DTLS on top of 721 SCTP. 723 This specification does not introduce new security considerations in 724 addition to those defined in the specifications listed above. 726 15. IANA Considerations 728 15.1. New SDP proto values 730 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 731 document.] 733 This document updates the "Session Description Protocol (SDP) 734 Parameters" registry, following the procedures in [RFC4566], by 735 adding the following values to the table in the SDP "proto" field 736 registry: 738 +-------+---------------+-----------+ 739 | Type | SDP Name | Reference | 740 +-------+---------------+-----------+ 741 | proto | SCTP | [RFCXXXX] | 742 | proto | SCTP/DTLS | [RFCXXXX] | 743 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 744 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 745 +-------+---------------+-----------+ 747 Table 1: SDP "proto" field values 749 15.2. New SDP Attributes 751 15.2.1. sctp-port 753 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 754 document.] 756 This document defines a new SDP media-level attribute,'sctp-port', as 757 follows: 759 Attribute name: sctp-port 760 Type of attribute: media 761 Mux category: SPECIAL 762 Subject to charset: No 763 Purpose: Indicate the SCTP port value associated 764 with the SDP Media Description. 765 Appropriate values: Integer 766 Contact name: Christer Holmberg 767 Contact e-mail: christer.holmberg@ericsson.com 768 Reference: RFCXXXX 770 15.2.2. max-message-size 772 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 773 document.] 775 This document defines a new SDP media-level attribute,'max-message- 776 size', as follows: 778 Attribute name: max-message-size 779 Type of attribute: media 780 Mux category: SPECIAL 781 Subject to charset: No 782 Purpose: Indicate the maximum message size that 783 an SCTP endpoint is willing to receive 784 on the SCTP association associated 785 with the SDP Media Description. 786 Appropriate values: Integer 787 Contact name: Christer Holmberg 788 Contact e-mail: christer.holmberg@ericsson.com 789 Reference: RFCXXXX 791 15.3. association-usage Name Registry 793 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 794 document.] 796 This specification creates a new IANA registry, following the 797 procedures in [RFC5226], for the "fmt" namespace associated with the 798 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 799 identifiers. Each "fmt" value describes the usage of an entire SCTP 800 association, including all SCTP streams associated with the SCTP 801 association. 803 NOTE: Usage indication of individual SCTP streams is outside the 804 scope of this specification. 806 The "fmt" value, "association-usage", used with these "proto" is 807 required. It is defined in [Section 4]. 809 As part of this registry, IANA maintains the following information: 811 association-usage name: The identifier of the subprotocol, as will 812 be used as the "fmt" value. 814 association-usage reference: A reference to the document in which 815 the association-usage is defined. 817 association-usage names are to be subject to the "First Come First 818 Served" IANA registration policy [RFC5226]. 820 IANA is asked to add initial values to the registry. 822 |----------------------------------------------------------| 823 | name | Reference | 824 |----------------------------------------------------------| 825 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 826 |----------------------------------------------------------| 828 [RFC EDITOR NOTE: Please hold the publication of this draft 829 until draft-ietf-rtcweb-data-protocol has been published as an RFC. 830 Then, replace the reference to draft-ietf-rtcweb-data-protocol 831 with the RFC number.] 833 Figure 1 835 16. Acknowledgments 837 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 838 Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen 839 and Ari Keranen for their comments and useful feedback. 841 17. Change Log 843 [RFC EDITOR NOTE: Please remove this section when publishing] 845 Changes from draft-ietf-mmusic-sctp-sdp-13 847 o Changes based on comments from Paul Kyzivat. 849 o - Text preventing usage of well-known ports removed. 851 o - Editorial clarification. 853 Changes from draft-ietf-mmusic-sctp-sdp-12 855 o Mux category rules added for new SDP attributes. 857 o Reference to draft-ietf-mmusic-sdp-mux-attributes added. 859 o Changes based on comments from Roman Shpount: 861 o - Specify that fingerprint or setup roles must not be modified, 862 unless underlying transport protocol is also modified. 864 o Changes based on comments from Ari Keranen: 866 o - Editorial corrections. 868 o Changes based on comments from Flemming Andreasen: 870 o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the 871 DTLS connection is established before the SCTP association. 873 o - Clarify that max-message-size value is given in bytes, and that 874 different values can be used per direction. 876 o - Section on fmtp attribute removed. 878 o - Editorial corrections. 880 Changes from draft-ietf-mmusic-sctp-sdp-11 882 o Example added. 884 Changes from draft-ietf-mmusic-sctp-sdp-10 886 o SDP max-message-size attribute added to IANA considerations. 888 o Changes based on comments from Paul Kyzivat: 890 o - Text about max message size removed from fmtp attribute section. 892 Changes from draft-ietf-mmusic-sctp-sdp-09 894 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 896 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 897 transports added. 899 Changes from draft-ietf-mmusic-sctp-sdp-08 901 o Default SCTP port removed: 903 o - Usage of SDP sctp-port attribute mandatory. 905 o SDP max-message-size attribute defined: 907 o - Attribute definition. 909 o - SDP Offer/Answer procedures. 911 o Text about SDP direction attributes added. 913 o Text about TLS role determination added. 915 18. References 917 18.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, March 1997. 922 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 923 with Session Description Protocol (SDP)", RFC 3264, June 924 2002. 926 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 927 the Session Description Protocol (SDP)", RFC 4145, 928 September 2005. 930 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 931 Extensions (MIME) Part Four: Registration Procedures", BCP 932 13, RFC 4289, December 2005. 934 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 935 Description Protocol", RFC 4566, July 2006. 937 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 938 and RTP Control Protocol (RTCP) Packets over Connection- 939 Oriented Transport", RFC 4571, July 2006. 941 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 942 Transport Layer Security (TLS) Protocol in the Session 943 Description Protocol (SDP)", RFC 4572, July 2006. 945 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 946 4960, September 2007. 948 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 949 Kozuka, "Stream Control Transmission Protocol (SCTP) 950 Dynamic Address Reconfiguration", RFC 5061, September 951 2007. 953 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 954 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 955 May 2008. 957 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 958 Specifications: ABNF", STD 68, RFC 5234, January 2008. 960 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 961 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 963 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 964 Security Version 1.2", RFC 6347, January 2012. 966 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 967 Specifications and Registration Procedures", BCP 13, RFC 968 6838, January 2013. 970 [I-D.ietf-tsvwg-sctp-dtls-encaps] 971 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 972 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 973 dtls-encaps-09 (work in progress), January 2015. 975 [I-D.ietf-mmusic-sdp-mux-attributes] 976 Nandakumar, S., "A Framework for SDP Attributes when 977 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 978 (work in progress), January 2015. 980 18.2. Informative References 982 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 983 793, September 1981. 985 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 986 (ICE): A Protocol for Network Address Translator (NAT) 987 Traversal for Offer/Answer Protocols", RFC 5245, April 988 2010. 990 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 991 for Establishing a Secure Real-time Transport Protocol 992 (SRTP) Security Context Using Datagram Transport Layer 993 Security (DTLS)", RFC 5763, May 2010. 995 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 996 Transport Layer Security (DTLS) for Stream Control 997 Transmission Protocol (SCTP)", RFC 6083, January 2011. 999 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 1000 "TCP Candidates with Interactive Connectivity 1001 Establishment (ICE)", RFC 6544, March 2012. 1003 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 1004 Control Transmission Protocol (SCTP) Packets for End-Host 1005 to End-Host Communication", RFC 6951, May 2013. 1007 [I-D.ietf-behave-sctpnat] 1008 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1009 Transmission Protocol (SCTP) Network Address Translation", 1010 draft-ietf-behave-sctpnat-09 (work in progress), September 1011 2013. 1013 Authors' Addresses 1015 Christer Holmberg 1016 Ericsson 1017 Hirsalantie 11 1018 Jorvas 02420 1019 Finland 1021 Email: christer.holmberg@ericsson.com 1023 Salvatore Loreto 1024 Ericsson 1025 Hirsalantie 11 1026 Jorvas 02420 1027 Finland 1029 Email: Salvatore.Loreto@ericsson.com 1031 Gonzalo Camarillo 1032 Ericsson 1033 Hirsalantie 11 1034 Jorvas 02420 1035 Finland 1037 Email: Gonzalo.Camarillo@ericsson.com