No.
I think that is indicative of the problem.
Don't you?
- ferg
The only data I have is from the MIT anti-spoofing test project which
has been pretty consistent for a long time. About 75%-80% of the nets, addressses, ASNs tests couldn't spoof, and about 20%-25% could.
The geo-location maps don't show much difference between parts of
the world. RIPE countries don't seem to be better or worse than ARIN
countries or APNIC countries or so on. ISPs on every continent seem
to be about the same.
http://spoofer.csail.mit.edu/summary.php
If someone finds the silver bullet that will change the remaining 25% or
so of networks, I think ISPs on every continent would be interested.
Financial incentive is the key. If there is none, those with the most to
gain (backbone operators) also have to power to create such incentive.
It wouldn't be fundamentally different from the basic network policing
that happened on the academic networks which formed the Internet
backbone in the 80s and early 90s.
Keywords:
That would be nice -- but I wonder how much operational impact that would
have.
As you note, the 20-25% figure (of addresses) has been pretty constant
for quite a while. Assuming that subverted machines are uniformly
distributed (a big assumption) and assuming that their methodology is
valid (another big assumption), that means we've already knocked out the
75-80% of the sources of spoofed IP address attacks. Has anyone seen a
commensurate reduction in DDoS attacks? I sure haven't heard of that.
Are people saying that the problem would be several times worse if
anti-spoofing weren't in place? As best I can tell, the limiting factor
on attack rates isn't the lack of sources but the lack of a profit motive
for launching the attacks.
Put another way, anti-spoofing does three things: it makes reflector
attacks harder, it makes it easier to use ACLs to block sources, and it
helps people track down the bot and notify the admin. Are people actually
successfully doing either of the latter two? I'd be surprised if there
were much of either. That leaves reflector attacks. Are those that large
a portion of the attacks people are seeing?
I agree that anti-spoofing is a good idea, and I've said so for a long
time. I was one of the people who insisted that AT&T do it, way back
when. But I'm not convinced it's a major factor here.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
* Steven M. Bellovin:
As you note, the 20-25% figure (of addresses) has been pretty constant
for quite a while. Assuming that subverted machines are uniformly
distributed (a big assumption)
I doubt this assumption about distribution is valid. At least over
here, consumer-grade ISPs (think DSL with dynamic IP addresses) apply
ingress filters, while real ISPs don't. If you're lucky, you get
egress filters at some border routers, but it's not standard at all.
Customer-facing interfaces are generally unfiltered.
(But I have to admit that we recently ran into filters at an
upstream's upstream, so there's at least some BCP 38 adoption.)
I disagree. As someone who has been attacked by spoof-source packets, and not-spoof-source packed, I can say, from personal experience, that the former is much, much easier to mitigate.
And, as I posted before, even if all universal adoption of BCP38 means is that DDoS attacks move to botnets with 100% real source IP addresses, that would still be a Very Good Thing, IMHO.
But perhaps others feel differently. Or perhaps they just haven't been attacked enough. 
Put another way, anti-spoofing does three things: it makes reflector
attacks harder, it makes it easier to use ACLs to block sources, and it
helps people track down the bot and notify the admin. Are people actually
successfully doing either of the latter two?
I think it's a time constraint- looking up, sorting and notifying admins about 10,000 attack sources isn't practical. I'd love to do it- but I don't have time. That said- if someone notifies me of a compromised host I immediately investigate- and I suspect so would everyone else on this list.
Has anyone put together a centralized system where you can send in a list of attacking bots, let it automatically sort by allocation, and then let it notify the appropriate admin with a list of [potentially] compromised hosts?
Then again: Considering how many admins don't care, how many end users don't care/know, and how quickly many of thee systems would get re-infected maybe it's all a bit pointless.
I'd be surprised if there were much of either. That leaves reflector attacks. Are those that large a portion of the attacks people are seeing?
Everything I have seen of late has been legitimate traffic originating from across the globe. With tens of thousands of compromised hosts that's all it takes.
-Don
Those are good points. It would be interesting to look at the raw AS
data and see what classes of organizations were represented.
Unfortunately, that data is not publicly available, according to the FAQ
for that project.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
mynetwatchman [1] comes to mind and so does dshield [2]
Anyone familiar with these folks?
http://www.simplicita.com/Simplicita_Research_Data_Partner_Program.html
--Michael
Microsoft no longer demands licensing for Sender-ID. Executing SPF
scripts may become increasingly popular for validating SMTP clients
against MAILFROM, PRA, or perhaps DKIM domains. SPF scripts can be far
more malicious than even spoofed source reflective DNS attacks. Dozens
of TXT or hundreds of A record transactions might be invoked by the
recipients of each message.
In addition to MTAs processing SPF script, popular applications like
SpamAssassin executes a different script after an elapsed timeout of 5
seconds. Such short timeouts eliminate congestion avoidance. SPF is
analogous to a complex lock where there is no obvious place for a key.
One must trust a stranger to operate their own unique DNS based
mechanism.
The macro capability of this script also allows any element of an
email-address to randomize DNS queries against any unseen victim domain.
SMTP logs may not indicate who initiated an attack, nor indicate when an
attack was in progress. BCP38 filtering or ACLs on recursive DNS will
not offer protection from this exploit, which can achieve gains much
higher than spoofed source reflective DNS attacks.
Spam being sent through Bot farms has already set the stage for
untraceable DNS attacks based upon SPF. In addition to taking out major
interconnects, these attacks can:
a) inundate authoritative DNS;
b) requests A records from anywhere;
c) probe IP address, port, and the transaction IDs of resolvers;
While not as bad as eavesdropping, it still places the network and the
integrity of DNS at risk. All of this while the spam is still being
delivered. What a productivity tool!
How is this attack detected?
How is this attack avoided?
-Doug
How is this attack avoided?
Sounds like the attack is inherent in SPF. In that case,
avoiding it is simple. Discourage the use of SPF, perhaps
by putting any SPF using domain into a blacklist.
Eventually, people will stop using SPF and the attack
vector goes away.
--Michael Dillon
* Douglas Otis:
Spam being sent through Bot farms has already set the stage for
untraceable DNS attacks based upon SPF. In addition to taking out major
interconnects, these attacks can:a) inundate authoritative DNS;
b) requests A records from anywhere;
c) probe IP address, port, and the transaction IDs of resolvers;
(b) and (c) are not new developments because lots of MTAs already
perform A lookups on HELO arguments, and MX lookups on sender domains.
While not as bad as eavesdropping, it still places the network and the
integrity of DNS at risk. All of this while the spam is still being
delivered. What a productivity tool!
The purpose of SPF, as it is deployed, is to facilitate routing
solicited bulk email around spam filters. Look at email.bn.com/IN/TXT
to get the idea. This application requires some of the indirection
features offered by SPF.
how did the thread about dns providers and rfc compliance morph into SPF
and spam discussions?
* Douglas Otis:
> Spam being sent through Bot farms has already set the stage for
> untraceable DNS attacks based upon SPF. In addition to taking out major
> interconnects, these attacks can:
>
> a) inundate authoritative DNS;
>
> b) requests A records from anywhere;
>
> c) probe IP address, port, and the transaction IDs of resolvers;(b) and (c) are not new developments because lots of MTAs already
perform A lookups on HELO arguments, and MX lookups on sender domains.
Each message's SPF script can prompt for web-site addresses while also
inundating the web-site's DNS with other randomized requests. Network
gains achieved by each script can reach 70:1, and when instances of
execution (MTA/MUA, MAILFROM/PRA/DKIM, and recipient) are considered,
gains per message may exceed 1000:1 while still permitting delivery and
while not exposing who their victim was.
> While not as bad as eavesdropping, it still places the network and the
> integrity of DNS at risk. All of this while the spam is still being
> delivered. What a productivity tool!The purpose of SPF, as it is deployed, is to facilitate routing
solicited bulk email around spam filters. Look at email.bn.com/IN/TXT
to get the idea. This application requires some of the indirection
features offered by SPF.
The risk is from an amplification achieved by SPF scripts while still
hiding which messages are attacking.
Bulk senders can use APL RRs (42) (see rfc3123) to list the CIDRs of
their SMTP clients without imposing these risks. Standardized prefixes
such as _smtp-c0 and _smtp-c1 permits chaining signaled with a
"continuation" address-family, as example. Executing powerful SPF
scripts from strangers is a heavily promoted bad idea that truly needs
to be discouraged.
-Doug
> > How is this attack avoided?
>
> Sounds like the attack is inherent in SPF. In that case,how did the thread about dns providers and rfc compliance morph into SPF
and spam discussions?
Ask Doug Otis. He stated that SPF sets the stage for DDoS
attacks against DNS servers. Presumably he said this because
it points to another *COST* of DDoS that could be used as
a business justification to implement BCP38.
Or you could look at it as a weakness of SPF that should be
used as a justification for discouraging its use. After all
if we discourage botnets because they are DDoS enablers,
shouldn't we discourage other DDoS enablers like SPF?
--Michael Dillon
under this assumption we should discourage user use of the internet... 
anyway, please let's get back to the original discussion
how did the thread about dns providers and rfc compliance morph into SPF
and spam discussions?
for the spf hammerers, everything looks like a nail? 
personally, i think it is overloading of mpls, dns, and bgp.
randy
As Steve already pointed out, BCP38 is not a complete solution. Not only does SPF prevent the source of a Botnet attack from being detected, it also enables significantly greater amplification than might be achieved with a spoofed source DNS reflective attack. In addition, the Botnet resources are not wasted, as their spam is still being delivered. This aspect alone dangerously changes the costs related to such attacks. It seems wholly imprudent not to consider SPF in the same discussion.
-Doug
Doug, I wonder, HOW do you intend / do track down the source of a botnet
attack? I know how I and others do it. There are three approaches which
fork everywhere on an expression tree.
If you believe SPF prevents you from doing it, can you elaborate how?