How about making the limit optional, and calling it 'advice'? That is,
"capabilities":{"query-limit-advice": 1000}
means the server will probably accept requests if n(src)*n(dest) < 1000, and
will probably reject queries for more cost-points -- but there are no
guarantees.
BTW, speaking as a server implementor, it would be difficult to dynamically
determine a limit based on the current load. Instead, I'd just define a
static limit (a configuration parameter, of course), and enforce that limit
regardless of the current conditions.
- Wendy Roome
> From: "Y. Richard Yang" <y...@cs.yale.edu>
> Date: Tue, March 19, 2013 16:48
> To: Wendy Roome <w.ro...@alcatel-lucent.com>
> Cc: <alto@ietf.org>
> Subject: Re: [alto] Security problem: DoS attacks via overload
>
>
>> 2) For filtered cost map requests, add an optional IRD capability giving the
>> server's limit on the number of source/destination pairs allowed per request.
>> 3) Add a "Request Too Large" ALTO error code in case a client exceeds that
>> limit.
>
> I feel that the limit can be load/server capacity dependent. Adding the limit
> may be a too large a change at this moment. I do like the idea of adding a
> Request Too Large error code, and hence a client can learn (through binary
> search or an future error code indicating suggested size). What do you think?
>
> Richard
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
