Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 25 October 2018 17:39 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317BB130DFC; Thu, 25 Oct 2018 10:39:02 -0700 (PDT)
X-Quarantine-ID: <cDaZxVneIhwI>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 cDaZxVneIhwI; Thu, 25 Oct 2018 10:39:00 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934311277D2; Thu, 25 Oct 2018 10:38:59 -0700 (PDT)
X-AuditID: 12074424-17fff70000000321-7e-5bd1ffaf00ad
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E2.B7.00801.0BFF1DB5; Thu, 25 Oct 2018 13:38:57 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.14.7/8.9.2) with ESMTP id w9PHcopE022839; Thu, 25 Oct 2018 13:38:52 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9PHciGX028886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Oct 2018 13:38:47 -0400
Date: Thu, 25 Oct 2018 12:38:43 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ari =?iso-8859-1?Q?Ker=E4nen?= <ari.keranen@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-core-too-many-reqs@ietf.org" <draft-ietf-core-too-many-reqs@ietf.org>, Carsten Bormann <cabo@tzi.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
Message-ID: <20181025173843.GC45914@kduck.kaduk.org>
References: <154032461873.31236.9757655812218106074.idtracker@ietfa.amsl.com> <73D663A8-782F-4417-ABB4-E95C657FBE87@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <73D663A8-782F-4417-ABB4-E95C657FBE87@ericsson.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6norvx/8Vog1drZCyuXfvPZnFkyl1W i20bL7BZ7Hu7ntliQetWFosZfyYyO7B5/Pp6lc1jyZKfTB7TFmUGMEdx2aSk5mSWpRbp2yVw ZZxbs56tYKZ4xd8NvcwNjBeEuhg5OSQETCSW/H7B3sXIxSEksIZJ4uvxx2wQzkZGiV3PHrBA OHeZJCYde80M0sIioCqx/NNnFhCbTUBFoqH7MlCcg0NEwFbi9eE6kHpmgWYmiQdTToPVCwsk SFxtaWIDsXmB1v1YfpEJYmgzo8TJDY+YIBKCEidnPgEbyiygLvFn3iWwocwC0hLL/3FAhLUl li2EuIFTwEHi3t9GsHJRAWWJvX2H2CcwCs5CMmkWkkmzECbNQjJpASPLKkbZlNwq3dzEzJzi 1GTd4uTEvLzUIl1zvdzMEr3UlNJNjOBIcFHZwdjd432IUYCDUYmHd8K3i9FCrIllxZW5hxgl OZiURHkTU4BCfEn5KZUZicUZ8UWlOanFhxglOJiVRHj33gbK8aYkVlalFuXDpKQ5WJTEeSe2 LI4WEkhPLEnNTk0tSC2CycpwcChJ8Hb+A2oULEpNT61Iy8wpQUgzcXCCDOcBGn4RpIa3uCAx tzgzHSJ/ilFRSpz38l+ghABIIqM0D64XlKgksvfXvGIUB3pFmHcuSDsPMMnBdb8CGswENHiG wgWQwSWJCCmpBkamj1bLHp4uSr7Ac+TT1UmVglJZy/M8097ZSTKudGIQ6bt70qD796fpB4uX X+Ff6vv1StGcoEkh85MTt6qt2RBV3Mu06iWL1qq0l3xrOrU950849Fo11pX11dQYfk0DXXfV F6ENoTau8nfsFulONZnW+K/I49vc5csWd8Qn93zbXVZquV2E1UuJpTgj0VCLuag4EQC0mpC+ LwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/l8YMUK1BPdCYH62HgxzX3abj9XY>
Subject: Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 17:39:02 -0000

On Wed, Oct 24, 2018 at 06:35:44AM +0000, Ari Keränen wrote:
> Thank you for the review Ben!
> 
> I have addressed most of your comments in the IESG review PR:
> https://github.com/core-wg/too-many-reqs/pull/5/files

Thanks!

> See answers and one more discussion point inline.
> 
> > On 23 Oct 2018, at 22.57, Benjamin Kaduk <kaduk@mit.edu>; wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-core-too-many-reqs-05: No Objection
> [...]
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Section 3
> > 
> > It may be appropriate to explicitly reiterate that "The 4.29 response code is
> > only returned to the client(s) sending requests too frequently; if other
> > clients are sending requests that cannot be served due to server overload,
> > the 5.03 response code is more appropriate."
> 
> Good point. Added this text to the server behavior section.
> 
> >   If a client repeats a request that was answered with 4.29 before Max-
> >   Age time has passed, it is possible the client did not recognize the
> >   error code and the server MAY respond with a more generic error code
> >   (e.g., 5.03).
> > 
> > Isn't it also possible that the additional requests were already in flight
> > when the 4.29 was generated?  (It's unclear whether that needs to be
> > specifcially mentioned in the document.)
> 
> Yes. I clarified this now in the end of server behavior section.
> 
> > Section 5
> > 
> > As per the previous comment, a server that erroneously returns 4.29 to too
> > many (i.e., including well-behaving) clients would unnecessarily DoS the
> > well-behaved clients.
> 
> Are you referring to “many requests in flight” issue? For a client sending too many requests before receiving an answer a 4.29 seems like appropriate answer. Or which well-behaving client do you mean here?

I had in mind a rather more unlikely scenario.  The easiest to explain
version would be a server operator that misreads this document as "a new
response code 4.29 to replace 5.03 when requests are coming in too fast",
and sends 4.29 responses to *all* requests during an overload condition,
regardless of how frequently any individual client is sending requests. The
desired behavior is that 4.29 is restricted to just the clients that are
behaving poorly, and if the server sends 4.29 to a broader audience than
that, some well-behaved clients will be DoSed.  Looking back, I'm not sure
why I wrote "as per the previous comment", so my apologies for seeding
confusion.

-Benjamin

> > It may be appropriate to reference the RFC 7252 security considerations as
> > continuing to apply.
> 
> OK, I added a note in the beginning referring to RFC7252.
> 
> 
> Thanks,
> Ari