Re: [dns-operations] responding to spoofed ANY queries
I would be in favour of either a compiler directive or configuration option to disable support for ANY queries. I'd save the time used in editing the code myself Peter Davies On Thu, Jan 17, 2013 at 5:39 AM, Vernon Schryver v...@rhyolite.com wrote: From: Frank Bulk frnk...@iname.com Perhaps the ratio could be a dynamic whitelist -- if it's 1.5 or less, then allow the response to go out. What would be gained by spending the code complexity and CPU cycles such a mechanism would require? What bad things would be avoided or good things achieved? (Please do not mention false positives, because that notion of false positive is irrelevant and does not happen with RRL.) Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Perhaps the ratio could be a dynamic whitelist -- if it's 1.5 or less, then allow the response to go out. Frank -Original Message- From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of Vernon Schryver Sent: Sunday, January 13, 2013 4:52 PM To: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] responding to spoofed ANY queries From: Jim Reid j...@rfc1035.com I suppose a name server could keep a (small?) cache of recently marshalled answers and use that to either rate limit responses which are too large or identical to one that has recently been sent to the same IP address(es). [For some definition of large and recent.] A problem with that thought is what I tried to state before, that there is no definition of large that is small enough to permit an exemption from rate limiting but not so small that it keeps mininimal DNS responses rate limited. For example, seems that random.rfc1035.com to your 93.186.33.42 is good for a 2X amplified stream of NXDMOAINS. 2X is small but too high for DoS victims to tolerate. I trust you will eventually turn on DNSSEC, which will probably boost your amplification of random requests well above 5X. It could be good to have something which rate limits outgoing responses in addition to what's done with incoming queries. Please recall that RRL stands for *response* rate limiting and neither *query* rate limiting nor *client* rate limiting. The differences are significant. Among those differences is one that wrecks the goal of turning off RRL for those mythical small enough to not be amplified responses. Because RRL is about rate limiting responses instead of clients, there is few or no good reasons to turn it off for large or small legitimate responses. Legitimate responses are not frequently repeated and so don't get dropped except in rare or dubious scenarios. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: Frank Bulk frnk...@iname.com Perhaps the ratio could be a dynamic whitelist -- if it's 1.5 or less, then allow the response to go out. What would be gained by spending the code complexity and CPU cycles such a mechanism would require? What bad things would be avoided or good things achieved? (Please do not mention false positives, because that notion of false positive is irrelevant and does not happen with RRL.) Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
* Paul Vixie: The spoofing problem could be mitigated if we actually wanted to, and were willing to punish those who try to send their pollution to the rest of the network. no. there is no we in this context. I meant the we in we the people. Punishment for community-harming behavior should be the prerogative of the sovereign, anyway. We just need to admit that self-regulation by the industry has failed to address this matter adequately. and having so admitted, what will we do next or do differently? We could lobby for law that makes those who push packets with forged source addresses (so that original network operator cannot be identified anymore) liable for the damage these packets cause. the internet is extra-legal because it is extra-national. Doesn't really matter. If a network peer doesn't have the same liability as you do, you better put in filters. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: David Conrad d...@virtualized.org I suspect you're misunderstanding what I'm saying ... Yes, it is yet another form of security theatre, but when has that stopped anyone? Yes, I misunderstand your position as the same as others'. However, I'm pretty sure this isn't appropriate fodder for dns-operations... Perhaps not, if the supposed lack of laws is not an excuse for DNS recursive server operators to keep them open and for authoritative servers to refuse to install some kind of rate limiting. The many years of stop bothering me, spam isn't illegal responses from operators of open SMTP relays and other spam-critical services make me wonder. There are many open recursive servers and authority servers without rate limiting or with RRL manually disabled except for the previously common flavors of attack. ] From: Frank Bulk frnk...@iname.com ] If the problem is amplification, why not only perform RRL on only those DNS ] communications exchanges that have certain amplification factor (i.e. 1.5). That sounds nice but has problems. The main one for me is that you'd have wait until the response has been marshalled before determining it size and deciding whether to drop it. That seems to me harder to code in BIND9 and more expensive in CPU cycles. A better reason is that simple A requests are much smaller than typical non-DNSSEC responses. `dig iname.com @204.74.108.1` sends 38 bytes and receives 225 for 5.9X amplification. 5X is not as flashy as 30X, but is a big problem. 5X is a lot more than your 1.5X and so in practice you would rate limit all responses. If you always do it, you might as well do it in the cheapest way possible, before knowing and regardless of the size of the response. Even 1X or no amplification could be useful to a bad guy wiggling through firewall holes or obscuring an origin. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On 13 Jan 2013, at 16:28, Vernon Schryver v...@rhyolite.com wrote: If the problem is amplification, why not only perform RRL on only those DNS communications exchanges that have certain amplification factor (i.e. 1.5). That sounds nice but has problems. The main one for me is that you'd have wait until the response has been marshalled before determining it size and deciding whether to drop it. That seems to me harder to code in BIND9 and more expensive in CPU cycles. I suppose a name server could keep a (small?) cache of recently marshalled answers and use that to either rate limit responses which are too large or identical to one that has recently been sent to the same IP address(es). [For some definition of large and recent.] This might even be cheaper/faster in some cases. ie Generating a reply with a memcpy() from whatever outgoing packets have been kept in this cache instead of assembling all the RRs, doing label compression, etc. It could be good to have something which rate limits outgoing responses in addition to what's done with incoming queries. Doesn't some name server implementation - PowerDNS? - already do this? Might not be for rate limiting though... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
The problem is amplification. No, the actual problem is source address spoofing. It can only be mitigated. The spoofing problem could be mitigated if we actually wanted to, and were willing to punish those who try to send their pollution to the rest of the network. We just need to admit that self-regulation by the industry has failed to address this matter adequately. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
In message 201301122311.r0cnbedd082...@calcite.rhyolite.com, Vernon Schryver writes: From: Florian Weimer f...@deneb.enyo.de The problem is amplification. No, the actual problem is source address spoofing. ok. It can only be mitigated. The spoofing problem could be mitigated if we actually wanted to, and were willing to punish those who try to send their pollution to the rest of the network. We just need to admit that self-regulation by the industry has failed to address this matter adequately. That statement is wrong and irritating. Neither the UN, ITU, U.S. Department Homeland Security, nor any other mechanism could improve the self-regulation by the industry situation. The UN/ITU is impotent except when its dictums are enforced by local governments; there are no blue helmeted netcops in the foreseeable future. There are too many jurisdictions that don't enforce too many real world norms to rely on law enforcement organizations. Governments can require ISP's implement BCP 38 on customer connections along with compliance audits, random spot checks etc. One of the main reason ISP's site for not doing BCP 38 is that it puts them at a competive disavantage. Such regulation would remove the competive disavantage excuse. If state actors have not been forging IP header source fields, they will. Blunt force denial of service by flooding of a few well known commercial outfits is not the only use for forged IP headers. The tool is too tempting and potentially effective for too many government projects ranging from national hostilities to operations by law enforcement against criminals to expect governments to entirely support BCP38 or even allow its complete deployment. This is like the prospects for governments and politicians limiting their own spam. But they do limit UCE, some more than others. Governments are in a position to influence other governments. The best we can hope for is more self-regulation by the industry in the form of slowly increasing ingress filtering and ultimately the de-peering of networks that are too obviously problems. Even that ultimate stage wouldn't stop forged IP source addresses. There will always be boxes on the wrong sides of filters that will be used for DNS reflection and other bad conduct. IP source address forging is like spam. An occassional exceptionally stupid and irritating spammer is fined or sent to jail and the SMTP equivalents of network egress filtering keeps individual mailboxes useful. (BCP38 is ingress filtering.) Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Vernon, On Jan 12, 2013, at 3:11 PM, Vernon Schryver v...@rhyolite.com wrote: We just need to admit that self-regulation by the industry has failed to address this matter adequately. That statement is wrong and irritating. While I might agree it is irritating, it is so because it is true. Industry self-regulation has indeed failed. The tool is too tempting and potentially effective for too many government projects ranging from national hostilities to operations by law enforcement against criminals to expect governments to entirely support BCP38 or even allow its complete deployment. This is like the prospects for governments and politicians limiting their own spam. A possibility but I've not yet reached that level of cynicism. I suspect that when there is a sufficient demonstration of the effectiveness of source address spoofing against government or infrastructure targets, laws will suddenly appear that require ISPs to take steps to ensure the traffic they source has appropriate source addresses, just as laws appeared to allow lawful intercept of traffic. I personally believe it is only a matter of time. IP source address forging is like spam. Not really. Spam doesn't affect anything except email. Source address spoofing can affect _anything_ on the Internet. Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Paul, On Jan 12, 2013, at 4:51 PM, Paul Vixie p...@redbarn.org wrote: in that having only spoofing and not amplification would mean there would be a smaller problem, it's less true. In a world of million-zombie botnets, amplification is merely icing on the cake. the internet is extra-legal because it is extra-national. While I would agree that national laws do not apply outside of national boundaries (Predator drones not withstanding), pragmatically speaking, in the face of a massive infrastructure outage caused by an attack facilitated by spoofed addresses, I suspect the distinction you are making isn't going to be made by lawmakers. More to the point, I suspect such nationally-based laws would actually have a positive impact: it would force spoofing to move from domestic circuits to international circuits where the situation is slightly different. However, I don't think this is really all that related to dns-operations... Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: David Conrad d...@virtualized.org The tool is too tempting and potentially effective for too many government projects ranging from national hostilities to operations by law enforcement against criminals to expect governments to entirely support BCP38 or even allow its complete deployment. This is like the prospects for governments and politicians limiting their own spam. A possibility but I've not yet reached that level of cynicism. I suspect that when there is a sufficient demonstration of the effectiveness of source address spoofing against government or infrastructure targets, laws will suddenly appear that require ISPs to take steps to ensure the traffic they source has appropriate source addresses, just as laws appeared to allow lawful intercept of traffic. Wouldn't spoofing against government or infrastructure targets invoke the Patriot Act and other terrorism laws? Would an ISP that hasn't deployed the recommend, available and official standard measures to prevent such attacks be an accomplice in a violation of the CFAA? The laws mandating support for wiretaps are in the opposite direction, because they mandate support for network abouse. Laws requiring that all routers support one or more of the BCP 38 mechanisms sound rather late and redundant and wouldn't do much to make ISPs turn them on, especially given the occassional perfectly legitimate situation where simple ingress filtering is wrong. More relevant than CALEA are anti-spam laws and the current noise about Iran being the source of recent reflection attacks. (Never mind whether that noise true this time or is merely more lies and FUD from the usual suspects and beltway bandits.) Everyone with experience in the spam realm knows how impotent the anti-spam laws have been. Even if someday one nation after all these years of broken promises really does outlaw unsolicited bulk email, there will still be plenty of others that won't. Why doesn't the same dire problem affect laws against all forms of network abuse including IP header forgery? Then there is the enforcement problem. Would you have DHS inspectors checking compliance? Would they spot check cages in data centers, consumer access routers, and so on and so forth? That sounds like a bigger job airport security. Would the inspectors be as competent, trustworthy, and educated as TSA inspectors? A common response reaction at this point is something about the civil courts. Why haven't the targets of the recent reflection attacks sued anyone? All authority servers that are not negligent should by now be doing something, whether RRL in BIND or NSP or operators standing by with axes. Reflecting recursive servers have no excuse besides desires to make money cheaply. I suspect some of the ISPs of the sources of the forged requests have been identified, but I've not heard of any court cases against ISPs. Besides the lack of action from the victims, there are the lessons of spam history. You won't find any signs of the civil legal victories of AOL and Earthlink in charts of spam volume. Unless Spamford Wallace goes down on electronic mail fraud, intentional damage to a protected computer, and criminal contempt, will he ever really retire? https://en.wikipedia.org/wiki/Sanford_Wallace IP source address forging is like spam. Not really. Spam doesn't affect anything except email. Source address spoofing can affect _anything_ on the Internet. Even if we agreed that spam affects nothing but email (we don't), we should learn the lessons of the spam war both in general and in the effectiveness of laws on such problems. That there would be fewer interests trying to water down a BCP 38 law into equivalents of CAN-SPAM is irrelevant, because most spam is and has been illegal since CAN-SPAM was signed. In the real world, the phrase covering laws against cybercrime is security theater. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Vernon, On Jan 12, 2013, at 5:55 PM, Vernon Schryver v...@rhyolite.com wrote: Laws requiring that all routers support one or more of the BCP 38 mechanisms sound rather late and redundant and wouldn't do much to make ISPs turn them on, Do you really believe that in the aftermath of a successful spoofing-based infrastructure attack in which (say) people die that politicians and lawmakers would care about the fact that the law was late or redundant? I suspect you're misunderstanding what I'm saying: while I might believe nationally-based legislation may (possibly) have a positive impact in that it might reduce domestic spoofing and change the dynamics (forcing ISPs and hosting providers to wipe their own butts), whether or not a law is effective is beside the point. In the face of a high profile event which demonstrates industry self-regulation has utterly failed, politicians will feel a need to do something and the only thing they can do is pass laws. Yes, it is yet another form of security theatre, but when has that stopped anyone? However, I'm pretty sure this isn't appropriate fodder for dns-operations... Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
... Frank Bulk wrote: If the problem is amplification, why not only perform RRL on only those DNS communications exchanges that have certain amplification factor (i.e. 1.5). i had not thought of this. now that you're making me do so, i think three things. first, 1.5X is probably a compelling amplification factor. second, such a limit would not remove the need to know how many repeated responses are reasonable for some netblock. that consideration does not have gray areas in which we might use response size ratio as a tie breaker. third, in the rare false positive case, someone getting timeouts and having to retry with either udp or tcp, would have more difficulty diagnosing the cause of that problem if the size of the responses they aren't getting was one of the determining factors of whether they got it. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
I'm looking forward to rate-limiting first included in the main releases of market-leading software implementations, allowing operators to enable defenses without separate patches, and subsequently have those features enabled by default after positive feedback. We must be able to act as the villagers that took some action to defend against the wild shepherds with sheep run amok in the Commons. In the grand scheme of our near future, it really wouldn't be that hard for Cisco, Juniper, and a few others to enable uRPF by default on all new model equipment, requiring operators to specifically disable it where necessary, resulting in a significant drop in spoofing, much the same as how some ISPs are preventing outbound SMTP from residential space to clean their networks of SPAM generating sources. RRL should be implemented in the same fashion for DNS. Meandering comments follow. Abusers will move to the next low-hanging fruit In the real world, the phrase covering laws against cybercrime is security theater. +1. Agreed. industry self regulation does not prevent shepherds from grazing their flocks in the village commons. for that class of problem, the solution throughout human history has been law. There are cases where villagers took action against shepherds directly in response to the Commons overrun by flocks, obviating the need of written law until much later. Written law is an abstract to have a governing body punish others for matters which outmatch an individual's resources. Better to empower individuals than become too dependent upon overly powerful governing bodies. admit that self-regulation by the industry has failed to address this matter adequately. Law doesn't reduce crime to zero, and to listen to some, existing laws don't address matters adequately. New laws don't necessarily change the balance old laws attempted. Given that industry self regulation hasn't reduced spoofing to zero isn't a failure, neither is all law a failure. The pursuit of happiness, the struggle, is the point. There is no Utopia to be reached, only strived for. There will always be takers/abusers and nothing will reduce that to zero. Murder has been outlawed since Cain and Abel, yet we keep passing new laws trying to stop it. The Internet works. Reading this email is proof of that. Industry self regulation has gotten us a long way, and likely will continue to do so. The easiest model to review is SPAM. Email became almost unusable several years ago, and then the industry matured (villagers took action against shepherds, followed later with what amounts to law in some nations, but it's the villagers that are most effective, not law). Another model to review is the Wild West, and how it's no longer as Wild. Law alone didn't tame it. The industry is adapting. The Internet will continue to work, or a new communication method will rise from the ashes of the old. Would you have DHS inspectors checking compliance? Would they spot check cages in data centers, consumer access routers, and so on and so forth? That would be as efficient and effective as TSA at airports. Let's hope the madness ends soon! --/-- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
... Patrick, Robert (CONTR) wrote: I'm looking forward to rate-limiting first included in the main releases of market-leading software implementations, allowing operators to enable defenses without separate patches, and subsequently have those features enabled by default after positive feedback. nevertheless i think it's very cool that the freebsd ports maintainer for BIND9 has made RRL a configurable option. There are cases where villagers took action against shepherds directly in response to the Commons overrun by flocks, obviating the need of written law until much later. Written law is an abstract to have a governing body punish others for matters which outmatch an individual's resources. Better to empower individuals than become too dependent upon overly powerful governing bodies. the analogy fails here. on the internet, every network-to-network connection adds to everybody else's commons. as the founder of MAPS, which was the first anti-spam company, i could tell you some stories of exactly why one person's right to swing their fist ends at the point of another person's chin. but, that would digress. ... Given that industry self regulation hasn't reduced spoofing to zero isn't a failure, neither is all law a failure. binary filters (failure or not a failure) aren't useful here. what's happened is that clouds and virtual hosting have dramatically increased the attack surface. millions of poorly trained amateurs are now responsible for kvm environment running now-outdated operating systems and unpatched web servers and unpatched web-app frameworks. by service definition, the operators of the upstream networks have no insight or control over what's running. by economics, the operators of these upstream networks can neither act on complaints, nor monitor outflow, nor run BCP38 ingress filtering on their customer facing interfaces. self regulation won't be fixing that. law might. if all industry self regulation hadn't done was reduce spoofing i'd be willing to entertain arguments that industry self regulation had not failed. since what's actually happened is a well capitalized world wide expansion of gigabit connected spoof generators, i am willing to say that in this case, industry self regulation has, abjectly, failed. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On Jan 10, 2013 7:49 PM, Jim Reid j...@rfc1035.com wrote: It would be nice if ANY queries just got thrown away. I can live with the breakage that causes. YMMV. However if there was something that generally blocked or discarded ANY queries, the bad guys would switch to some other QTYPE that can't be blocked without causing significant operational problems. ___ What makes you think they won't? I mean, isn't this a classic mistake of cold war defense modelling, that you assume your enemy will use weapons you can confidently defend against and ignore the ones you suspect you cannot? ANY has good amplification. If its not working, they surely will move to others. Or both. And if it is working they may move to others anyway. G ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On 10 Jan 2013, at 09:53, George Michaelson g...@apnic.net wrote: What makes you think they won't? I mean, isn't this a classic mistake of cold war defense modelling, that you assume your enemy will use weapons you can confidently defend against and ignore the ones you suspect you cannot? It would be if that's what I was suggesting. Which isn't the case George. I hoped I was saying that while blocking ANY queries might buy some short term relief, it wouldn't help in the long run. Oh well. Whatever defences get added to our name servers are going to prolong an arms race. However, to continue with the military analogy, we're fighting the wrong battle in the wrong place with the wrong equipment and the wrong tactics. I'll fight in that battle because it's pretty much the only option open to me. Things like RRL or kernel firewall setups are all very well. It's good that we have these. But these address the symptoms, not the underlying disease. [Apologies for mixing metaphors.] What's needed IMO is stronger action on BCP38, more help from IXPs and Tier-1s to identify and stop the bogus traffic. High profile arrests that lead to jail time would be good too. I hope we all know this and agree. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
It would be nice if ANY queries just got thrown away. I can live with the breakage that causes. YMMV. However if there was something that generally blocked or discarded ANY queries, the bad guys would switch to some other QTYPE that can't be blocked without causing significant operational problems. ___ What makes you think they won't? I mean, isn't this a classic mistake of cold war defense modelling, that you assume your enemy will use weapons you can confidently defend against and ignore the ones you suspect you cannot? ANY has good amplification. If its not working, they surely will move to others. Or both. And if it is working they may move to others anyway. The bad guys are *already* using other tools than ANY queries - for instance, I have seen quite a few amplification attacks based on TXT queries. There's nothing new under the sun... Steinar Haug, AS 2116 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On 10/1/13 14:10 , sth...@nethelp.no wrote: It would be nice if ANY queries just got thrown away. I can live with the ANY has good amplification. If its not working, they surely will move to others. Or both. And if it is working they may move to others anyway. The bad guys are *already* using other tools than ANY queries - for instance, I have seen quite a few amplification attacks based on TXT queries. Which is exactly why I believe it is a tremendously bad idea to burn parts of the protocol *forever* in order to gain a short term advantage. (in case a metric is needed: if the advantage gained is shorter than the time needed to publish a corrective RFC, don't do it) Gilles ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
Hi George, At 01:53 10-01-2013, George Michaelson wrote: What makes you think they won't? I mean, isn't this a classic mistake of cold war defense modelling, that you assume your enemy will use weapons you can confidently defend against and ignore the ones you suspect you cannot? There are parallels with antispam. The current suspect (ANY queries) will be considered as bad. Abusers will move to the next low-hanging fruit [1]. I would have to do something about the low-hanging fruit if it turns into an operational problem. The problem is amplification. It can only be mitigated. Regards, -sm 1. https://lists.dns-oarc.net/pipermail/dns-operations/2006-March/000135.html ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On Thu, 10 Jan 2013, Jim Reid wrote: IMO, responding to these spoofed queries is a Bad Idea. Not responding is worse. - valid recursors will just retry - valid recursors might conclude the auth server is slow/bad/unreachable and avoid it for legitimate queries as well. The BIND RRL patch -- just reply to one in a thousand (say) of the bogus queries -- is perhaps the best defence. Though it's not the only one. It's a _much_ better defense. It would be nice if ANY queries just got thrown away. No it would not be. Just like a totally mangled packet still gets an answer. You want legitimate resolvers to stop retrying their bogus stuff. Additionally, once ANY queries would be dropped, attackers would move to requesting NSEC3 answers or CNAME/DNAME chains. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
So if I understand correctly, the solution you are advocating is to only answer non-spoofed queries? On Jan 10, 2013, at 7:23 AM, Jim Reid j...@rfc1035.com wrote: I agree: provided we're talking about responding to queries from valid recursors. However we're not. The context is spoofed queries. [See above.] Responding to these is bad because (a) it chews your bandwidth and CPU; (b) the replies don't go to the actual source that generated the queries; (c) the destination of those responses doesn't want or need that inbound traffic. This is why we agree RRL helps to reduce the damage from spoofed ANY flood attacks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On 10 Jan 2013, at 17:39, Matthew Ghali mgh...@snark.net wrote: So if I understand correctly, the solution you are advocating is to only answer non-spoofed queries? It's one of them, yes. Though since it's hard for a DNS server to distinguish between spoofed and genuine source IP addresses, the RRL patch is the easiest way to get the same effect. Your server would then respond to a teeny fraction of the thousands of queries per second from the same (forged) IP address(es). Further measures will be necessary, especially if/when the characteristics of the current attacks change to make them less amenable to RRL dampening. Sadly, there is no magic bullet which will solve this problem. A bunch of countermeasures and defences are needed, some of which will be outside the realm of network operations or the DNS protocol. This should not be news to anyone here. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
In message fbdea1f1-c2ea-49bd-bc4b-227b997b8...@rfc1035.com, Jim Reid writes: On 10 Jan 2013, at 17:39, Matthew Ghali mgh...@snark.net wrote: So if I understand correctly, the solution you are advocating is to only answer non-spoofed queries? It's one of them, yes. Though since it's hard for a DNS server to distinguish between spoofed and genuine source IP addresses, the RRL patch is the easiest way to get the same effect. Your server would then respond to a teeny fraction of the thousands of queries per second from the same (forged) IP address(es). Further measures will be necessary, especially if/when the characteristics of the current attacks change to make them less amenable to RRL dampening. Sadly, there is no magic bullet which will solve this problem. A bunch of countermeasures and defences are needed, some of which will be outside the realm of network operations or the DNS protocol. This should not be news to anyone here. As far as I can tell there is no way to stop reflection attacks as long as ISP's allow spoof traffic to enter their networks. The attackers will just go broad spectrum (millions of reflectors) and no single reflector will be able to see that it is part of a attack. It is possible to detect current reflection attacks and mitigate them using RRL but this is only a stop gap measure which causes the attackers to choose different refectors. What we can do is turn off amplification attacks. We know a number of methods of how to do this. * set TC=1 on all UDP query replies and force the client to TCP. * do a handshake over UDP before sending amplified replies. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: Casey Deccio ca...@deccio.net I'm not familiar with other RRL behavior, but to provide some numbers for BIND's patch: All responses to rate-limited queries are truncated, but default behavior is to withhold response altogether for only 1 out of 2 such queries (50%). As Paul Vixie often says, the goals of RRL do not include stopping DNS reflection DoS attacks but: 1. attenuating reflection attacks so much that the attacker would do more damage to the victim by sending the bogus DNS requests directly to the victim 2. not letting the attacker deny DNS service to the victim by failing to answer the victims real requests. Goal #1 is achieved by attenuating or sending fewer bits toward the victim than the attacker sends to the DNS server. With slip 2, the attacker's bits are reduced by about 50%. The attacker would do twice the damage by sending toward the target instead of the reflector. Goal #2 is approached with slip hack and by rate limiting responses instead of clients. The victim's DNS requests are unaffected unless they are for the same name and type as the attacker's forged requests. Goal #2 is practically reached while the attacker avoids the major query types. If the attack uses a major type such as A, then we rely on the probability of at least one of the victim's requests getting a slip or TC=1 response. It helps that the victim need only get one response per DNS cache lifetime. depends on the query rate. The statisticians might provide a good rule of thumb for reasonable response rate given query rates, but it seems like 50% is in fact a good starting place. With slip=2 and the victim trying and retrying a total 3 times, the probability that all of the victims responses will be dropped is 0.5*0.5*0.5 = 0.125. That makes the probability that the victim will get a response despite matching the DoS flood about 88%. That's not perfect, but not bad. If it's a mail system that will retry a few times or a user at a browser that will manually retry a failed page, it gets even better. The BIND RRL patch also has an option for scaling down the slip value (which dictates response rate) in the presence of increased query rates. I haven't had time to play with it, but the idea is smart. The impression that the slip value can be scaled down using the gross qps rate comes from an error of mine the documentation. Only the real rates can be scaled. I've proposed that the 'slip' value be scaled up the qps ratio or the square of the qps ratio to keep the TC=1 responses/second rate constant. On the other hand, any reduction of TC=1 responses (i.e. increase in slip) reduces the reason to have slip. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
In message 201301102157.r0alvdah025...@calcite.rhyolite.com, Vernon Schryver writes: From: Mark Andrews ma...@isc.org As far as I can tell there is no way to stop reflection attacks as long as ISP's allow spoof traffic to enter their networks. The attackers will just go broad spectrum (millions of reflectors) and no single reflector will be able to see that it is part of a attack. A problem with using a million reflectors is that it is a lot more hassle. The goal need not be preventing all reflection attacks but only making reflection attacks less rewarding and more costly than other attacks, such as simple UDP floods from a modest botnet. The other part of the goal is to not lose resourse. Reflection attacks help there. It is possible to detect current reflection attacks and mitigate them using RRL but this is only a stop gap measure which causes the attackers to choose different refectors. I agree, with the reservation that eventually RRL could eventually cause attackers to choose different attacks. What we can do is turn off amplification attacks. We know a number of methods of how to do this. * set TC=1 on all UDP query replies and force the client to TCP. which would kill busy DNS servers. Indeed. RRL does this selectively. * do a handshake over UDP before sending amplified replies. What qualifies as amplification? An unsigned (no DNSSEC) A request/response is good for at least 3X. 10X or 20X is impressive but merely eases the attacker's job by allowing fewer reflectors. We can go from 1X upwards. Would you turn off all DNS/UDP without a DNS cookie by augmenting https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 with some kind of minimal try again with a cookie response similar to but different from a minimal TC=1? I like DNS cookies, but they would take many more years to deploy widely enough to matter than have already passed since the I-D expired. If we had a code point we could see 10% deployment within a year especially if it pushed out in maintanence releases of older code trains. If cookies, ttcp, or some other DNS protocol change is The Answer, then in the years before The Answer is deployed, you're stuck with making reflection attacks less attractive than alternatives, which will slow The Answer. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On Thu, Jan 10, 2013 at 2:24 PM, Vernon Schryver v...@rhyolite.com wrote: thumb for reasonable response rate given query rates, but it seems like 50% is in fact a good starting place. With slip=2 and the victim trying and retrying a total 3 times, the probability that all of the victims responses will be dropped is 0.5*0.5*0.5 = 0.125. That makes the probability that the victim will get a response despite matching the DoS flood about 88%. That's not perfect, but not bad. Thanks for correcting my math. I was thinking that the probability that the victim got a response was dependent on query rate, but of course that would only be the case if response rate was a function of responses per time interval, not responses per number of queries. It's simply a function of response rate and retry, i.e., p = 1 - (1 - (1/slip))^retries -- a much better success rate than the alternative in the midst of a flood of forged queries. Casey ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
