idnits 2.17.1 draft-loreto-mmusic-sctp-sdp-07.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4785 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) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** 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 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-04 == Outdated reference: A later version (-07) exists of draft-tuexen-sctp-udp-encaps-06 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC S. Loreto 3 Internet-Draft G. Camarillo 4 Intended status: Standards Track Ericsson 5 Expires: September 15, 2011 March 14, 2011 7 Stream Control Transmission Protocol (SCTP)-Based Media Transport in the 8 Session Description Protocol (SDP) 9 draft-loreto-mmusic-sctp-sdp-07 11 Abstract 13 SCTP (Stream Control Transmission Protocol) is a transport protocol 14 used to establish associations between two endpoints. This document 15 describes how to express media transport over SCTP in SDP (Session 16 Description Protocol). This document defines the 'SCTP' and 'SCTP/ 17 DTLS' protocol identifiers for SDP. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . . 3 56 4. The Setup and Connection Attributes and Association 57 Management . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . . 5 61 6.2. Existing Connection Reuse . . . . . . . . . . . . . . . . . 6 62 6.3. SDP description for DTLS Connection . . . . . . . . . . . . 6 63 7. Network Address Translators (NAT) Considerations . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 SDP (Session Description Protocol) [RFC4566] provides a general- 72 purpose format for describing multimedia sessions in announcements or 73 invitations. RFC4145 [RFC4145] specifies a general mechanism for 74 describing and establishing TCP (Transmission Control Protocol) 75 streams. RFC 4572 [RFC4572] extends RFC4145 [RFC4145] for describing 76 TCP-based media streams that are protected using TLS (Transport Layer 77 Security) [RFC5246]. 79 This document defines a new protocol identifier, 'SCTP', to describe 80 SCTP-based [RFC4960] media streams. Additionally, this document 81 specifies the use of the 'setup' and 'connection' SDP attributes to 82 establish SCTP associations. These attributes were defined in 83 RFC4145 [RFC4145] for TCP. This document discusses their use with 84 SCTP. 86 Additionally this document defines a new protocol identifier, 'SCTP/ 87 DTLS', to establish secure SCTP-based media streams over DTLS 88 (Datagram Transport Layer Security) [RFC4347], as specified in 89 [RFC6083], using SDP. The authentication certificates are 90 interpreted and validated as defined in RFC4572 [RFC4572]. Self- 91 signed certificates can be used securely, provided that the integrity 92 of the SDP description is assured as defined in RFC4572 [RFC4572]. 94 TLS is designed to run on top of a byte-stream oriented transport 95 protocol providing a realible, in-sequence delivery like TCP. Since 96 no-one so far has implemented SCTP over TLS, due to some serious 97 limitations described in [RFC6083], this document does not make use 98 of TLS over SCTP as described in RFC3436 [RFC3436]. 100 2. Terminology 102 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 103 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 104 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 105 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 106 levels for compliant implementations. 108 3. Protocol Identifier 110 The following is the format for an 'm' line, as specified in RFC4566 111 [RFC4566]: 113 m= ... 115 This document defines two new values for the 'proto' field: 'SCTP' 116 and 'SCTP/DTLS'. 118 The 'SCTP' protocol identifier is similar to both the 'UDP' and 'TCP' 119 protocol identifiers in that it only describes the transport protocol 120 and not the upper-layer protocol. Media described using an 'm' line 121 containing the 'SCTP' protocol identifier are carried using SCTP 122 [RFC4960]. 124 The 'SCTP/DTLS' protocol identifier indicates that the media 125 described will use the Datagram Transport Layer Security (DTLS) 126 [RFC4347] over SCTP as specified in [RFC6083]. 128 An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' MUST further qualify 129 the application-layer protocol using an fmt identifier. 131 An 'm' line that specifies 'SCTP/DTLS' MUST further provide a 132 certificate fingerprint. An SDP attribute (an 'a' line) is used to 133 transport and exchange end point certificate. The authentication 134 certificates are interpreted and validated as defined in [RFC4572]. 136 4. The Setup and Connection Attributes and Association Management 138 The use of the 'setup' and 'connection' attributes in the context of 139 an SCTP association is identical to the use of these attributes in 140 the context of a TCP connection. That is, SCTP endpoints MUST follow 141 the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to 142 the use of the 'setup' and 'connection' attributes in offer/answer 143 [RFC3264] exchanges. 145 The management of an SCTP association is identical to the management 146 of a TCP connection. That is, SCTP endpoints MUST follow the rules 147 in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations. 148 Whether to use the SCTP ordered or unordered delivery service is up 149 to the applications using the SCTP association. 151 5. Multihoming 153 An SCTP endpoint, unlike a TCP endpoint, can be multihomed. An SCTP 154 endpoint is considered to be multihomed if it has more than one IP 155 address. A multihomed SCTP endpoint informs a remote SCTP endpoint 156 about all its IP addresses using the address parameters of the INIT 157 or the INIT-ACK chunk (depending on whether or not the multihomed 158 endpoint is the one initiating the establishment of the association). 159 Therefore, once the address provided in the 'c' line has been used to 160 establish the SCTP association (i.e., to send the INIT chunk), 161 address management is performed using SCTP. This means that two SCTP 162 endpoints can use addresses that were not listed in the 'c' line but 163 that were negotiated using SCTP mechanisms. 165 Some intermediaries performing firewall control use the addresses in 166 offer/answer exchanges to perform media authorization. That is, they 167 will not let media through unless it is sent to the address in the 168 'c' line. 170 The SCTP endpoints MAY choose to use the main address all the time 171 (e.g., they do not send retransmissions to a backup address) and to 172 send a re-INVITE every time they change that address. 174 However not using non-primary paths for retransmission means not to 175 utilize the multi-homing feature of SCTP for resilience. Therefore, 176 the SCTP endpoints MAY use the 'candidate' SDP attribute to 177 disclosure, to intermediaries performing firewall control, all its 178 alternative IP addresses; this will avoid the need for the SCTP 179 endpoints to send a re-INVITE every time they change the primary 180 path. 182 6. Examples 184 The following examples show the use of the 'setup' and 'connection' 185 SDP attributes. As discussed in Section 4, the use of these 186 attributes with an SCTP association is identical to their use with a 187 TCP connection. For the purpose of brevity, the main portion of the 188 session description is omitted in the examples, which only show 'm' 189 lines and their attributes (including 'c' lines). 191 6.1. Actpass/Passive 193 An offerer at 192.0.2.2 signals its availability for an SCTP 194 association at SCTP port 54111. Additionally, this offerer is also 195 willing to initiate the SCTP association: 197 m=image 54111 SCTP * 198 c=IN IP4 192.0.2.2 199 a=setup:actpass 200 a=connection:new 202 Figure 1 204 The endpoint at 192.0.2.1 responds with the following description: 206 m=image 54321 SCTP * 207 c=IN IP4 192.0.2.1 208 a=setup:passive 209 a=connection:new 211 Figure 2 213 This will cause the offerer (at 192.0.2.2) to initiate an SCTP 214 association to port 54321 at 192.0.2.1. 216 6.2. Existing Connection Reuse 218 Subsequent to the exchange in Section 6.1, another offer/answer 219 exchange is initiated in the opposite direction. The endpoint at 220 192.0.2.1, which now acts as the offerer, wishes to continue using 221 the existing association: 223 m=application 54321 SCTP * 224 c=IN IP4 192.0.2.1 225 a=setup:passive 226 a=connection:new 228 Figure 3 230 The endpoint at 192.0.2.2 also wishes to use the existing SCTP 231 association and responds with the following description: 233 m=application 9 SCTP * 234 c=IN IP4 192.0.2.2 235 a=setup:active 236 a=connection:new 238 Figure 4 240 The existing SCTP association between 192.0.2.2 and 192.0.2.1 will be 241 reused. 243 6.3. SDP description for DTLS Connection 245 An offerer at 192.0.2.2 signals the availability of a T.38 fax 246 session over SCTP/DTLS. 248 m=image 54111 SCTP/DTLS t38 249 c=IN IP4 192.0.2.2 250 a=setup:actpass 251 a=connection:new 252 a=fingerprint:SHA-1 \ 253 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 255 Figure 5 257 7. Network Address Translators (NAT) Considerations 259 SCTP specific features (not present in UDP/TCP), as the checksum 260 (CRC32c) value calculated on the whole packet (not just the header) 261 or multihoming, present new challenges for a NAT. 262 [I-D.ietf-behave-sctpnat] describes an SCTP specific variant of NAT 263 which provides similar features of Network Address and Port 264 Translation (NAPT). 266 As an alternative to design SCTP specific NAT, SCTP-over-UDP 267 [I-D.tuexen-sctp-udp-encaps] makes possible, encapsulating SCTP 268 packets into UDP packets, to use SCTP in networks with legacy NAT and 269 firewalls not supporting SCTP. 271 OPEN ISSUE: do we want to include in SDP the ability to signal SCTP- 272 over-UDP ? 274 TBD: How to use Interactive Connectivity Establishment (ICE) to 275 establish SCTP streams. 277 OPENT ISSUE: Do we want ICE to only use SCTP over IP candidates, or 278 we ant ICE to use SCTP over UDP candidates as well? 280 8. Security Considerations 282 See RFC 4566 [RFC4566] for security considerations on the use of SDP 283 in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572 284 [RFC4572] for security considerations on establishing media streams 285 using offer/answer exchanges. See RFC 4960 [RFC4960] for security 286 considerations on SCTP in general and [RFC6083] for security 287 consideration using DTLS on top of SCTP. This specification does not 288 introduce any new security consideration in addition to the ones 289 discussed in those specifications. 291 9. IANA Considerations 293 This document defines two new proto values: 'SCTP' and 'SCTP/DTLS'. 294 Their formats are defined in Section 3. These proto values should be 295 registered by the IANA under "Session Description Protocol (SDP) 296 Parameters" under "proto". 298 The SDP specification, [RFC4566], states that specifications defining 299 new proto values, like the SCTP and SCTP/DTLS proto values defined in 300 this RFC, must define the rules by which their media format (fmt) 301 namespace is managed. For the SCTP protocol, new formats SHOULD have 302 an associated MIME registration. Use of an existing MIME subtype for 303 the format is encouraged. If no MIME subtype exists, it is 304 RECOMMENDED that a suitable one is registered through the IETF 305 process [RFC4288] [RFC4289] by production of, or reference to, a 306 standards-track RFC that defines the transport protocol for the 307 format. 309 10. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 315 with Session Description Protocol (SDP)", RFC 3264, 316 June 2002. 318 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 319 Layer Security over Stream Control Transmission Protocol", 320 RFC 3436, December 2002. 322 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 323 the Session Description Protocol (SDP)", RFC 4145, 324 September 2005. 326 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 327 Registration Procedures", BCP 13, RFC 4288, December 2005. 329 [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail 330 Extensions (MIME) Part Four: Registration Procedures", 331 BCP 13, RFC 4289, December 2005. 333 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 334 Security", RFC 4347, April 2006. 336 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 337 Description Protocol", RFC 4566, July 2006. 339 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 340 Transport Layer Security (TLS) Protocol in the Session 341 Description Protocol (SDP)", RFC 4572, July 2006. 343 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 344 RFC 4960, September 2007. 346 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 347 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 349 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 350 Transport Layer Security (DTLS) for Stream Control 351 Transmission Protocol (SCTP)", RFC 6083, January 2011. 353 [I-D.ietf-behave-sctpnat] 354 Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 355 Transmission Protocol (SCTP) Network Address Translation", 356 draft-ietf-behave-sctpnat-04 (work in progress), 357 December 2010. 359 [I-D.tuexen-sctp-udp-encaps] 360 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 361 Packets", draft-tuexen-sctp-udp-encaps-06 (work in 362 progress), January 2011. 364 Authors' Addresses 366 Salvatore Loreto 367 Ericsson 368 Hirsalantie 11 369 Jorvas 02420 370 Finland 372 Email: Salvatore.Loreto@ericsson.com 374 Gonzalo Camarillo 375 Ericsson 376 Hirsalantie 11 377 Jorvas 02420 378 Finland 380 Email: Gonzalo.Camarillo@ericsson.com