RE: draft-asveren-dispatch-http-overload

Martin,

Thanks for the feedback/questions.

i- Why Retry-After is inadequate
Not that I am lazy but I think https://tools.ietf.org/html/rfc5390 (5.3.  The Off/On Retry-After Problem is probably the most relevant part for your question) already explains this better than I could do. It is for SIP but the same arguments would apply for any real-time application where response times matter.

BTW, the issues listed in RFC5390 and the mechanism defined in RFC7339 to deal with it are tested/observed/verified by a group consisting of multiple vendors while preparing these specifications.

ii- The goal of this mechanism is not to provide a solution against malicious attacks. It is meant to be used between well-behaving entities. Nonetheless I don’t think it makes DoS more likely nor does it leak information which significantly can increase efficiency of DoS. It is true that it conveys information about load status of a server but I think this can be deducted by an attacker anyhow (at least to some reasonable extent) by sending requests and checking the response times. So, a server should do whatever it does today when it suspects DoS activity. No changes are defined/assumed on that front.

iii- “The table” is specific for the application type. It has multiple values as most -if not all- real-time applications have the notion of regular/priority/emergency request types. The drop percentage for each could be different depending on server and current overload conditions.

Thanks,
Tolga

From: Martin Thomson <martin.thomson@gmail.com>
Sent: Monday, April 30, 2018 1:55 AM
To: Asveren, Tolga <tasveren@rbbn.com>
Cc: ietf-http-wg@w3.org
Subject: Re: draft-asveren-dispatch-http-overload

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

This is the right working group, for sure. However, I don't find the
introduction convincing. Maybe I'm missing something. How is
Retry-After inadequate?

As for the mechanism described, how does it not expose information
about the server configuration such that DOS could be more precisely
targetted? What is the scope of the table? What is the point of
multiple values?


On Mon, Apr 30, 2018 at 3:50 AM, Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>> wrote:
> I submitted draft-asveren-dispatch-http-overload-control to DISPATCH WG a
> while ago. It aims to specify a generic overload control mechanism for
> HTTP/HTTPS applications.
>
>
>
> https://www.ietf.org/id/draft-asveren-dispatch-http-overload-control-00.txt

>
>
>
>
>
> I thought it could be a good idea to herald it here as well as some folks
> may not be following DISPATCH WG.
>
>
>
> I would appreciate any feedback about overall idea/need/alternatives/in
> general.
>
>
>
> Thanks,
>
> Tolga
>
>