Re: [rtcweb] STUN for keep-alive - RTCP-less applications

[Magnus Westerlund <[e-mail]>]

On 2011-09-22 15:34, Hadriel Kaplan wrote:
> 
> On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote:
> 
>>> If the concern is just that the far-end is dead or terminated the
>>> call but the local side didn't get the memo, we can solve that
>>> other ways.
>> 
>> On the last issue, do you have a suggestion for how to achieve this
>> that isn't RTCP?
> 
> If we assume that a gateway to legacy has to handle ICE termination
> anyway, then it can send STUN indications during the call. The rtcweb
> browser can use those to see the far end is alive and expecting media
> on the 5-tuple. If we're worried about those being faked/spoofed by
> malicious server/JS, we can modify the indication mechanism (which
> could also allay ekr's concerns about consent refresh).

Yes, the question is if the indications are sufficient as their security
properties even when signed are a bit different from the STUN request
with answer.

> 
> 
>>> Yup.  I don't doubt we'll need some form of media-plane gateway 
>>> either in the web server or separate to interop with legacy -
>>> I'm just trying to keep it from becoming so expensive and
>>> complicated that it would be cheaper/easier/better to use SIP
>>> softclients or plugins instead.
>>> 
>> 
>> I understand and support that we shouldn't have unnecessary 
>> complications for legacy interop. However, but I don't see it being
>> done by compromising security to the level where RTCWEB can't be
>> deployed even for browser to browser usage.
> 
> Welllll... could we just require specific user consent for calls
> to/from legacy?
> 

No, I don't think so. The user is not capable of determining the
difference between the two consent types. I am not certain that a random
picked person on this very mailing list will be able to explain it and
get agreement on the implications from the others in the first try.

What we might have is some other security indications for some set of
behaviors. But as the assumption discussion have showed it will not be
easy.

Having sounded quite negative, I still think it is worth spending some
time discussing the trade-offs that can be made. But I rather error on
the side of better security initially and then go back and change things
if we realize that it can be done.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------