--- 1/draft-ietf-rtcweb-data-protocol-08.txt 2015-01-04 10:14:52.215266046 -0800 +++ 2/draft-ietf-rtcweb-data-protocol-09.txt 2015-01-04 10:14:52.243266733 -0800 @@ -1,21 +1,21 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: April 1, 2015 Ericsson +Expires: July 8, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - September 28, 2014 + January 4, 2015 WebRTC Data Channel Establishment Protocol - draft-ietf-rtcweb-data-protocol-08.txt + draft-ietf-rtcweb-data-protocol-09.txt Abstract The WebRTC framework specifies protocol 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. @@ -27,25 +27,25 @@ 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 1, 2015. + This Internet-Draft will expire on July 8, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 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 @@ -74,23 +74,25 @@ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Data Channel Establishment Protocol (DCEP) 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) [RFC4347] as described in + Transport Layer Security (DTLS) as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already - standardized transport and security features. + standardized transport and security features. DTLS 1.0 is defined in + [RFC4347] and the present latest version, DTLS 1.2, is defined in + [RFC6347]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "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: @@ -126,31 +128,32 @@ o an optional label for the Data Channel. o an optional protocol for the Data Channel. o the Streams. This protocol uses a two way handshake to open a Data Channel. The handshake pairs one incoming and one outgoing Stream, both having the same Stream Identifier, into a single bidirectional Data Channel. - The side wanting to open a Data Channel selects a Stream Identifier - for which the corresponding incoming and outgoing Streams are unused - and sends a DATA_CHANNEL_OPEN message on the outgoing Stream. The - peer responds with a DATA_CHANNEL_ACK message on its corresponding - outgoing Stream. Then the Data Channel is open. Data Channel - Establishment Protocol 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 Establishment Protocol uses a specific PPID. + The peer that initiates opening a Data Channel selects a Stream + Identifier for which the corresponding incoming and outgoing Streams + are unused and sends a DATA_CHANNEL_OPEN message on the outgoing + Stream. The peer responds with a DATA_CHANNEL_ACK message on its + corresponding outgoing Stream. Then the Data Channel is open. Data + Channel Establishment Protocol 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 Establishment Protocol uses a specific + PPID. - Note: The opening side can send user messages before the + Note: The opening side MAY send user messages before the DATA_CHANNEL_ACK is received. To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, each side MUST use Streams with either even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which side uses odd or even is based on the underlying DTLS connection role: the side acting as the DTLS client MUST use Streams with even Stream Identifiers, the side acting as the DTLS server MUST use @@ -262,28 +265,28 @@ | 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 Data Channel as a UTF-8 encoded string. This may - be an empty string. + The name of the Data Channel as a UTF-8 encoded string as + specified in [RFC3629]. This may be an empty string. Protocol: Variable Length (sequence of characters) If this is an empty string the protocol is unspecified. If it is a non-empty string, it specifies a protocol registered in the 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This - string is UTF-8 encoded. + string is UTF-8 encoded as specified in [RFC3629]. 5.2. DATA_CHANNEL_ACK Message This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE message on the stream used for user messages using the Data Channel. Reception of this message tells the opener that the Data 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 @@ -300,42 +303,27 @@ All Data Channel Establishment Protocol messages MUST be sent using ordered delivery and reliable transmission. They MUST be sent on the same outgoing Stream as the user messages belonging to the corresponding Data Channel. Multiplexing and demultiplexing is done by using the SCTP payload protocol identifier (PPID). Therefore Data Channel Establishment Protocol message MUST be sent with the assigned PPID for the Data Channel Establishment Protocol (see Section 8.1). Other messages MUST NOT be sent using this PPID. - If one side wants to open a Data Channel, it chooses a Stream + The peer that initiates opening a Data Channel selects a Stream Identifier for which the corresponding incoming and outgoing Streams - are free. If the side is the DTLS client, it MUST choose an even + are unused. If the side is the DTLS client, it MUST choose an even Stream Identifier, if the side is the DTLS server, it MUST choose an odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message and sends it on the chosen Stream. - After the DATA_CHANNEL_OPEN message has been sent, the sender of the - DATA_CHANNEL_OPEN can start sending messages containing user data - without waiting for the reception of the corresponding - DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK - message or any other message has been received on a Data Channel, all - other messages containing user data and belonging to this Data - Channel MUST be sent ordered, no matter whether the Data Channel is - ordered or not. After the DATA_CHANNEL_ACK or any other message has - been received on the Data Channel, messages containing user data MUST - be send ordered on ordered Data Channels and MUST be sent unordered - on unordered Data Channels. Therefore receiving a message containing - user data on an unused Stream indicates an error. The corresponding - Data Channel MUST be closed as described in - [I-D.ietf-rtcweb-data-channel]. - If a DATA_CHANNEL_OPEN message is received on an unused Stream, the Stream Identifier corresponds to the role of the peer and all parameters in the DATA_CHANNEL_OPEN message are valid, then a corresponding DATA_CHANNEL_ACK message is sent on the Stream with the same Stream Identifier as the one the DATA_CHANNEL_OPEN message was received on. If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for instance if a DATA_CHANNEL_OPEN message is received on an already used Stream or there are any problems with parameters within @@ -345,20 +333,35 @@ described in [I-D.ietf-rtcweb-data-channel] 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. After also successfully resetting the corresponding outgoing Stream, which concludes the Data Channel closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be sent on the Stream. + After the DATA_CHANNEL_OPEN message has been sent, the sender of the + DATA_CHANNEL_OPEN MAY start sending messages containing user data + without waiting for the reception of the corresponding + DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK + message or any other message has been received on a Data Channel, all + other messages containing user data and belonging to this Data + Channel MUST be sent ordered, no matter whether the Data Channel is + ordered or not. After the DATA_CHANNEL_ACK or any other message has + been received on the Data Channel, messages containing user data MUST + be sent ordered on ordered Data Channels and MUST be sent unordered + on unordered Data Channels. Therefore receiving a message containing + user data on an unused Stream indicates an error. The corresponding + Data Channel MUST be closed as described in + [I-D.ietf-rtcweb-data-channel]. + 7. Security Considerations The DATA_CHANNEL_OPEN messages contains two variable length fields: the protocol and the label. A receiver must be prepared to receive DATA_CHANNEL_OPEN messages where these field have the maximum length of 65535 bytes. Error cases like the use of inconsistent lengths fields, unknown parameter values or violation the odd/even rule must also be handled by closing the corresponding Data Channel. An end- point must also be prepared that the peer open the maximum number of Data Channels. @@ -458,22 +461,22 @@ 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: 1. A name for the new Channel Type; 2. A detailed procedural description of the user message handling for Data Channels using this new Channel Type. Please note that if new Channel Types support ordered and unordered - message delivery, the high order bit SHOULD be used to indicate - whether the message delivery is unordered or not. + message delivery, the high order bit MUST be used to indicate whether + the message delivery is unordered or not. Initially the following values need to be registered: +------------------------------------------------+------+-----------+ | Name | Type | Reference | +------------------------------------------------+------+-----------+ | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | @@ -484,51 +487,57 @@ | Unassigned | rest | | +------------------------------------------------+------+-----------+ Please note that the values 0x7f and 0xff have been reserved for future extensibility. The range of possible values is from 0x00 to 0xff. 9. Acknowledgments The authors wish to thank Harald Alvestrand, Richard Barnes, Adam - Bergkvist, Barry Dingle, Stefan Haekansson, Cullen Jennings, Paul - Kyzivat, Doug Leonard, Irene Ruengeler, Randall Stewart, Peter - Thatcher, Martin Thompson, Justin Uberti, and many others for their - invaluable comments. + Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen + Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick, + Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, + Justin Uberti, and many others for their invaluable comments. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 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-05 (work in progress), July 2014. + dtls-encaps-07 (work in progress), December 2014. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data - Channels", draft-ietf-rtcweb-data-channel-11 (work in - progress), July 2014. + Channels", draft-ietf-rtcweb-data-channel-12 (work in + progress), September 2014. 10.2. Informational References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-07 (work in progress), July 2014.