Re: [rtcweb] PeerConnection Data Channel

Justin Uberti <juberti@google.com> Sat, 03 September 2011 03:45 UTC

Return-Path: <juberti@google.com>
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 3874821F8BD5 for <rtcweb@ietfa.amsl.com>; Fri, 2 Sep 2011 20:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.612
X-Spam-Level:
X-Spam-Status: No, score=-105.612 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 xkKdv3bd63Of for <rtcweb@ietfa.amsl.com>; Fri, 2 Sep 2011 20:45:27 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2363921F8C30 for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:45:26 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p833l1nl024032 for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:47:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315021622; bh=5/QQMjmicBQS2Z64dhJVwAjstQE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qm0RFUZeCr6RfrCl6G54p5Oiv+cDz2RWMoGqt47xWgVA7fT99GPmkNgLBPlTLsilb 0m6+9WXs6d9FqCh7IaE7w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=YJ/9gmvAt0Ppivw1CkYjU44CVbrSLt19HY+mKL6iuHyO70rjNlzlGCY/XqMTNlNkg kqPKeWptB6+ilFYygw1nw==
Received: from iadk27 (iadk27.prod.google.com [10.12.137.27]) by wpaz5.hot.corp.google.com with ESMTP id p833l0Wv009576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:47:00 -0700
Received: by iadk27 with SMTP id k27so4849828iad.29 for <rtcweb@ietf.org>; Fri, 02 Sep 2011 20:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YsYYoOhzbXkBALsaHBE5EMr8YMvZEYMxanXBUkg/hDw=; b=pgxzt9Rgy+g+cdyci+9E3he1iwUHyOLWcBww7gEJulglREpihqIrfQXF52fzmh7HMU 6jZ68SmqM0AoRiKB/JEA==
Received: by 10.42.245.5 with SMTP id ls5mr1596049icb.149.1315021620300; Fri, 02 Sep 2011 20:47:00 -0700 (PDT)
Received: by 10.42.245.5 with SMTP id ls5mr1596040icb.149.1315021620115; Fri, 02 Sep 2011 20:47:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.10 with HTTP; Fri, 2 Sep 2011 20:46:40 -0700 (PDT)
In-Reply-To: <BLU152-W197013CA571F772294FFF6931B0@phx.gbl>
References: <CAOJ7v-1xEEA3+AX0hN4kR=9YggX7EW=wr4b67ASjibG_T=m2mQ@mail.gmail.com> <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> <BLU152-W197013CA571F772294FFF6931B0@phx.gbl>
From: Justin Uberti <juberti@google.com>
Date: Fri, 02 Sep 2011 23:46:40 -0400
Message-ID: <CAOJ7v-2QyB+jd7UoDKy+-oGwG926KNdgbwoJZcm6twUcKrGZjg@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary="90e6ba5bc13789fac404ac01541d"
X-System-Of-Record: true
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: Sat, 03 Sep 2011 03:45:28 -0000

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.

I think this is an interesting discussion, so I'll send a new email to the
list to discuss the wire format of this protocol, which I think can be
considered separately from the DataStream proposal I'm putting forth here.

>
> > >> - For encryption, it simply uses the underlying encryption of the
> > >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.
>
> [BA] If the underlying semantics of RTP aren't a good fit, why would that
> make sense?
>

True. However, if we use DTLS, we can apply DTLS without the need for RTP
semantics. Or as Matthew says, we could also make SRTP-style encryption work
with whatever datagram protocol we come up with.

>
> > > Absolutely correct. Possibly needs masking for the "none" case
> > > however... need to discuss.
>
> [BA] Right.  That's why it's there, not to provide a generic security
> framework.
>

See above.

>
> >
> > Hmmm.... This (blah-SRTP for encrypting the data streams means full
> > un-encrypted RTP headers at a minimum, plus a bunch of those "RTP
> > semantics" you disagreed with above. Unless I mis-understand how this
> > would work.
>
> [BA] Right.  That's what trying to force RTP security on non-media data
> isn't appropriate.
>

See above.

>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>