RE: Signaling & peerconnection API questions

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

In section 5.1 of rfc 5245 it says
"The agent will proceed with the ICE procedures defined in this
   specification if, for each media stream in the SDP it received, the
   default destination for each component of that media stream appears
   in a candidate attribute.  For example, in the case of RTP, the IP
   address and port in the c and m lines, respectively, appear in a
   candidate attribute and the value in the rtcp attribute appears in a
   candidate attribute.

   If this condition is not met, the agent MUST process the SDP based on
   normal RFC 3264 procedures, without using any of the ICE mechanisms
   described in the remainder of this specification with the following
   exceptions:"
The second part here says that if the SDP offer indicates that the other end does not support ICE the session setup should continue anyway without using ICE. This should in my view be blocked (as the SDP offer in question could in fact have been generated locally by the application).
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 26 July 2011 09:40:03 UTC