Re: [dns-operations] Defending against DNS reflection amplification attacks
On 23/02/2013, at 2:53 AM, Jo Rhett jrh...@netconsonance.com wrote: No. I've had this conversation many times and employees of big companies feel that it's impossible, and don't even raise the issue with their management. In two different occasions I arranged a meeting with their management and made the case for it, at which point the managers told the unbelieving employee to make it happen. On Feb 23, 2013, at 8:36 PM, Daniel Griggs wrote: If you have a presentation that you can share with the class, that would be great. It would make a useful addition to any security workshops or discussions I have with providers around security. This topic really is so much simpler than most people put it out there. Completely ignore any topic of being a good person. There are a group of related legal terms that come into play: 1. Gross Negligence 2. Good Faith Business Judgement 3. Commercially Reasonable Effort ...a few others, it's been a while since I had this discussion. But the long and short is that for a person or company suing the provider to prove gross negligence, they must prove that this particular provider (1) knew that the damage it would cause and (2) failed to provide reasonable effort to prevent the damage. It's a very short trip for a lawyer to convince even the most ignorant jury what the IETF is, and what BCP38 is, and that there is no reasonable way that the commercial entity was unaware of BCP38. Last time I was in court the lawyer threw three other RFCs into the mix but I have forgotten offhand what they are. Tail that together with the extensive promotion efforts by others, and a company would have to claim that they had never heard of the IETF and never went to any conferences and never participated any forums or mailing lists. That's a very easy bit of information to gather to prove they did. Note: I have always entered the conversation having this exact information in hand, to show just how easy it was to prove. Then the lawyer must prove that it was commercially reasonable, ie, their competition does it. In the lawsuits that I was involved in, the lawyer didn't bother making a case for the industry as a whole but instead made a case for the providers just down the street. In particular, the fact that the customer who initiated the attack moved from a provider who was BCP38 compliant to them just days before the attack was used as evidence that the provider was directly to blame. Note: I don't bring this up, but several providers have asked if implementing BCP38 would make it more likely their competitors would face this lawsuit. I plead off being a lawyer but I acknowledge that it seems entirely reasonable. I do point out that if a competitor's failure to implement BCP38 was involved in an outage in their network, all of the same facters are involved. (and vice versa) Then, the lawyer must simply provide evidence that the attacks came from the provider's network (wouldn't be a lawsuit without that part) and voila, you have a clear judgement for gross negligence. The last bit of information that I bring is a round-up of what awards juries toss at large corporations convicted of gross negligence. Given the current anti-big-business mindset in this country, it is always ridiculously high numbers. note 1: not a lawyer and I make it clear. In fact, I express clearly that this is something they should discuss with their own lawyer(s). note 2: I've only done this with US companies, or companies with US divisions. Legal terms and expectations may differ elsewhere. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. ___ 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] Defending against DNS reflection amplification attacks
On 23/02/2013, at 2:53 AM, Jo Rhett jrh...@netconsonance.com wrote: - big companies with staff who care about BCP38 have likely already deployed it; No. I've had this conversation many times and employees of big companies feel that it's impossible, and don't even raise the issue with their management. In two different occasions I arranged a meeting with their management and made the case for it, at which point the managers told the unbelieving employee to make it happen. BCP has some really good arguments for any public company, basically this. If you have a presentation that you can share with the class, that would be great. It would make a useful addition to any security workshops or discussions I have with providers around security. -- Daniel ___ 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] Defending against DNS reflection amplification attacks
On Wed, Feb 20, 2013 at 08:48:19AM +0100, Jan-Piet Mens jpmens@gmail.com wrote a message of 12 lines which said: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. Very good paper, highly recommended. I was surprised they did not test NSD+RRL (or other solutions). Lack of time? ___ 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] Defending against DNS reflection amplification attacks
On Feb 22, 2013, at 4:04 AM, Paul Vixie p...@redbarn.org wrote: at which point it's easier to fix source address validation and make THAT universal. which we already know can't be done. Don't confuse won't with can't. It absolutely can be done. It won't be done because the carriers see profit in laziness, and see no profit in stopping criminals. In fact, I would argue that it could be done within a month net-wide if the carriers were motivated to do it. Sadly, it will probably take a large scale event that makes large carriers implement it completely in defense of their own networks to force the small carriers to get around to it. ...not dissing small carriers. I know many who implement it completely. It's the large carriers who tend to whine the most, but they are also the ones with a board of directors who could demand it -- thus, they are the place where the elbow could be placed. ___ 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] Defending against DNS reflection amplification attacks
On 2013-02-22, at 13:55, Jo Rhett jrh...@netconsonance.com wrote: On Feb 22, 2013, at 4:04 AM, Paul Vixie p...@redbarn.org wrote: at which point it's easier to fix source address validation and make THAT universal. which we already know can't be done. Don't confuse won't with can't. It absolutely can be done. It won't be done because the carriers see profit in laziness, and see no profit in stopping criminals. Before everybody starts waving red flags and marching in the streets: - the carriers of which you speak are big companies; - big companies with staff who care about BCP38 have likely already deployed it; - big companies with non-trivial networks who have yet to deploy it need a business reason to do so, since the implementation and support costs are likely enough to be significant that there's probably no room under the radar to do it there; - companies have a responsibility to their shareholders to act according to a profit motive; - there is no profit motive in increase my costs so that I can decrease the costs of my competitors. If you can describe BCP38 deployment in a non-trivial network such that deployment is to the benefit of shareholders and non-deployment is not, I'm all ears. Absent regulation and punitive fines for non-compliance, I don't see it. If there's a logical or practical fallacy in here, someone please point it out. (As if I have to type that.) Joe ___ 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] Defending against DNS reflection amplification attacks
From: Joe Abley jab...@hopcount.ca If you can describe BCP38 deployment in a non-trivial network such that deployment is to the benefit of shareholders and non-deployment is not, I'm all ears. Absent regulation and punitive fines for non-compliance, I don't see it. Civil lawsuits by victims of DNS reflection and other attacks that depend on failures to deploy BCP38 might help convince boards of directors. It might help to take up a collection to help pay the legal fees a victim sueing one of those non-trivial networks. I've the vague impression that kind of fund raising is illegal. I've learned to avoid using the word fine in a different but related context. I have long claimed that ESPs (bulk mailer for hire) could practically stop the large amounts of unsolicited bulk email that they send by fining their customers with dirty target lists. A $100 fine for each spam complaint verified by the ESP (maybe only after the 5th complaint and maybe capped at $5,000) would practically stop the ESP spam sent toward my personal mailbox and to my spam traps feeding DCC. A representative of a major ESP insisted in public that my claim is nonsense, because it is illegal (sic) for an ESP to fine its customers. Because ESPs are private enterprises, that might be literally true. It's also a lie because ESPs could say cleanup fee or spam complaint processing fee instead of fine without reducing the disincentive for purchased, harvested, re-purposed, or other dirty mailboxes in target lists. 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] Defending against DNS reflection amplification attacks
On Feb 22, 2013, at 10:22 AM, Joe Abley jab...@hopcount.ca wrote: - big companies with staff who care about BCP38 have likely already deployed it; No. I've had this conversation many times and employees of big companies feel that it's impossible, and don't even raise the issue with their management. In two different occasions I arranged a meeting with their management and made the case for it, at which point the managers told the unbelieving employee to make it happen. BCP has some really good arguments for any public company, basically this. - big companies with non-trivial networks who have yet to deploy it need a business reason to do so, since the implementation and support costs are likely enough to be significant that there's probably no room under the radar to do it there; Every implementation I have done at the edge was nearly trivial in the amount of effort involved. I've been paid as a consultation to do it, and in several situations I was able to enable BCP for 1000+ customers for less than one day's worth of billable hours. (filtering at the core is an entirely different topic and is absolutely much harder) Not all situations are that easy, but it's often much easier than anyone believes. - companies have a responsibility to their shareholders to act according to a profit motive; - there is no profit motive in increase my costs so that I can decrease the costs of my competitors. There is absolutely a profit motive in preventing very costly lawsuits. I was personally involved in the complete death of an small european ISP which was used repeatedly for multi-gigabit random-source attacks. Their customer base and gear was sold off for 8% of annual operating revenue at the close of the criminal case. Stockholders very much care about this. If you can describe BCP38 deployment in a non-trivial network such that deployment is to the benefit of shareholders and non-deployment is not, I'm all ears. Absent regulation and punitive fines for non-compliance, I don't see it. I am seriously looking for a great opportunity to sue a very large carrier for a failure to implement BCP38, since it very clearly meets the guidelines for reasonable and expected that the courts love to use. One very large carrier + one very large settlement, and the other carriers will notice. ___ 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] Defending against DNS reflection amplification attacks
Civil lawsuits by victims of DNS reflection and other attacks that depend on failures to deploy BCP38 might help convince boards of directors. as will black helicopters. can we stick to reality as we actually experience it? it is the reality on which the management, of which joe spoke so well, operates (well ...) randy ___ 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] Defending against DNS reflection amplification attacks
On Feb 22, 2013, at 12:04 PM, Randy Bush ra...@psg.com wrote: Civil lawsuits by victims of DNS reflection and other attacks that depend on failures to deploy BCP38 might help convince boards of directors. as will black helicopters. can we stick to reality as we actually experience it? Having been a witness in two of these lawsuits, I don't see them as unrealistic. Both lawsuits were remarkably effective. This is one of the few technical topics which can be explained to normal jurors very easily. ___ 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] Defending against DNS reflection amplification attacks
Civil lawsuits by victims of DNS reflection and other attacks that depend on failures to deploy BCP38 might help convince boards of directors. Having been a witness in two of these lawsuits, cites, please randy ___ 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] Defending against DNS reflection amplification attacks
On Feb 22, 2013, at 2:09 PM, Randy Bush ra...@psg.com wrote: Civil lawsuits by victims of DNS reflection and other attacks that depend on failures to deploy BCP38 might help convince boards of directors. Having been a witness in two of these lawsuits, cites, please That's a great request that unfortunately I have no clue if I can respond to. Both were early-mid 2000s and I was forbidden by the court from talking about it at the time. I need to track down the legal team of the companies and find out if I can discuss the topic now that it's settled. (both were settled as soon as the lawyer's realized that the juryAnd unfortunately both companies that brought me in as a witness have been acquired, one twice since then so it's going to be fun to do. I have already started that process however once this conversation began because I knew that this would be asked. ___ 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] Defending against DNS reflection amplification attacks
Are you willing to also help us do the hard work to do the right thing? I'm pretty sure the answer is Yes. So let's get busy, and stop finding reasons not to do the Right Thing. - ferg you may have a problem with your mail system. it seems to be re-sending messages from a decade ago, though they seem to have today's date. odd. perhaps, after the decade of us telling others how they should run their networks, an actual large operator who has deployed bcp38 can give us an analysis of the costs, capex and opex, and how they minimized them. randy ___ 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] Defending against DNS reflection amplification attacks
On Fri, Feb 22, 2013 at 7:13 PM, Randy Bush ra...@psg.com wrote: Are you willing to also help us do the hard work to do the right thing? I'm pretty sure the answer is Yes. So let's get busy, and stop finding reasons not to do the Right Thing. - ferg you may have a problem with your mail system. it seems to be re-sending messages from a decade ago, though they seem to have today's date. odd. Not at all odd -- we still have the same problems. I think that is indicative of several things, none of which I will expand on at this moment. perhaps, after the decade of us telling others how they should run their networks, an actual large operator who has deployed bcp38 can give us an analysis of the costs, capex and opex, and how they minimized them. I think we are far beyond that -- those are the things that have apparently already failed. It is several factors -- ignorance, negligence, among them. We as a community have not a good job of boiling it down to non-technical issues that those executives understand (with regards to revenue issues). I agree that we should have some hard stats on who has deployed these measures, and how it impacted them. Please speak up if you have any data. I can say, however, that we *do* have data on who has *not* deployed it, and how they are virtually criminally negligent for doing so. And don't get me wrong -- there are still some really hard problems. - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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] Defending against DNS reflection amplification attacks
On Fri, Feb 22, 2013 at 7:38 PM, Randy Bush ra...@psg.com wrote: one urban definition of insanity is repeating the same thing expecting different results. i do not disagree with bcp38. i just don't think repeating that anyone who does not deploy it is an anti-internet asshole is going to get any more significent deployment. that approach has been failing for many years. randy I don't think I said anything even closely resembling that. I did said that we (community) are not doing a proper job of promoting proper behavior (and configuration) on the Internet. And it's not all about BCP38 either. There are tens of millions of open DNS recursive resolvers out there... - ferg -- Fergie, a.k.a. Paul Ferguson fergdawgster(at)gmail.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] Defending against DNS reflection amplification attacks
Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. -JP [1] http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf i had a brief look. actually, i skipped straight to appendix E :) i think measuring performance with process accounting (top, htop...) is not such a great idea. something like cyclesoak would probably be better: `cyclesoak' calculates CPU load by a subtractive method: a background cycle-soaking task is executed on all CPUs and `cyclesoak' measures how much the throughput of the background tasks is degraded by running the traffic. This means that ALL effects of networking (or other userspace + kernel activity) are measured - interrupt load, softirq handling, memory bandwidth usage, etc. This is much more accurate than using Linux process accounting. (http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/README.zc) and perf is a great profiling tool for linux, too. (https://perf.wiki.kernel.org/) -- Robert Edmonds edmo...@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] Defending against DNS reflection amplification attacks
* Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. Despite they are using the wrong patch for DNS Dampening, the results are impressing. Works as designed. Of course, they require a SLIP parameter. I heard this. ___ 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] Defending against DNS reflection amplification attacks
FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. -JP [1] http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf ___ 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
