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

[Ari Keränen <[e-mail]>]

> On 25 Oct 2018, at 20.39, Benjamin Kaduk <[e-mail]> wrote:
> 
>> On Wed, Oct 24, 2018 at 06:35:44AM +0000, Ari Keränen wrote:
[...]
>>> 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
[... trimming cleared issues]
>>>  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.

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