idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-12.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 (January 15, 2015) is 3386 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Section 5' is mentioned on line 504, but not defined == Missing Reference: 'Section 6' is mentioned on line 507, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 686, but not defined == Missing Reference: 'Section 4' is mentioned on line 747, 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-06 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 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: July 19, 2015 Ericsson 6 January 15, 2015 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-12 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 July 19, 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.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6 71 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. SDP 'max-message-size' Attribute . . . . . . . . . . . . . . 7 74 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. SDP 'fmtp' Attribute . . . . . . . . . . . . . . . . . . . . 7 77 8. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 7 78 9. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 8 79 10. SCTP Association Management . . . . . . . . . . . . . . . . . 8 80 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 8 81 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute . . . 8 82 10.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . 8 83 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 8 84 10.3.2. SCTP Association Initiation . . . . . . . . . . . . 9 85 10.3.3. TLS Role Determination . . . . . . . . . . . . . . . 9 86 10.4. SDP connection Attribute . . . . . . . . . . . . . . . . 9 87 11. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 88 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 10 89 11.2. Generating the Initial SDP Offer . . . . . . . . . . . . 10 90 11.3. Generating the SDP Answer . . . . . . . . . . . . . . . 11 91 11.4. Offerer Processing of the SDP Answer . . . . . . . . . . 12 92 11.5. Modifying the Session . . . . . . . . . . . . . . . . . 12 93 12. Multihoming Considerations . . . . . . . . . . . . . . . . . 13 94 13. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13 96 13.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 14 98 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 14.1. Establishment of UDP/DTLS/SCTP association . . . . . . . 14 100 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 101 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 102 16.1. New SDP proto values . . . . . . . . . . . . . . . . . . 15 103 16.2. New SDP Attributes . . . . . . . . . . . . . . . . . . . 15 104 16.2.1. sctp-port . . . . . . . . . . . . . . . . . . . . . 15 105 16.2.2. max-message-size . . . . . . . . . . . . . . . . . . 16 106 16.3. association-usage Name Registry . . . . . . . . . . . . 16 107 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 108 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 110 19.1. Normative References . . . . . . . . . . . . . . . . . . 18 111 19.2. Informative References . . . . . . . . . . . . . . . . . 19 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 114 1. Introduction 116 SDP (Session Description Protocol) [RFC4566] provides a general- 117 purpose format for describing multimedia sessions in announcements or 118 invitations. TCP-Based Media Transport in the Session Description 119 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 120 and establishing TCP (Transmission Control Protocol) [RFC5246] 121 streams. Connection-Oriented Media Transport over the Transport 122 Layer Security (TLS) Protocol in the Session Description Protocol 123 (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based 124 media streams that are protected using TLS. 126 SCTP (Stream Control Transmission Protocol) is a transport protocol 127 used to establish associations between two endpoints. 129 This specification describes how to describe SCTP associations using 130 the Session Description Protocol (SDP) [RFC4566], and defines the 131 following new SDP Media Description [RFC4566] protocol identifiers 132 (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 133 SCTP'. 135 The specification also describes how to use the new proto values 136 together with the SDP Offer/Answer mechanism [RFC3264] in order to 137 negotiate and establish SCTP associations, and how to indicate the 138 SCTP application usage. 140 NOTE: TLS is designed to run on top of a byte-stream oriented 141 transport protocol providing a reliable, in-sequence delivery like 142 TCP. [RFC6083] presents serious limitations with transporting SCTP 143 on top of TLS. Therefore, defining a mechanism to negotiate media 144 streams transported using SCTP on top of TLS is outside the scope of 145 this specification. 147 2. Terminology 149 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 150 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 151 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 152 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 153 levels for compliant implementations. 155 3. SCTP Terminology 157 SCTP Association: A protocol relationship between SCTP endpoints, 158 composed of the two SCTP endpoints and protocol state information 159 including Verification Tags and the currently active set of 160 Transmission Sequence Numbers (TSNs), etc. An association can be 161 uniquely identified by the transport addresses used by the endpoints 162 in the association. Two SCTP endpoints MUST NOT have more than one 163 SCTP association between them at any given time. 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 either UDP or TCP, SCTP is 198 carried on top of either of those transport-layer protocols. 200 The m- line fmt value, identifying the application-layer protocol, 201 MUST be registered by IANA. 203 4.2. Protocol Identifiers 205 The new proto values are defined as below: 207 o The 'SCTP' proto value describes an SCTP association, as defined 208 in [RFC4960]. 210 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 211 Security (DTLS) [RFC6347] connection on top of an SCTP 212 association, as defined in [RFC6083]. 214 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 215 top of a DTLS connection on top of UDP, as defined in Section 8. 217 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 218 top of a DTLS connection on top of TCP, as defined in Section 9. 220 4.3. Media Format Management 222 [RFC4566] defines that specifications defining new proto values must 223 define the rules by which their media format (fmt) namespace is 224 managed. Use of an existing MIME subtype for the format is 225 encouraged. If no MIME subtype exists, it is recommended that a 226 suitable one is registered through the IETF process [RFC6838] 227 [RFC4289] by production of, or reference to, a standards-track RFC 228 that defines the transport protocol for the format. 230 An m- line with a proto value of 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' 231 or 'TCP/DTLS/SCTP' always describe a single SCTP association. 233 In addition, such m- line MUST further indicate the application-layer 234 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 235 value per m- line associated with the proto values defined in this 236 specification. The "fmt" namespace associated with those proto 237 values describes the generic application usage of the entire SCTP 238 association, including the associated SCTP streams. 240 NOTE: A mechanism on how to describe, and manage, individual SCTP 241 streams within an SCTP association, is outside the scope of this 242 specification. 244 4.4. Syntax 246 sctp-m-line = %x6d "=" 247 ("application" SP sctp-port SP "SCTP" SP fmt CRLF) / 248 ("application" SP sctp-port SP "SCTP/DTLS" SP fmt CRLF) / 249 ("application" SP udp-port SP "UDP/DTLS/SCTP" SP fmt CRLF) / 250 ("application" SP tcp-port SP "TCP/DTLS/SCTP" SP fmt CRLF) 252 sctp-port = port 254 udp-port = port 256 tcp-port = port 258 fmt = association-usage 260 association-usage = token 262 4.5. Example 264 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 265 a=max-message-size: 100000 267 5. SDP 'sctp-port' Attribute 269 5.1. General 271 This section defines a new SDP media-level attribute, 'sctp-port'. 272 The attribute can be associated with an SDP media descriptor (m- 273 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in 274 which case the m- line port value indicates the port of the 275 transport-layer protocol (UDP or TCP), on which SCTP is carried. 277 If the SDP sctp-port attribute is not present, the m- line MUST be 278 discarded. 280 Usage of the SDP sctp-port attribute with other proto values is not 281 specified, and MUST be discarded if received. 283 5.2. Syntax 285 sctp-port-attr = "a=sctp-port:" port 286 port = 1*DIGIT 288 6. SDP 'max-message-size' Attribute 290 6.1. General 292 The SDP 'max-message-size' attribute can be associated with an m- 293 line to indicate the maximum message size that an SCTP endpoint is 294 willing to receive on the SCTP association associated with the m- 295 line. 297 The remote peer MUST assume that larger messages will be rejected by 298 the SCTP endpoint. SCTP endpoints need to decide on appropriate 299 behavior in case a message that exceeds the maximum size needs to be 300 sent. 302 If the SDP 'max-message-size' attribute contains a maximum message 303 size value of zero, it indicates the SCTP endpoint will handle 304 messages of any size, subject to memory capacity etc. 306 If the SDP 'max-message-size' attribute is not present, the default 307 value is 64K. 309 NOTE: This specification only defines the usage of the SDP 'max- 310 message-size' attribute when associated with an m- line containing 311 one of the following proto values: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/ 312 SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with other proto 313 values needs to be defined in a separate specification. 315 6.2. Syntax 317 max-message-size-attr = "a=max-message-size:" max-message-size 318 max-message-size = 1*DIGIT 320 7. SDP 'fmtp' Attribute 322 The SDP 'fmtp' attribute [RFC4566] can be used to carry association- 323 usage specific parameters. If the attribute is used with a specific 324 association-usage, the usage and detailed syntax MUST be defined in 325 that association-usage specification. 327 8. UDP/DTLS/SCTP Transport Realization 329 The UDP/DTLS/SCTP transport is realized as described below: 331 o SCTP on top of DTLS is realized according to the procedures 332 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 334 o DTLS on top of UDP is realized according to the procedures in 335 defined in [RFC6347]. 337 9. TCP/DTLS/SCTP Transport Realization 339 The TCP/DTLS/SCTP transport is realized as described below: 341 o SCTP on top of DTLS is realized according to the procedures 342 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 344 o DTLS on top of TCP is realized using the framing method defined in 345 [RFC4571]. 347 NOTE: DTLS on top of TCP, without using the framing method defined in 348 [RFC4571] is outside the scope of this specification. A separate 349 proto value would need to be registered for such transport 350 realization. 352 10. SCTP Association Management 354 10.1. General 356 The management of an SCTP association is identical to the management 357 of a TCP connection. An SCTP endpoints MUST follow the rules in 358 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 359 the SCTP ordered or unordered delivery service is up to the 360 applications using the SCTP association, and this specification does 361 not define a mechanism to indicate the type of delivery service using 362 SDP. 364 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute 366 This specification does not define semantics for the SDP direction 367 attributes [RFC4566]. Specifications for an individual SCTP 368 association usage MAY define how the attributes can be used with that 369 usage. Unless semantics of these attributes for an SCTP association 370 usage have been defined, SDP direction attributes MUST be discarded 371 if present. 373 10.3. SDP setup Attribute 375 10.3.1. General 377 The SDP setup attribute is used to determine the 'active/passive' 378 status of the endpoints, following the procedures for TCP in 379 [RFC4145]. 381 10.3.2. SCTP Association Initiation 383 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 384 association, and MUST use the same SCTP port as client port and 385 server port (in order to prevent two separate SCTP associations from 386 being established). 388 NOTE: The procedure above is different from TCP, where only the 389 'active' endpoint initiates the TCP connection [RFC4145]. 391 If the m- line proto value is 'TCP/DTLS/SCTP', only the 'active' 392 endpoint will initiate the TCP connection, following the procedures 393 in [RFC4145]. Both endpoints will still initiate the SCTP 394 association on top of the TCP connection. 396 10.3.3. TLS Role Determination 398 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 399 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 400 TLS roles of the endpoints. Following the procedures in [RFC4572], 401 the 'active' endpoint will take the TLS client role. 403 Once a DTLS connection has been established, if the 'active/passive' 404 status of the endpoints change (as result of an offer/answer 405 transaction) during a session, a new DTLS connection MUST be 406 established. Therefore, endpoints SHOULD NOT change the 'active/ 407 passive' status during a session, unless they want to establish a new 408 DTLS connection. 410 If the transport parameters or the key fingerprints change, the 411 endpoints MUST establish a new DTLS connection. In such case the 412 'active/passive' status of the endpoints will again be determined 413 following the procedures in [RFC4145], and the new status will be 414 used to determine the TLS roles of the endpoints associated with the 415 new DTLS connection. 417 NOTE: The procedure above is identical to the one defined for SRTP- 418 DTLS in [RFC5763]. 420 10.4. SDP connection Attribute 422 The SDP connection attribute is used following the procedures in 423 [RFC4145], with the additional SCTP specific considerations described 424 in this section. 426 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 427 attribute associated with that m- line applies to both the SCTP 428 association and the TCP connection. Therefore, an attribute 'new' 429 value indicates that both a new SCTP association, and a new TCP 430 connection, have to be established, following the procedures in 431 [RFC4145]. 433 NOTE: This specification does not define a mechanism which allows re- 434 establishing of a new SCTP association, while maintaining the TCP 435 connection. 437 The SDP connection attribute value does not automatically impact an 438 existing DTLS connection. Section 10.3.3 describes in which cases a 439 new DTLS connections will be established. 441 NOTE: If the m- line proto value is 'SCTP/DTLS', and if the SCTP 442 association is re-established, the DTLS connection also needs to be 443 re-established. 445 11. SDP Offer/Answer Procedures 447 11.1. General 449 This section defines the SDP Offer/Answer [RFC3264] procedures for 450 negotiating and establishing an SCTP association. Unless explicitly 451 stated, the procedures apply to all m- line proto values ('SCTP', 452 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 453 specification. 455 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 456 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 457 fingerprint, using the SDP 'fingerprint' attribute [RFC4572], if the 458 endpoint supports, and is willing to use, a cipher suite with an 459 associated certificate. 461 The authentication certificates are interpreted and validated as 462 defined in [RFC4572]. Self-signed certificates can be used securely, 463 provided that the integrity of the SDP description is assured as 464 defined in [RFC4572]. 466 NOTE: The procedures apply to a specific m- line describing an SCTP 467 association. If an offer or answer contains multiple m- lines 468 describing SCTP associations, the procedures are applied separately 469 to each m- line. 471 11.2. Generating the Initial SDP Offer 473 When the offerer creates an initial offer, the offerer: 475 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 476 or 'TCP/DTLS/SCTP', associate an SDP setup attribute 477 [Section 10.3], with an 'actpass' value, with the m- line; 479 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 480 associate an SDP 'sctp-port' attribute [Section 5] with the m- 481 line; 483 o MUST associate an SDP 'connection' attribute [Section 10.4], with 484 a 'new' value, with the m- line; and 486 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 487 the m- line. 489 11.3. Generating the SDP Answer 491 When the answerer receives an offer, which contains an m- line 492 describing an SCTP association, if the answerer accepts the m- line 493 it: 495 o MUST insert a corresponding m- line in the answer, with an 496 identical m- line proto value [RFC3264]; 498 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 499 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute 500 [Section 10.3], with an 'active' or 'passive' value, with the m- 501 line; 503 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 504 associate an SDP 'sctp-port' attribute[Section 5] with the m- 505 line; and 507 o MAY associate an SDP 'max-message-size' attribute [Section 6] with 508 the m- line. 510 Once the answerer has sent the answer, the answerer: 512 o MUST, if an SCTP association associated with the m- line has yet 513 not been established, or if an existing SCTP association is to be 514 re-established, initiate the establishing of the SCTP association; 515 and 517 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 518 connection associated with the m- line is to be established (or 519 re-established), initiate the establishing of the DTLS connection 520 (by sending a ClientHello message). 522 If the answerer does not accept the m- line in the offer, it MUST 523 assign a zero port value to the corresponding m- line in the answer. 524 In addition, the answerer MUST NOT establish an SCTP association, or 525 a DTLS connection, associated with the m- line. 527 11.4. Offerer Processing of the SDP Answer 529 When the offerer receives an answer, which contains an m- line with a 530 non-zero port value, describing an SCTP association, the offerer: 532 o MUST, if the offerer is the 'active' endpoint, if the m- line 533 proto is 'TCP/DTLS/SCTP', and if a TCP connection used to carry 534 the SCTP association has yet not been established (or if an 535 existing TCP connection is to be re-established), initiate the 536 establishing of the TCP connection; 538 o MUST, if an SCTP association associated with the m- line has yet 539 not been established (or if an existing SCTP association is to be 540 re-established), initiate the establishing of the SCTP 541 association; and 543 o MUST, if the offerer is the 'active' endpoint, and if an DTLS 544 connection associated with the m- line is to be established (or if 545 an existing DTLS connection is to be re-established), initiate the 546 establishing of the DTLS connection (by sending a ClientHello 547 message). 549 If the m- line in the answer contains a zero port value, the offerer 550 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 551 connection, associated with the m- line. 553 11.5. Modifying the Session 555 When an offerer sends an updated offer, in order to modify a 556 previously established SCTP association, it follows the procedures in 557 Section 11.2, with the following exceptions: 559 o Unless the offerer wants to re-establish an existing SCTP 560 association, the offerer MUST associate an SDP connection 561 attribute, with an 'existing' value, with the m- line; and 563 o If the offerer wants to disable a previously established SCTP 564 association, it MUST assign a zero port value to the m- line 565 associated with the SCTP association, following the procedures in 566 [RFC3264]. 568 NOTE: Different SCTP association usages might define protocol 569 procedures etc that need to be performed before an SCTP association 570 is terminated. Such procedures are outside the scope of this 571 specification. 573 12. Multihoming Considerations 575 SCTP supports multihoming. An SCTP endpoint is considered multihomed 576 if it has more than one IP address on which SCTP can be used. An 577 SCTP endpoint inform the remote peer about its IP addresses using the 578 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 579 is used to describe an SCTP association, while the "c=" line contains 580 the address which was used to negotiate the SCTP association, 581 multihomed SCTP endpoints might end up using other IP addresses. 583 If an endpoint removes the IP address [RFC5061] that it offered in 584 the SDP "c=" line associated with the SCTP association, it MUST send 585 a new Offer, in which the "c=" line contains an IP address with is 586 valid within the SCTP association. 588 NOTE: In some network environments, intermediaries performing gate- 589 and firewall control use the address information in the SDP "c=" and 590 "m=" lines to authorize media, and will not pass media sent using 591 other addresses. In such network environment, if an SCTP endpoints 592 wants to change the address information on which media is sent and 593 received, it needs to send an updated Offer, in which the SDP "c=" 594 and "m=" lines contain the new address information. 596 Multihoming is not supported when sending SCTP on top of DTLS, as 597 DTLS does not expose address management to its upper layer. 599 13. NAT Considerations 601 13.1. General 603 SCTP features not present in UDP or TCP, including the checksum 604 (CRC32c) value calculated on the whole packet (rather than just the 605 header), and multihoming, introduce new challenges for NAT traversal. 606 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 607 which provides similar features of Network Address and Port 608 Translation (NAPT). 610 Current NATs typically do not support SCTP. [RFC6951] defines a 611 mechanism for sending SCTP on top of UDP, which makes it possible to 612 use SCTP with NATs and firewalls that do not support SCTP. 614 13.2. ICE Considerations 616 At the time of writing this specification, no procedures have been 617 defined for using ICE (Interactive Connectivity Establishment) 618 [RFC5768] together with SCTP. Such procedures, including the 619 associated SDP Offer/Answer procedures, are outside the scope of this 620 specification, and might be defined in a future specification. 622 14. Examples 624 14.1. Establishment of UDP/DTLS/SCTP association 626 SDP Offer: 628 m=application 54111 UDP/DTLS/SCTP webrtc-datachannel 629 c=IN IP4 192.0.2.1 630 a=setup:actpass 631 a=connection:new 632 a=sctp-port:5000 633 a=max-message-size: 100000 635 - The offerer indicates that the usage of the 636 UDP/DTLS/SCTP association will be as defined 637 for the 'webrtc-datachannel' format value. 638 - The offerer UDP port value is 54111. 639 - The offerer SCTP port value is 5000. 640 - The offerer indicates that it can take either the 641 active or the passive role. 643 SDP Answer: 645 m=application 64300 UDP/DTLS/SCTP webrtc-datachannel 646 c=IN IP4 192.0.2.2 647 a=setup:passive 648 a=sctp-port:6000 649 a=max-message-size: 100000 651 - The answerer UDP port value is 64300. 652 - The answerer SCTP port value is 6000. 653 - The answerer takes the passive role. 655 15. Security Considerations 657 [RFC4566] defines general SDP security considerations, while 658 [RFC3264], [RFC4145] and [RFC4572] define security considerations 659 when using the SDP offer/answer mechanism to negotiate media streams. 661 [RFC4960] defines general SCTP security considerations. security 662 considerations on SCTP in general, while [RFC6083] defines security 663 considerations when using DTLS on top of SCTP. 665 This specification does not introduce new security considerations in 666 addition to those defined in the specifications listed above. 668 16. IANA Considerations 670 16.1. New SDP proto values 672 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 673 document.] 675 This document updates the "Session Description Protocol (SDP) 676 Parameters" registry, following the procedures in [RFC4566], by 677 adding the following values to the table in the SDP "proto" field 678 registry: 680 +-------+---------------+-----------+ 681 | Type | SDP Name | Reference | 682 +-------+---------------+-----------+ 683 | proto | SCTP | [RFCXXXX] | 684 | proto | SCTP/DTLS | [RFCXXXX] | 685 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 686 | proto | TCP/DTLS/SCTP | [RFCXXXX] | 687 +-------+---------------+-----------+ 689 Table 1: SDP "proto" field values 691 16.2. New SDP Attributes 693 16.2.1. sctp-port 695 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 696 document.] 698 This document defines a new SDP media-level attribute,'sctp-port', as 699 follows: 701 Attribute name: sctp-port 702 Type of attribute: media 703 Subject to charset: No 704 Purpose: Indicate the SCTP port value associated 705 with the SDP Media Description. 706 Appropriate values: Integer 707 Contact name: Christer Holmberg 708 Contact e-mail: christer.holmberg@ericsson.com 709 Reference: RFCXXXX 711 16.2.2. max-message-size 713 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 714 document.] 716 This document defines a new SDP media-level attribute,'max-message- 717 size', as follows: 719 Attribute name: max-message-size 720 Type of attribute: media 721 Subject to charset: No 722 Purpose: Indicate the maximum message size that 723 an SCTP endpoint is willing to receive 724 on the SCTP association associated 725 with the SDP Media Description. 726 Appropriate values: Integer 727 Contact name: Christer Holmberg 728 Contact e-mail: christer.holmberg@ericsson.com 729 Reference: RFCXXXX 731 16.3. association-usage Name Registry 733 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 734 document.] 736 This specification creates a new IANA registry, following the 737 procedures in [RFC5226], for the "fmt" namespace associated with the 738 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 739 identifiers. Each "fmt" value describes the usage of an entire SCTP 740 association, including all SCTP streams associated with the SCTP 741 association. 743 NOTE: Usage indication of individual SCTP streams is outside the 744 scope of this specification. 746 The "fmt" value, "association-usage", used with these "proto" is 747 required. It is defined in [Section 4]. 749 As part of this registry, IANA maintains the following information: 751 association-usage name: .The identifier of the subprotocol, as will 752 be used as the "fmt" value. 754 association-usage reference: A reference to the document in which 755 the association-usage is defined. 757 association-usage names are to be subject to the "First Come First 758 Served" IANA registration policy [RFC5226]. 760 IANA is asked to add initial values to the registry. 762 | name | Reference | 763 -+--------------------+-------------------------------------+ 764 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 765 -+----------------------------------------------------------| 767 Figure 1 769 17. Acknowledgments 771 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 772 Kyzivat, Michael Tuexen for their comments and useful feedback. 774 18. Change Log 776 [RFC EDITOR NOTE: Please remove this section when publishing] 778 Changes from draft-ietf-mmusic-sctp-sdp-11 780 o Example added. 782 Changes from draft-ietf-mmusic-sctp-sdp-10 784 o SDP max-message-size attribute added to IANA considerations. 786 o Changes based on comments from Paul Kyzivat: 788 o - Text about max message size removed from fmtp attribute section. 790 Changes from draft-ietf-mmusic-sctp-sdp-09 791 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 793 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 794 transports added. 796 Changes from draft-ietf-mmusic-sctp-sdp-08 798 o Default SCTP port removed: 800 o - Usage of SDP sctp-port attribute mandatory. 802 o SDP max-message-size attribute defined: 804 o - Attribute definition. 806 o - SDP Offer/Answer procedures. 808 o Text about SDP direction attributes added. 810 o Text about TLS role determination added. 812 19. References 814 19.1. Normative References 816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 817 Requirement Levels", BCP 14, RFC 2119, March 1997. 819 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 820 with Session Description Protocol (SDP)", RFC 3264, June 821 2002. 823 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 824 the Session Description Protocol (SDP)", RFC 4145, 825 September 2005. 827 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 828 Extensions (MIME) Part Four: Registration Procedures", BCP 829 13, RFC 4289, December 2005. 831 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 832 Description Protocol", RFC 4566, July 2006. 834 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 835 and RTP Control Protocol (RTCP) Packets over Connection- 836 Oriented Transport", RFC 4571, July 2006. 838 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 839 Transport Layer Security (TLS) Protocol in the Session 840 Description Protocol (SDP)", RFC 4572, July 2006. 842 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 843 4960, September 2007. 845 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 846 Kozuka, "Stream Control Transmission Protocol (SCTP) 847 Dynamic Address Reconfiguration", RFC 5061, September 848 2007. 850 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 851 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 852 May 2008. 854 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 855 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 857 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 858 Security Version 1.2", RFC 6347, January 2012. 860 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 861 Specifications and Registration Procedures", BCP 13, RFC 862 6838, January 2013. 864 [I-D.ietf-tsvwg-sctp-dtls-encaps] 865 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 866 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 867 dtls-encaps-06 (work in progress), November 2014. 869 19.2. Informative References 871 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 872 for Establishing a Secure Real-time Transport Protocol 873 (SRTP) Security Context Using Datagram Transport Layer 874 Security (DTLS)", RFC 5763, May 2010. 876 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 877 Connectivity Establishment (ICE) in the Session Initiation 878 Protocol (SIP)", RFC 5768, April 2010. 880 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 881 Transport Layer Security (DTLS) for Stream Control 882 Transmission Protocol (SCTP)", RFC 6083, January 2011. 884 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 885 Control Transmission Protocol (SCTP) Packets for End-Host 886 to End-Host Communication", RFC 6951, May 2013. 888 [I-D.ietf-behave-sctpnat] 889 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 890 Transmission Protocol (SCTP) Network Address Translation", 891 draft-ietf-behave-sctpnat-09 (work in progress), September 892 2013. 894 Authors' Addresses 896 Christer Holmberg 897 Ericsson 898 Hirsalantie 11 899 Jorvas 02420 900 Finland 902 Email: christer.holmberg@ericsson.com 904 Salvatore Loreto 905 Ericsson 906 Hirsalantie 11 907 Jorvas 02420 908 Finland 910 Email: Salvatore.Loreto@ericsson.com 912 Gonzalo Camarillo 913 Ericsson 914 Hirsalantie 11 915 Jorvas 02420 916 Finland 918 Email: Gonzalo.Camarillo@ericsson.com