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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 12:56:58 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-too-many-reqs-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/

----------------------------------------------------------------------
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."

   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.)

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.

It may be appropriate to reference the RFC 7252 security considerations as
continuing to apply.

---

From: Ari Keränen <[email-masked]>
Date: Wed, 24 Oct 2018 06:35:44 +0000

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

See answers and one more discussion point inline.

> On 23 Oct 2018, at 22.57, Benjamin Kaduk <[email-masked]> wrote:
> 
[...]

Good point. Added this text to the server behavior section.

> specifcially mentioned in the document.)

Yes. I clarified this now in the end of server behavior section.

> many (i.e., including well-behaving) clients would unnecessarily DoS the

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?

> It may be appropriate to reference the RFC 7252 security considerations as

OK, I added a note in the beginning referring to RFC7252.

Thanks,
Ari

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Oct 2018 12:38:43 -0500

> https://github.com/core-wg/too-many-reqs/pull/5/files

Thanks!

> 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 me…

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

---

From: Ari Keränen <[email-masked]>
Date: Thu, 1 Nov 2018 00:50:11 +0000

> On 25 Oct 2018, at 20.39, Benjamin Kaduk <[email-masked]> wrote:
> 
[...]
>>> draft-ietf-core-too-many-reqs-05: No Objection
[... trimming cleared issues]
> why I wrote "as per the previous comment", so my apologies for seeding

Thank you for the clarification! I don’t think that’s actually a big problem since both 5.03 and 4.29 have the same semantics for the back-off period. 5.03 is basically just more generic and gives client less information on what it could actually do. Also there’s not much we can do in general if implementation chooses to use inappropriate response codes.

Cheers,
Ari