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

[Bob Harold]

It would make sense to me to optionally be able to set the maximum slip
rate in terms of slips per second, or seconds per slip, since that is what
you would end up with.  That would be easier than working through
calculations to decide what rate I would get.

On a related note, can I set responses per second to less than 1 per
second?   I see an ongoing attacker sending one packet every 3 seconds (for
isc.org any), and given enough open resolvers, they could be conducting an
attack under the radar.

I am preparing to deploy rrl in logging only mode tomorrow to gather data
before I go live with it.

-- 
Bob Harold
University of Michigan
rharolde at umich.edu


Date: Sun, 6 Jan 2013 20:19:03 GMT
> From: Vernon Schryver <vjs at rhyolite.com>
> To: ratelimits at lists.redbarn.org
> Subject: Re: [ratelimits] can't make qps-scale change effective slip
> Message-ID: <201301062019.r06KJ3Ua038991 at calcite.rhyolite.com>
>
> > 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
>
>
> ------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130107/b59cc439/attachment.htm>