--- 1/draft-ietf-rtcweb-data-protocol-07.txt 2014-09-28 15:14:46.964704163 -0700 +++ 2/draft-ietf-rtcweb-data-protocol-08.txt 2014-09-28 15:14:46.992704847 -0700 @@ -1,21 +1,21 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: January 5, 2015 Ericsson +Expires: April 1, 2015 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - July 4, 2014 + September 28, 2014 WebRTC Data Channel Establishment Protocol - draft-ietf-rtcweb-data-protocol-07.txt + draft-ietf-rtcweb-data-protocol-08.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,21 +27,21 @@ 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 January 5, 2015. + This Internet-Draft will expire on April 1, 2015. Copyright Notice 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 @@ -57,22 +57,23 @@ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 - 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 - 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 + 8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9 + 8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9 + 8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The Data Channel Establishment Protocol (DCEP) is designed to provide, in the WebRTC Data Channel context @@ -125,60 +126,61 @@ 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 an Stream Identifier + 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. Note: The opening side can send user messages before the DATA_CHANNEL_ACK is received. - To avoid glare in opening Data Channels, each side MUST use Streams - with either even or odd Stream Identifiers when sending a - DATA_CHANNEL_OPEN message. When using SCTP over DTLS + 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 Streams with odd Stream Identifiers. - Note: There is no attempt to resolve label glare; if both sides open - a Data Channel labeled "x" at the same time, there will be two Data - Channels labeled "x" - one on an even Stream pair, one on an odd - pair. + Note: There is no attempt to ensure uniqueness for the label; if both + sides open a Data Channel labeled "x" at the same time, there will be + two Data 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 user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]), and may be useful for homogeneous applications which may create more than one type of Data Channel. Please note that - there is also no attempt to resolve protocol glare. + there is also no attempt to ensure uniqueness for the protocol field. 5. Message Formats Every Data Channel Establishment 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). + Section 8.2.1). 5.1. DATA_CHANNEL_OPEN Message This message is sent initially on the Stream used for user messages using the Data Channel. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Channel Type | Priority | @@ -191,26 +193,26 @@ | Label | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / | Protocol | / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the - DATA_CHANNEL_OPEN message. The suggested value of this field for - IANA is 0x03. + DATA_CHANNEL_OPEN message. The value of this field is 0x03 as + specified in Section 8.2.1. Channel Type: 1 byte (unsigned integer) This field specifies the type of the Data Channel to be opened and - the values are managed by IANA (see Section 8.3): + the values are managed by IANA (see Section 8.2.2): DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a reliable in-order bi-directional communication. DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides a reliable unordered bi-directional communication. DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel provides a partially-reliable in-order bi-directional communication. User messages will not be retransmitted more @@ -284,36 +286,36 @@ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | +-+-+-+-+-+-+-+-+ Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the - DATA_CHANNEL_ACK message. The suggested value of this field for - IANA is 0x02. + DATA_CHANNEL_ACK message. The value of this field is 0x02 as + specified in Section 8.2.1. 6. Procedures 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 an Stream - identifier for which the corresponding incoming and outgoing Streams + If one side wants to open a Data Channel, it chooses 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 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 @@ -372,44 +374,56 @@ 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] IANA is asked to update the reference of an already existing SCTP - PPID assignment and to create two new registries for the Data Channel - Establishment Protocol. + PPID assignment (Section 8.1) and to create a new standalone registry + with its own URL for the DCEP (Section 8.2) containing two new + registration tables (Section 8.2.1 and Section 8.2.2). 8.1. SCTP Payload Protocol Identifier This document uses one already registered SCTP Payload Protocol Identifier (PPID) named "WebRTC Control". [RFC4960] creates the registry "SCTP Payload Protocol Identifiers" from which this identifier was assigned. IANA is requested to update the reference of this assignment to point to this document and to update the name. + The corresponding date should be kept. + Therefore this assignment should be updated to read: - +-------------+-----------+-----------+ - | Value | SCTP PPID | Reference | - +-------------+-----------+-----------+ - | WebRTC DCEP | 50 | [RFCXXXX] | - +-------------+-----------+-----------+ + +-------------+-----------+-----------+------------+ + | Value | SCTP PPID | Reference | Date | + +-------------+-----------+-----------+------------+ + | WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 | + +-------------+-----------+-----------+------------+ -8.2. New Message Type Registry +8.2. New Standalone Registry for the DCEP + + IANA is requested to create a new standalone registry (aka a webpage) + with its own URL for the Data Channel Establishment Protocol (DCEP). + The title should be "Data Channel Establishment Protocol (DCEP) + Parameters". It will contain the two tables as described in + Section 8.2.1 and Section 8.2.2. + +8.2.1. New Message Type Registry IANA is requested to create a new registration table "Message Type Registry" for the Data Channel Establishment Protocol (DCEP) to manage the one byte "Message Type" field in DCEP messages (see - Section 5). + Section 5). This registration table should be part of the registry + described in Section 8.2. The assignment of new message types is done through an RFC required action, as defined in [RFC5226]. Documentation of the new message type MUST contain the following information: 1. A name for the new message type; 2. A detailed procedural description of the use of messages with the new type within the operation of the Data Channel Establishment Protocol. @@ -423,28 +437,30 @@ | 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. The value 0xff has been reserved for - future extensibility. + future extensibility. The range of possible values is from 0x00 to + 0xff. -8.3. New Channel Type Registry +8.2.2. New Channel Type Registry IANA is requested to create a new registration table "Channel Type Registry" for the Data Channel Establishment Protocol to manage the one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see - Section 5.1). + Section 5.1). This registration table should be part of the registry + described in Section 8.2. 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. @@ -461,27 +477,31 @@ | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | | Reserved | 0x7f | [RFCXXXX] | | Reserved | 0xff | [RFCXXXX] | | 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, 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. + 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. 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. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. @@ -489,39 +509,39 @@ [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. [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-04 (work in progress), May 2014. + dtls-encaps-05 (work in progress), July 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. 10.2. Informational References [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. - [I-D.ietf-rtcweb-data-channel] - Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data - Channels", draft-ietf-rtcweb-data-channel-10 (work in - progress), June 2014. - [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- - ietf-rtcweb-security-06 (work in progress), January 2014. + ietf-rtcweb-security-07 (work in progress), July 2014. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-09 (work in progress), February 2014. + rtcweb-security-arch-10 (work in progress), July 2014. Authors' Addresses Randell Jesup Mozilla US Email: randell-ietf@jesup.org Salvatore Loreto