IETF Logo Mail Archive

Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

Martin Thomson <martin.thomson@gmail.com> Fri, 01 May 2015 20:06 UTC

Return-Path: <martin.thomson@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 648901A8AD0 for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 13:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 Qsp4uKZsmeUT for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 13:06:19 -0700 (PDT)
Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E521A8AB5 for <rtcweb@ietf.org>; Fri, 1 May 2015 13:06:18 -0700 (PDT)
Received: by ykft189 with SMTP id t189so20517934ykf.1 for <rtcweb@ietf.org>; Fri, 01 May 2015 13:06:18 -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=JitWIvETsZbI2u7CnrE5CWO+gCOLFmXn/XLiQWbEkwU=; b=Ge9bHz/ri6NkN2CwfJb/72XrLYTX1DqXdtJEzrCA9Cpwzo7v81U0iCM8WRHabTQL9D hR/TKVAXPL9FVl2hxv1YCbVd02mslyx+UJTDqUCN7zUesKDdDTTaTw8fJMPPzNYOsx9Q O0RqRO+/KmauX/HBqDNmm0kgm+j4z3krX90ifxpF/7JZIg5uRGOYS1ogOS64rOHJe95D AbwK154NSvsC8ppmBMF8MBykpP8HmNiEotojTgQFv6YL+lXqrZHtpYNs5YPl6HShmDGW AQBIiqmPeTHL/gL2Quf5Mmjuii+yh8nlyFF6hpx7Gk4AI3ziFz/nUnkTTkHDNIkVJsiN FloQ==
MIME-Version: 1.0
X-Received: by 10.236.106.74 with SMTP id l50mr5659658yhg.143.1430510778226; Fri, 01 May 2015 13:06:18 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Fri, 1 May 2015 13:06:18 -0700 (PDT)
In-Reply-To: <CAOW+2dsk-3W8rgx9OfRcT+mEDd0W7H8ssUyUukUdfU1oGDfBhQ@mail.gmail.com>
References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <CAOW+2dsk-3W8rgx9OfRcT+mEDd0W7H8ssUyUukUdfU1oGDfBhQ@mail.gmail.com>
Date: Fri, 01 May 2015 13:06:18 -0700
Message-ID: <CABkgnnUOpjB1P-GdxPDRUS34U6=GOWMaF2eU-xiZcWL5mVhRsQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/X35UHVNGT2Oy8FOlvYWKKnHRn_w>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11
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, 01 May 2015 20:06:20 -0000

On 1 May 2015 at 11:44, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>    After consent is lost for any reason, the same ICE credentials MUST
>    NOT be used on the affected 5-tuple again.  That means that a new
>    session, or an ICE restart, is needed to obtain consent to send.
>
> [BA] I am curious about the reasons behind this text.  Is there a security
> vulnerability that this addresses?  From a transport point of view, 30
> second outages are quite possible on the Internet due to routing transients
> and so will introduce some brittleness, effectively requiring an ICE restart
> (with attendant re-gathering).  As a counter-example, congestion controlled
> protocols such as TCP do not give up this quickly.  So I'm wondering if this
> is taking on a function better handled in circuit breakers/congestion
> control specifications.

There was a long discussion on this point and this only documents the
conclusion.  My recollection is that the concern is a robustness one,
not a security one.

See the thread here:
https://mailarchive.ietf.org/arch/msg/rtcweb/O1Hk9vFmfj4VnKLxyrBw029Hw4M

Sorry about the length, we're short on brevity, it seems.

v2.23.0 | Report a Bug | By Email