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


Doug just responded rather eloquently to this thread, I'll try my best.

On 6/28/04 10:06 PM, Greg Connor sent forth electrons to convey:

On Mon, 28 Jun 2004, Matthew Elvey wrote:
BLs have a single point of failure that is similar to the problem
of running core DNS, you take down one part of the network and in
time the rest of the net grinds to a halt.
You have failled to show that there is a dependency that looks anythinglike the dependency that a mail server has on a BL or on core DNS.
What part of "it makes them very resource intensive, so folks stop using'em" don't you understand?
I am going to agree with Phillip on this one. SPF queries don't go to acentral location, they go to the spammer's DNS server (or that of whoever thespammer is trying to impersonate. It sounds like the worst they could dowould be to make the receiving mail server really busy, stop their own mailfrom getting through, or pick on one or two other domains that have weaknameservers. I don't see a type of attack that erodes DNS in general foreverybody.

Again, the attacker's immediate goal is just to get folks to stop using SPF!

Furthermore, the spammer is exposing his own IP during the attackso he should be blocked quickly.

Huh? He's got a zombie army, and AGAIN, how do you identify the attackas an attack?

Here's the three paragraphs, with some editing by me.
I'm sorry if you don't understand them, but they are clear.
It has nothing to to with XML (which is dead, WRT MARID), at least now.

Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack.  ...  As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.

An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs.  The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel.  (If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn

also outsource for yet more chaining.)

For example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 10 queries with an average of 5 seconds a query,

then this limits each process to about 1 message about every minute.These 10 queries will also add to the traffic at 350 bytes per record a

total of 4K bytes of additional traffic for a doubling of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second.  This may still represent the same amount
of network traffic, just half as much mail gets through the network.

You cannot redefine the size of the emails the attacker sends to make the attack less effective.

This seems reasonably clear, but it doesn't identify a damaging attack. Isthe attacker trying to get his message through, or just trying to make troublefor the receiver?

The latter!!! Quoting myself:

What part of "it makes [SPF] very resource intensive, so folks stop using[SPF]" don't you understand?

We get a lot of spam (attempts anyway) from domains that don't resolve due totimeouts.

Sure, but I bet it's a small fraction.

That means the spammer is already causing resolvers to time out andmail servers to keep connections open for as long as it takes to time out.

That's generally one query to a possibly non-responding nameserver permessage, not < 20 or < infinity, .

So, if the main element of the theoretical attack is "lots of mail sent atonce and it makes the resolver do lots of queries that time out" -- I think wealready have the problem today and are dealing with it. (In several cases Ihave had to install DNS servers directly on the mail server box to keep itfrom bogging down our normal nameserver.)

You can deal with it being 100 x worse?

In other words, there are already a number of DNS queries being done permessage, and many of those time out. 5 more or even 20 more DNS queries areprobably not as harmful as, say, increasing the incoming smtp connections, orconsuming SMTP sockets with spoofed SYN packets or something.

Possibly. But these wouldn't achieve the attacker's goal. And only asmall fraction of these DNS queries time out.

Now, I think it's actually interesting to compare this type of attack scenariowith normal spam. Normal spam may be from a domain that doesn't resolveproperly, but if the result is a timeout (for spf or for just resolving theMAIL FROM and its MX) then you don't get to go on to the next step. If theDNS responds well enough to keep the connection alive, then the spam isaccepted (which consumes more bandwith than the DNS lookups) and sent toSpamAssassin (which consumes CPU, the steps before haven't relied on CPUmuch).
In other words, it is likely that taking a normal spam run and addingrecursive SPF queries that respond erratically and don't cache well, mightshift more load onto the resolver, but the more effective it is at weighingdown the resolver, the more likely the spam will get a 454 answer and not goon to DATA. In that case I get my bandwidth back and I get my CPU back, sothe impact is actually less than a normal spam run, approximately.

Well, you get your CPU back, but Doug is arguing that the bandwidth isspent on the SPF queries - ~4k/message.

But this is a valid point you make; there is the potential for some win.

Anyway, if the point of all this is "We should ensure that LMAP queries aren'tallowed to be chained more than X deep" or "We should test to make sure thatcomplicated SPF queries don't adversely affect the mail server or its dnsserver" I would agree with that. I wouldn't describe this as a new attackvector however... anything that starts with "Assume a large number of incomingSMTP connections..." ought to be familiar territory to any mail serveroperator :)

No. The second half of the sentence could be something they'recompletely unfamiliar with. In this case, it may well be.