IETF Logo Mail Archive

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

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Fri, 22 August 2014 05:25 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 865581A0054 for <rtcweb@ietfa.amsl.com>; Thu, 21 Aug 2014 22:25:56 -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 Gbd5WYcwuB_v for <rtcweb@ietfa.amsl.com>; Thu, 21 Aug 2014 22:25:55 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1E11A0053 for <rtcweb@ietf.org>; Thu, 21 Aug 2014 22:25:54 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id q58so10222367wes.4 for <rtcweb@ietf.org>; Thu, 21 Aug 2014 22:25:53 -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=POvhw7zvmlHT5At6nJAe6LLsp/SfUC3E7BFue+Qmw6w=; b=M2f3IWa49OhOmNTmlL3qFAykcDcLMB8XQDiV4mvv3RQDhg3lvdYOhgmxfDIeIY4Yyp pq2l/1BQxyBEJxL86jWLLUUEPxZ275oNWXLgb2QPHySATcPQkcaU+sO7L3QgykKUtKBb KareYQK8E8o4azPWFA1+ccYgItM+vpo4fz2hpAlD4hxZWamQsEOVbzt5JgXfPac8UOFn 7AZmSWaMNgj+2gEOExUx34M7FKiU8ZWk7lHHmRUaqAdCXhy2c+RXG2OkdIMOs4Xb0jY3 hrBUxlWQkIZL/CajLT20Kli+TzkMSH+0MLvAhg+mZyagETH6Tl6nNwuoCVVybrFYTk/Q 4fRQ==
MIME-Version: 1.0
X-Received: by 10.180.73.139 with SMTP id l11mr8524283wiv.30.1408685153181; Thu, 21 Aug 2014 22:25:53 -0700 (PDT)
Received: by 10.180.14.65 with HTTP; Thu, 21 Aug 2014 22:25:53 -0700 (PDT)
In-Reply-To: <CABkgnnXUpibu8kWYmbJJJT2J3RNGXFV8LbceLijgG0U-pGY2xQ@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>
Date: Fri, 22 Aug 2014 10:55:53 +0530
Message-ID: <CAKz0y8z_oBf2efavfOLgzqE1R8sZstefZ1tvwwJLkhRskXZERQ@mail.gmail.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="f46d043c07de27e51505013112ef"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wGy_T6qNca0ZD__7fUj4-8EYnnQ
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: Fri, 22 Aug 2014 05:25:56 -0000

ICE-lite entities don't even perform connectivity checks. Requiring they
perform consent freshness doesn't seem to make sense to me (of course, we
can come up with a new spec ICE-lite-with-consent, but that's a different
problem).

I am not saying you can't spoof a public VoIP service to send RTP anywhere.
Legacy ICE entities perform connectivity checks today and not consent and
consent freshness. Do we want to make them more secure? Sure. It however is
a problem of different scope and need to be solved in MMUSIC or elsewhere,
IMHO.

draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser
more secure. It however allows an RTP endpoint (that also does ICE) to use
the mechanism to make it more secure or compute RTT or carry network
information or whatever. However, requiring every RTP endpoint perform it
seems asking too much.

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD
Other RTP entities (including WebRTC gateway) - MAY

Thoughts?

Muthu

On Fri, Aug 22, 2014 at 1:06 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 21 August 2014 11:25, Roman Shpount <roman@telurix.com> wrote:
> > All entities receive peer transport information from elsewhere, including
> > gateways running ICE-Lite. Does it mean all of them need to perform
> consent?
>
> That's the logical conclusion, yes.
>

v2.23.0 | Report a Bug | By Email