--- 1/draft-ietf-rtcweb-data-protocol-04.txt 2014-05-15 12:14:19.403494552 -0700 +++ 2/draft-ietf-rtcweb-data-protocol-05.txt 2014-05-15 12:14:19.431495234 -0700 @@ -1,48 +1,47 @@ Network Working Group R. Jesup Internet-Draft Mozilla Intended status: Standards Track S. Loreto -Expires: October 11, 2014 Ericsson +Expires: November 16, 2014 Ericsson M. Tuexen Muenster Univ. of Appl. Sciences - April 9, 2014 + May 15, 2014 WebRTC Data Channel Establishment Protocol - draft-ietf-rtcweb-data-protocol-04.txt + draft-ietf-rtcweb-data-protocol-05.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. + The Real-Time Communication in WEB-browsers working group is charged + to provide 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 October 11, 2014. + This Internet-Draft will expire on November 16, 2014. 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 @@ -56,25 +55,25 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 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 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 11 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 @@ -105,56 +104,59 @@ 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 + 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 the priority of the Channel. o an optional label for the Channel. o an optional protocol for the Channel. o the SCTP streams. The Data Channel Establishment Protocol uses a two way handshake to open a data 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 + corresponding incoming and outgoing SCTP streams are unused and sends + a DATA_CHANNEL_OPEN message on the 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 Establishment 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 WebRTC, with the side - acting as the DTLS client using even stream identifiers. + To avoid glare in opening Channels, each side MUST use Streams with + either even or odd SCTP stream identifiers when sending a + DATA_CHANNEL_OPEN message. When using + [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 + SCTP stream identifiers, the side acting as the DTLS server MUST use + Streams with odd SCTP 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 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 Channel. Please note that there is @@ -222,21 +224,21 @@ seconds in the Reliability Parameter. This life-time starts when providing the user message to the protocol stack. 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 protocol stack. - Priority: 2 bytes (integer) + Priority: 2 bytes (unsigned integer) 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) For reliable channels this field MUST be set to 0 on the sending side and MUST be ignored on the receiving side. 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 @@ -337,22 +339,35 @@ 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 SCTP stream, which concludes the channel closing initiated by the peer, 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 + 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 channel. An end-point + must also be prepared that the peer open the maximum number of data + channels. + + When using DCEP over SCTP encapsulated in DTLS as specified in + [I-D.ietf-tsvwg-sctp-dtls-encaps], security properties like privacy, + integrity, and source authentication can be provided by DTLS. If + DCEP is used without running over DTLS, this is not the case. + + For general considerations see [I-D.ietf-rtcweb-security] and [I-D.ietf-rtcweb-security-arch]. 8. IANA Considerations [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number you assign this document. ] @@ -464,38 +479,34 @@ [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. - [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-03 (work in progress), February 2014. + dtls-encaps-04 (work in progress), May 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-07 (work in - progress), February 2014. + Channels", draft-ietf-rtcweb-data-channel-08 (work in + progress), April 2014. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- 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-09 (work in progress), February 2014. Authors' Addresses