> From: william(at)elan.net [mailto:[EMAIL PROTECTED]
> On Tue, 28 Feb 2006, Hallam-Baker, Phillip wrote: > > > There are people who think they need to do such things, such people > > tend to be wrong with remarkable frequency. > > I happened to think there are better ways to achieve the > results but I would not go into saying that those who need > spoofing capabilities right now are wrong. In any case, you > need to face the facts that many ISPs are not going to drop > spoofed packets now even if we tell them to as this is > capability some of their business customers require. That depends on how they are told. There are more effective means of communication than flaming on Nanog. A presentation to MAAWG for example. Or the DHS, regulation happens, it is a fact of life. Left unguided the policy makers will regulate on autopilot and the results will be bad. Give them concrete ideas to work with and the results are much better. My view is that a network that is sourcing spoofed source address packets is liable for the damage they cause to other networks. There is a clearly irentified risk, a clearly identified loss, the probability of the risk being realized is essentially 1, the expected loss is much greater than the cost of control. Sounds like this passes the Hands test to me. > This is > slightly better with DSL access providers but even there it > is quite often allowed for business connections. It may be allowed but I am having a hard time understanding why anybody other than a spammer or a backbone provider would want that capability. > The entire tcp session connection is established using dialup > ip address as source, but actual packets go out from > different interface - fairly easy to achieve actually on > linux and used for legitimate purposes. As with folk who used undocumented Windows API calls. Its your funeral, when it stops working, there is no reasonable expectation that that particular feature will continue to be supported. > It used to be more popular for spam purposes but I think this > is quite rare now due to availability of zombies. What > spammers do still use is getting space at some > carrier-neutral colo center, connecting to multiple providers > and using one's ip address to establish the session but > really sending data though cheaper network (typically cogent) > without actively advertising such connectivity from outside. > Considering this is totally legitimate way to do traffic > engineering, there is nothing that can really be done about > this practice. Given the number of legitimate practices that we have shut down in the name of stopping spam I have a hard time believing that there is nothing that can be done about this particular abuse. > > The amplifier attack you describe will worst case cause a > doubling in > > the data volume and that only if the attack machine is directing > > traffic through multiple DNS servers at one time. > > I'd really like to see where you came up with this "doubling" > number estimate especially "if multiple DNS servers" are used. > Just so you know the current cisco.com DKIM record results in > 342bytes message data (do "dig txt > nebraska._domainkey.cisco.com") and security of this key is > may not be sufficient and many will probably use 2k ones in > the future. The original packet request to retrieve that key > was 40-50 bytes in size (only QUESTION section). My estimates > is that just one dns server with DKIM record abused by this > attack should give about 8x amplification effect (if you like > I can write specialized scripts and give exact numbers for > several sites). Unless you are sending the requests out to multiple servers the DNS server that is the subject of the attack is going to be throttled by its outbound bandwidth. You can only get the multiplier effect if 1) the DNS server is on a bigger pipe than the machine attacking it 2) the DNS server that is attacked has no throttling capability of its own. I don't know about you but if I was writing a DNS server I would probably have put code in it to prevent this type of attack quite some time ago. Otherwise the DNS server is vulnerable to DDoS attack itself. A solution is very simple: 1) keep a cache of the past 10 or so recent requests plus identified attacks 2) When a new request comes in see if the purported source matches the recent request list 3) if match not found, insert request in cache, return 4) if match found increment tracking counter 5) if indicated frequency exceeds threshold, mark as identified attack 6) respond to only requestsize/responsesize% of identified attacks That took me less than ten minutes to think up and I'll bet that similar code is already in BIND and that DJB has an even better way to do it. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
