idnits 2.17.1 draft-holmberg-clue-datachannel-01.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 7, 2014) is 3729 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 234, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 239, but no explicit reference was found in the text ** 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-06 Summary: 1 error (**), 0 flaws (~~), 5 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 7, 2014 5 Expires: August 11, 2014 7 CLUE Protocol Data Channel 8 draft-holmberg-clue-datachannel-01 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 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4.4. Stream Reset . . . . . . . . . . . . . . . . . . . . 4 69 3.4.5. Interleaving . . . . . . . . . . . . . . . . . . . . 5 70 3.4.6. SCTP Multihoming . . . . . . . . . . . . . . . . . . 5 71 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 75 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 78 9.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 This document specifies how to use the Stream Control Transmission 84 Protocol (SCTP) on top of the Datagram Transport Layer Security 85 (DTLS) protocol (SCTPoDTLS) for transporting CLUE protocol messages 86 between CLUE entities. 88 The document describes the SCTP considerations for CLUE, and the SDP 89 Offer/Answer procedures for negotiating a SCTPoDTLS connection for 90 CLUE. 92 Details and procedures associated with the CLUE protocol are outside 93 the scope of this document. 95 2. Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14, RFC 2119 100 [RFC2119]. 102 CLUE data channel refers to the SCTPoDTLS association that is used 103 between two CLUE entities in order to transport CLUE messages. 105 CLUE message refers to a CLUE protocol message that is sent over the 106 CLUE data channel. 108 CLUE entity refers to a SIP User Agent (UA) device that supports the 109 CLUE mechanism (including the CLUE protocol). 111 [RFC4960] defines a SCTP stream as a unidirectional logical channel 112 established from one to another associated SCTP endpoint, within 113 which all user messages are delivered in sequence except for those 114 submitted to the unordered delivery service. 116 [RFC4960] defines a SCTP identifier as a unsigned integer, which 117 identifies an SCTP stream. 119 3. Usage of SCTPoDTLS in the CLUE Context 121 3.1. General 123 This section defines the CLUE data channel, and describes the SCTP 124 features and extensions used to realize it. 126 The CLUE data channel realization, and set of SCTP features, are 127 based on the the RTCWEB data channel defined in 128 [I-D.ietf-rtcweb-data-channel]. This will allow CLUE entities to be 129 interoperable with entities implementing 130 [I-D.ietf-rtcweb-data-channel]. 132 3.2. CLUE Data Channel Definition 134 The CLUE data channel is realized by using the Stream Control 135 Transmission Protocol (SCTP) on top of the Datagram Transport Layer 136 Security (DTLS) protocol [I-D.ietf-tsvwg-sctp-dtls-encaps]. 138 The realization of a bidirectional CLUE Data Channel is a pair of one 139 incoming SCTP stream and one outgoing SCTP stream. These streams are 140 then used to transport CLUE messages in both directions. 142 The SCTP streams MUST belong to the same SCTP association. 144 The SCTP streams MUST have identical SCTP stream identifier values, 145 unless a specific value is already used for some other purpose. 147 OPEN ISSUE: The requirement to use identical STCP stream identifier 148 values might be modified depending on what mechanism will be used to 149 negotiate the identifier values. 151 3.3. RTCWEB Data Channel Protocol Usage 153 OPEN ISSUE: It is FFS whether the RTCWEB Data Channel Protocol will 154 be used in the CLUE context. 156 3.4. SCTP Considerations 158 3.4.1. SCTP Payload Protocol Identifier (PPID) 160 CLUE entities MUST use a PPID value of 51 or 54, according to the 161 procedures in [I-D.ietf-rtcweb-data-channel]. 163 NOTE: As described in [I-D.ietf-rtcweb-data-channel], the PPID values 164 are used to indicate that the SCTP message contains data encoded in a 165 DOMstring format [reference-needed]. 167 3.4.2. Reliability 169 CLUE entities MUST use the reliable transport SCTP feature. 171 NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the 172 partial reliability extension defined in [RFC3758]. This is not 173 needed for CLUE, as messages are required to always be sent reliably. 174 [I-D.ietf-rtcweb-data-channel] also mandates support of the limited 175 retransmission policy defined in[ref-to-tuexen-tsvwg-sctp- 176 prpolicies]. 178 3.4.3. Order 180 CLUE entities MUST use the ordered delivery SCTP feature. 182 3.4.4. Stream Reset 184 CLUE entities MUST support the stream reset extension defined in 185 [RFC6525] 187 The dynamic address reconfiguration extension defined in [RFC5061] 188 MUST be used to signal the support of the stream reset extension 189 defined in [RFC6525]. Other features of [RFC5061] MUST NOT be used. 191 3.4.5. Interleaving 193 CLUE entities MUST support the message interleaving mechanism [ref- 194 to-tuexen-tsvwg-sctp-prpolicies]. 196 3.4.6. SCTP Multihoming 198 CLUE entities MUST NOT use SCTP multihoming. 200 NOTE: The SCTPoDTLS mechanism does not support SCTP multihoming. 202 4. SDP Offer/Answer Procedures 204 TBD 206 5. Security Considerations 208 TBD 210 6. IANA Considerations 212 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 213 document.] 215 7. Acknowledgments 217 TBD 219 8. Change Log 221 [RFC EDITOR NOTE: Please remove this section when publishing] 223 Changes from draft-holmberg-clue-datachannel-00 225 o Editorial corrections based on comments from Paul K 227 9. References 229 9.1. Normative References 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 235 A., Peterson, J., Sparks, R., Handley, M., and E. 236 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 237 June 2002. 239 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 240 with Session Description Protocol (SDP)", RFC 3264, June 241 2002. 243 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 244 4960, September 2007. 246 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 247 Kozuka, "Stream Control Transmission Protocol (SCTP) 248 Dynamic Address Reconfiguration", RFC 5061, September 249 2007. 251 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 252 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 253 6525, February 2012. 255 [I-D.ietf-tsvwg-sctp-dtls-encaps] 256 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 257 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 258 dtls-encaps-02.txt (work in progress), October 2013. 260 [I-D.ietf-rtcweb-data-channel] 261 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 262 Channels", draft-ietf-rtcweb-data-channel-06.txt (work in 263 progress), October 2013. 265 9.2. Informative References 267 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 268 Conrad, "Stream Control Transmission Protocol (SCTP) 269 Partial Reliability Extension", RFC 3758, May 2004. 271 Author's Address 273 Christer Holmberg 274 Ericsson 275 Hirsalantie 11 276 Jorvas 02420 277 Finland 279 Email: christer.holmberg@ericsson.com