- 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 UTC