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 16:54 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 A4E891A9138 for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 09:54:44 -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 JjeCZ_8yhfdY for <rtcweb@ietfa.amsl.com>; Fri, 1 May 2015 09:54:43 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (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 6FAD01A6FCF for <rtcweb@ietf.org>; Fri, 1 May 2015 09:54:43 -0700 (PDT)
Received: by yhcb70 with SMTP id b70so18852152yhc.0 for <rtcweb@ietf.org>; Fri, 01 May 2015 09:54:42 -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=XFZ5JtdckkHAJl5DJ5JP2JvTDUgZ9hmmISHKFRqSZa0=; b=WvEAqUEZXfRorXW0vNZ0viadeNhRYrRP2V32pEmtWO5K1SLmkZinxZ6eDKniK2uoEx OGmq75DZ/Utr8atDuxyC315w1Fzat2qkA3c2ObX/UDm2M765LL4oCPJSp3gjRZAx/Rgr nBd7ESqP9FtUrlgjwb5r8SzOoil5deAIIx/Oev3QCNJkL8RB4SKRyZUVkluUgGMODRoE JdqCQ1kwyv2w/xjT04XdpC0rFFF7qf46A4xI+OqVskmZy1ihcZB0Ipyt+UJ6hDWwm9kE f5T81UwXcf8opz0fWy1FJQTYw5+bGtv3d3q08gYWKFvL5nkr1j4CL1EUQ1fD1x1/S1kL YLfQ==
MIME-Version: 1.0
X-Received: by 10.170.166.3 with SMTP id i3mr9176514ykd.104.1430499282808; Fri, 01 May 2015 09:54:42 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Fri, 1 May 2015 09:54:42 -0700 (PDT)
In-Reply-To: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in>
References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in>
Date: Fri, 01 May 2015 09:54:42 -0700
Message-ID: <CABkgnnU=NeP7MzqxE1Mg+ZN8EZf=3FtayyLP1Q-z=6vaPUtAuA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/c07QWNUrLEQCK3qdbGPwl_tZtxU>
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 16:54:44 -0000

On 30 April 2015 at 17:32, Alissa Cooper <alissa@cooperw.in> wrote:
> "An endpoint that is not sending any application data does not need to
>    maintain consent.  However, failure to send could cause any NAT or
>    firewall mappings for the flow to expire.  Furthermore, having one
>    peer unable to send is detrimental to many protocols."
>
> It sounds like the unstated implication here is that if you are such an endpoint, you should keep doing consent checks anyway to maintain consent. Should that be stated explicitly, or am I misunderstanding?

Can you tell that this is my text?

Yep, the unspoken implication is that if you stop maintaining consent,
a flow is highly likely to break.  I'm OK with making that explicit.

... .  Absent better information about the network, an endpoint SHOULD
maintain consent if there is any possibility that a flow might be
needed again.

(Thanks for the suggestion on Sec7.  I wasn't happy with it before.)

v2.23.0 | Report a Bug | By Email