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.
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Ted Hardie
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Ram Mohan R (rmohanr)
- [rtcweb] Review of draft-ietf-rtcweb-stun-consent… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Emil Ivov
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Bernard Aboba
- Re: [rtcweb] Review of draft-ietf-rtcweb-stun-con… Martin Thomson