idnits 2.17.1 draft-ietf-rtcweb-data-protocol-02.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 9, 2014) is 3728 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: 'RFCXXXX' is mentioned on line 430, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-03 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-06 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-08 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: August 13, 2014 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 February 9, 2014 10 WebRTC Data Channel Protocol 11 draft-ietf-rtcweb-data-protocol-02.txt 13 Abstract 15 The Web Real-Time Communication (WebRTC) working group is charged to 16 provide protocols to support for direct interactive rich 17 communication using audio, video, and data between two peers' web- 18 browsers. This document specifies a simple protocol for establishing 19 symmetric data channels between the peers. It uses a two way 20 handshake and allows sending of user data without waiting for the 21 handshake to complete. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 13, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 61 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 63 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 6 64 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 8 68 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8 69 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9 70 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informational References . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The data channel protocol is designed to provide, in the WebRTC data 80 channel context [I-D.ietf-rtcweb-data-channel], a simple in-band 81 method to open symmetric data channels. As discussed in 82 [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control 83 Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram 84 Transport Layer Security (DTLS) [RFC6347] as described in 85 [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already 86 standardized transport and security features. 88 2. Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Terminology 96 This document uses the following terms: 98 Association: An SCTP association. 100 Stream: A unidirectional stream of an SCTP association. It is 101 uniquely identified by an SCTP stream identifier (0-65534). Note: 102 the SCTP stream identifier 65535 is reserved due to SCTP INIT and 103 INIT-ACK chunks only allowing a maximum of 65535 streams to be 104 negotiated (0-65534). 106 Channel: Two Streams with the same SCTP stream identifier, one in 107 each direction, which are managed together. 109 4. Protocol Overview 111 This protocol is a simple, low-overhead way to establish 112 bidirectional Channels over an SCTP association with a consistent set 113 of properties. 115 The set of consistent properties includes 117 o whether the messages are transmitted reliable or unreliable. In 118 case of unreliable transmissions, the same level of unreliability 119 is used. 121 o whether the messages are delivered in-order or out-of order. 123 o an optional label for the Channel. 125 o an optional protocol for the Channel. 127 o the SCTP streams. 129 The data channel protocol uses a two way handshake to open a data 130 channel by combining two SCTP streams, one in each direction, with 131 the same SCTP stream identifier. The side wanting to open a data 132 channel selects an SCTP stream identifier for which the corresponding 133 incoming and outgoing SCTP stream is unused and sends a 134 DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer 135 responds with a DATA_CHANNEL_ACK message on its corresponding 136 outgoing SCTP stream. Then the data channel is open. Please note 137 that the opening side can send user messages before the 138 DATA_CHANNEL_ACK is received. Data channel messages are sent on the 139 same Stream as the user messages belonging to the data channel. The 140 demultiplexing is based on the SCTP payload protocol identifier 141 (PPID), since the data channel protocol uses a specific PPID. 143 To avoid glare in opening Channels, each side MUST use either even or 144 odd Streams when sending a DATA_CHANNEL_OPEN message. The method 145 used to determine which side uses odd or even is based on the 146 underlying DTLS connection role when used in WebRTC, with the side 147 acting as the DTLS client using even stream identifiers. 149 Note: There is no attempt to resolve label glare; if both sides open 150 a Channel labeled "x" at the same time, there will be two Channels 151 labeled "x" - one on an even Stream pair, one on an odd pair. 153 The protocol field is to ease cross-application interoperation 154 ("federation") by identifying the user data being passed with an 155 IANA-registered string (see Section 8.4), and may be useful for 156 homogenous applications which may create more than one type of 157 Channel. 159 5. Message Formats 161 Every data channel protocol message starts with a one byte field 162 called "Message Type" which indicates the type of the message. The 163 corresponding values are managed by IANA (see Section 8.2). 165 5.1. DATA_CHANNEL_OPEN Message 167 This message is sent initially on the stream used for user messages 168 using the channel. 170 0 1 2 3 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Message Type | Channel Type | Priority | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Reliability Parameter | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Label Length | Protocol Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 \ / 180 | Label | 181 / \ 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 \ / 184 | Protocol | 185 / \ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Message Type: 1 byte (unsigned integer) 189 This field holds the IANA defined message type for the the 190 DATA_CHANNEL_OPEN message. The suggested value of this field for 191 IANA is 0x03. 193 Channel Type: 1 byte (unsigned integer) 194 This field specifies the type of the channel to be opened and the 195 values are managed by IANA (see Section 8.3): 197 DATA_CHANNEL_RELIABLE (0x00): The channel provides a reliable in- 198 order bi-directional communication channel. 200 DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a 201 reliable unordered bi-directional communication channel. 203 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides 204 a partially-reliable in-order bi-directional Communication 205 channel. User messages will not be retransmitted more times 206 than specified in the Reliability Parameter. 208 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The 209 channel provides a partial reliable unordered bi-directional 210 Communication channel. User messages will not be retransmitted 211 more times than specified in the Reliability Parameter. 213 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides 214 a partial reliable in-order bi-directional Communication 215 channel. User messages might not be transmitted or 216 retransmitted after a specified life-time given in milli- 217 seconds in the Reliability Parameter. This life-time starts 218 when providing the user message to the Javascript engine. 220 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel 221 provides a partial reliable unordered bi-directional 222 Communication channel. User messages might not be transmitted 223 or retransmitted after a specified life-time given in milli- 224 seconds in the Reliability Parameter. This life-time starts 225 when providing the user message to the Javascript engine. 227 Priority: 2 bytes (integer) 228 The priority of the channel as described in 229 [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower 230 the priority. 232 Reliability Parameter: 4 bytes (unsigned integer) 233 This field is ignored if a reliable channel is used. 234 If a partial reliable channel with limited number of 235 retransmissions is used, this field specifies the number of 236 retransmissions. If a partial reliable channel with limited 237 lifetime is used, this field specifies the maximum lifetime in 238 milliseconds. The following table summarizes this: 240 +------------------------------------------------+------------------+ 241 | Channel Type | Reliability | 242 | | Parameter | 243 +------------------------------------------------+------------------+ 244 | DATA_CHANNEL_RELIABLE | Ignored | 245 | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | 246 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | 247 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | 248 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | 249 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | 250 +------------------------------------------------+------------------+ 252 Label Length: 2 bytes (unsigned integer) 253 The length of the label field in bytes. 255 Protocol Length: 2 bytes (unsigned integer) 256 The length of the protocol field in bytes. 258 Label: Variable Length (sequence of characters) 259 The name of the channel. This may be an empty string. 261 Protocol: Variable Length (sequence of characters) 262 The protocol for the channel. If this is an empty string the 263 protocol us unspecified. If it is an non-empty string, it 264 specifies an IANA-registered protocol (see Section 8.4). 266 5.2. DATA_CHANNEL_ACK Message 268 This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE 269 message on the stream used for user messages using the channel. 270 Reception of this message tells the opener that the channel setup 271 handshake is complete. 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Message Type | 277 +-+-+-+-+-+-+-+-+ 279 Message Type: 1 byte (unsigned integer) 280 This field holds the IANA defined message type for the the 281 DATA_CHANNEL_ACK message. The suggested value of this field for 282 IANA is 0x02. 284 6. Procedures 286 All data channel protocol messages MUST be sent requesting ordered 287 delivery and using reliable transmission. They MUST be sent on the 288 same outgoing SCTP stream as the user messages belonging to the 289 corresponding data channel. Multiplexing and demultiplexing is done 290 by using the SCTP payload protocol identifier (PPID). Therefore data 291 channel protocol message MUST be sent with the assigned PPID for the 292 data channel protocol (see Section 8.1). Other message MUST NOT be 293 sent using this PPID. 295 If one sides wants to open a data channel, it chooses a free outgoing 296 SCTP stream. If the side is the DTLS client, it MUST choose an even 297 stream identifier, if the side is the DTLS server, it MUST choose an 298 odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message 299 and sends it on the chosen SCTP stream. 301 After the DATA_CHANNEL_OPEN message has been sent, the sender of it 302 can start sending messages containing user data without waiting for 303 the reception of the corresponding DATA_CHANNEL_ACK message. 304 However, before the DATA_CHANNEL_ACK message or any other message has 305 been received on the data channel, all other messages containing user 306 data and belonging to the data channel MUST be sent ordered, not 307 matter whether the data channel is ordered or not. After the 308 DATA_CHANNEL_ACK or any other message has been received on the data 309 channel, messages containing user data MUST be send ordered on 310 ordered data channels and MUST be sent unordered on unordered data 311 channels. Therefore receiving a message containing user data on an 312 unused SCTP stream indicates an error. The corresponding outgoing 313 SCTP stream MUST be reset using [RFC6525]. 315 If a DATA_CHANNEL_OPEN message is received on an unused stream, the 316 stream identifier corresponds to the role of the peer and all 317 parameters in the DATA_CHANNEL_OPEN message are valid, then a 318 corresponding DATA_CHANNEL_ACK message is sent on the stream with the 319 same stream identifier as the one the DATA_CHANNEL_OPEN message was 320 received on. 322 If a DATA_CHANNEL_OPEN message is received on an already used SCTP 323 stream or there are any problems with parameters within the 324 DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is 325 not well-formed, the receiver MUST reset the corresponding outgoing 326 SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK 327 message in response to the received message. Therefore, receiving an 328 SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK 329 message has been received indicates to the sender of the 330 corresponding DATA_CHANNEL_OPEN message the failure of the data 331 channel setup procedure. After also successfully resetting the 332 corresponding outgoing SCTP stream, a new DATA_CHANNEL_OPEN message 333 can be sent on the stream. 335 7. Security Considerations 337 This document does not add any additional considerations to the ones 338 given in [I-D.ietf-rtcweb-security] and 339 [I-D.ietf-rtcweb-security-arch]. 341 8. IANA Considerations 343 [NOTE to RFC-Editor: 345 "RFCXXXX" is to be replaced by the RFC number you assign this 346 document. 348 ] 350 IANA is asked to update the reference of an already existing SCTP 351 PPID assignment and to create three new registries for the data 352 channel protocol. 354 8.1. SCTP Payload Protocol Identifier 356 This document uses one already registered SCTP Payload Protocol 357 Identifier (PPID). [RFC4960] creates the registry "SCTP Payload 358 Protocol Identifiers" from which this identifier was assigned. IANA 359 is requested to update the reference of this assignment to point to 360 this document. Therefore this assignment should be updated to read: 362 +----------------+-----------+-----------+ 363 | Value | SCTP PPID | Reference | 364 +----------------+-----------+-----------+ 365 | WebRTC Control | 50 | [RFCXXXX] | 366 +----------------+-----------+-----------+ 368 8.2. New Message Type Registry 370 IANA is requested to create a new registration table "Message Type 371 Registry" for the data channel protocol to manage the one byte 372 "Message Type" field in data channel messages (see Section 5). 374 The assignment of new message types is done through an RFC required 375 action, as defined in [RFC5226]. Documentation of the new message 376 type MUST contain the following information: 378 1. A name for the new message type; 379 2. A detailed procedural description of the use of messages with the 380 new type within the operation of the data channel protocol. 382 Initially the following values need to be registered: 384 +-------------------+-----------+-----------+ 385 | Name | Type | Reference | 386 +-------------------+-----------+-----------+ 387 | Reserved | 0x00 | [RFCXXXX] | 388 | Reserved | 0x01 | [RFCXXXX] | 389 | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | 390 | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | 391 | Unassigned | 0x04-0xfe | | 392 | Reserved | 0xff | [RFCXXXX] | 393 +-------------------+-----------+-----------+ 395 Please note that the values 0x00 and 0x01 are reserved to avoid 396 interoperability problems, since they have been used in earlier 397 versions of the document. 399 8.3. New Channel Type Registry 401 IANA is requested to create a new registration table "Channel Type 402 Registry" for the data channel protocol to manage the one byte 403 "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). 405 The assignment of new message types is done through an RFC required 406 action, as defined in [RFC5226]. Documentation of the new channel 407 type MUST contain the following information: 409 1. A name for the new channel type; 411 2. A detailed procedural description of the user message handling 412 for data channels using this new channel type. 414 Please note that if new channel types support ordered and unordered 415 message delivery, the high order bit SHOULD be used to indicated 416 whether the message delivery is unordered or not. 418 Initially the following values need to be registered: 420 +------------------------------------------------+------+-----------+ 421 | Name | Type | Reference | 422 +------------------------------------------------+------+-----------+ 423 | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | 424 | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | 425 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | 426 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | 427 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | 428 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | 429 | Reserved | 0x7f | [RFCXXXX] | 430 | Reserved | 0xff | [RFCXXXX] | 431 | Unassigned | rest | | 432 +------------------------------------------------+------+-----------+ 434 8.4. New Protocol Registry 436 IANA is requested to create a new registration table "Protocol 437 Registry" for the data channel protocol to manage the "Protocol" 438 field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1). 440 The assignment of new message types is done through an First Come 441 First Served action, as defined in [RFC5226]. Documentation of the 442 new protocol MUST contain the following information: 444 1. A name for the protocol; 446 2. A reference for the protocol indicated by the registered string. 448 Initially this registry is empty. 450 9. Acknowledgments 452 The authors wish to thank Martin Thompson, Cullen Jennings, Harald 453 Alvestrand, Peter Thatcher, Adam Bergkvist, Justin Uberti, Randall 454 Stewart, Stefan Haekansson and many others for their invaluable 455 comments. 457 10. References 459 10.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 465 4960, September 2007. 467 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 468 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 469 May 2008. 471 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 472 Security Version 1.2", RFC 6347, January 2012. 474 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 475 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 476 6525, February 2012. 478 [I-D.ietf-tsvwg-sctp-dtls-encaps] 479 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 480 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 481 dtls-encaps-03 (work in progress), February 2014. 483 10.2. Informational References 485 [I-D.ietf-rtcweb-data-channel] 486 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 487 Channels", draft-ietf-rtcweb-data-channel-06 (work in 488 progress), October 2013. 490 [I-D.ietf-rtcweb-security] 491 Rescorla, E., "Security Considerations for WebRTC", draft- 492 ietf-rtcweb-security-06 (work in progress), January 2014. 494 [I-D.ietf-rtcweb-security-arch] 495 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 496 rtcweb-security-arch-08 (work in progress), January 2014. 498 Authors' Addresses 500 Randell Jesup 501 Mozilla 502 US 504 Email: randell-ietf@jesup.org 506 Salvatore Loreto 507 Ericsson 508 Hirsalantie 11 509 Jorvas 02420 510 FI 512 Email: salvatore.loreto@ericsson.com 513 Michael Tuexen 514 Muenster University of Applied Sciences 515 Stegerwaldstrasse 39 516 Steinfurt 48565 517 DE 519 Email: tuexen@fh-muenster.de