Subject: [ietf-dkim] Amplification attack solution.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Feb 2006 09:45:40 -0800

> From: william(at)elan.net [mailto:[email-masked]] 

> 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