On 6/28/2012 7:50 PM, Michael Graff wrote: >>> "BCP 38" Enough said. >> what does that mean? > It means that time and time again, either sufficient mass must implement a > feature like this, or it is effectively pointless. It also means that the > pain of installing such a security feature is on the side that does not feel > the pain.
none of that is true. first, because every server who refuses to participate reduces the attack surface. we do not argue that "i should not bother to deploy BCP 38 here because until everyone does it, there is no point." nor do we are thusly about open SMTP relays, or carbon emission limits, voting in political elections, or pollution. every little bit DOES help. each of us should do what little we can do. second, because reflective amplifiers feel considerable pain. the 20X+ larger responses cost money to transmit, and use link and path headroom. the phone also rings when victims call in to say "please stop answering queries i am not sending you." so while i agree with you that BCP 38's incentives are misaligned, that is demonstrably not the case in DNS RRL. > But, unlike BCP38 which would make a difference if enough ISPs implemented > it, this is another form of an arms race against a well armed opponent. sometimes the best you can do is require your opponent to become better armed, and continue the game to the next round. consider four approaches to this problem: 1. implement per-source-ip rate limits (like f-root and many other authority servers do.) 2. implement per-pattern filters (like EDNS bufsize==9000 filters as some are doing now.) 3. implement DNS RRL, which rate limits based on source-ip *and* prospective response. 4. do nothing for now until a better idea comes to us. i believe that #3 is the right next step, since the ease of bypass for #1 and #2 is too trivial, and since #4 is inevitable anyway. do you have an argument to make in favour of #4? > That said, the "slip" factor is clever, but I still worry about translating > what would be a UDP timeout into a TCP query in addition to a filter that > takes only 5 sequential packets to activate. i'm a tcp/53 hater of some long standing. i resisted TC=1 for this until nothing else proved out. at this point i'm thinking that if the repeated queries are somehow coming from a real resolver, that TC=1 no more than every other request should get them an answer that they can cache which would then shut them up. and if the repeated queries are coming from a spoofer, then these will at least be small (non-amplifying) and infrequent (not sent in response to every request) packet-bombs. and if there's a mix of both real and spoofed traffic, then the fact that real resolvers both retry and cache, means that SLIP reduces the attack surface. (here i'm thinking of kaminsky attacks.) i apologize to anyone here who believes that there is a silver bullet to be had. DNS RRL is a tradeoff, useful for risk management. if your risk of processing and transmitting large flows toward victims who are not sending you packets, is greater than your risk of dropping responses toward legitimate resolvers during times they are being attacked, then you should probably sign your zones with DNSSEC and restart your thought process. but in any case DNS RRL is not a silver bullet. there is no silver bullet. paul _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
