idnits 2.17.1 draft-holmberg-clue-datachannel-03.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 date (February 12, 2014) is 3720 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) == Unused Reference: 'RFC3261' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 279, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-02 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-07 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-03 ** Downref: Normative reference to an Informational draft: draft-tuexen-tsvwg-sctp-prpolicies (ref. 'I-D.tuexen-tsvwg-sctp-prpolicies') Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Intended status: Standards Track February 12, 2014 5 Expires: August 16, 2014 7 CLUE Protocol Data Channel 8 draft-holmberg-clue-datachannel-03 10 Abstract 12 This document specifies how to use the Stream Control Transmission 13 Protocol (SCTP) on top of the Datagram Transport Layer Security 14 (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol messages 15 between CLUE entities. 17 The document describes the SCTP considerations for CLUE, and the SDP 18 Offer/Answer procedures for negotiating a SCTPoDTLS connection for 19 CLUE. 21 Details and procedures associated with the CLUE protocol are outside 22 the scope of this document. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 16, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Usage of SCTPoDTLS in the CLUE Context . . . . . . . . . . . 3 61 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. CLUE Data Channel Definition . . . . . . . . . . . . . . 3 63 3.3. RTCWEB Data Channel Protocol Usage . . . . . . . . . . . 4 64 3.4. SCTP Considerations . . . . . . . . . . . . . . . . . . . 4 65 3.4.1. SCTP Payload Protocol Identifier (PPID) . . . . . . . 4 66 3.4.2. Reliability . . . . . . . . . . . . . . . . . . . . . 4 67 3.4.3. Order . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.4.4. Stream Reset . . . . . . . . . . . . . . . . . . . . 5 69 3.4.5. Interleaving . . . . . . . . . . . . . . . . . . . . 5 70 3.4.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5 71 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 72 4.1. SDP-based WebRTC Data Channel Negotiation Usage . . . . . 5 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 76 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 9.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 This document specifies how to use the Stream Control Transmission 85 Protocol (SCTP) on top of the Datagram Transport Layer Security 86 (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol messages 87 between CLUE entities. 89 The document describes the SCTP considerations for CLUE, and the SDP 90 Offer/Answer procedures for negotiating a SCTPoDTLS connection for 91 CLUE. 93 Details and procedures associated with the CLUE protocol are outside 94 the scope of this document. 96 2. Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP 14, RFC 2119 101 [RFC2119]. 103 CLUE data channel refers to the SCTPoDTLS association that is used 104 between two CLUE entities in order to transport CLUE messages. 106 CLUE message refers to a CLUE protocol message that is sent over the 107 CLUE data channel. 109 CLUE entity refers to a SIP User Agent (UA) device that supports the 110 CLUE mechanism (including the CLUE protocol). 112 [RFC4960] defines a SCTP stream as a unidirectional logical channel 113 established from one to another associated SCTP endpoint, within 114 which all user messages are delivered in sequence except for those 115 submitted to the unordered delivery service. 117 [RFC4960] defines a SCTP identifier as a unsigned integer, which 118 identifies an SCTP stream. 120 3. Usage of SCTPoDTLS in the CLUE Context 122 3.1. General 124 This section defines the CLUE data channel, and describes the SCTP 125 features and extensions used to realize it. 127 The CLUE data channel realization, and set of SCTP features, are 128 based on the the RTCWEB data channel defined in 129 [I-D.ietf-rtcweb-data-channel]. This will allow CLUE entities to be 130 interoperable with entities implementing 131 [I-D.ietf-rtcweb-data-channel]. 133 3.2. CLUE Data Channel Definition 135 The CLUE data channel is realized by using the Stream Control 136 Transmission Protocol (SCTP) on top of the Datagram Transport Layer 137 Security (DTLS) protocol [I-D.ietf-tsvwg-sctp-dtls-encaps]. 139 The realization of a bidirectional CLUE Data Channel is a pair of one 140 incoming SCTP stream and one outgoing SCTP stream. These streams are 141 then used to transport CLUE messages in both directions. 143 The SCTP streams MUST belong to the same SCTP association. 145 Within a given CLUE session, CLUE entities MUST use a single CLUE 146 data channel for all CLUE messages associated with the CLUE session. 148 The SCTP streams MUST have identical SCTP stream identifier values, 149 unless a specific value is already used for some other purpose. 151 OPEN ISSUE #1: The requirement to use identical STCP stream 152 identifier values might be modified depending on what mechanism will 153 be used to negotiate the identifier values. 155 3.3. RTCWEB Data Channel Protocol Usage 157 OPEN ISSUE #2: It is FFS whether the RTCWEB Data Channel Protocol 158 [I-D.ietf-rtcweb-data-protocol] will be used with the CLUE data 159 channel. 161 NOTE: If [I-D.ietf-rtcweb-data-protocol] will be used with the CLUE 162 data channel, a new associated 'protocol' value needs to be 163 registered with IANA in the 'Protocol Registry' defined by 164 [I-D.ietf-rtcweb-data-protocol]. 166 3.4. SCTP Considerations 168 3.4.1. SCTP Payload Protocol Identifier (PPID) 170 CLUE entities MUST use the PPID value 51 when sending CLUE messages, 171 according to the procedures in [I-D.ietf-rtcweb-data-channel]. 173 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID value 174 51 indicates that the SCTP message contains data encoded in a UTF-8 175 format. The PPID value 51 does not indicate what protocol the SCTP 176 message contains. 178 NOTE: If the RTCWEB Data Channel Protocol 179 [I-D.ietf-rtcweb-data-protocol] will be used for the CLUE data 180 channel, the PPID value 50 will be used for Data Channel Protocol 181 messages. 183 3.4.2. Reliability 185 The usage of SCTP for the data channel ensures reliable transport of 186 CLUE messages. 188 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 189 partial reliability extension defined in [RFC3758]. This is not 190 needed for CLUE, as messages are required to always be sent reliably. 191 [I-D.ietf-rtcweb-data-channel] also mandates support of the limited 192 retransmission policy defined in [I-D.tuexen-tsvwg-sctp-prpolicies]. 194 3.4.3. Order 196 CLUE entities MUST use the ordered delivery SCTP service, as 197 described in section 6.6 of [RFC2960]. 199 3.4.4. Stream Reset 201 CLUE entities MUST support the stream reset extension defined in 202 [RFC6525] 204 The dynamic address reconfiguration extension defined in [RFC5061] 205 MUST be used to signal the support of the stream reset extension 206 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 208 3.4.5. Interleaving 210 CLUE entities MUST support the message interleaving mechanism defined 211 in [I-D.stewart-tsvwg-sctp-ndata]. 213 3.4.6. SCTP Multihoming 215 CLUE entities MUST NOT use SCTP multihoming. 217 NOTE: The SCTPoDTLS mechanism does not support SCTP multihoming. 219 4. SDP Offer/Answer Procedures 221 4.1. SDP-based WebRTC Data Channel Negotiation Usage 223 OPEN ISSUE #3: It is FFS whether the SDP-based WebRTC Data Channel 224 Negotiation mechanism [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 225 will be used with the CLUE data channel. 227 NOTE: If [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] will be used 228 with the CLUE data channel, a new associated 'sub-protocol' value 229 needs to be registered with IANA. 231 5. Security Considerations 233 TBD 235 6. IANA Considerations 237 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 238 document.] 240 7. Acknowledgments 242 Thanks to Paul Kyzivat and Christian Groves for comments on the 243 document. 245 8. Change Log 247 [RFC EDITOR NOTE: Please remove this section when publishing] 249 Changes from draft-holmberg-clue-datachannel-02 251 o PPID value for CLUE messages added 252 o References updated 254 Changes from draft-holmberg-clue-datachannel-01 256 o More text added 258 Changes from draft-holmberg-clue-datachannel-00 260 o Editorial corrections based on comments from Paul K 262 9. References 264 9.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 270 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 271 Zhang, L., and V. Paxson, "Stream Control Transmission 272 Protocol", RFC 2960, October 2000. 274 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 275 A., Peterson, J., Sparks, R., Handley, M., and E. 276 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 277 June 2002. 279 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 280 with Session Description Protocol (SDP)", RFC 3264, June 281 2002. 283 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 284 4960, September 2007. 286 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 287 Kozuka, "Stream Control Transmission Protocol (SCTP) 288 Dynamic Address Reconfiguration", RFC 5061, September 289 2007. 291 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 292 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 293 6525, February 2012. 295 [I-D.ietf-tsvwg-sctp-dtls-encaps] 296 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 297 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 298 dtls-encaps-02.txt (work in progress), October 2013. 300 [I-D.ietf-rtcweb-data-channel] 301 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 302 Channels", draft-ietf-rtcweb-data-channel-07.txt (work in 303 progress), February 2014. 305 [I-D.ietf-rtcweb-data-protocol] 306 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 307 Establishment Protocol", draft-ietf-rtcweb-data- 308 protocol-03.txt (work in progress), February 2014. 310 [I-D.ejzak-dispatch-webrtc-data-channel-sdpneg] 311 Ejzak, R. and J. Marcon, "SDP-based WebRTC data channel 312 negotiation", draft-ejzak-dispatch-webrtc-data-channel- 313 sdpneg-00.txt (work in progress), October 2013. 315 [I-D.stewart-tsvwg-sctp-ndata] 316 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 317 New Data Chunk for Stream Control Transmission Protocol", 318 draft-stewart-tsvwg-sctp-ndata-03.txt (work in progress), 319 October 2013. 321 [I-D.tuexen-tsvwg-sctp-prpolicies] 322 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 323 "Additional Policies for the Partial Delivery Extension of 324 the Stream Control Transmission Protocol", draft-tuexen- 325 tsvwg-sctp-prpolicies-03.txt (work in progress), October 326 2013. 328 9.2. Informative References 330 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 331 Conrad, "Stream Control Transmission Protocol (SCTP) 332 Partial Reliability Extension", RFC 3758, May 2004. 334 Author's Address 336 Christer Holmberg 337 Ericsson 338 Hirsalantie 11 339 Jorvas 02420 340 Finland 342 Email: christer.holmberg@ericsson.com