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

Martin Thomson <martin.thomson@gmail.com> Fri, 22 May 2015 16:38 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 D5DBD1A1BA2; Fri, 22 May 2015 09:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no
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 wC817DihBiL0; Fri, 22 May 2015 09:38:07 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::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 417611A1B7C; Fri, 22 May 2015 09:38:07 -0700 (PDT)
Received: by yhom41 with SMTP id m41so5707077yho.1; Fri, 22 May 2015 09:38:06 -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=JhE1rpEpNlXY48/VcAYSch6QWFdLBa7LdZe8uvMBR+0=; b=WD0gg6WQT06M+NWlHT10QJGxp5UVm3rnpxS6SeFZuVY3pqfkZ1RLsnjpzD1v9ceLLF EpMCFCyGBzup8hlyC0K9N/zw2ZclP/ZerfbhHYadtUFOHGH2MVqkziaFwBucmCcNuSiw Z9qLTvVRVsPFmCc/y1U4V9OupewpWoWl+7qX9SInj69t5sqG5XNxOYXq833pYBWn6I4D R5YdRTpJC1iaojH74uqR8SeOnVs0GUK5HdH8bYkvZDInGAsClnH0IhMSu6wAG7aoJKyw xbNDBRTd6dQItEL3GvEitez4+P+HxHg9O+YgyFqg7svDODzeF92r8d0rsk0R8DXQ8un6 Bf2Q==
MIME-Version: 1.0
X-Received: by 10.170.204.15 with SMTP id v15mr177459yke.57.1432312686631; Fri, 22 May 2015 09:38:06 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 09:38:06 -0700 (PDT)
In-Reply-To: <CAOW+2dtDBxBBC7ToBGvP8cqYjGKUAYuR-5uL=NSjzE5iVwLRrA@mail.gmail.com>
References: <CAOW+2dsv8CVpaKoBsUvc5MGh2s3xD2J5NiXPAnFUMOhYqSmjzQ@mail.gmail.com> <CABkgnnWgpSYDjRQpk16Z0mCLietUcK1dSiNL-Y+jmFCpqan4Gg@mail.gmail.com> <CAOW+2dtDBxBBC7ToBGvP8cqYjGKUAYuR-5uL=NSjzE5iVwLRrA@mail.gmail.com>
Date: Fri, 22 May 2015 09:38:06 -0700
Message-ID: <CABkgnnUmcWUJDuems=P=vmifRGmhNvxv6=ps5O9-vmaQPYr=Ew@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/529AB6DH9-p2RDRDFp6kCDQscpk>
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 16:38:09 -0000

Tiru/Muthu, where the hell is the master copy of the draft?  This
requires a little care and I'd like to propose several pull requests.

On 21 May 2015 at 16:54, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> Martin said:
>> 1. Adaptation of the RTO via RTT measurement
>
> [Martin] 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.
>
> [BA] If you cite the RFC 5389 text relating to initial RTO, caching,
> estimation algorithm, etc. you can then use the calculated value to
> determine how long to await a STUN response.

That's reasonable.  I'll propose text as soon as I can lay my hands on
a copy of a draft.

>> 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.
>
> [BA] The effective transmission rate matters in DDOS more than running time
> - which is why the RFC 5389 backoff algorithm makes a difference.  Here an
> Rc value of 7 is not as critical as having it be a constant.

The draft requires at most one check every 4s for a pair and only when
consent is active.  ICE sends at 20ms intervals.  Open loop.  That
matters far more for DDOS.

>> 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).
>
> [BA] That is true if the transaction ID doesn't change (e.g. RFC 5389).  But
> if the transaction ID changes, then you can use the arrival time of response
> i to get a better RTO estimate, even if i+1 arrives first. This is valuable
> since it is most likely to happen when the originally calculated RTO value
> is too low, making a false retransmission timeout more likely.  RFC 5682
> describes some of the concerns relating to F-RTO.

Sure, but I don't think that we *need* that level of sophistication.
There's nothing stopping an implementation from doing smarter things,
but we are only looking to ensure that consent doesn't persist
indefinitely.

> [BA] Varying Rc will produce a false retransmission probability that will
> vary by network conditions, particularly if Rc can be small (e.g. only a few
> retransmissions prior to declaring consent revocation).

See above regarding unnecessary sophistication.

>> 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?
>
> [BA] If consent expires at 30 seconds + RTO (or better, at last request
> sending time plus RTO) then that would clarify things.

I can see where you are coming from here.  I think that we need a
different fix, if anything.

1. STUN requests are sent at a regular interval (with variance).
2. Each STUN request is tracked for RTO+delta.
3. If a successful STUN response has been received in the last 30
seconds, you have consent.

That is a subtle change, but it would allow for connections with an
RTO greater than 30 seconds.  The only actual problem I can detect
with the current formulation.

> I like that.  Note that "excessive traffic" was intended to be in
> time, not volume.
>
> [BA] Why would time matter if consent packets aren't being sent (e.g.
> backoff)?

Let me rephrase.  The mechanism in this draft prevents packets from
being sent to an unwilling recipient.  It does that by limiting the
*time* that this can happen.  It does nothing about the *volume*,
either in number of packets or number of bytes.  I agree that
"excessive" implies the latter (and hence think that your proposed
text in this regard was good.)

> 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:
>
> [BA] The question is when consent is acquired. I'd assume that this begins
> when media starts being sent - which according to RFC 5245 can occur after a
> successful connectivity check response.  So ICE isn't necessarily complete.

Right.  We can clarify that too.  If only I had a copy of the damned
draft, I'd propose some changes.

> ... is needed to obtain consent to send *on that candidate pair*.
>
> [BA] That part makes sense - but if there is another valid pair, it should
> be possible to start sending media on that pair without having to do an ICE
> restart.  That is allowed under RFC 5245.

Correct.  We can add that clarification too.