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

["Dan Wing" <[e-mail]>]

> -----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).

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).

-d