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

Martin Thomson <> Mon, 01 June 2015 22:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 09E3B1A1A7E; Mon, 1 Jun 2015 15:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K99Ushi9inAj; Mon, 1 Jun 2015 15:50:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 143CB1A19FE; Mon, 1 Jun 2015 15:50:49 -0700 (PDT)
Received: by yhom41 with SMTP id m41so37362626yho.1; Mon, 01 Jun 2015 15:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G8EXoLG4V7dbDE0Up15zfXSrXsewhxVU499cpZ5We3I=; b=BGP2MwfF1Ll0c6gfxZIQQ8/UX5CIwP/TSkuwmWDQeVEWWRIF1VAZSfT4+hALOLg25B /nKe34JJpyTMYvpZD+lPZ8NFepZEgPV5DVMYr/h8hdl46cGwMX6ObIKrXO6EXDzxrBtf 7zOoxIsrZYryJA85uL9+41mXXWttwOlbft5BWbbpV1rCp13wqxtMiXw5xjHv+WfcHdx2 KniDRLb4pZadNl6yXd3gk4Zz98urUMYoDN4Wj2SVbep+Sw45A3igiOMFxhZ0mbrou4cf hoDbX9gqnC9UksqrSwUvSCSONGj5RfYzBvA1//8g1qMwvkL1KkqXw6h0k3HA9u8A3llj Rlgg==
MIME-Version: 1.0
X-Received: by with SMTP id t29mr25264933yhb.69.1433199048423; Mon, 01 Jun 2015 15:50:48 -0700 (PDT)
Received: by with HTTP; Mon, 1 Jun 2015 15:50:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 01 Jun 2015 15:50:48 -0700
Message-ID: <>
From: Martin Thomson <>
To: Bernard Aboba <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>, The IESG <>
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jun 2015 22:50:51 -0000

On 1 June 2015 at 15:06, Bernard Aboba <> wrote:
> Comments on the PR:
> +pair when the pair enters Succeeded ICE state.  consent; this document
> +establishes a 30 second expiry time on consent.
> [BA] Is the text starting from "consent;" intended to be there? Looks like a
> cut/paste error.

The latter statement was intended to be there.

> [BA] If a response still has not been received, but the RTO timer has not
> expired, why should consent be revoked just because the 30 second timer
> elapsed? As an example, if a request is sent at 29.9 seconds, and the RTO
> timer is 2 seconds, why should consent be revoked only 100 ms after sending
> the request?? Also, this text does not appear consistent with the text
> below:

If you sent something 100ms ago, then it might be useful in the
future, but for now, your consent has expired.  Extending the window
to max(30, Tlast-request + RTO) is extending the window.  It's also
more complicated to implement.

I'm not sure how that would be inconsistent; the text below says that
consent expiry is independent of check interval.

If I were to implement this (as I once did), I would initiate a check
every 5s, awaiting a response for each separately.  If one of those
succeeded, I would update a "lastSuccessfulCheck" variable to the
current time.

Then when sending, I would check that "lastSuccessfulCheck" is more
recent than (now - 30s).  If so, explode.

Or you can run a 30s timer that you reset each time a check succeeds.
Explode if it ever actually runs to completion without being reset.

Neither of those needs to care about RTO.  The implementation of the
checking might (in practice, you can just wait.

> +An endpoint SHOULD await a binding response for each request it sends for a
> time
> +based on the estimated round-trip time (RTT) (see Section 7.2.1 of <xref
> +target="RFC5389"/>) with an allowance for variation in network delay.  The
> +value can be updated as described in <xref target="RFC5389"/>.  After this
> time
> +elapses, an endpoint can discard associated state and ignore any late
> responses.
> [BA] I do not understand why responses arriving after the RTO timer expires
> are completely ignored.  Post-RTO responses not only indicate that consent
> has been maintained, but also that the RTO needs to be revised upwards.  So
> I would consider deleting the last sentence.

OK.  Done.

> +All outstanding STUN consent transactions for a candidate pair MUST be
> discarded
> +when consent expires.
> [BA] This part does make sense.  But overall, the paragraph seems to
> indicate that consent expires at max(30, Tlast-request + RTO), not 30
> seconds.

I don't know how you get that.  It's certainly isn't the intent.