idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-13.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 14 characters in excess of 72. -- 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 4, 2015) is 3312 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 746, but not defined == Missing Reference: 'Section 4' is mentioned on line 809, but not defined == Unused Reference: 'RFC5246' is defined on line 954, 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: 7 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 5, 2015 Ericsson 6 March 4, 2015 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-13 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 5, 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14 98 12.1. General . . . . . . . . . . . . . . . . . . . . . . . . 15 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 Applications MUST NOT use well-known port values, or port 306 values that have been registered for specific purposes. 307 Leading zeroes MUST NOT be used. 309 5.3. Mux Category 311 The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the SDP 312 sctp-port' attribute is SPECIAL. Usage of the attribute is only 313 applicable when associated with 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 314 proto value m- lines. 316 As the usage of multiple SCTP associations on top of a single DTLS 317 connection is outside the scope of this specification, no mux rules 318 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 319 values. Future extensions, that define how to negotiate multiplexing 320 of multiple SCTP associations of top of a single DTLS connection, 321 need to also define the mux rules for the attribute. 323 6. SDP 'max-message-size' Attribute 325 6.1. General 327 This section defines a new SDP media-level attribute, 'max-message- 328 size'. The attribute can be associated with an m- line to indicate 329 the maximum message size (indicated in bytes) that an SCTP endpoint 330 is willing to receive on the SCTP association associated with the m- 331 line. Different attribute values can be used in each direction. 333 The remote peer MUST assume that larger messages will be rejected by 334 the SCTP endpoint. SCTP endpoints need to decide on appropriate 335 behavior in case a message that exceeds the maximum size needs to be 336 sent. 338 If the SDP 'max-message-size' attribute contains a maximum message 339 size value of zero, it indicates the SCTP endpoint will handle 340 messages of any size, subject to memory capacity etc. 342 If the SDP 'max-message-size' attribute is not present, the default 343 value is 64K. 345 NOTE: This specification only defines the usage of the SDP 'max- 346 message-size' attribute when associated with an m- line containing 347 one of the following proto values: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/ 348 SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto 349 values needs to be defined in a separate specification. 351 6.2. Syntax 353 The ABNF for the SDP 'max-message-size' attribute is: 355 max-message-size-attr = "a=max-message-size:" max-message-size 356 max-message-size = 1*DIGIT 358 Leading zeroes MUST NOT be used. 360 6.3. Mux Category 362 The mux category for the SDP 'max-message-size' attribute is SPECIAL. 363 The mux rules depends on the proto value of the associated m- line. 364 If the proto value is 'SCTP' or 'SCTP/DTLS' the rules are identical 365 to the rules associated with the TRANSPORT mux category. 367 As the usage of multiple SCTP associations on top of a single DTLS 368 connection is outside the scope of this specification, no mux rules 369 are specified for the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 370 values. 372 7. UDP/DTLS/SCTP Transport Realization 374 The UDP/DTLS/SCTP transport is realized as described below: 376 o SCTP on top of DTLS is realized according to the procedures 377 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 379 o DTLS on top of UDP is realized according to the procedures in 380 defined in [RFC6347]. 382 NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP 383 associations on top of a single DTLS connection, the procedures in 384 this specification only supports the negotiation of a single SCTP 385 association on top of any given DTLS connection. 387 8. TCP/DTLS/SCTP Transport Realization 389 The TCP/DTLS/SCTP transport is realized as described below: 391 o SCTP on top of DTLS is realized according to the procedures 392 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 394 o DTLS on top of TCP is realized using the framing method defined in 395 [RFC4571], with DTLS packets being sent instead of RTP/RTCP 396 packets, and SDP signaling according to the procedures defined in 397 this specification. 399 NOTE: DTLS on top of TCP, without using the framing method defined in 400 [RFC4571] is outside the scope of this specification. A separate 401 proto value would need to be registered for such transport 402 realization. 404 9. SCTP Association Management 406 9.1. General 408 The management of an SCTP association is identical to the management 409 of a TCP connection. An SCTP endpoint MUST follow the rules in 410 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 411 the SCTP ordered or unordered delivery service is up to the 412 applications using the SCTP association, and this specification does 413 not define a mechanism to indicate the type of delivery service using 414 SDP. 416 9.2. SDP sendrecv/sendonly/recvonly/inactive Attribute 418 This specification does not define semantics for the SDP direction 419 attributes [RFC4566]. Unless semantics of these attributes for an 420 SCTP association usage have been defined, SDP direction attributes 421 MUST be discarded if present. 423 9.3. SDP setup Attribute 425 9.3.1. General 427 The SDP setup attribute is used to determine the 'active/passive' 428 status of the endpoints, following the procedures for TCP in 429 [RFC4145]. 431 9.3.2. SCTP Association Initiation 433 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 434 association, and MUST use the same SCTP port as client port and 435 server port (in order to prevent two separate SCTP associations from 436 being established). 438 NOTE: The procedure above is different from TCP, where only the 439 'active' endpoint initiates the TCP connection [RFC4145]. 441 NOTE: If the underlying transport protocol is UDP or TCP (e.g. if the 442 m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'), when the 443 SCTP association is established it is assumed that any NAT traversal 444 procedures for the underlying transport protocol has successfully 445 been performed. 447 If the m- line proto value is 'TCP/DTLS/SCTP', the 'active' endpoint 448 only MUST initiate the TCP connection, following the procedures in 449 [RFC4145]. Both endpoints MUST still initiate the SCTP association 450 on top of the TCP connection. 452 9.3.3. TLS Role Determination 454 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 455 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 456 (D)TLS roles of the endpoints. Following the procedures in 457 [RFC4572], the 'active' endpoint will take the (D)TLS client role. 459 Once the DTLS connection has been established, the endpoints MUST NOT 460 modify (as result of an offer/answer exchange) the TLS roles, or the 461 'active/passive' status, of the endpoints, unless the underlying 462 transport protocol is also modified (e.g. if an IP address- or port 463 value associated with the transport protocol is modified). 465 If the underlying transport protocol is modified, the endpoints MUST 466 establish a new DTLS connection. In such case the 'active/passive' 467 status of the endpoints will again be determined following the 468 procedures in [RFC4145], and the new status will be used to determine 469 the (D)TLS roles of the endpoints associated with the new DTLS 470 connection. 472 NOTE: The procedure above is identical to the one defined for SRTP- 473 DTLS in [RFC5763]. 475 9.4. SDP connection Attribute 477 The SDP connection attribute is used following the procedures in 478 [RFC4145], with the additional SCTP specific considerations described 479 in this section. 481 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 482 attribute associated with that m- line applies to both the SCTP 483 association and the TCP connection. Therefore, an attribute 'new' 484 value indicates that both a new SCTP association and new TCP 485 connection have to be established, following the procedures in 486 [RFC4145]. 488 NOTE: This specification does not define a mechanism which allows re- 489 establishing of a new SCTP association, while maintaining the 490 underlying TCP connection. 492 The SDP connection attribute value does not automatically impact an 493 existing DTLS connection. Section 9.3.3 describes in which cases a 494 new DTLS connections will have to be re-established. 496 10. SDP Offer/Answer Procedures 498 10.1. General 500 This section defines the SDP Offer/Answer [RFC3264] procedures for 501 negotiating and establishing an SCTP association. Unless explicitly 502 stated, the procedures apply to all m- line proto values ('SCTP', 503 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 504 specification. 506 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 507 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 508 fingerprint, using the SDP 'fingerprint' attribute [RFC4572], if the 509 endpoint supports, and is willing to use, a cipher suite with an 510 associated certificate. 512 The authentication certificates are interpreted and validated as 513 defined in [RFC4572]. Self-signed certificates can be used securely, 514 provided that the integrity of the SDP description is assured as 515 defined in [RFC4572]. 517 NOTE: The procedures apply to a specific m- line describing an SCTP 518 association. If an offer or answer contains multiple m- lines 519 describing SCTP associations, the procedures are applied separately 520 to each m- line. 522 10.2. Generating the Initial SDP Offer 524 When the offerer creates an initial offer, the offerer: 526 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 527 or 'TCP/DTLS/SCTP', associate an SDP setup attribute, with an 528 'actpass' value, with the m- line (see Section 9.3); 530 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 531 associate an SDP 'sctp-port' attribute with the m- line (see 532 Section 5); 534 o MUST associate an SDP 'connection' attribute, with a 'new' value, 535 with the m- line (see Section 9.4); and 537 o MAY associate an SDP 'max-message-size' attribute with the m- line 538 (see Section 6). 540 10.3. Generating the SDP Answer 542 When the answerer receives an offer, which contains an m- line 543 describing an SCTP association, if the answerer accepts the m- line 544 it: 546 o MUST insert a corresponding m- line in the answer, with an 547 identical m- line proto value [RFC3264]; 549 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 550 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute, with an 551 'active' or 'passive' value, with the m- line (see Section 9.3); 553 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 554 associate an SDP 'sctp-port' attribute with the m- line (see 555 Section 5); and 557 o MAY associate an SDP 'max-message-size' attribute with the m- line 558 (see Section 6). The attribute value in the answer is independent 559 from the value (if present) in the corresponding m- line of the 560 offer. 562 Once the answerer has sent the answer, the answerer: 564 o MUST, if an SCTP association associated with the m- line has yet 565 not been established, or if an existing SCTP association is to be 566 re-established, initiate the establishing of the SCTP association; 567 and 569 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 570 connection associated with the m- line is to be established (or 571 re-established), initiate the establishing of the DTLS connection 572 (by sending a ClientHello message). 574 If the answerer does not accept the m- line in the offer, it MUST 575 assign a zero port value to the corresponding m- line in the answer. 576 In addition, the answerer MUST NOT establish an SCTP association, or 577 a DTLS connection, associated with the m- line. 579 10.4. Offerer Processing of the SDP Answer 581 When the offerer receives an answer, which contains an m- line with a 582 non-zero port value, describing an SCTP association, the offerer: 584 o MUST, if the offerer is the 'active' endpoint, if the m- line 585 proto value is 'TCP/DTLS/SCTP', and if a TCP connection used to 586 carry the SCTP association has not yet been established (or if an 587 existing TCP connection is to be re-established), initiate the 588 establishing of the TCP connection; 590 o MUST, if an SCTP association associated with the m- line has not 591 yet been established (or if an existing SCTP association is to be 592 re-established), initiate the establishing of the SCTP 593 association; and 595 o MUST, if the offerer is the 'active' endpoint, and if a DTLS 596 connection associated with the m- line is to be established (or if 597 an existing DTLS connection is to be re-established), initiate the 598 establishing of the DTLS connection (by sending a ClientHello 599 message). 601 o NOTE: If the m- line proto value is 'UDP/DTLS/SCTP' or 'TCP/DTLS/ 602 SCTP', the two actions above are performed in switch order, as the 603 underlying DTLS connection needs to be established before the SCTP 604 association can be established. 606 If the m- line in the answer contains a zero port value, the offerer 607 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 608 connection, associated with the m- line. 610 10.5. Modifying the Session 612 When an offerer sends an updated offer, in order to modify a 613 previously established SCTP association, it follows the procedures in 614 Section 10.2, with the following exceptions: 616 o Unless the offerer wants to re-establish an existing SCTP 617 association, the offerer MUST associate an SDP connection 618 attribute, with an 'existing' value, with the m- line; and 620 o If the offerer wants to disable a previously established SCTP 621 association, it MUST assign a zero port value to the m- line 622 associated with the SCTP association, following the procedures in 623 [RFC3264]. 625 11. Multihoming Considerations 627 SCTP supports multihoming. An SCTP endpoint is considered multihomed 628 if it has more than one IP address on which SCTP can be used. An 629 SCTP endpoint inform the remote peer about its IP addresses using the 630 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 631 is used to describe an SCTP association, while the "c=" line contains 632 the address which was used to negotiate the SCTP association, 633 multihomed SCTP endpoints might end up using other IP addresses. 635 If an endpoint removes the IP address [RFC5061] that it offered in 636 the SDP "c=" line associated with the SCTP association, it MUST send 637 a new Offer, in which the "c=" line contains an IP address which is 638 valid within the SCTP association. 640 NOTE: In some network environments, intermediaries performing gate- 641 and firewall control using the address information in the SDP "c=" 642 and "m=" lines to authorize media, and will not pass media sent using 643 other addresses. In such network environments, if an SCTP endpoints 644 wants to change the address information on which media is sent and 645 received, it needs to send an updated Offer, in which the SDP "c=" 646 and "m=" lines contain the new address information. 648 Multihoming is not supported when sending SCTP on top of DTLS, as 649 DTLS does not expose address management of the underlying transport 650 protocols (UDP or TCP) to its upper layer. 652 12. NAT Considerations 653 12.1. General 655 SCTP features not present in UDP or TCP, including the checksum 656 (CRC32c) value calculated on the whole packet (rather than just the 657 header), and multihoming, introduce new challenges for NAT traversal. 658 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 659 which provides similar features of Network Address and Port 660 Translation (NAPT). 662 Current NATs typically do not support SCTP. [RFC6951] defines a 663 mechanism for sending SCTP on top of UDP, which makes it possible to 664 use SCTP with NATs and firewalls that do not support SCTP. 666 12.2. ICE Considerations 668 At the time of writing this specification, no procedures have been 669 defined for using ICE (Interactive Connectivity Establishment) 670 [RFC5245] together with SCTP as transport layer protocol. Such 671 procedures, including the associated SDP Offer/Answer procedures, are 672 outside the scope of this specification, and might be defined in a 673 future specification. 675 When the transport layer protocol is UDP (in case of an SCTP 676 association on top of a DTLS connection on top of UDP), if ICE is 677 used, the ICE procedures defined in [RFC5245] are used. 679 When the transport layer protocol is TCP (in case of an SCTP 680 association on top of a DTLS connection on top of TCP), if ICE is 681 used, the ICE procedures defined in [RFC6544] are used. 683 13. Examples 685 13.1. Establishment of UDP/DTLS/SCTP association 686 SDP Offer: 688 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 689 c=IN IP4 192.0.2.1 690 a=setup:actpass 691 a=connection:new 692 a=sctp-port:5000 693 a=max-message-size:100000 695 - The offerer indicates that the usage of the 696 UDP/DTLS/SCTP association will be as defined 697 for the 'webrtc-datachannel' format value. 698 - The offerer UDP port value is 54111. 699 - The offerer SCTP port value is 5000. 700 - The offerer indicates that it can take either the 701 active or the passive role. 703 SDP Answer: 705 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel 706 c=IN IP4 192.0.2.2 707 a=setup:passive 708 a=sctp-port:6000 709 a=max-message-size:100000 711 - The answerer UDP port value is 64300. 712 - The answerer SCTP port value is 6000. 713 - The answerer takes the passive role. 715 14. Security Considerations 717 [RFC4566] defines general SDP security considerations, while 718 [RFC3264], [RFC4145] and [RFC4572] define security considerations 719 when using the SDP offer/answer mechanism to negotiate media streams. 721 [RFC4960] defines general SCTP security considerations, while 722 [RFC6083] defines security considerations when using DTLS on top of 723 SCTP. 725 This specification does not introduce new security considerations in 726 addition to those defined in the specifications listed above. 728 15. IANA Considerations 730 15.1. New SDP proto values 732 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 733 document.] 735 This document updates the "Session Description Protocol (SDP) 736 Parameters" registry, following the procedures in [RFC4566], by 737 adding the following values to the table in the SDP "proto" field 738 registry: 740 +-------+---------------+-----------+ 741 | Type | SDP Name | Reference | 742 +-------+---------------+-----------+ 743 | proto | SCTP | [RFCXXXX] | 744 | proto | SCTP/DTLS | [RFCXXXX] | 745 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 746 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 747 +-------+---------------+-----------+ 749 Table 1: SDP "proto" field values 751 15.2. New SDP Attributes 753 15.2.1. sctp-port 755 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 756 document.] 758 This document defines a new SDP media-level attribute,'sctp-port', as 759 follows: 761 Attribute name: sctp-port 762 Type of attribute: media 763 Mux category: SPECIAL 764 Subject to charset: No 765 Purpose: Indicate the SCTP port value associated 766 with the SDP Media Description. 767 Appropriate values: Integer 768 Contact name: Christer Holmberg 769 Contact e-mail: christer.holmberg@ericsson.com 770 Reference: RFCXXXX 772 15.2.2. max-message-size 774 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 775 document.] 777 This document defines a new SDP media-level attribute,'max-message- 778 size', as follows: 780 Attribute name: max-message-size 781 Type of attribute: media 782 Mux category: SPECIAL 783 Subject to charset: No 784 Purpose: Indicate the maximum message size that 785 an SCTP endpoint is willing to receive 786 on the SCTP association associated 787 with the SDP Media Description. 788 Appropriate values: Integer 789 Contact name: Christer Holmberg 790 Contact e-mail: christer.holmberg@ericsson.com 791 Reference: RFCXXXX 793 15.3. association-usage Name Registry 795 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 796 document.] 798 This specification creates a new IANA registry, following the 799 procedures in [RFC5226], for the "fmt" namespace associated with the 800 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 801 identifiers. Each "fmt" value describes the usage of an entire SCTP 802 association, including all SCTP streams associated with the SCTP 803 association. 805 NOTE: Usage indication of individual SCTP streams is outside the 806 scope of this specification. 808 The "fmt" value, "association-usage", used with these "proto" is 809 required. It is defined in [Section 4]. 811 As part of this registry, IANA maintains the following information: 813 association-usage name: The identifier of the subprotocol, as will 814 be used as the "fmt" value. 816 association-usage reference: A reference to the document in which 817 the association-usage is defined. 819 association-usage names are to be subject to the "First Come First 820 Served" IANA registration policy [RFC5226]. 822 IANA is asked to add initial values to the registry. 824 |----------------------------------------------------------| 825 | name | Reference | 826 |----------------------------------------------------------| 827 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 828 |----------------------------------------------------------| 830 [RFC EDITOR NOTE: Please hold the publication of this draft 831 until draft-ietf-rtcweb-data-protocol has been published as an RFC. 832 Then, replace the reference to draft-ietf-rtcweb-data-protocol 833 with the RFC number.] 835 Figure 1 837 16. Acknowledgments 839 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 840 Kyzivat, Michael Tuexen, Juergen Stoetzer-Bradler, Flemming Andreasen 841 and Ari Keranen for their comments and useful feedback. 843 17. Change Log 845 [RFC EDITOR NOTE: Please remove this section when publishing] 847 Changes from draft-ietf-mmusic-sctp-sdp-12 849 o Mux category rules added for new SDP attributes. 851 o Reference to draft-ietf-mmusic-sdp-mux-attributes added. 853 o Changes based on comments from Roman Shpount: 855 o - Specify that fingerprint or setup roles must not be modified, 856 unless underlying transport protocol is also modified. 858 o Changes based on comments from Ari Keranen: 860 o - Editorial corrections. 862 o Changes based on comments from Flemming Andreasen: 864 o - Clarify that, if UDP/DTLS/SCTP or TCP/DTLS/SCTP is used, the 865 DTLS connection is established before the SCTP association. 867 o - Clarify that max-message-size value is given in bytes, and that 868 different values can be used per direction. 870 o - Section on fmtp attribute removed. 872 o - Editorial corrections. 874 Changes from draft-ietf-mmusic-sctp-sdp-11 876 o Example added. 878 Changes from draft-ietf-mmusic-sctp-sdp-10 880 o SDP max-message-size attribute added to IANA considerations. 882 o Changes based on comments from Paul Kyzivat: 884 o - Text about max message size removed from fmtp attribute section. 886 Changes from draft-ietf-mmusic-sctp-sdp-09 888 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 890 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 891 transports added. 893 Changes from draft-ietf-mmusic-sctp-sdp-08 895 o Default SCTP port removed: 897 o - Usage of SDP sctp-port attribute mandatory. 899 o SDP max-message-size attribute defined: 901 o - Attribute definition. 903 o - SDP Offer/Answer procedures. 905 o Text about SDP direction attributes added. 907 o Text about TLS role determination added. 909 18. References 911 18.1. Normative References 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, March 1997. 916 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 917 with Session Description Protocol (SDP)", RFC 3264, June 918 2002. 920 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 921 the Session Description Protocol (SDP)", RFC 4145, 922 September 2005. 924 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 925 Extensions (MIME) Part Four: Registration Procedures", BCP 926 13, RFC 4289, December 2005. 928 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 929 Description Protocol", RFC 4566, July 2006. 931 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 932 and RTP Control Protocol (RTCP) Packets over Connection- 933 Oriented Transport", RFC 4571, July 2006. 935 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 936 Transport Layer Security (TLS) Protocol in the Session 937 Description Protocol (SDP)", RFC 4572, July 2006. 939 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 940 4960, September 2007. 942 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 943 Kozuka, "Stream Control Transmission Protocol (SCTP) 944 Dynamic Address Reconfiguration", RFC 5061, September 945 2007. 947 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 948 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 949 May 2008. 951 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 952 Specifications: ABNF", STD 68, RFC 5234, January 2008. 954 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 955 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 957 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 958 Security Version 1.2", RFC 6347, January 2012. 960 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 961 Specifications and Registration Procedures", BCP 13, RFC 962 6838, January 2013. 964 [I-D.ietf-tsvwg-sctp-dtls-encaps] 965 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 966 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 967 dtls-encaps-09 (work in progress), January 2015. 969 [I-D.ietf-mmusic-sdp-mux-attributes] 970 Nandakumar, S., "A Framework for SDP Attributes when 971 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-08 972 (work in progress), January 2015. 974 18.2. Informative References 976 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 977 793, September 1981. 979 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 980 (ICE): A Protocol for Network Address Translator (NAT) 981 Traversal for Offer/Answer Protocols", RFC 5245, April 982 2010. 984 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 985 for Establishing a Secure Real-time Transport Protocol 986 (SRTP) Security Context Using Datagram Transport Layer 987 Security (DTLS)", RFC 5763, May 2010. 989 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 990 Transport Layer Security (DTLS) for Stream Control 991 Transmission Protocol (SCTP)", RFC 6083, January 2011. 993 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 994 "TCP Candidates with Interactive Connectivity 995 Establishment (ICE)", RFC 6544, March 2012. 997 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 998 Control Transmission Protocol (SCTP) Packets for End-Host 999 to End-Host Communication", RFC 6951, May 2013. 1001 [I-D.ietf-behave-sctpnat] 1002 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 1003 Transmission Protocol (SCTP) Network Address Translation", 1004 draft-ietf-behave-sctpnat-09 (work in progress), September 1005 2013. 1007 Authors' Addresses 1009 Christer Holmberg 1010 Ericsson 1011 Hirsalantie 11 1012 Jorvas 02420 1013 Finland 1015 Email: christer.holmberg@ericsson.com 1017 Salvatore Loreto 1018 Ericsson 1019 Hirsalantie 11 1020 Jorvas 02420 1021 Finland 1023 Email: Salvatore.Loreto@ericsson.com 1025 Gonzalo Camarillo 1026 Ericsson 1027 Hirsalantie 11 1028 Jorvas 02420 1029 Finland 1031 Email: Gonzalo.Camarillo@ericsson.com