[ratelimits] Referrals incorrectly limited.

[john]

On 1/9/13 4:21 PM, Vernon Schryver wrote:
>> 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
>> nxdomains-per-second?
> 
> 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.
Understood

>>> <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.
The point is more that enabling the patch will block legitimate traffic.
 Rate limiting is always a balance between blocking unwanted traffic
while minimising false positives.  By limiting referrals we are blocking
more legitimate traffic then illegitimate.  This assumes a liberal
definition of legitimate, making an assumption that traffic is
legitimate until proven otherwise.

>> 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
> limiting.
For similar reasons to why we would like to change the behaviour of
referrals, too many false positives.  however we are just testing at the
moment.  it is unlikely we would have it disabled completely in a
production environment; however it would likely have a higher value then
responses-per-second.  this would also be true for the referral limiting
we would be unlikely to disable it but it would have higher values.



>> 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?
I haven't investigated what traffic extensively.  It is mostly people
scanning, walking domains.  To what end im not sure.

 >> The sample traffic was from a university research project trying to do
>> something similar to the old ripe ncc hostcount project[1].  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.
This is an point i could raise internally, thanks

> 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.
I think even if they did this they would still hit the ratelimiting as a
large amount of the addresses space we are authoritative for has not
been delegated.  Therefore the user would get many referrals for our
ns-set.  admittedly this is a gut feeling, i have not look at the actual
probabilities.


>> 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?
No but if we see users consuming a lot of resources we would try and
contact them and see if we can agree on a better solution.

> 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
> from Europe.
RIPE NCC as an organisation tries to remain impartial, therefore the
biggest problem is defining what is evil.  Then making a choice as to
whether we can take measures as the technical operate or if the change
we are considering effects the service our community expects and more
importantly is this or should it be covered by policy.

We want to stop reflection attacks this is most definitely something we
could do as the technical operator.  Im not so sure about blocking
legitimate traffic, regardless of if you or i consider the traffic to be
evil or ill thought.

> 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.  
I think we agree on this point.

> 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.
This is where we are a little bit more liberal.  Ill discuss internally
to see what peoples feelings are on being more aggressive.

Thanks for your considered response

Regards
John