Re: [rtcweb] STUN for keep-alive

Eric Rescorla <ekr@rtfm.com> Wed, 14 September 2011 17:11 UTC

Return-Path: <ekr@rtfm.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 B275A21F8B8F for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 10:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.898
X-Spam-Level:
X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 aodXLnqqMuNy for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 10:11:31 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7A21F8B67 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 10:11:30 -0700 (PDT)
Received: by wyg24 with SMTP id 24so1941730wyg.31 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 10:13:39 -0700 (PDT)
Received: by 10.227.28.141 with SMTP id m13mr87757wbc.37.1316020419810; Wed, 14 Sep 2011 10:13:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.196.9 with HTTP; Wed, 14 Sep 2011 10:13:19 -0700 (PDT)
In-Reply-To: <4E70D2E6.1000809@alvestrand.no>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 14 Sep 2011 10:13:19 -0700
Message-ID: <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] 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: Wed, 14 Sep 2011 17:11:31 -0000

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.

-Ekr

On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <harald@alvestrand.no>; wrote:
> On 09/14/11 15:07, Christer Holmberg wrote:
>>
>> Hi,
>>
>>>> |Sure, but there is still a max time between the keep-alives.
>>>
>>> You are free to set it to a very long duration that disables
>>> keepalives for all practical purposes (assuming such duration
>>> is represented by a 32-bit unsigned integer you can set it to
>>> ~136 years).
>>
>> Yes, but at the end of the day something has to be sent in order to keep
>> the NAT binding open.
>>
>>>> |Using e.g. RTP, the media handler would not have to be prepared to
>>>> |receive the STUN keep-alives in the first place, it could
>>>> |simply just
>>>> |relay whatever comes on the media plane.
>>>
>>> If the media handles can handle STUN binding requests
>>> efficiently I don't see why they can't handle STUN binding
>>> indications (keepalives) in a similar manner.
>>
>> I believe it knows when to expect those. But, in any case, the main reason
>> behind the proposal is to decrease the number of STUN requests.
>
> I think it's a more urgent desire that we should minimize the number of
> variants of protocols in use.
> Defining a variant of ICE that modifies the keepalive mechanism seems to me
> like a Bad Idea.
>
>                     Harald
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>