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

Martin Thomson <> Thu, 21 May 2015 23:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6CC531A8A9D; Thu, 21 May 2015 16:10:22 -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 VZWX40O1fw8V; Thu, 21 May 2015 16:10:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F7561A001D; Thu, 21 May 2015 16:10:20 -0700 (PDT)
Received: by yked142 with SMTP id d142so702289yke.3; Thu, 21 May 2015 16:10:19 -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=RYvHsIh2hyFrjUsWrZ5C7P+tOKW0jCgiTaWdk0O0bkk=; b=vjG+RWNlYmoo+ZHOU3OCrIJDLNKN2u0WgeAhkioK3RMwN0+G5FYzsjjyhkYeBGGMN5 DXIRsvInJ3ulAXQsWMjAYD+o8Fbq0Mf2JJQLu2hJGKICwQS+8rGxFEDURZqUXYNM1o8Z 6AGTi0zh0O5TA6238hLuwD6gpVR+R7VcyKYEe1vtZ5i3Kq25cVvvIIGcBo59hVC6T7MP dMYs90vSdzA53gT0AvxNKqbJWcleLrVmtzMg9Bz5pEfBfm0OM+VSKvEyrLVaEd/h5tAm uKVRUD6JZGaNitzEdASOywfzSDMJIQW/9OnwpAoPZMbcuuWe3VinLAzDOF1Kp8sIRurb sT8Q==
MIME-Version: 1.0
X-Received: by with SMTP id t29mr4984511yhb.69.1432249819747; Thu, 21 May 2015 16:10:19 -0700 (PDT)
Received: by with HTTP; Thu, 21 May 2015 16:10:19 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 21 May 2015 16:10:19 -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: Thu, 21 May 2015 23:10:22 -0000

On 20 May 2015 at 16:48, Bernard Aboba <> wrote:
> This is a review of draft-ietf-rtcweb-stun-consent-freshness.
> 1. Adaptation of the RTO via RTT measurement

I agree that this is a concern, but we have a means of determining
RTO, so we just need to add text that says something like: The initial
STUN transaction produces a value for RTO on any given candidate pair.
That value is used in determining how long to await a STUN response,
it is updated as new STUN responses are received.

> 2. Consistent number of requests sent without a response (Rc) before
> transaction failure
> 3. Total time to transaction failure robust against routing transients

I don't agree that either of these is a problem.  It's a design,
certainly, but it suffers from a dire lack of determinism in running
time, something that might be exploited to increase denial of service
exposure time.

> 1. No RTT/RTO estimation - and given that responses to a request that arrive
> after a new request is sent are ignored, no ability to make use of the
> information that is available. Effectively, the specification sets the RTO
> to be a random value between 4 and 6 seconds, with no relationship to
> network characteristics.

If response i arrives after i+1, that's not going to provide any
useful information about RTO itself (RTO jitter perhaps).  Note that
the original STUN design doesn't even allow you to detect this sort of
reordering, since the transaction ID is reused, so that's strictly

> 2. Inconsistent number of requests before failure.  Given the randomization,
> 4 to 6 requests might be sent within the 30 seconds.

That doesn't bother me.

> 3. Unclear timer behavior.  Does an implementation continue to send requests
> until 30 seconds has elapsed, or does it stop before then so as to allow for
> a response to the last request to arrive?  One could interpret the above to
> imply that requests continue to be sent for up to 30 seconds, but the last
> request is considered failed as soon as the 30 second timer expires.

How can we make this clearer?

It says:

   Consent expires after 30 seconds.


   [...] a STUN binding request can be sent
   periodically [at] a default interval of 5 seconds, [...]

Those are independent.  If you are under the impression that these are
somehow coupled, we can add "This timer is independent of the consent
expiry timeout."

> My suggested rewording is as follows:
> "To prevent browsers supporting WebRTC from being used to launch denial of
> service attacks by sending media to unsuspecting victims, periodic consent
> needs to be obtained from remote endpoints."

I like that.  Note that "excessive traffic" was intended to be in
time, not volume.

> Section 4.1
> An endpoint MUST NOT send data other than paced STUN connectivity checks or
> responses toward any transport address  unless the receiving endpoint
> consents to receive data. That is, no application data (e.g., RTP or DTLS)
> can be  sent until consent is obtained. After a successful ICE connectivity
> check on a particular transport address, consent MUST be maintained
> following the procedure described in this document.
> [BA] The last sentence seems to imply that consent checks are scheduled
> before ICE completes, and would therefore interact with the scheduling and
> pacing mechanism specified in RFC 5245.  This does make some sense, since in
> Trickle ICE, trickling all the candidates might take a while, and media
> might be sent after a successful response, so that consent would be in
> order.  However, if that is the intent, then it needs to be explicitly
> stated, and this document
> needs to contain an Updates: RFC 5245 header.

That's easy, let's just say that this process applies *after* consent
has been acquired.  maybe we could move this up to Section 4:

   Initial consent to send traffic is obtained using ICE.  Consent
   expires after 30 seconds.  An endpoint maintains consent as
described in Section 4.2.

The second sentence can stay where it is to provide context.
Repetition of that point is harmless.

> Each STUN binding request for consent MUST use a new cryptographically
> strong [RFC4086] STUN transaction ID.
> [BA] I think that RFC 5389 Section 6 says what is in intended here in a more
> precise way, so it should be referenced instead:
>    As such, the transaction ID MUST be uniformly
>    and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
>    cryptographically random.

WFM.  We can cite that instead.

> 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] The second sentence does not follow from the first. RFC 5245 enables
> sending of media once a successful ICE connectivity check has been received.
> If multiple successful candidate pairs have been identified, why should
> failure of consent on one candidate pair require an ICE restart if another
> operational candidate pair exists?

... is needed to obtain consent to send *on that candidate pair*.

There was a long discussion about this point, the conclusion of which
was "use it or lose it".  This captures that conclusion.  I can't
remember the details of the discussion, but I think that it wasn't a
security concern but a robustness one.

> Also, it is not clear what "any reason" means -

We can drop those words.