Subject: RE: Will SPF/Unified SPF/SenderID bring down the 'net?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 28 Jun 2004 13:36:53 -0700

> 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 vase
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.

> 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.

> I could see SPF causing some free DNS providers to go belly 
> up.  

I don't see how. 

> 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?

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.

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.

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.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jun 2004 15:53:34 -0700

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 
> Caller-Id required a single packet in each direction for the vast

Again, this was in regard to an attack scenario.  Assuming best case
does not provide meaningful analysis nor is DNS on par with NNTP.

> 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 

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.

> 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  

> 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.

> any worse. If the problem is serious it should be addressed in its own

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?

> 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

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 28 Jun 2004 16:32:27 -0700

On 6/28/04 1:36 PM, Hallam-Baker, Phillip sent forth electrons to convey:

> <>
> Caller-Id required a single packet in each direction for the vas[t]
> <snip>

Please watch your tone.
That's incorrect. Please read the earlier post to this thread at
http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html
as it argues that this is not the case.
I don't see you addressing the concerns Doug raised.
Perhaps you were arguing that all mail servers should rely on local 
caching DNS servers that will cache all the word's active LMAP records.
If that's the case, then *perhaps* that does present a strong DDoS 
defense.  Please confirm/flesh out.  Does it work in the face of 
malicious macro SPF records?

BTW, I wonder if it would make sense to specify that caching DNS servers 
MAY cache LMAP records for x hours, even if they have a short TTL.
This would reduce DDoS exposure.  At what cost, and what's a good x?  
Without this, it's appropriate to assume that the attackers will publish 
LMAP records with TTLs ~= 0.

MARID provides additional motivation for DDoS against the DNS.