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

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

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Monday, September 19, 2011 8:35 AM
> To: Dan Wing
> Cc: 'Harald Alvestrand'; 'Eric Rescorla'; [e-mail]
> Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
> 
> 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

Thanks for that pointer.

In that post, you wrote:

  "So one case of attack is the one when the webserver S uses 
   the connected clients to attack target T by instructing client 
   C to send to target T. 
   ..."

That attack is what Jonathan called the 'voice hammer' attack.  
ICE solves that attack very well, 
http://tools.ietf.org/html/rfc5245#section-18.5.1 -- is more
needed for that attack?


When Eric mentioned 'consent freshness', it was the first time I 
had seen him use that term.  (No, I didn't search the archives.)
My interpretation 'consent freshness' is that, after a call had been
up and running the RTP receiver might die or disconnect from the
network, and a new host or restarted application might take over
that IP address and possibly also start listening on that same
UDP port.  By 'consent freshness', he wants a valid listener to
occasionally say "yes, I still like receiving this flow" 
and he wants other listeners to not send that message -- causing
the sender to eventually give up.


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

-d


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