[ratelimits] RRL vs other approaches
dmiller at tiggee.com
Tue Feb 19 15:50:28 UTC 2013
On 2/19/2013 10:02 AM, Paul Vixie wrote:
> Jared Mauch wrote:
>> On Feb 19, 2013, at 8:48 AM, Edward Lewis wrote:
>> Sending back TC to "authenticate" clients would likely help reduce the abuse of 'udp any'
> no. really. not. the subsequent udp queries you would prospectively
> receive following a successful tcp session in the above scenario need
> not be truly sourced. using a successful tcp session as a gate to a
> lightweight udp session is entirely wrong in terms of protecting
> spoofed-source victims from your orbiting death ray projector. (i'm
> touchy about this since i had the same idea and vernon had to straighten
> me out on the subject.)
Agreed, if you are only "authenticating" source IP. If TC->TCP was
"authenticating" other characteristics as well I would hope for better
results. Some characteristics that could be used, off the top of my
head, would be TTL, DO bit, EDNS/bufsize.
>> I was "forced" to rebuild my dns server in the past week or so.. I have not built-in the rrl patch yet as part of the running server and have noticed that the CPU usage is significantly lower. (Instead of "150%" it's about 50% of a core).
>> Right now I'm debating if it makes sense to continue to patch w/ rrl due to the much higher "cost" (2-3x)
> as warren said, this sounds like pilot error or measurement failure.
> your cpu costs under RRL should be far lower during an attack since
> you're avoiding the response marshalling cost, and should be about the
> same during non-attack since the hash table is preallocated and the
> hashing is pretty quick. please investigate your claim above, and report
> ratelimits mailing list
> ratelimits at lists.redbarn.org
More information about the ratelimits