IETF Logo Mail Archive

Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

Martin Thomson <martin.thomson@gmail.com> Fri, 22 May 2015 17: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 7E41B1A8729; Fri, 22 May 2015 10:54:39 -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 Fhhear-Vcv2z; Fri, 22 May 2015 10:54:38 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (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 2E3521A8774; Fri, 22 May 2015 10:54:38 -0700 (PDT)
Received: by yked142 with SMTP id d142so8240612yke.3; Fri, 22 May 2015 10:54:37 -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=5qtaVJiooh8i7vdYXmlXMK+5fEiAvM5vffqJnrsvCkA=; b=SMgO12wXScgVO//j+Tn54vUV0zICbuMzGLISp2F8bsSPNumuZt2Tu0L6DOaDu5Yp70 3pmwe+Pri7/fA8bvaMfp+nk0sUuXnpgn5k8YB43c1k+fB26SzaVX0AvOHQSs4agRynpA D73xbxMphpuMkuYunJ8UmdyooW91GPv3RV6pSXE5rRSFZ8Ty+/aJXjd3Fi4kalc4w4ig 5xqPkdNjLpwXScQ6mrc/2PG27Y01UM5vSTnLr4oS6461t5/eBPqrwpuCoyhBbba5zAnY 0x37OqWl8UVHAOhH7NyRsLlt/0R5GQ4vg3sWZrj7M6U66Q9Fi8qY3xdPFkIUVv3jatST x7DA==
MIME-Version: 1.0
X-Received: by 10.170.112.18 with SMTP id e18mr5912713ykb.101.1432317277558; Fri, 22 May 2015 10:54:37 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 10:54:37 -0700 (PDT)
In-Reply-To: <CAOW+2dt8GgcuREevwwo-PU=xzmm0MNgbyR7776bL9q9R1pa6yA@mail.gmail.com>
References: <CAOW+2dsv8CVpaKoBsUvc5MGh2s3xD2J5NiXPAnFUMOhYqSmjzQ@mail.gmail.com> <CABkgnnWgpSYDjRQpk16Z0mCLietUcK1dSiNL-Y+jmFCpqan4Gg@mail.gmail.com> <CAOW+2dtDBxBBC7ToBGvP8cqYjGKUAYuR-5uL=NSjzE5iVwLRrA@mail.gmail.com> <CABkgnnUmcWUJDuems=P=vmifRGmhNvxv6=ps5O9-vmaQPYr=Ew@mail.gmail.com> <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> <CAOW+2dt8GgcuREevwwo-PU=xzmm0MNgbyR7776bL9q9R1pa6yA@mail.gmail.com>
Date: Fri, 22 May 2015 10:54:37 -0700
Message-ID: <CABkgnnUzdBO5+YoFgWrkfD+O6++C3jNDHmD7TVeUdRAy=EuTKg@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/usmyFlurs_FXtjpdEA4XcSOx_mI>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [rtcweb] Review of 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 May 2015 17:54:39 -0000

On 22 May 2015 at 10:40, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> [BA] If a STUN request is still being tracked (RTO has not yet expired),
> would expiration of the 30 second timer still cause consent to expire?  Or
> would revocation wait until the RTO timer expires?  The latter makes more
> sense to me.

I think the former is better since it makes the consent window more
deterministic.  The only consequence there is that an increase in RTO
over the course of that 30s interval will increase the probability of
failure.

If we assume that a client sends every 5s, it should be receiving at
5s intervals too.

v2.27.8 | Report a Bug | By Email | System Status