[ratelimits] Referrals incorrectly limited.
vjs at rhyolite.com
Wed Jan 9 15:21:39 UTC 2013
> From: john <jbond at ripe.net>
> > That rate limiting applies to referrals is an intended feature.
> Would it be possible to tune this with an option similar to
Anything that can be described can be coded, but every additional
feature, parameter, etc. has costs. Add too many and the system
becomes uselessly slow and unmaintainable junk. Without a compelling
use case, I would oppose separate counters and parameters for referrals.
In this case, the authorities for the /24s in that /16 might thank you
for rate limiting those referrals. Unless there are many undefined
reverse names in their /24s to trigger NXDOMAIN RRL, they are probably
hammered by those students.
> > <random>.170.170.91.in-addr.arpa ns" are good for reflection attacks
> > with an amplification of about 6.5X. That is as not big as other
> We are aware we would still have some amplifications. however we are
> not seeing attacks that match this pattern at the moment.
I do not understand "not under that attack at the moment" reasoning.
> Also a bad
> guy would have much better results querying for nxdomains as the
> amplification their is closer to 13X.
I saw and also do not understand turning off NXDOMAIN response rate
> Currently we get a lot of traffic which is not DOS traffic being blocked
> by this feature
Please note that RRL almost never *blocks* legitimate DNS traffic.
It only slows it down. It it is legitimate, then the DNS client
will try again and get an answer.
Could you describe some other legitimate traffic that is either
blocked or slowed by rate limiting referrals?
> > What is a legitimate reason for more than 25 referrals per second
> > (from your "responses-per-second 25") from a single DNS client
> > for reverse DNS lookups in 184.108.40.206/16?
> The sample traffic was from a university research project trying to do
> something similar to the old ripe ncc hostcount project. This meant
> they where walking the full in-addr.arpa tree.
They are doing it in an evil way and should be treated like any
other apparent network abuser, such as the ever popular university
projects based on surveys sent in unsolicited bulk email or spam.
It's not only that "evil is as evil does," but if they are not smart
enough to do probe in-addr.arpa wisely, then they are unlikely to
be smart enough to get useful results from their project.
The obvious, easy, and non-abusive way to walk the in-addr.arpa tree
or any other DNS tree is psuedo-randomly and/or with delays so that
they do not hit any DNS server frequently. If they are walking only
that /16 tree, then delaying 0.1 seconds between each request would
completely walk the /16 tree in 18 hours. If they are walking all of
in-addr.arpa, then they could use a linear contruential random number
generator to cover all 4 billion IPv4 addresses as fast as possible
without hitting any authority too often.
> In this case the traffic was genuine although i'm sure we get a lot of
> traffic that some may consider abusive. Unfortunately that is not the
> problem we are trying to deal with now. When the rate limit was enabled
> with a responses-per-second of 10 we where limiting roughly one prefix
> per second matching this traffic signature i.e. referrals.
> The time involved investigating each one of these to understand if it is
> genuine or abusive would be significant.
Why investicate each one and every? Most DNS clients that are not
abusive will automatically rate limit themselves below RRL limits
with delays between retransmissions and by switching to TCP.
> For now we want to stop the reflection traffic we are seeing and
> minimise the false positives. As our goal is DOS mitigation a false
> positive is any traffic which does not look like a reflection attack.
Do you plan to contact every source of traffic that is rate limited?
How can that project ever end? As with other problems, there will
always be new people inventing new reasons and re-inventing old reasons
for doing doubtful things, like university survey spam.
Second, how do you defend against social engineering? If I were walking
the in-addr.arpa tree for evil, and you called me to see if rate
limiting my DNS responses were false positives, I would have a nice
story. If my chosen story involved academic research, I'd give you
telephone numbers of supposed academic advisors and department chairs.
I doubt you'd be able with limited time and money to penetrate my smoke
I do not intended to suggest that this particular case is anything
other than what you say. I know nothing about it, except that since
I first got the RRL code working about one year ago, I've been limiting
some of the same continual probers hammering on 61.188.192.IN-ADDR.ARPA.
My point is that it is impossible for anyone to know about all
potential cases. Once one is willing to say "I don't and can never
know," many things become easier and better. Abuse handing can
operate based on "evil is as evil does." Secondary goals including
justice, equity, and transparency are improved when the watchers
admit the limits of their knowlege.
Vernon Schryver vjs at rhyolite.com
More information about the ratelimits