Re: [rtcweb] Requiring ICE for RTC calls

[Roman Shpount <[e-mail]>]

Matthew,

One possible solution would be to have a slow rate RTP start, if remote end
point does not indicate ICE support. Instead of sending real media, RTC end
point will send no-media RTP packets at the rate of 2-3 per second for 10-15
seconds. If it receives a valid RTP packet back from the destination IP, it
will consider RTP flow verified and switch to sending media at normal rate,
otherwise media stream is terminated. We can have a better timing mechanism
for RTP packets to match the number of packets in the initial STUN handshake
in ICE, but the general idea is to get interoperability with existing
networks at the cost of 20 packet handshake. I do realize that the problem
with this that the RTP packets can be spoofed to force the web end point to
transmit, but this is the best solution I see so far.

If we do decide that ICE is a requirement, we can also have a local policy,
web site can be specified for which the calls are allowed without ICE.

Independently from all of this, SRTP should be optional. It does present
privacy concerns, but they are no different then privacy concerns over HTTP.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 11:15 AM, Matthew Kaufman <[e-mail]
> wrote:

> On 9/27/2011 7:46 AM, Roman Shpount wrote:
>
>>
>> How real or big do you think this problem is going to be? None of the
>> current SIP/VoIP clients address this now, and we have quite a number of
>> them out there. I understand that this is an attack vector but how big of an
>> attack vector is this going to be if we ask for user confirmation?
>>
>>
> There is no plan to ask for user confirmation to open a connection, receive
> media, or send and receive data. The only user confirmation that is expected
> would be for camera and/or microphone access.
>
> I've seen a dozen messages from you arguing that the requirement for a STUN
> connectivity check is a barrier and should be removed, but I have not yet
> seen an alternative proposal that meets the requirements of browser authors
> with regard to preventing attacks on behind-firewall infrastructure from the
> browser platform.
>
> Matthew Kaufman
>