On Mon, 2004-06-28 at 13:36, Hallam-Baker, Phillip wrote:
If it turns out that SPF adoption leads to significant network
harm, then it would be possible to tweak it or replace it with
something more effective, with narrower scope, in particular CSV.
This is a valuable discussion.
Caller-Id required a single packet in each direction for the vast
majority of mail interactions.
Furthermore this data is cachable.
Based on an estimate of about 10 million active email domains
we have worst case a problem that is orders of magnitude less than
distributing alt.binaries over a flood fill routing algorithm
like NNTP.
Again, this was in regard to an attack scenario. Assuming best case
does not provide meaningful analysis nor is DNS on par with NNTP.
Let's flesh out more your attack scenario, so we can be
proactive about this.
No, lets consign it to the bit bucket where it belongs. The
argument is nothing more than big numbers are scary.
Many MTAs are already performing multiple DNS queries per
email connection without significant impact on net performance,
the only threat here comes from the spam.
Those queries are often to _known_ DNS servers done in parallel. The
number of these SPF queries may be chained into a series of 20 queries
using the prior SPF specifications. If SPF employed at the MTA forces a
defensive mode of closing lists in response to possible DDoS attacks,
then these records WILL become more complex to allow the oft needed
ability to originate mail from different locations. This complexity
introduces a growing hazard.
I could see SPF causing some free DNS providers to go belly
up.
I don't see how.
Perhaps reviewing the original message
http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html
I could formulate overhead for DNS being roughly the TXT record size +
110 bytes plus the name size assuming just the TXT record was returned
in the query. This increases again with the need to discover the NS and
SOA for a domain.
If the attacker sent spoofed messages to multiple destinations, then the
receiving MTAs create DDoS conditions with efforts to query the same
server not robust enough to handle the resulting load. This does not
require each domain to list 20 records, but rather each domain offers an
additional reference on average. If it resolved, the search would
conclude, but as this is spoofed, the search continues until the limit
or the lists become exhausted. It really does not matter if the list is
open or closed for this to be an expensive exercise.
It seems that traditional BLs were near the tipping point- concerted
DDoS attacks brought down some BLs, but were unable to take down
others.
There is no issue here, a DDoS attack against WHAT?
The spoofed source is the means of attack. This happens as the SPF
looks to the message source to ascertain permissions. Meng has
suggested yet another level of HELO domain queries be added to this
sequence as a means to unify SPF+CSV. :-0
Sure DDoS attacks against DNS happen. But what is the scenario being
suggested here? A DDoS attack against who?
Worst case is that the spammer takes out the DNS server of alice.com
and then sends impersonation spam from alice.com. Its hardly convincing,
bob.com can see that alice.com is unavailable so the forged messages
from the spammer get treated as suspect.
Sure its bad that alice.com can't send mail when there is a DDos
on its dns. So what? DDoS extortion is already a problem, alice.com
is probably a bit more worried about the web site being out of service
during this period than the fact that the email is being queued.
The problem is not with a particular destination or spoofed source. The
problem is that the mail channel becomes clogged if checking SPF in
addition to unfortunate DNS servers being hammered. It could be the DNS
records are maniacally constructed with short TTLs and the DNS servers
engineered to be erratic. I suspect that as SPF becomes widely used,
neither of these efforts will be required to stage an attack however.
There is a real DDoS against DNS issue, this attack does not make it
any worse. If the problem is serious it should be addressed in its own
right.
That would be to not approve the SPF approach as being inherently prone
to abuse DNS and thereby clog mail servers? That would then be to not
approve SPF, as with its extensibility, it is inherently abusive to DNS
cache?
It isa quite easy to deal with for MARID, just keep the last valid result
from any site irrespective of the cache status and reuse that in the case of
a system being unavailable.
These results can be very large as compared to a typical DNS query. If
each MTA SPF record contained less than 2 indirections and resulted with
an average of 10 overall, this would then represent about 4K bytes of
records and perhaps 2 to 3 times this amount in cache. Seeing 80,000
sources per day could mean about 1 GB of DNS cache would be needed. If
the average number of indirections exceeded 2, then the number of
indirections would require some arbitrary restriction as to the depth
allowed. Presently this is set to 20. If so, just double these numbers
and reduce throughput even further. This would imply it becomes
critical the order records are queried and how loops are discovered. In
other words, SPF does not scale and DNS suffers as a result. : <
-Doug