W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Signaling & peerconnection API questions

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 26 Jul 2011 02:50:27 +0000 (UTC)
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
cc: Cullen Jennings <fluffy@cisco.com>, Matthew Kaufman <matthew.kaufman@skype.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <Pine.LNX.4.64.1107260248340.2079@ps20323.dreamhostps.com>
On Wed, 20 Jul 2011, Stefan Håkansson LK wrote:
> On 2011-07-20 00:40, Cullen Jennings wrote:
> > On Jul 19, 2011, at 12:21 , Matthew Kaufman wrote:
> > > On 7/19/2011 10:49 AM, Ian Hickson wrote:
> > > > On Tue, 19 Jul 2011, Stefan Håkansson LK wrote:
> > > > > 
> > > > > So basically the web app could fake an SDP offer (indicating no 
> > > > > support of ICE) locally, feed it to a PeerConnection object and 
> > > > > then use 'send' to have the browser send data to an IP address 
> > > > > and port of its choice (the address/port in the fake SDP).
> > > > > 
> > > > > This is not at all my area, so apologies up front if I got 
> > > > > things wrong.
> > > >
> > > > I don't know about the audio and video streams, but at least in 
> > > > the case of the data streams, this is the kind of thing we avoid 
> > > > having to worry about by having the data stream be 
> > > > indistinguishable from line noise.
> > > 
> > > I think an SDP offer that indicates no support of ICE MUST be 
> > > rejected as failing to comply with the security model. No handshake, 
> > > no sending audio, video, or data to them.
> >
> > +1 - seriously, I can't see any alternative to this
>
> My conclusion was the same. This means as far as I understand it that 
> the spec should be updated. Today it just references rfc5245, I think a 
> clause saying something like "that an SDP offer indicating that ICE is 
> not supported must be rejected" should be added. Alternative it could 
> say that no sending of audio, video or data is allowed if there has not 
> been an ICE handshake. (I guess others will be able to phrase this much 
> better).

I tried to add something to this effect to the spec, but I couldn't find 
where in the ICE spec it would ever cause any processing to occur in a 
manner that didn't involve a probe which would fail if the other side 
wasn't expecting a connection. Can someone more familiar with ICE 
elaborate on what behaviour exactly it is that I should be blocking here?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 26 July 2011 02:50:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 July 2011 02:51:00 GMT