Re: [rtcweb] PeerConnection Data Channel

Colin Perkins <csp@csperkins.org> Tue, 06 September 2011 10:39 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFA221F85A1 for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 03:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.491
X-Spam-Level:
X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkqHSBay-bQP for <rtcweb@ietfa.amsl.com>; Tue, 6 Sep 2011 03:39:26 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE55F21F8586 for <rtcweb@ietf.org>; Tue, 6 Sep 2011 03:39:25 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0t5a-0005MU-mK; Tue, 06 Sep 2011 10:41:11 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-117--156462467
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAOJ7v-2QyB+jd7UoDKy+-oGwG926KNdgbwoJZcm6twUcKrGZjg@mail.gmail.com>
Date: Tue, 6 Sep 2011 11:41:10 +0100
Message-Id: <AC72FCDE-91C5-4808-B1C7-7F3F12242631@csperkins.org>
References: <CAOJ7v-1xEEA3+AX0hN4kR=9YggX7EW=wr4b67ASjibG_T=m2mQ@mail.gmail.com> <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> <BLU152-W197013CA571F772294FFF6931B0@phx.gbl> <CAOJ7v-2QyB+jd7UoDKy+-oGwG926KNdgbwoJZcm6twUcKrGZjg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org, public-webrtc@w3.org
Subject: Re: [rtcweb] PeerConnection Data Channel
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2011 10:39:27 -0000

On 3 Sep 2011, at 04:46, Justin Uberti wrote:
> On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> > >> Section 5 in the WEBRTC spec 
> > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at 
> > >> length a mechanism for transmitting and securing datagrams over the 
> > >> PeerConnection transport. 
> 
> [BA] The objective here appears to be "masking" (e.g. to prevent sending of arbitrary datagrams) rather than providing a full set of security services. 
> 
> The current spec provides an encryption and authentication mechanism, in addition to the masking. From the spec: "The data is made to appear pseudo-random, so that it cannot be used in a cross-protocol attack, even if somehow the stream were to be directed at an unsuspecting remote host. The data is hashed in such a way that it cannot be modified in transit. That data is encrypted so that it cannot be read in transit."
> 
> > > > At both an API and a wire level, this 
> > >> mechanism is quite different from the existing mechanisms that are 
> > >> used for transmission of audio and video data:
> > >> - The availability of the data stream is not easily known, whereas 
> > >> audio/video can be negotiated and stream existence learned from the 
> > >> *Stream methods/callbacks.
> 
> [BA] It looked to me that the data channel was negotiated in SDP, no?
> 
> Yes. But the API doesn't expose whether the data channel was successfully negotiated. 
> 
> > >> - It defines its own encryption mechanism, whereas audio/video will 
> > >> use SDES-SRTP, or DTLS-SRTP
> 
> [BA] I don't believe that the objective here is to duplicate the security services in SRTP, DTLS, TLS, IPsec or any other comprehensive security framework. 
> It's closer to the "masking" supported by WebSockets.  
> 
> That's not my understanding of the spec, as evidenced above.
>  
> 
> 
> > >> - This stream will show up in SDP
> 
> [BA] I believe that's what the current spec already says. 
> 
> > > Disagree. RTP semantics are inappropriate for sending data. The data 
> > > should be sent using one of the two methods for muxing data that were 
> > > proposed (one by me, one by cbran).
> 
> [BA] Agree that RTP semantics aren't necessarily appropriate for non media-stream data. 
> 
> Yeah, I admit my original opinion on this was that RTP was crazy. But looking at it more, we're going to end up duplicating much of what RTP provides - Matthew's proposal adds a 4 byte header to distinguish it from STUN, and we probably also need a stream id and a sequence number (for TFRC). At that point we're only a timestamp away from a full RTP header.

...and a payload type, contributing source list, header extensions, a bunch of semantics relating to timing and media playout, and the whole of RTCP. RTP is not just a data header format.

-- 
Colin Perkins
http://csperkins.org/