[dns-operations] "bad infosec economics " Re: <something paul wrote>

[Edward Lewis]

At 14:18 +0000 6/10/12, Paul Vixie wrote:

>thinking about or acting against ANY is bad infosec economics.

This I agree with.  Here are some of my knee-jerk, anti-filtering thoughts:

1 - DNS providers are paid to answer questions, not drop traffic.
2 - Rate limits that are not managed eventually become the reason why 
address blocks are contaminated.  Recall the 512 byte limit devices.
3 - Whenever I've considered limiting any pattern I think of a few 
other patterns that could be substituted in short order if its an APT.

I agree that rate limiting is an effective short-term, immediate 
reaction to events. But once you leave that time horizon they become 
liabilities - "permanent fixes to temporary solutions."

Another part of this discussion centered around determining the 
source of the offensive traffic.  Again, "bad infosec economics" 
comes here - while it is interesting to diagnose, rarely does the 
search for answers to this question lead to a permanent solution. 
We've collectively known about Dan Bernstein's use of t=ANY for a 
decade and we know he's reluctant to listen to calls for change nor 
make the change.  10+ years.  Nothing's changed - except the newest 
younger crowd learns about this old tale.

The suggestion to limit EDNS0 to "a smaller size" might be the first 
step to decent (but still suboptimal) improvement.  Guessing that the 
malicious data seeks two things - a large, valid and reputable chunk 
of data to throw at a victim and an reputable and capable address 
from which to throw it, perhaps at least limiting the data size in a 
way that does not cause choking to legitimate uses is a good thing.

I've said in presentations that the same fertile ground that lets DNS 
be the beast that it is also enables DDoS (rooted in the nature of 
UDP).  The fact that we are still talking DDoS prevention many years 
after we started is empirical evidence that DDoS is a hard problem to 
solve.  Rate limiting is one technique, not a cure-all.  If it was, 
we'd not be talking about it in 2012.  So, use it with caution.

PS - One possibility, instead of simply not responding, send back 
rcode=REFUSED.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!