--- 1/draft-ietf-rtcweb-data-protocol-01.txt 2014-02-09 14:14:34.962787758 -0800 +++ 2/draft-ietf-rtcweb-data-protocol-02.txt 2014-02-09 14:14:34.990788452 -0800 @@ -1,21 +1,21 @@ -RTCWeb Working Group R. Jesup +Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: April 24, 2014 Ericsson +Expires: August 13, 2014 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - October 21, 2013 + February 9, 2014 - RTCWeb Data Channel Protocol - draft-ietf-rtcweb-data-protocol-01.txt + WebRTC Data Channel Protocol + draft-ietf-rtcweb-data-protocol-02.txt Abstract The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. @@ -28,58 +28,58 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 24, 2014. + This Internet-Draft will expire on August 13, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 6 - 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 7 + 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 8 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 8 - 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 8 - 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 9 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 9 + 8.4. New Protocol Registry . . . . . . . . . . . . . . . . . . 10 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 10.2. Informational References . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.2. Informational References . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The data channel protocol is designed to provide, in the WebRTC data channel context [I-D.ietf-rtcweb-data-channel], a simple in-band method to open symmetric data channels. As discussed in [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) [RFC6347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already @@ -91,71 +91,77 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology This document uses the following terms: Association: An SCTP association. Stream: A unidirectional stream of an SCTP association. It is - uniquely identified by a stream identifier (0-65534). Note: - stream identifier 65535 is reserved due to SCTP Init messages - allowing a maximum of 65535 streams to be negotiated (0-65534). + uniquely identified by an SCTP stream identifier (0-65534). Note: + the SCTP stream identifier 65535 is reserved due to SCTP INIT and + INIT-ACK chunks only allowing a maximum of 65535 streams to be + negotiated (0-65534). - Channel: Two Streams with the same identifier, one in each - direction, which are managed together. + Channel: Two Streams with the same SCTP stream identifier, one in + each direction, which are managed together. 4. Protocol Overview This protocol is a simple, low-overhead way to establish bidirectional Channels over an SCTP association with a consistent set of properties. The set of consistent properties includes o whether the messages are transmitted reliable or unreliable. In case of unreliable transmissions, the same level of unreliability is used. o whether the messages are delivered in-order or out-of order. o an optional label for the Channel. o an optional protocol for the Channel. - o the outgoing SCTP stream. + o the SCTP streams. The data channel protocol uses a two way handshake to open a data - channel. The side wanting to open a data channel selects an unused - Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with - a DATA_CHANNEL_ACK message. Then the data channel is open. Please - note that the opening side can send user messages before the - DATA_CHANNEL_ACK is received. These data channel messages are sent - on the same Stream as the user messages belonging to the data - channel. The demultiplexing is based on the SCTP payload protocol - identifier. + channel by combining two SCTP streams, one in each direction, with + the same SCTP stream identifier. The side wanting to open a data + channel selects an SCTP stream identifier for which the corresponding + incoming and outgoing SCTP stream is unused and sends a + DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer + responds with a DATA_CHANNEL_ACK message on its corresponding + outgoing SCTP stream. Then the data channel is open. Please note + that the opening side can send user messages before the + DATA_CHANNEL_ACK is received. Data channel messages are sent on the + same Stream as the user messages belonging to the data channel. The + demultiplexing is based on the SCTP payload protocol identifier + (PPID), since the data channel protocol uses a specific PPID. To avoid glare in opening Channels, each side MUST use either even or odd Streams when sending a DATA_CHANNEL_OPEN message. The method used to determine which side uses odd or even is based on the - underlying DTLS connection role when used in RTCWeb, with the side + underlying DTLS connection role when used in WebRTC, with the side acting as the DTLS client using even stream identifiers. Note: There is no attempt to resolve label glare; if both sides open a Channel labeled "x" at the same time, there will be two Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation - ("federation") by identifying the data being passed with an IANA- - registered string, and may be useful for homogenous applications - which may create more than one type of Channel. + ("federation") by identifying the user data being passed with an + IANA-registered string (see Section 8.4), and may be useful for + homogenous applications which may create more than one type of + Channel. 5. Message Formats Every data channel protocol message starts with a one byte field called "Message Type" which indicates the type of the message. The corresponding values are managed by IANA (see Section 8.2). 5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the stream used for user messages @@ -194,62 +200,75 @@ DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The channel provides a reliable unordered bi-directional communication channel. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The channel provides a partially-reliable in-order bi-directional Communication channel. User messages will not be retransmitted more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The channel provides a partial reliable unordered bi-directional - Communication channel. User messages will not be - retransmitted more times than specified in the Reliability - Parameter. + Communication channel. User messages will not be retransmitted + more times than specified in the Reliability Parameter. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The channel provides a partial reliable in-order bi-directional Communication channel. User messages might not be transmitted or retransmitted after a specified life-time given in milli- seconds in the Reliability Parameter. This life-time starts when providing the user message to the Javascript engine. DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel provides a partial reliable unordered bi-directional - Communication channel. User messages might not be - transmitted or retransmitted after a specified life-time - given in milli-seconds in the Reliability Parameter. This - life-time starts when providing the user message to the - Javascript engine. + Communication channel. User messages might not be transmitted + or retransmitted after a specified life-time given in milli- + seconds in the Reliability Parameter. This life-time starts + when providing the user message to the Javascript engine. Priority: 2 bytes (integer) - The priority of the channel. + The priority of the channel as described in + [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower + the priority. Reliability Parameter: 4 bytes (unsigned integer) This field is ignored if a reliable channel is used. If a partial reliable channel with limited number of retransmissions is used, this field specifies the number of retransmissions. If a partial reliable channel with limited lifetime is used, this field specifies the maximum lifetime in - milliseconds. + milliseconds. The following table summarizes this: + + +------------------------------------------------+------------------+ + | Channel Type | Reliability | + | | Parameter | + +------------------------------------------------+------------------+ + | DATA_CHANNEL_RELIABLE | Ignored | + | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | + | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | + | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | + | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | + | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | + +------------------------------------------------+------------------+ Label Length: 2 bytes (unsigned integer) The length of the label field in bytes. Protocol Length: 2 bytes (unsigned integer) The length of the protocol field in bytes. Label: Variable Length (sequence of characters) The name of the channel. This may be an empty string. Protocol: Variable Length (sequence of characters) - The protocol for the channel. This may be an empty string. If - used, it is an IANA-registered protocol (see Section 8.4). + The protocol for the channel. If this is an empty string the + protocol us unspecified. If it is an non-empty string, it + specifies an IANA-registered protocol (see Section 8.4). 5.2. DATA_CHANNEL_ACK Message This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE message on the stream used for user messages using the channel. Reception of this message tells the opener that the channel setup handshake is complete. 0 1 2 3 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 @@ -302,21 +321,23 @@ If a DATA_CHANNEL_OPEN message is received on an already used SCTP stream or there are any problems with parameters within the DATA_CHANNEL_OPEN message or the DATA_CHANNEL_OPEN message itself is not well-formed, the receiver MUST reset the corresponding outgoing SCTP stream using [RFC6525] and MUST NOT send a DATA_CHANNEL_ACK message in response to the received message. Therefore, receiving an SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the data - channel setup procedure. + channel setup procedure. After also successfully resetting the + corresponding outgoing SCTP stream, a new DATA_CHANNEL_OPEN message + can be sent on the stream. 7. Security Considerations This document does not add any additional considerations to the ones given in [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. 8. IANA Considerations [NOTE to RFC-Editor: @@ -364,20 +385,24 @@ | Name | Type | Reference | +-------------------+-----------+-----------+ | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | | Unassigned | 0x04-0xfe | | | Reserved | 0xff | [RFCXXXX] | +-------------------+-----------+-----------+ + Please note that the values 0x00 and 0x01 are reserved to avoid + interoperability problems, since they have been used in earlier + versions of the document. + 8.3. New Channel Type Registry IANA is requested to create a new registration table "Channel Type Registry" for the data channel protocol to manage the one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see Section 5.1). The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new channel type MUST contain the following information: @@ -445,38 +471,39 @@ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", RFC 6525, February 2012. [I-D.ietf-tsvwg-sctp-dtls-encaps] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- - dtls-encaps-02 (work in progress), October 2013. + dtls-encaps-03 (work in progress), February 2014. 10.2. Informational References [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data - Channels", draft-ietf-rtcweb-data-channel-05 (work in - progress), July 2013. + Channels", draft-ietf-rtcweb-data-channel-06 (work in + progress), October 2013. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- - ietf-rtcweb-security-05 (work in progress), July 2013. + ietf-rtcweb-security-06 (work in progress), January 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-07 (work in progress), July 2013. + rtcweb-security-arch-08 (work in progress), January 2014. Authors' Addresses + Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420