idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-10.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 : ---------------------------------------------------------------------------- No issues found here. 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 (December 19, 2014) is 3415 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 518, but not defined == Missing Reference: 'Section 7' is mentioned on line 521, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 670, but not defined == Missing Reference: 'Section 4' is mentioned on line 709, 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 (==), 1 comment (--). 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: June 22, 2015 Ericsson 6 December 19, 2014 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-10 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 June 22, 2015. 44 Copyright Notice 46 Copyright (c) 2014 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 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. UDP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 8 80 9. TCP/DTLS/SCTP Transport Realization . . . . . . . . . . . . . 8 81 10. SCTP Association Management . . . . . . . . . . . . . . . . . 8 82 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 8 83 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute . . . 9 84 10.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . 9 85 10.3.1. General . . . . . . . . . . . . . . . . . . . . . . 9 86 10.3.2. SCTP Association Initiation . . . . . . . . . . . . 9 87 10.3.3. TLS Role Determination . . . . . . . . . . . . . . . 9 88 10.4. SDP connection Attribute . . . . . . . . . . . . . . . . 10 89 11. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 90 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 10 91 11.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 92 11.3. Generating the SDP Answer . . . . . . . . . . . . . . . 11 93 11.4. Offerer Processing of the SDP Answer . . . . . . . . . . 12 94 11.5. Modifying the Session . . . . . . . . . . . . . . . . . 13 95 12. Multihoming Considerations . . . . . . . . . . . . . . . . . 13 96 13. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 14 97 13.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14 98 13.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 14 99 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 100 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 101 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 102 16.1. New SDP proto values . . . . . . . . . . . . . . . . . . 14 103 16.2. New SDP Attribute . . . . . . . . . . . . . . . . . . . 15 104 16.3. association-usage Name Registry . . . . . . . . . . . . 15 105 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 106 18. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 19.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 19.2. Informative References . . . . . . . . . . . . . . . . . 18 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 SDP (Session Description Protocol) [RFC4566] provides a general- 115 purpose format for describing multimedia sessions in announcements or 116 invitations. TCP-Based Media Transport in the Session Description 117 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 118 and establishing TCP (Transmission Control Protocol) [RFC5246] 119 streams. Connection-Oriented Media Transport over the Transport 120 Layer Security (TLS) Protocol in the Session Description Protocol 121 (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based 122 media streams that are protected using TLS. 124 SCTP (Stream Control Transmission Protocol) is a transport protocol 125 used to establish associations between two endpoints. 127 This specification describes how to describe SCTP associations using 128 the Session Description Protocol (SDP) [RFC4566], and defines the 129 following new SDP Media Description [RFC4566] protocol identifiers 130 (proto values):'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 131 SCTP'. 133 The specification also describes how to use the new proto values 134 together with the SDP Offer/Answer mechanism [RFC3264] in order to 135 negotiate and establish SCTP associations, and how to indicate the 136 SCTP application usage. 138 NOTE: TLS is designed to run on top of a byte-stream oriented 139 transport protocol providing a reliable, in-sequence delivery like 140 TCP. [RFC6083] presents serious limitations with transporting SCTP 141 on top of TLS. Therefore, defining a mechanism to negotiate media 142 streams transported using SCTP on top of TLS is outside the scope of 143 this specification. 145 2. Terminology 147 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 148 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 149 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 150 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 151 levels for compliant implementations. 153 3. SCTP Terminology 155 SCTP Association: A protocol relationship between SCTP endpoints, 156 composed of the two SCTP endpoints and protocol state information 157 including Verification Tags and the currently active set of 158 Transmission Sequence Numbers (TSNs), etc. An association can be 159 uniquely identified by the transport addresses used by the endpoints 160 in the association. Two SCTP endpoints MUST NOT have more than one 161 SCTP association between them at any given time. 163 SCTP Stream: A unidirectional logical channel established from one to 164 another associated SCTP endpoint, within which all user messages are 165 delivered in sequence except for those submitted to the unordered 166 delivery service. 168 SCTP Transport address: A transport address is traditionally defined 169 by a network-layer address, a transport-layer protocol, and a 170 transport-layer port number. In the case of SCTP running over IP, a 171 transport address is defined by the combination of an IP address and 172 an SCTP port number (where SCTP is the transport protocol). 174 4. SDP Media Descriptions 176 4.1. General 178 This section defines the following new SDP Media Description (m- 179 line) protocol identifiers (proto values) for describing an SCTP 180 association: 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/ 181 SCTP'. The section also describes how an m- line, associated with 182 the proto values, is created. 184 The following is the format for an 'm' line, as specified in RFC4566 185 [RFC4566]: 187 m= ... 189 The 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto 190 values are similar to both the 'UDP' and 'TCP' proto values in that 191 they only describe the transport-layer protocol and not the upper- 192 layer protocol. 194 NOTE: When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values are 195 used, the underlying transport protocol is either UDP or TCP, SCTP is 196 carried on top of either of those transport-layer protocols. 198 The m- line fmt value, identifying the application-layer protocol, 199 MUST be registered by IANA. 201 4.2. Protocol Identifiers 203 The new proto values are defined as below: 205 o The 'SCTP' proto value describes an SCTP association, as defined 206 in [RFC4960]. 208 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 209 Security (DTLS) [RFC6347] connection on top of an SCTP 210 association, as defined in [RFC6083]. 212 o The 'UDP/DTLS/SCTP' proto value describes an SCTP association on 213 top of a DTLS connection on top of UDP, as defined in Section 8. 215 o The 'TCP/DTLS/SCTP' proto value describes an SCTP association on 216 top of a DTLS connection on top of TCP, as defined in Section 9. 218 4.3. Media Format Management 220 [RFC4566] defines that specifications defining new proto values must 221 define the rules by which their media format (fmt) namespace is 222 managed. Use of an existing MIME subtype for the format is 223 encouraged. If no MIME subtype exists, it is recommended that a 224 suitable one is registered through the IETF process [RFC6838] 225 [RFC4289] by production of, or reference to, a standards-track RFC 226 that defines the transport protocol for the format. 228 An m- line with a proto value of 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' 229 or 'TCP/DTLS/SCTP' always describe a single SCTP association. 231 In addition, such m- line MUST further indicate the application-layer 232 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 233 value per m- line associated with the proto values defined in this 234 specification. The "fmt" namespace associated with those proto 235 values describes the generic application usage of the entire SCTP 236 association, including the associated SCTP streams. 238 NOTE: A mechanism on how to describe, and manage, individual SCTP 239 streams within an SCTP association, is outside the scope of this 240 specification. 242 4.4. Syntax 244 sctp-m-line = %x6d "=" 245 ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / 246 ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / 247 ("application" SP udp-port SP "UDP/DTLS/SCTP" SP sctp-fmt CRLF) / 248 ("application" SP udp-port SP "TCP/DTLS/SCTP" SP sctp-fmt CRLF) 250 sctp-port = port 252 udp-port = port 254 sctp-fmt = association-usage 256 association-usage = token 258 4.5. Example 260 m=application 12345 UDP/DTLS/SCTP webrtc-datachannel 261 a=max-message-size: 100000 263 5. SDP 'sctp-port' Attribute 265 5.1. General 267 This section defines a new SDP media-level attribute, 'sctp-port'. 268 The attribute can be associated with an SDP media descriptor (m- 269 line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in 270 which case the m- line port value indicates the port of the 271 transport-layer protocol (UDP or TCP), on which SCTP is carried. 273 If the SDP sctp-port attribute is not present, the m- line MUST be 274 discarded. 276 Usage of the SDP sctp-port attribute with other proto values is not 277 specified, and MUST be discarded if received. 279 5.2. Syntax 281 sctp-port-attr = "a=sctp-port:" port 282 port = 1*DIGIT 284 6. SDP 'max-message-size' Attribute 286 6.1. General 288 The SDP 'max-message-size' attribute can be associated with an m- 289 line to indicate the maximum message size that an SCTP endpoint is 290 willing to receive on the SCTP association associated with the m- 291 line. 293 The remote peer MUST assume that larger messages will be rejected by 294 the SCTP endpoint. SCTP endpoints need to decide on appropriate 295 behavior in case a message that exceeds the maximum size needs to be 296 sent. 298 If the SDP 'max-message-size' attribute contains a maximum message 299 size value of zero, it indicates the SCTP endpoint will handle 300 messages of any size, subject to memory capacity etc. 302 If the SDP 'max-message-size' attribute is not present, the default 303 value is 64K. 305 6.2. Syntax 307 max-message-size-attr = "a=max-message-size:" max-message-size 308 max-message-size = 1*DIGIT 310 7. SDP 'fmtp' Attribute 312 7.1. General 314 The SDP 'fmtp' attribute can be used with an m- line, associated with 315 an SCTP association, to indicate the maximum message size that an 316 SCTP endpoint is willing to receive, for a particular SCTP 317 association usage, on that SCTP association. 319 The remote peer MUST assume that larger messages will be rejected by 320 the SCTP endpoint. SCTP endpoints need to decide on appropriate 321 behavior in case a message that exceeds the maximum size needs to be 322 sent. 324 If the SDP 'fmtp' attribute contains a maximum message size value of 325 zero, it indicates the SCTP endpoint will handle messages of any 326 size, subject to memory capacity etc. 328 If the SDP 'fmtp' attribute is not present, the default value is 64K. 330 NOTE: This specification only defines the usage of the SDP 'max- 331 message-size' attribute when associated with an m- line containing 332 one of the following proto field values: 'SCTP', 'SCTP/DTLS', 333 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP'. Usage of the attribute with 334 other proto values needs to be defined in a separate specification. 336 7.2. Syntax 338 sctpmap-attr = "a=fmtp:" association-usage [max-message-size] 339 max-message-size = "max-message-size" EQUALS 1*DIGIT 341 8. UDP/DTLS/SCTP Transport Realization 343 The UDP/DTLS/SCTP transport is realized as described below: 345 o SCTP on top of DTLS is realized according to the procedures 346 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 348 o DTLS on top of UDP is realized according to the procedures in 349 defined in [RFC6347]. 351 9. TCP/DTLS/SCTP Transport Realization 353 The TCP/DTLS/SCTP transport is realized as described below: 355 o SCTP on top of DTLS is realized according to the procedures 356 defined in [I-D.ietf-tsvwg-sctp-dtls-encaps]; and 358 o DTLS on top of TCP is realized using the framing method defined in 359 [RFC4571]. 361 NOTE: DTLS on top of TCP, without using the framing method defined in 362 [RFC4571] is outside the scope of this specification. A separate 363 proto value would need to be registered for such transport 364 realization. 366 10. SCTP Association Management 368 10.1. General 370 The management of an SCTP association is identical to the management 371 of a TCP connection. An SCTP endpoints MUST follow the rules in 372 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 373 the SCTP ordered or unordered delivery service is up to the 374 applications using the SCTP association, and this specification does 375 not define a mechanism to indicate the type of delivery service using 376 SDP. 378 10.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute 380 This specification does not define semantics for the SDP direction 381 attributes [RFC4566]. Specifications for an individual SCTP 382 association usage MAY define how the attributes can be used with that 383 usage. Unless semantics of these attributes for an SCTP association 384 usage have been defined, SDP direction attributes MUST be discarded 385 if present. 387 10.3. SDP setup Attribute 389 10.3.1. General 391 The SDP setup attribute is used to determine the 'active/passive' 392 status of the endpoints, following the procedures for TCP in 393 [RFC4145]. 395 10.3.2. SCTP Association Initiation 397 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 398 association, and MUST use the same SCTP port as client port and 399 server port (in order to prevent two separate SCTP associations from 400 being established). 402 NOTE: The procedure above is different from TCP, where only the 403 'active' endpoint initiates the TCP connection [RFC4145]. 405 If the m- line proto value is 'TCP/DTLS/SCTP', only the 'active' 406 endpoint will initiate the TCP connection, following the procedures 407 in [RFC4145]. Both endpoints will still initiate the SCTP 408 association on top of the TCP connection. 410 10.3.3. TLS Role Determination 412 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 413 'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the 414 TLS roles of the endpoints. Following the procedures in [RFC4572], 415 the 'active' endpoint will take the TLS client role. 417 Once a DTLS connection has been established, if the 'active/passive' 418 status of the endpoints change (as result of an offer/answer 419 transaction) during a session, a new DTLS connection MUST be 420 established. Therefore, endpoints SHOULD NOT change the 'active/ 421 passive' status during a session, unless they want to establish a new 422 DTLS connection. 424 If the transport parameters or the key fingerprints change, the 425 endpoints MUST establish a new DTLS connection. In such case the 426 'active/passive' status of the endpoints will again be determined 427 following the procedures in [RFC4145], and the new status will be 428 used to determine the TLS roles of the endpoints associated with the 429 new DTLS connection. 431 NOTE: The procedure above is identical to the one defined for SRTP- 432 DTLS in [RFC5763]. 434 10.4. SDP connection Attribute 436 The SDP connection attribute is used following the procedures in 437 [RFC4145], with the additional SCTP specific considerations described 438 in this section. 440 If the m- line proto value is 'TCP/DTLS/SCTP', an SDP connection 441 attribute associated with that m- line applies to both the SCTP 442 association and the TCP connection. Therefore, an attribute 'new' 443 value indicates that both a new SCTP association, and a new TCP 444 connection, have to be established, following the procedures in 445 [RFC4145]. 447 NOTE: This specification does not define a mechanism which allows re- 448 establishing of a new SCTP association, while maintaining the TCP 449 connection. 451 The SDP connection attribute value does not automatically impact an 452 existing DTLS connection. Section 10.3.3 describes in which cases a 453 new DTLS connections will be established. 455 NOTE: If the m- line proto value is 'SCTP/DTLS', and if the SCTP 456 association is re-established, the DTLS connection also needs to be 457 re-established. 459 11. SDP Offer/Answer Procedures 461 11.1. General 463 This section defines the SDP Offer/Answer [RFC3264] procedures for 464 negotiating and establishing an SCTP association. Unless explicitly 465 stated, the procedures apply to all m- line proto values ('SCTP', 466 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP') defined in this 467 specification. 469 If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or 470 'TCP/DTLS/SCTP', each endpoint MUST provide a certificate 471 fingerprint, using the SDP 'fingerprint' attribute [RFC4145], if the 472 endpoint supports, and is willing to use, a cipher suite with an 473 associated certificate. 475 The authentication certificates are interpreted and validated as 476 defined in [RFC4572]. Self-signed certificates can be used securely, 477 provided that the integrity of the SDP description is assured as 478 defined in [RFC4572]. 480 NOTE: The procedures apply to a specific m- line describing an SCTP 481 association. If an offer or answer contains multiple m- lines 482 describing SCTP associations, the procedures are applied separately 483 to each m- line. 485 11.2. Generating the Initial SDP Offer 487 When the offerer creates an initial offer, the offerer: 489 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 490 or 'TCP/DTLS/SCTP', associate an SDP setup attribute 491 [Section 10.3], with an 'actpass' value, with the m- line; 493 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 494 associate an SDP 'sctp-port' attribute [Section 5] with the m- 495 line; 497 o MUST associate an SDP 'connection' attribute [Section 10.4], with 498 a 'new' value, with the m- line; and 500 o MAY associate an SDP 'max-message-size' attribute [Section 7] with 501 the m- line. 503 11.3. Generating the SDP Answer 505 When the answerer receives an offer, which contains an m- line 506 describing an SCTP association, if the answerer accepts the m- line 507 it: 509 o MUST insert a corresponding m- line in the answer, with an 510 identical m- line proto value [RFC3264]; 512 o MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' 513 or 'TCP/DTLS/SCTP', associate an SDP 'setup' attribute 514 [Section 10.3], with an 'active' or 'passive' value, with the m- 515 line; 517 o MUST, if the m- line proto is 'UDP/DTLS/SCTP' or 'TCP/DTLS/SCTP', 518 associate an SDP 'sctp-port' attribute[Section 5] with the m- 519 line; and 521 o MAY associate an SDP 'max-message-size' attribute [Section 7] with 522 the m- line. 524 Once the answerer has sent the answer, the answerer: 526 o MUST, if an SCTP association associated with the m- line has yet 527 not been established, or if an existing SCTP association is to be 528 re-established, initiate the establishing of the SCTP association; 529 and 531 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 532 connection associated with the m- line is to be established (or 533 re-established), initiate the establishing of the DTLS connection 534 (by sending a ClientHello message). 536 If the answerer does not accept the m- line in the offer, it MUST 537 assign a zero port value to the corresponding m- line in the answer. 538 In addition, the answerer MUST NOT establish an SCTP association, or 539 a DTLS connection, associated with the m- line. 541 11.4. Offerer Processing of the SDP Answer 543 When the offerer receives an answer, which contains an m- line with a 544 non-zero port value, describing an SCTP association, the offerer: 546 o MUST, if the offerer is the 'active' endpoint, if the m- line 547 proto is 'TCP/DTLS/SCTP', and if a TCP connection used to carry 548 the SCTP association has yet not been established (or if an 549 existing TCP connection is to be re-established), initiate the 550 establishing of the TCP connection; 552 o MUST, if an SCTP association associated with the m- line has yet 553 not been established (or if an existing SCTP association is to be 554 re-established), initiate the establishing of the SCTP 555 association; and 557 o MUST, if the offerer is the 'active' endpoint, and if an DTLS 558 connection associated with the m- line is to be established (or if 559 an existing DTLS connection is to be re-established), initiate the 560 establishing of the DTLS connection (by sending a ClientHello 561 message). 563 If the m- line in the answer contains a zero port value, the offerer 564 MUST NOT establish a TCP connection, an SCTP association, or a DTLS 565 connection, associated with the m- line. 567 11.5. Modifying the Session 569 When an offerer sends an updated offer, in order to modify a 570 previously established SCTP association, it follows the procedures in 571 Section 11.2, with the following exceptions: 573 o Unless the offerer wants to re-establish an existing SCTP 574 association, the offerer MUST associate an SDP connection 575 attribute, with an 'existing' value, with the m- line; and 577 o If the offerer wants to disable a previously established SCTP 578 association, it MUST assign a zero port value to the m- line 579 associated with the SCTP association, following the procedures in 580 [RFC3264]. 582 NOTE: Different SCTP association usages might define protocol 583 procedures etc that need to be performed before an SCTP association 584 is terminated. Such procedures are outside the scope of this 585 specification. 587 12. Multihoming Considerations 589 SCTP supports multihoming. An SCTP endpoint is considered multihomed 590 if it has more than one IP address on which SCTP can be used. An 591 SCTP endpoint inform the remote peer about its IP addresses using the 592 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 593 is used to describe an SCTP association, while the "c=" line contains 594 the address which was used to negotiate the SCTP association, 595 multihomed SCTP endpoints might end up using other IP addresses. 597 If an endpoint removes the IP address [RFC5061] that it offered in 598 the SDP "c=" line associated with the SCTP association, it MUST send 599 a new Offer, in which the "c=" line contains an IP address with is 600 valid within the SCTP association. 602 NOTE: In some network environments, intermediaries performing gate- 603 and firewall control use the address information in the SDP "c=" and 604 "m=" lines to authorize media, and will not pass media sent using 605 other addresses. In such network environment, if an SCTP endpoints 606 wants to change the address information on which media is sent and 607 received, it needs to send an updated Offer, in which the SDP "c=" 608 and "m=" lines contain the new address information. 610 Multihoming is not supported when sending SCTP on top of DTLS, as 611 DTLS does not expose address management to its upper layer. 613 13. NAT Considerations 615 13.1. General 617 SCTP features not present in UDP or TCP, including the checksum 618 (CRC32c) value calculated on the whole packet (rather than just the 619 header), and multihoming, introduce new challenges for NAT traversal. 620 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 621 which provides similar features of Network Address and Port 622 Translation (NAPT). 624 Current NATs typically do not support SCTP. [RFC6951] defines a 625 mechanism for sending SCTP on top of UDP, which makes it possible to 626 use SCTP with NATs and firewalls that do not support SCTP. 628 13.2. ICE Considerations 630 At the time of writing this specification, no procedures have been 631 defined for using ICE (Interactive Connectivity Establishment) 632 [RFC5768] together with SCTP. Such procedures, including the 633 associated SDP Offer/Answer procedures, are outside the scope of this 634 specification, and might be defined in a future specification. 636 14. Examples 638 TODO: ADD EXAMPLES HERE 640 15. Security Considerations 642 [RFC4566] defines general SDP security considerations, while 643 [RFC3264], [RFC4145] and [RFC4572] define security considerations 644 when using the SDP offer/answer mechanism to negotiate media streams. 646 [RFC4960] defines general SCTP security considerations. security 647 considerations on SCTP in general, while [RFC6083] defines security 648 considerations when using DTLS on top of SCTP. 650 This specification does not introduce new security considerations in 651 addition to those defined in the specifications listed above. 653 16. IANA Considerations 655 16.1. New SDP proto values 657 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 658 document.] 659 This document updates the "Session Description Protocol (SDP) 660 Parameters" registry, following the procedures in [RFC4566], by 661 adding the following values to the table in the SDP "proto" field 662 registry: 664 +---------------+---------------+-----------+ 665 | Type | SDP Name | Reference | 666 +---------------+---------------+-----------+ 667 | proto | SCTP | [RFCXXXX] | 668 | proto | SCTP/DTLS | [RFCXXXX] | 669 | proto | UDP/DTLS/SCTP | [RFCXXXX] | 670 | TCP/DTLS/SCTP | [RFCXXXX] | 671 +---------------+---------------+-----------+ 673 Table 1: SDP "proto" field values 675 16.2. New SDP Attribute 677 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 678 document.] 680 This document defines a new SDP media-level attribute,'sctp-port', as 681 follows: 683 Attribute name: sctp-port 684 Type of attribute: media 685 Subject to charset: No 686 Purpose: Indicate the SCTP port value associated 687 with the SDP Media Description. 688 Appropriate values: Integer 689 Contact name: Christer Holmberg 690 Contact e-mail: christer.holmberg@ericsson.com 691 Reference: RFCXXXX 693 16.3. association-usage Name Registry 695 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 696 document.] 698 This specification creates a new IANA registry, following the 699 procedures in [RFC5226], for the "fmt" namespace associated with the 700 'SCTP', 'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' protocol 701 identifiers. Each "fmt" value describes the usage of an entire SCTP 702 association, including all SCTP streams associated with the SCTP 703 association. 705 NOTE: Usage indication of individual SCTP streams is outside the 706 scope of this specification. 708 The "fmt" value, "association-usage", used with these "proto" is 709 required. It is defined in [Section 4]. 711 As part of this registry, IANA maintains the following information: 713 association-usage Name: .The identifier of the subprotocol, as will 714 be used in the subfield. 716 association-usage reference: A reference to the document in which 717 the association usage is defined. 719 association-usage names are to be subject to the "First Come First 720 Served" IANA registration policy [RFC5226]. 722 IANA is asked to add initial values to the registry. 724 | name | Reference | 725 -+--------------------+-------------------------------------+ 726 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 727 -+----------------------------------------------------------| 729 Figure 1 731 17. Acknowledgments 733 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 734 Kyzivat, Michael Tuexen for their comments and useful feedback. 736 18. Change Log 738 [RFC EDITOR NOTE: Please remove this section when publishing] 740 Changes from draft-ietf-mmusic-sctp-sdp-09 742 o 'DTLS/SCTP' split into 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' 744 o Procedures for realizing UDP/DTLS/SCTP- and TCP/DTLS/SCTP 745 transports added. 747 Changes from draft-ietf-mmusic-sctp-sdp-08 749 o Default SCTP port removed: 751 o - Usage of SDP sctp-port attribute mandatory. 753 o SDP max-message-size attribute defined: 755 o - Attribute definition. 757 o - SDP Offer/Answer procedures. 759 o Text about SDP direction attributes added. 761 o Text about TLS role determination added. 763 19. References 765 19.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 771 with Session Description Protocol (SDP)", RFC 3264, June 772 2002. 774 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 775 the Session Description Protocol (SDP)", RFC 4145, 776 September 2005. 778 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 779 Extensions (MIME) Part Four: Registration Procedures", BCP 780 13, RFC 4289, December 2005. 782 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 783 Description Protocol", RFC 4566, July 2006. 785 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 786 and RTP Control Protocol (RTCP) Packets over Connection- 787 Oriented Transport", RFC 4571, July 2006. 789 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 790 Transport Layer Security (TLS) Protocol in the Session 791 Description Protocol (SDP)", RFC 4572, July 2006. 793 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 794 4960, September 2007. 796 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 797 Kozuka, "Stream Control Transmission Protocol (SCTP) 798 Dynamic Address Reconfiguration", RFC 5061, September 799 2007. 801 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 802 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 803 May 2008. 805 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 806 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 808 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 809 Security Version 1.2", RFC 6347, January 2012. 811 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 812 Specifications and Registration Procedures", BCP 13, RFC 813 6838, January 2013. 815 [I-D.ietf-tsvwg-sctp-dtls-encaps] 816 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 817 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 818 dtls-encaps-06 (work in progress), November 2014. 820 19.2. Informative References 822 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 823 for Establishing a Secure Real-time Transport Protocol 824 (SRTP) Security Context Using Datagram Transport Layer 825 Security (DTLS)", RFC 5763, May 2010. 827 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 828 Connectivity Establishment (ICE) in the Session Initiation 829 Protocol (SIP)", RFC 5768, April 2010. 831 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 832 Transport Layer Security (DTLS) for Stream Control 833 Transmission Protocol (SCTP)", RFC 6083, January 2011. 835 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 836 Control Transmission Protocol (SCTP) Packets for End-Host 837 to End-Host Communication", RFC 6951, May 2013. 839 [I-D.ietf-behave-sctpnat] 840 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 841 Transmission Protocol (SCTP) Network Address Translation", 842 draft-ietf-behave-sctpnat-09 (work in progress), September 843 2013. 845 Authors' Addresses 847 Christer Holmberg 848 Ericsson 849 Hirsalantie 11 850 Jorvas 02420 851 Finland 853 Email: christer.holmberg@ericsson.com 855 Salvatore Loreto 856 Ericsson 857 Hirsalantie 11 858 Jorvas 02420 859 Finland 861 Email: Salvatore.Loreto@ericsson.com 863 Gonzalo Camarillo 864 Ericsson 865 Hirsalantie 11 866 Jorvas 02420 867 Finland 869 Email: Gonzalo.Camarillo@ericsson.com