Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]

[Magnus Westerlund <[e-mail]>]

On 2011-09-19 17:09, Dan Wing wrote:
>> -----Original Message-----
>> From: Harald Alvestrand [mailto:[e-mail]]
>> Sent: Sunday, September 18, 2011 2:11 PM
>> To: Eric Rescorla
>> Cc: Dan Wing; [e-mail]
>> Subject: Re: [rtcweb] STUN for keep-alive
>>
>> On 09/16/2011 08:30 PM, Eric Rescorla wrote:
>>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing<[e-mail]>  wrote:
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>> Behalf Of Eric Rescorla
>>>>> Sent: Wednesday, September 14, 2011 10:32 AM
>>>>> To: Christer Holmberg
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [rtcweb] STUN for keep-alive
>>>>>
>>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg
>>>>> <[e-mail]>  wrote:
>>>>>> Hi,
>>>>>>
>>>>>>> One new concern in this context is maintaining the consent
>> freshness.
>>>>>>> The browser needs to be sure that the recipient of traffic is
>> stil
>>>>> responding in a way that can't be forged. It's likely RTCP provides
>>>>> this (though we'd need to analyze to be sure) but perhaps better
>> would
>>>>> be to mandate STUN checks
>>>>>>> at enough frequency that you get some sort of level of
>> freshness....
>>>>> maybe every 2 minutes or something.
>>>>>> Please note that the STUN keep-alives are implemented using STUN
>>>>> indication messages, so there are no replies (nor does the receiver
>>>>> perform an authentication check).
>>>>>
>>>>>
>>>>> Oh... I had forgotten that.... that's not good.
>>>> The RTCP receiver reports should be adequate for 'consent
>> freshness', no?
>>>> If I still like receiving the traffic, I'll report that I'm
>> receiving it.
>>>> If I have crashed or disconnected or am not listening on that port,
>> I won't.
>>> I believe so, though I'd have to make sure there's enough entropy.
>> And of course
>>> some implementations may not do RTCP...
>> Depending on RTCP seems less uncomfortable with SRTP than with
>> plaintext
>> RTCP.
>> I don't think we want to support RTCP-less applicaitons; if saying "no"
>> to them helps them not occur (it doesn't always help...)
> 
> (Case in point: RTCP has long been a requirement for RTP, but 
> implementation was still skipped by Cisco, and probably others.)
> 
> I don't know how much entropy Eric was looking for.  RTCP receiver
> reports only echo back the SSRC, which is 32 bits and is going to
> be static for the duration of each RTP session (yes, SSRC collision
> could make it change.  But that is atypical.)  STUN request/response
> echoes back the 96-bit transaction id, which changes as often as the
> requestor likes (typically each new STUN transaction).

As I wrote in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html

The amount of entropy in an RTCP message may be as low as 8 bits. If
certain restrictions is accepted then we can probably reach 20-24 bits
without requiring more than basic RTCP provides.

> 
> Which would someone skip -- skip sending/implementing RTCP for 
> consent freshness, or skip sending/implementing STUN request/response 
> for consent freshness?  The STUN request/response is also additional
> data, whereas RTCP is something that is "already being sent" (thus
> the consent freshness isn't adding more bits on the wire).

I think RTCP may work for consent freshness. A longer series of
consistent RTCP messages to maintain the consent seems reasonable,
despite the low number of entropy bits per actual message. But, I do
think RTCP might have to few bits for the initial check where one wants
a rapid indication that it is fine to send media at higher bit-rates.

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