From: william(at)elan.net [mailto:william(_at_)elan(_dot_)net]
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