idnits 2.17.1 draft-ietf-mmusic-sctp-sdp-09.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 5, 2014) is 3428 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 499, but not defined == Missing Reference: 'Section 7' is mentioned on line 501, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 643, 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 (~~), 6 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 8, 2015 Ericsson 6 December 5, 2014 8 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 9 Session Description Protocol (SDP) 10 draft-ietf-mmusic-sctp-sdp-09 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' and '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 8, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 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. SCTP Association Management . . . . . . . . . . . . . . . . . 8 80 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute . . . . 8 82 8.3. SDP setup Attribute . . . . . . . . . . . . . . . . . . . 8 83 8.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 84 8.3.2. SCTP Association Initiation . . . . . . . . . . . . . 9 85 8.3.3. TLS Role Determination . . . . . . . . . . . . . . . 9 86 8.4. SDP connection Attribute . . . . . . . . . . . . . . . . 9 87 9. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 10 88 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 9.2. Generating the Initial SDP Offer . . . . . . . . . . . . 11 90 9.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 11 91 9.4. Offerer Processing of the SDP Answer . . . . . . . . . . 12 92 9.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12 93 10. Multihoming Considerations . . . . . . . . . . . . . . . . . 13 94 11. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . 13 96 11.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 13 98 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 100 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 101 14.1. New SDP proto values . . . . . . . . . . . . . . . . . . 14 102 14.2. New SDP Attribute . . . . . . . . . . . . . . . . . . . 14 103 14.3. association-usage Name Registry . . . . . . . . . . . . 15 104 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 105 16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 108 17.2. Informative References . . . . . . . . . . . . . . . . . 17 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 111 1. Introduction 113 SDP (Session Description Protocol) [RFC4566] provides a general- 114 purpose format for describing multimedia sessions in announcements or 115 invitations. TCP-Based Media Transport in the Session Description 116 Protocol (SDP) [RFC4145] specifies a general mechanism for describing 117 and establishing TCP (Transmission Control Protocol) [RFC5246] 118 streams. Connection-Oriented Media Transport over the Transport 119 Layer Security (TLS) Protocol in the Session Description Protocol 120 (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based 121 media streams that are protected using TLS. 123 SCTP (Stream Control Transmission Protocol) is a transport protocol 124 used to establish associations between two endpoints. 126 This specification describes how to describe SCTP associations using 127 the Session Description Protocol (SDP) [RFC4566], and defines the 128 following new SDP Media Description [RFC4566] protocol identifiers 129 (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. 131 The specification also describes how to use the new proto values 132 together with the SDP Offer/Answer mechanism [RFC3264] in order to 133 negotiate and establish SCTP associations, and how to indicate the 134 SCTP application usage. 136 NOTE: TLS is designed to run on top of a byte-stream oriented 137 transport protocol providing a reliable, in-sequence delivery like 138 TCP. [RFC6083] presents serious limitations with transporting SCTP 139 on top of TLS. Therefore, defining a mechanism to negotiate media 140 streams transported using SCTP on top of TLS is outside the scope of 141 this specification. 143 2. Terminology 145 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 146 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 147 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 148 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 149 levels for compliant implementations. 151 3. SCTP Terminology 153 SCTP Association: A protocol relationship between SCTP endpoints, 154 composed of the two SCTP endpoints and protocol state information 155 including Verification Tags and the currently active set of 156 Transmission Sequence Numbers (TSNs), etc. An association can be 157 uniquely identified by the transport addresses used by the endpoints 158 in the association. Two SCTP endpoints MUST NOT have more than one 159 SCTP association between them at any given time. 161 SCTP Stream: A unidirectional logical channel established from one to 162 another associated SCTP endpoint, within which all user messages are 163 delivered in sequence except for those submitted to the unordered 164 delivery service. 166 SCTP Transport address: A transport address is traditionally defined 167 by a network-layer address, a transport-layer protocol, and a 168 transport-layer port number. In the case of SCTP running over IP, a 169 transport address is defined by the combination of an IP address and 170 an SCTP port number (where SCTP is the transport protocol). 172 4. SDP Media Descriptions 174 4.1. General 176 This section defines the following new SDP Media Description (m- 177 line) protocol identifiers (proto values) for describing an SCTP 178 association: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The section also 179 describes how an m- line, associated with the proto values, is 180 created. 182 The following is the format for an 'm' line, as specified in RFC4566 183 [RFC4566]: 185 m= ... 187 The 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' proto values are similar to 188 both the 'UDP' and 'TCP' proto values in that they only describe the 189 transport protocol and not the upper-layer protocol. 191 NOTE: When the 'DTLS/SCTP' proto value is used, the underlying 192 transport protocol is either UDP or TCP. 194 The m- line fmt value, identifying the application-layer protocol, 195 MUST be registered by IANA. 197 4.2. Protocol Identifiers 199 The new proto values are defined as below: 201 o The 'SCTP' proto value describes an SCTP association, as defined 202 in [RFC4960]. 204 o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer 205 Security (DTLS) [RFC6347] connection on top of an SCTP 206 association, as defined in [RFC6083]. 208 o The 'DTLS/SCTP' proto value describes an SCTP association on top 209 of a DTLS connection, as defined in 210 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 212 NOTE: In the case of 'DTLS/SCTP', the actual transport protocol below 213 DTLS is either UDP or TCP. 215 OPEN ISSUE #1: It is FFS whether separate proto values will be used, 216 depending on whether the underlying transport protocol is UDP (e.g. 217 'UDP/DTLS/SCTP') or TCP (e.g. 'TCP/DTLS/SCTP'). 219 4.3. Media Format Management 221 [RFC4566] defines that specifications defining new proto values must 222 define the rules by which their media format (fmt) namespace is 223 managed. Use of an existing MIME subtype for the format is 224 encouraged. If no MIME subtype exists, it is recommended that a 225 suitable one is registered through the IETF process [RFC6838] 226 [RFC4289] by production of, or reference to, a standards-track RFC 227 that defines the transport protocol for the format. 229 An m- line with a proto value of 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' 230 always describe a single SCTP association. 232 In addition, such m- line MUST further indicate the application-layer 233 protocol using an 'fmt' identifier. There MUST be exactly one 'fmt' 234 value per m- line associated with the proto values defined in this 235 specification. The "fmt" namespace associated with those proto 236 values describes the generic application usage of the entire SCTP 237 association, including the associated SCTP streams. 239 NOTE: A mechanism on how to describe, and manage, individual SCTP 240 streams within an SCTP association, is outside the scope of this 241 specification. 243 4.4. Syntax 245 sctp-m-line = %x6d "=" 246 ("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) / 247 ("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) / 248 ("application" SP udp-port SP "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 TEMP: 261 m=application 12345 DTLS/SCTP webrtc-datachannel 262 a=max-message-size=100000 263 m=application 12345 DTLS/SCTP webrtc-datachannel 264 a=fmtp:webrtc-datachannel max-message-size=100000 266 5. SDP 'sctp-port' Attribute 268 5.1. General 270 This section defines a new SDP media-level attribute, 'sctp-port'. 271 The attribute can be associated with an SDP media descriptor (m- 272 line) with a 'DTLS/SCTP' proto value, in which case the m- line port 273 value indicates the port of the underlying transport protocol (UDP or 274 TCP). 276 TEMP: If the SDP sctp-port attribute is not present, the m- line 277 SHOULD be discarded. If the SDP sctp-port attribute is not present, 278 the default value is 5000. 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 behaviour 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 6.2. Syntax 311 max-message-size-attr = "a=max-message-size:" max-message-size 312 max-message-size = 1*DIGIT 314 7. SDP 'fmtp' Attribute 316 7.1. General 318 The SDP 'fmtp' attribute can be used with an m- line, associated with 319 an SCTP association, to indicate the maximum message size that an 320 SCTP endpoint is willing to receive, for a particular SCTP 321 association usage, on that SCTP association. 323 The remote peer MUST assume that larger messages will be rejected by 324 the SCTP endpoint. SCTP endpoints need to decide on appropriate 325 behaviour in case a message that exceeds the maximum size needs to be 326 sent. 328 If the SDP 'fmtp' attribute contains a maximum message size value of 329 zero, it indicates the SCTP endpoint will handle messages of any 330 size, subject to memory capacity etc. 332 If the SDP 'fmtp' attribute is not present, the default value is 64K. 334 NOTE: This specification only defines the usage of the SDP 'max- 335 message-size' attribute when associated with an m- line containing 336 one of the following proto field values: 'SCTP', 'SCTP/DTLS' or 337 'DTLS/SCTP'. Usage of the attribute with other proto field values 338 needs to be defined in a separate specification. 340 7.2. Syntax 342 sctpmap-attr = "a=fmtp:" association-usage [max-message-size] 343 max-message-size = "max-message-size" EQUALS 1*DIGIT 345 8. SCTP Association Management 347 8.1. General 349 The management of an SCTP association is identical to the management 350 of a TCP connection. An SCTP endpoints MUST follow the rules in 351 Section 6 of [RFC4145] to manage SCTP associations. Whether to use 352 the SCTP ordered or unordered delivery service is up to the 353 applications using the SCTP association, and this specification does 354 not define a mechanism to indicate the type of delivery service using 355 SDP. 357 8.2. SDP sendrecv/sendonly/sendrecv/inactive Attribute 359 This specification does not define any semantics for the SDP 360 direction attributes [RFC4566]. Specifications for an individual 361 SCTP association usage MAY define how the attributes can be used with 362 that association usage. If the semantics of these attributes for an 363 SCTP association usage has not been defined, SDP direction attributes 364 MUST be discarded if present. 366 8.3. SDP setup Attribute 368 8.3.1. General 370 The SDP setup attribute is used to determine the 'active/passive' 371 status of the endpoints, following the procedures for TCP in 372 [RFC4145]. 374 8.3.2. SCTP Association Initiation 376 Both the 'active' and 'passive' endpoint MUST initiate the SCTP 377 association, and MUST use the same SCTP port as client port and 378 server port (in order to prevent two separate SCTP associations from 379 being established). 381 NOTE: The procedure above is different from TCP, where only the 382 'active' endpoint initiates the TCP connection [RFC4145]. 384 If the m- line proto field value is 'DTLS/SCTP', and if SCTP is 385 carried on top of TCP, only the 'active' endpoint will initiate the 386 TCP connection, following the procedures in [RFC4145], while both 387 endpoints will initiate the SCTP association carried on top of the 388 TCP connection. 390 8.3.3. TLS Role Determination 392 If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the 393 'active/passive' status is used to determine the TLS roles. 394 Following the procedures in [RFC4572], the 'active' endpoint will 395 take the TLS client role. 397 Once a DTLS connection has been established, if the 'active/passive' 398 status of the endpoints change during a session, a new DTLS 399 connection MUST be established. Therefore, endpoints SHOULD NOT 400 change the 'active/passive' status in subsequent offers and answers, 401 unless they want to establish a new DTLS connection. 403 If the transport parameters or the key fingerprints change, the 404 endpoints MUST establish a new DTLS connection. In such case the 405 'active/passive' status of the endpoints will again be determined 406 following the procedures in [RFC4145], and the new status will be 407 used to determine the TLS roles associated with the new DTLS 408 connection. 410 NOTE: The procedure above is identical to the one defined for SRTP- 411 DTLS in [RFC5763]. 413 NOTE: A new DTLS connection needs to be established if the transport 414 parameters or the key fingerprints change. 416 8.4. SDP connection Attribute 418 The SDP connection attribute is used following the procedures in 419 [RFC4145], with the additional SCTP specific considerations described 420 in this section. 422 The SDP connection attribute only applies to an SCTP association and, 423 if the m- line proto field value is 'DTLS/SCTP', also to the TCP 424 connection which is used to carry the SCTP association. An attribute 425 'new' value indicates that a new SCTP association (and, if 426 applicable, the TCP connection, have to be established, following the 427 procedures in [RFC4145]. 429 OPEN ISSUE #3: We need to determine whether the SDP connection 430 attribute only applies to the transport-layer protocol, and not e.g. 431 to an SCTP assocation carried on top of UDP or TCP. 433 The SDP connection attribute value does not impact an existing DTLS 434 connection. Section 8.3.3 describes in which cases a new DTLS 435 connections will be established. 437 NOTE: if the m- line proto field value is 'SCTP/DTLS', and if the 438 SCTP association is re-established, the DTLS connection also needs to 439 be re-established. 441 OPEN ISSUE #2: Verify that the above statement regarding 'SCTP/DTLS' 442 is correct. 444 9. SDP Offer/Answer Procedures 446 9.1. General 448 This section defines the SDP Offer/Answer [RFC3264] procedures for 449 negotiating and establishing an SCTP association. Unless explicitly 450 stated, the procedures apply to all m- line proto values ('SCTP', 451 'SCTP/DTLS' and 'DTLS/SCTP') defined in this specification. 453 If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', each 454 endpoint MUST provide a certificate fingerprint, using the SDP 455 'fingerprint' attribute [RFC4145], if the endpoint supports, and is 456 willing to use, a cipher suite with an associated certificate. 458 The authentication certificates are interpreted and validated as 459 defined in [RFC4572]. Self-signed certificates can be used securely, 460 provided that the integrity of the SDP description is assured as 461 defined in [RFC4572]. 463 NOTE: The procedures apply to a specific m- line describing an SCTP 464 association. If an offer or answer contains multiple m- line 465 describing SCTP associations, the procedures are applied separately 466 to each m- line. 468 9.2. Generating the Initial SDP Offer 470 When the offerer creates an initial offer, the offerer: 472 o MUST, if the m- line proto field value is 'SCTP/DTLS' or 'DTLS/ 473 SCTP', associate an SDP setup attribute [Section 8.3], with an 474 'actpass' value, with the m- line; 476 o MUST, if the m- line proto field is 'DTLS/SCTP', associate an SDP 477 sctp-port attribute[Section 5] with the m- line; 479 o MUST associate an SDP 'connection' attribute [Section 8.4], with a 480 'new' value, with the m- line; and 482 o MAY associate an SDP 'max-message-size' attribute [Section 7] with 483 the m- line. 485 9.3. Generating the SDP Answer 487 When the answerer receives an offer, which contains an m- line 488 describing an SCTP association, if the answerer accepts the m- line 489 it: 491 o MUST insert a corresponiding m- line in the answer, with an 492 identical m- line proto value [RFC3264]; 494 o MUST, if the m- line proto field value is 'SCTP/DTLS' or 'DTLS/ 495 SCTP', associate an SDP setup attribute [Section 8.3], with an 496 'active' or 'passive' value, with the m- line; 498 o MUST, if the m- line proto field is 'DTLS/SCTP', associate an SDP 499 sctp-port attribute[Section 5] with the m- line; 501 o MAY associate an SDP 'max-message-size' attribute [Section 7] with 502 the m- line. 504 Once the answerer has sent the answer, the answerer: 506 o MUST, if an SCTP association associated with the m- line has yet 507 not been established, or if an existing SCTP association is to be 508 re-established, initiate the establishing of the SCTP association; 509 and 511 o MUST, if the answerer is the 'active' endpoint, and if an DTLS 512 connection associated with the m- line is to be established (or 513 re-established), initiate the establishing of the DTLS connection 514 (by sending a ClientHello message). 516 If the answerer does not accept the m- line in the offer, it MUST 517 assign a zero port value to the corresponding m- line in the answer. 518 In addition, the answerer MUST NOT establish an SCTP association, or 519 a DTLS connection, associated with the m- line. 521 9.4. Offerer Processing of the SDP Answer 523 When the offerer receives an answer, which contains an m- line with a 524 non-zero port value, describing an SCTP association, the offerer: 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 offerer 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 m- line in the answer contains a zero port value, the offerer 537 MUST NOT establish an SCTP association, or a DTLS connection, 538 associated with the m- line. 540 9.5. Modifying the Session 542 When an offerer sends an updated offer, in order to modify a 543 previously established SCTP assiciation, it follows the procedures in 544 Section 9.2, with the following exceptions: 546 o Unless the offerer wants to re-establish an existing SCTP 547 association, the offerer MUST associate an SDP connection 548 attribute, with an 'existing' value, with the m- line; and 550 o If the offerer wants to disable a previously established SCTP 551 association, it MUST assign a zero port value to the m- line 552 associated with the SCTP association, following the procedures in 553 [RFC3264]. 555 NOTE: Different SCTP association usages might define protocol 556 procedures etc that need to be performed before an SCTP association 557 is terminated. Such procedures are outside the scope of this 558 specification. 560 10. Multihoming Considerations 562 SCTP supports multihoming. An SCTP endpoint is considered multihomed 563 if it has more than one IP address on which SCTP can be used. An 564 SCTP endpoint inform the remote peer about its IP addresses using the 565 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP 566 is used to describe an SCTP association, while the "c=" line contains 567 the address which was used to negotiate the SCTP association, 568 multihomed SCTP endpoints might end up using other IP addresses. 570 If an endpoint removes the IP address [RFC5061] that it offered in 571 the SDP "c=" line associated with the SCTP association, it MUST send 572 a new Offer, in which the "c=" line contains an IP address with is 573 valid within the SCTP association. 575 NOTE: In some network environments, intermediaries performing gate- 576 and firewall control use the address information in the SDP "c=" and 577 "m=" lines to authorize media, and will not pass media sent using 578 other addresses. In such network environment, if an SCTP endpoints 579 wants to change the address information on which media is sent and 580 received, it needs to send an updated Offer, in which the SDP "c=" 581 and "m=" lines contain the new address information. 583 Multihoming is not supported when sending SCTP on top of DTLS, as 584 DTLS does not expose address management to its upper layer. 586 11. NAT Considerations 588 11.1. General 590 SCTP features not present in UDP or TCP, including the checksum 591 (CRC32c) value calculated on the whole packet (rather than just the 592 header), and multihoming, introduce new challenges for NAT traversal. 593 [I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT, 594 which provides similar features of Network Address and Port 595 Translation (NAPT). 597 Current NATs typically do not support SCTP. [RFC6951] defines a 598 mechanism for sending SCTP on top of UDP, which makes it possible to 599 use SCTP with NATs and firewalls that do not support SCTP. 601 11.2. ICE Considerations 603 At the time of writing this specification, no procedures have been 604 defined for using ICE ICE (Interactive Connectivity Establishment) 605 [RFC5768] together with SCTP. Such procedures, including the 606 associated SDP Offer/Answer procedures, are outside the scope of this 607 specification, and might be defined in a future specification. 609 12. Examples 611 TODO: ADD EXAMPLES HERE 613 13. Security Considerations 615 [RFC4566] defines general SDP security considerations, while 616 [RFC3264], [RFC4145] and [RFC4572] define security considerations 617 when using the SDP Offer/Answer mechanism to negotiate media streams. 619 [RFC4960] defines general SCTP security considerations. security 620 considerations on SCTP in general, while [RFC6083] defines security 621 considerations when using DTLS on top of SCTP. 623 This specification does not introduce new security considerations in 624 addition to those defined in the specifications listed above. 626 14. IANA Considerations 628 14.1. New SDP proto values 630 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 631 document.] 633 This document updates the "Session Description Protocol (SDP) 634 Parameters" registry, following the procedures in [RFC4566], by 635 adding the following values to the table in the SDP "proto" field 636 registry: 638 +-------+-----------+-----------+ 639 | Type | SDP Name | Reference | 640 +-------+-----------+-----------+ 641 | proto | SCTP | [RFCXXXX] | 642 | proto | SCTP/DTLS | [RFCXXXX] | 643 | proto | DTLS/SCTP | [RFCXXXX] | 644 +-------+-----------+-----------+ 646 Table 1: SDP "proto" field values 648 14.2. New SDP Attribute 650 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 651 document.] 653 This document defines a new SDP media-level attribute,'sctp-port', as 654 follows: 656 Attribute name: sctp-port 657 Type of attribute: media 658 Subject to charset: No 659 Purpose: Indicate the SCTP port value associated 660 with the SDP Media Description. 661 Appropriate values: Integer 662 Contact name: Christer Holmberg 663 Contact e-mail: christer.holmberg@ericsson.com 664 Reference: RFCXXXX 666 14.3. association-usage Name Registry 668 [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this 669 document.] 671 This specification creates a new IANA registry, following the 672 procedures in [RFC5226], for the "fmt" namespace associated with the 673 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers. Each "fmt" 674 value describes the usage of an entire SCTP association, including 675 all SCTP streams associated with the SCTP association. 677 NOTE: Usage indication of individual SCTP streams is outside the 678 scope of this specification. 680 The "fmt" value, "association-usage", used with these "proto" is 681 required. It is defined in section Section 4. 683 As part of this registry, IANA maintains the following information: 685 association-usage Name: .The identifier of the subprotocol, as will 686 be used in the subfield. 688 association-usage reference: A reference to the document in which 689 the the association usage is defined. 691 association-usage names are to be subject to the "First Come First 692 Served" IANA registration policy [RFC5226]. 694 IANA is asked to add initial values to the registry. 696 | name | Reference | 697 -+--------------------+-------------------------------------+ 698 | webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx | 699 -+----------------------------------------------------------| 701 Figure 1 703 15. Acknowledgments 705 The authors wish to thank Harald Alvestrand, Randell Jesup, Paul 706 Kyzivat, Michael Tuexen for their comments and useful feedback. 708 16. Change Log 710 [RFC EDITOR NOTE: Please remove this section when publishing] 712 Changes from draft-ietf-mmusic-sctp-sdp-08 714 o Default SCTP port removed 716 o - Usage of SDP sctp-port attribute mandatory 718 o SDP max-message-size attribute defined 720 o - Attribute definition 722 o - SDP Offer/Answer procedures 724 o Text about SDP direction attributes added 726 o Text about TLS role determination added 728 17. References 730 17.1. Normative References 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 736 with Session Description Protocol (SDP)", RFC 3264, June 737 2002. 739 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 740 the Session Description Protocol (SDP)", RFC 4145, 741 September 2005. 743 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 744 Extensions (MIME) Part Four: Registration Procedures", BCP 745 13, RFC 4289, December 2005. 747 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 748 Description Protocol", RFC 4566, July 2006. 750 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 751 Transport Layer Security (TLS) Protocol in the Session 752 Description Protocol (SDP)", RFC 4572, July 2006. 754 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 755 4960, September 2007. 757 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 758 Kozuka, "Stream Control Transmission Protocol (SCTP) 759 Dynamic Address Reconfiguration", RFC 5061, September 760 2007. 762 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 763 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 764 May 2008. 766 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 767 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 769 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 770 Security Version 1.2", RFC 6347, January 2012. 772 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 773 Specifications and Registration Procedures", BCP 13, RFC 774 6838, January 2013. 776 [I-D.ietf-tsvwg-sctp-dtls-encaps] 777 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 778 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 779 dtls-encaps-06 (work in progress), November 2014. 781 17.2. Informative References 783 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 784 for Establishing a Secure Real-time Transport Protocol 785 (SRTP) Security Context Using Datagram Transport Layer 786 Security (DTLS)", RFC 5763, May 2010. 788 [RFC5768] Rosenberg, J., "Indicating Support for Interactive 789 Connectivity Establishment (ICE) in the Session Initiation 790 Protocol (SIP)", RFC 5768, April 2010. 792 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 793 Transport Layer Security (DTLS) for Stream Control 794 Transmission Protocol (SCTP)", RFC 6083, January 2011. 796 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 797 Control Transmission Protocol (SCTP) Packets for End-Host 798 to End-Host Communication", RFC 6951, May 2013. 800 [I-D.ietf-behave-sctpnat] 801 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 802 Transmission Protocol (SCTP) Network Address Translation", 803 draft-ietf-behave-sctpnat-09 (work in progress), September 804 2013. 806 Authors' Addresses 808 Christer Holmberg 809 Ericsson 810 Hirsalantie 11 811 Jorvas 02420 812 Finland 814 Email: christer.holmberg@ericsson.com 816 Salvatore Loreto 817 Ericsson 818 Hirsalantie 11 819 Jorvas 02420 820 Finland 822 Email: Salvatore.Loreto@ericsson.com 824 Gonzalo Camarillo 825 Ericsson 826 Hirsalantie 11 827 Jorvas 02420 828 Finland 830 Email: Gonzalo.Camarillo@ericsson.com