Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Tue, 02 September 2014 13:59 UTC

Return-Path: <muthu.arul@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03B1A0484 for <rtcweb@ietfa.amsl.com>; Tue, 2 Sep 2014 06:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbfQiHS-5fP2 for <rtcweb@ietfa.amsl.com>; Tue, 2 Sep 2014 06:59:17 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687931A03F8 for <rtcweb@ietf.org>; Tue, 2 Sep 2014 06:59:17 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id e4so7919835wiv.8 for <rtcweb@ietf.org>; Tue, 02 Sep 2014 06:59:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6Kv2vHn9oizEXm4qLIbQUznChY1Gg6Jz97MvTt2eQo0=; b=I9R4sVCmeEb6OrjpPdFESHkQUBGVqHjvjKf4kl41qn0jnvxBwSz27Lil/w5hehsXHI 6MbCwl6l74C5xmBjCGgFc8CV6fQkQjfukKU+0oVPNyS9JKkhlkmkEivg3lWbWhol4mKe DhRaPlTrrUCocQ1Z39E8zpE9E/kSKuUwQkmsey20ZVA1+HzV3z6n71j17o0ZMXmpiUoI 39G7OifWbKZ81TExOo2CizW88clcVu0jaMWjailU4i3Sea1SR4TUTfa4oKkI8/0vfvik slgbszWalQzkOxlBRgD2viKQ1RWlnAdpzoKieFpLafEyP07vPFmgEWmeOoB/ybxZv1Ad ebhw==
MIME-Version: 1.0
X-Received: by 10.194.92.71 with SMTP id ck7mr38966327wjb.11.1409666355900; Tue, 02 Sep 2014 06:59:15 -0700 (PDT)
Received: by 10.180.197.168 with HTTP; Tue, 2 Sep 2014 06:59:15 -0700 (PDT)
In-Reply-To: <CABkgnnVGe_CPHrh7VL_H0STs7x3COW1w54xu=hsZSD=j-vHqCA@mail.gmail.com>
References: <CA+9kkMCZT1XW4LLaJ4Nq2DbrxD59cYnjLo5JXn9fjEb8pyamaQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <CAKz0y8zycsyr9m4BA=-8xOaWkU+Sog5Mbz7K-oN3woqi++mVzg@mail.gmail.com> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <CAKz0y8zNM3rc3XC6JqrK+d4hXiT5TomhNM+W2twg0+-83-pFow@mail.gmail.com> <CABkgnnUnfB5bskH4zWRfBMdHbSoqftV5Fo_GEXoLt9XCH9Tt_w@mail.gmail.com> <CAD5OKxsT9Vdm0=tjk9WsLAH4ekbAizgyjm--168TrOf8UAYGZw@mail.gmail.com> <CABkgnnXUpibu8kWYmbJJJT2J3RNGXFV8LbceLijgG0U-pGY2xQ@mail.gmail.com> <CAKz0y8z_oBf2efavfOLgzqE1R8sZstefZ1tvwwJLkhRskXZERQ@mail.gmail.com> <CAD5OKxsSqA=cki_fSaqAPP0GXCv_kHr6571C+K9ze4ceHCGYdQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <D01D6B42.104F8%rmohanr@cisco.com> <009001cfbe4f$6b92f280$42b8d780$@co.in> <CAKz0y8y3=0_-jwWiviR_Uj6tSq75NEq92Ocergc_NvFk2h_72Q@mail.gmail.com> <CAD5OKxugaPq=cLppPUqT8CUADV-E2zDMcz6m3sUgKOnK-TdQfQ@mail.gmail.com> <CABkgnnU6kv+=jQuxj4Ci-zYW9mHEfJ=6jqqrdqDTopPN06-kgw@mail.gmail.com> <CAD5OKxu=9X2um+EebZzp3isY-R_-NqyOgH+bWj55+_Q8qXfrqg@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E52F5F0@US70UWXCHMBA02.zam.alcatel-lucent.com> <CABkgnnUNk=QMFtGH3ZvD0V3B6OwSjcsOmaQU5+gcQ5wg9yo7aA@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E532F45@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAKz0y8wS93GbA-HrW9mMr=RsrTFVXTsV1=F14enNwYJ2Grfbnw@mail.gmail.com> <CABkgnnVGe_CPHrh7VL_H0STs7x3COW1w54xu=hsZSD=j-vHqCA@mail.gmail.com>
Date: Tue, 2 Sep 2014 19:29:15 +0530
Message-ID: <CAKz0y8wq-0wxWjNXZUoUcoryJFKJojHPOXZRsrsrDDcx-qNZhg@mail.gmail.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bf0d534654d3f050215860b
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VoZdSSkVfOwIdl1BWLts7U7Z2Io
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 02 Sep 2014 13:59:19 -0000

On Tue, Aug 26, 2014 at 11:30 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 26 August 2014 07:45, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> wrote:
> > Consent freshness is applicable to any WebRTC entity supporting full
> ICE. A
> > WebRTC browser/device as defined in the transport and overview drafts
> > support full ICE, so perform consent freshness. The requirements for
> other
> > WebRTC entities, including WebRTC gateway, is yet to be fully specified,
> and
> > the document that specifies them would also specify whether they support
> > full ICE or not (and hence whether they perform consent freshness or
> not).
>
>
> Actually, that's probably the best approach: note that this applies -
> and can be useful for - any ICE implementation.  And leave it at that
> for this document.  The transports or security docs might make some
> statements about mandating this mechanism.
>

draft-ietf-rtcweb-security-arch already does that (the reference there
needs an update, though) :

   The one remaining security property we need to establish is "consent
   freshness", i.e., allowing Alice to verify that Bob is still prepared
   to receive her communications so that Alice does not continue to send
   large traffic volumes to entities which went abruptly offline.  ICE
   specifies periodic STUN keepalizes but only if media is not flowing.
   Because the consent issue is more difficult here, we require RTCWeb
   implementations to periodically send keepalives.  As described in
   Section 5.3, these keepalives MUST be based on the consent freshness
   mechanism specified in [I-D.muthu-behave-consent-freshness].  If a
   keepalive fails and no new ICE channels can be established, then the
   session is terminated.


Muthu