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

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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