draft-ietf-rtcweb-data-protocol-04.txt   draft-ietf-rtcweb-data-protocol-05.txt 
Network Working Group R. Jesup Network Working Group R. Jesup
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Standards Track S. Loreto Intended status: Standards Track S. Loreto
Expires: October 11, 2014 Ericsson Expires: November 16, 2014 Ericsson
M. Tuexen M. Tuexen
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
April 9, 2014 May 15, 2014
WebRTC Data Channel Establishment Protocol WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-04.txt draft-ietf-rtcweb-data-protocol-05.txt
Abstract Abstract
The Web Real-Time Communication (WebRTC) working group is charged to The Real-Time Communication in WEB-browsers working group is charged
provide protocols to support for direct interactive rich to provide protocol support for direct interactive rich communication
communication using audio, video, and data between two peers' web- using audio, video, and data between two peers' web-browsers. This
browsers. This document specifies a simple protocol for establishing document specifies a simple protocol for establishing symmetric data
symmetric data channels between the peers. It uses a two way channels between the peers. It uses a two way handshake and allows
handshake and allows sending of user data without waiting for the sending of user data without waiting for the handshake to complete.
handshake to complete.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4
5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9
8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9 8.2. New Message Type Registry . . . . . . . . . . . . . . . . 9
8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10 8.3. New Channel Type Registry . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informational References . . . . . . . . . . . . . . . . 11 10.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Data Channel Establishment Protocol (DCEP) is designed to The Data Channel Establishment Protocol (DCEP) is designed to
provide, in the WebRTC data channel context provide, in the WebRTC data channel context
[I-D.ietf-rtcweb-data-channel], a simple in-band method to open [I-D.ietf-rtcweb-data-channel], a simple in-band method to open
skipping to change at page 3, line 26 skipping to change at page 3, line 26
Channel: Two Streams with the same SCTP stream identifier, one in Channel: Two Streams with the same SCTP stream identifier, one in
each direction, which are managed together. each direction, which are managed together.
4. Protocol Overview 4. Protocol Overview
This protocol is a simple, low-overhead way to establish This protocol is a simple, low-overhead way to establish
bidirectional Channels over an SCTP association with a consistent set bidirectional Channels over an SCTP association with a consistent set
of properties. of properties.
The set of consistent properties includes The set of consistent properties includes:
o whether the messages are transmitted reliable or unreliable. In o whether the messages are transmitted reliable or unreliable. In
case of unreliable transmissions, the same level of unreliability case of unreliable transmissions, the same level of unreliability
is used. is used.
o whether the messages are delivered in-order or out-of order. o whether the messages are delivered in-order or out-of order.
o the priority of the Channel. o the priority of the Channel.
o an optional label for the Channel. o an optional label for the Channel.
o an optional protocol for the Channel. o an optional protocol for the Channel.
o the SCTP streams. o the SCTP streams.
The Data Channel Establishment Protocol uses a two way handshake to The Data Channel Establishment Protocol uses a two way handshake to
open a data channel by combining two SCTP streams, one in each open a data channel by combining two SCTP streams, one in each
direction, with the same SCTP stream identifier. The side wanting to direction, with the same SCTP stream identifier. The side wanting to
open a data channel selects an SCTP stream identifier for which the open a data channel selects an SCTP stream identifier for which the
corresponding incoming and outgoing SCTP stream is unused and sends a corresponding incoming and outgoing SCTP streams are unused and sends
DATA_CHANNEL_OPEN message on this outgoing SCTP stream. The peer a DATA_CHANNEL_OPEN message on the outgoing SCTP stream. The peer
responds with a DATA_CHANNEL_ACK message on its corresponding responds with a DATA_CHANNEL_ACK message on its corresponding
outgoing SCTP stream. Then the data channel is open. Please note outgoing SCTP stream. Then the data channel is open. Please note
that the opening side can send user messages before the that the opening side can send user messages before the
DATA_CHANNEL_ACK is received. Data channel messages are sent on 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 same Stream as the user messages belonging to the data channel. The
demultiplexing is based on the SCTP payload protocol identifier demultiplexing is based on the SCTP payload protocol identifier
(PPID), since the Data Channel Establishment Protocol uses a specific (PPID), since the Data Channel Establishment Protocol uses a specific
PPID. PPID.
To avoid glare in opening Channels, each side MUST use either even or To avoid glare in opening Channels, each side MUST use Streams with
odd Streams when sending a DATA_CHANNEL_OPEN message. The method either even or odd SCTP stream identifiers when sending a
used to determine which side uses odd or even is based on the DATA_CHANNEL_OPEN message. When using
underlying DTLS connection role when used in WebRTC, with the side [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which
acting as the DTLS client using even stream identifiers. 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 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 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. labeled "x" - one on an even Stream pair, one on an odd pair.
The protocol field is to ease cross-application interoperation The protocol field is to ease cross-application interoperation
("federation") by identifying the user data being passed with an ("federation") by identifying the user data being passed with an
IANA-registered string ('WebSocket Subprotocol Name Registry' defined IANA-registered string ('WebSocket Subprotocol Name Registry' defined
in [RFC6455]), and may be useful for homogeneous applications which in [RFC6455]), and may be useful for homogeneous applications which
may create more than one type of Channel. Please note that there is may create more than one type of Channel. Please note that there is
skipping to change at page 6, line 14 skipping to change at page 6, line 14
seconds in the Reliability Parameter. This life-time starts seconds in the Reliability Parameter. This life-time starts
when providing the user message to the protocol stack. when providing the user message to the protocol stack.
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The channel
provides a partial reliable unordered bi-directional provides a partial reliable unordered bi-directional
communication channel. User messages might not be transmitted communication channel. User messages might not be transmitted
or retransmitted after a specified life-time given in milli- or retransmitted after a specified life-time given in milli-
seconds in the Reliability Parameter. This life-time starts seconds in the Reliability Parameter. This life-time starts
when providing the user message to the protocol stack. 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 The priority of the channel as described in
[I-D.ietf-rtcweb-data-channel]. The higher the number, the lower [I-D.ietf-rtcweb-data-channel]. The higher the number, the lower
the priority. the priority.
Reliability Parameter: 4 bytes (unsigned integer) Reliability Parameter: 4 bytes (unsigned integer)
For reliable channels this field MUST be set to 0 on the sending 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 side and MUST be ignored on the receiving side. If a partial
reliable channel with limited number of retransmissions is used, reliable channel with limited number of retransmissions is used,
this field specifies the number of retransmissions. If a partial this field specifies the number of retransmissions. If a partial
reliable channel with limited lifetime is used, this field reliable channel with limited lifetime is used, this field
skipping to change at page 8, line 34 skipping to change at page 8, line 34
message. Therefore, receiving an SCTP stream reset request for a message. Therefore, receiving an SCTP stream reset request for a
stream on which no DATA_CHANNEL_ACK message has been received stream on which no DATA_CHANNEL_ACK message has been received
indicates to the sender of the corresponding DATA_CHANNEL_OPEN indicates to the sender of the corresponding DATA_CHANNEL_OPEN
message the failure of the data channel setup procedure. After also message the failure of the data channel setup procedure. After also
successfully resetting the corresponding outgoing SCTP stream, which successfully resetting the corresponding outgoing SCTP stream, which
concludes the channel closing initiated by the peer, a new concludes the channel closing initiated by the peer, a new
DATA_CHANNEL_OPEN message can be sent on the stream. DATA_CHANNEL_OPEN message can be sent on the stream.
7. Security Considerations 7. Security Considerations
This document does not add any additional considerations to the ones The DATA_CHANNEL_OPEN messages contains two variable length fields:
given in [I-D.ietf-rtcweb-security] and 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]. [I-D.ietf-rtcweb-security-arch].
8. IANA Considerations 8. IANA Considerations
[NOTE to RFC-Editor: [NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this "RFCXXXX" is to be replaced by the RFC number you assign this
document. document.
] ]
skipping to change at page 11, line 22 skipping to change at page 11, line 43
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. 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] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 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 10.2. Informational References
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011. 6455, December 2011.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-07 (work in Channels", draft-ietf-rtcweb-data-channel-08 (work in
progress), February 2014. progress), April 2014.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-06 (work in progress), January 2014. ietf-rtcweb-security-06 (work in progress), January 2014.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-09 (work in progress), February 2014. rtcweb-security-arch-09 (work in progress), February 2014.
Authors' Addresses Authors' Addresses
 End of changes. 15 change blocks. 
31 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/