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

"Dan Wing" <dwing@cisco.com> Mon, 19 September 2011 15:57 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0661C21F8C6D for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.143
X-Spam-Level:
X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+Iq-cgsGVSM for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:57:15 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3D921F8C6A for <rtcweb@ietf.org>; Mon, 19 Sep 2011 08:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5777; q=dns/txt; s=iport; t=1316447978; x=1317657578; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=+yNHXKWrmTNHj/2dvhaLzdp4Uo2MHNN+FHKYWfpTvz0=; b=NGVmOhCfiMgJnNXQc5BuuQ1qd4dX9jsxuyZalCPnqcjrw8kaduhSLKav /9oxAsYOE15d7zukOS9MkYunjRJRUZ5XLSJDPMb/Dv9RlTBIAcLh/vazF aPf2qnkqEeVvuDHp7KGlSlvl5OZTqcpCGEDwQGAB9a/iTUNMHkHwZnNgq k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcAAANmd06rRDoJ/2dsb2JhbABCmFGBbIx7d4FTAQEBAQIBCAQGARdPBQcBAQICCQ8CBAEBAScHGQIhCgkIAQEEEwkCF4dVBJccAZ1rAoZ2BIc/MJ0n
X-IronPort-AV: E=Sophos;i="4.68,406,1312156800"; d="scan'208";a="2979267"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 19 Sep 2011 15:59:38 +0000
Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8JFxcCN029303; Mon, 19 Sep 2011 15:59:38 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com>
In-Reply-To: <4E77613B.4020805@ericsson.com>
Date: Mon, 19 Sep 2011 08:59:39 -0700
Message-ID: <0d4101cc76e5$2333d6d0$699b8470$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acx24cFSMXH/w5cJTmCfz+4yvHkOgwAAnl0Q
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 15:57:16 -0000

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Monday, September 19, 2011 8:35 AM
> To: Dan Wing
> Cc: 'Harald Alvestrand'; 'Eric Rescorla'; rtcweb@ietf.org
> 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:harald@alvestrand.no]
> >> Sent: Sunday, September 18, 2011 2:11 PM
> >> To: Eric Rescorla
> >> Cc: Dan Wing; rtcweb@ietf.org
> >> 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<dwing@cisco.com>;  wrote:
> >>>>> -----Original Message-----
> >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> >>>>> Behalf Of Eric Rescorla
> >>>>> Sent: Wednesday, September 14, 2011 10:32 AM
> >>>>> To: Christer Holmberg
> >>>>> Cc: rtcweb@ietf.org
> >>>>> Subject: Re: [rtcweb] STUN for keep-alive
> >>>>>
> >>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg
> >>>>> <christer.holmberg@ericsson.com>;  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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------