- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 20 Jul 2011 12:15:37 +0200
- To: Cullen Jennings <fluffy@cisco.com>
- CC: Matthew Kaufman <matthew.kaufman@skype.net>, Ian Hickson <ian@hixie.ch>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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. >> >> Matthew Kaufman >> > > > +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). Stefan > >
Received on Wednesday, 20 July 2011 10:16:01 UTC