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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 19 September 2011 15:33 UTC

Return-Path: <magnus.westerlund@ericsson.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 2645C21F8BF4 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.51
X-Spam-Level:
X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 vk9liwe9coax for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:33:03 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD921F8B8C for <rtcweb@ietf.org>; Mon, 19 Sep 2011 08:33:02 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-a0-4e77613c45ed
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.24.02839.C31677E4; Mon, 19 Sep 2011 17:35:24 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 17:35:24 +0200
Message-ID: <4E77613B.4020805@ericsson.com>
Date: Mon, 19 Sep 2011 17:35:23 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.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>
In-Reply-To: <0ced01cc76de$28731630$79594290$@com>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <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:33:04 -0000

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

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------