[ratelimits] can't make qps-scale change effective slip

[Vernon Schryver]

> From: Irwin Tillman <irwin at princeton.edu>

>    rate-limit {
>        responses-per-second 10;
>        qps-scale 60;
>    };
>
> I expected the result would be that the ongoing 7200 queries/second attack
> would cause effective slip = (60/7200)*2 = 0.016.
>
> So I expected the server would send approximately 7200 * 0.016 = 120
> "truncated" responses/second to this queryer.
> Instead the server continued to send approximately 3600 "truncated"
> responses/second to the queryer.

> I don't seem to be able to get qps-scale to change effective slip,
> or I'm misunderstanding qps-scale.

This is the text from http://ss.vix.su/~vjs/rl-arm.html about qps-scale:

   When the approximate query per second rate exceeds the QPS-SCALE
   value, the RESPONSES-PER-SECOND, ERRORS-PER-SECOND, NXDOMAINS-PER-SECOND,
   and SLIP values are reduced by the ratio of the current rate to the
   qps-scale value. This feature can tighten defenses during attacks.
   For example, with QPS-SCALE 250; RESPONSES-PER-SECOND 20; and a
   total query rate of 1000 queries/second for all queries from all
   DNS clients including via TCP, then the effective responses/second
   limit changes to (250/1000)*20 or 5. The limits for IP addresses
   using TCP are not reduced. Responses sent via TCP are not subject
   to rate limits but are counted to approximate the query per second rate.

That text probably should say nothing about "SLIP values", because the
slip threshold is not directly affected by the overall qps rate.  The
other thresholds are affected.  During the attack the responses-per-second
was (I hope) changed to (60/7200)*20, which is 1 response/second after
clamping to sanity.
Because practically all of the traffic was due to the attack and
the traffic was already above the responses-per-second threshold,
the outputs did not change.  Responses were still alternately dropped
and truncated.

Qps-scale is a dubious feature that exists only to address what I
(mis?)understood as a request that had to be addressed.  It is
supposed to both tighten defenses during an attack and somewhat
whitelist TCP clients.  The next item on my RRL/RPZ to-do list is
to think about those goals with an eye toward changing qps-scale.

Perhaps it would make more sense and you wanted the slip rate to
increase by the ratio, perhaps changing to (1/(60/7200))*2=240.964.
That would result in 240 dropped responses, 1 truncated response, 240
dropped, 1 truncated response, and so on.

Simultaneously increasing slip and decreasing responses-second by
the ratio would result in the about the same number of output
packets/second during the attack.  Perhaps slip should be increased
by the square of the ratio.  I don't know.

What do you think qps-scale should do?


thanks,
Vernon Schryver    vjs at rhyolite.com