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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Jun 2004 02:50:05 -0700

Since you simply keep repeating the same original statement and make no
attempt to clarify it I have to beleive that you do not intend to make your
point clearly.

I think I made it plain enough that there is no need to distinguish attacks
as malicious, any machine that issues a ridiculous record will be ignored,
code should be written to tolerate malformed spf records.

If a mail server gets 50 messages a second from the same ip address and they
are malicious it should block the ip address. 

A zombie machine rents at about a dollar a month on the black market. It is
not reasonable to hypothecate attacks which cost $10 a second (assume bot is
detected after 5 attempts). I for one would be very happy if the spammers
would act in ways that tell us with certainty the location of their bots.

If there is a problem with the spf macro language chuck it out. 

If there is no problem, but no use case either, chuck it out.

 -----Original Message-----
From: 	Matthew Elvey [mailto:[email-masked]]
Sent:	Mon Jun 28 20:57:54 2004
To:	Hallam-Baker, Phillip
Cc:	Douglas Otis; 'IETF MARID WG'
Subject:	Re: Will SPF/Unified SPF/SenderID bring down the 'net?

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

> <unparseable>
>
>  
>
>>>If malicious.com or compromised.com have a malicious record in
>>>their DNS it should become apparent quite quickly.
>>> 
>>>
>>>      
>>>
>>I don't see how.  Say 9/10s of a domain's record resolves. 
>>How is this 
>>domain identifiable as malicious?
>>Maybe it's just under attack.
>>    
>>
>
>If it is under attack then it probably should be ignored until
>it recovers. All the mail 'from' that source is most likely spam
>anyway.
>
>  
>
Again, how is this domain identifiable as malicious?  Many of your 
points are predicated on having this ability.

>  
>
>>>Also remember that the sender has to be holding an open TCP
>>>session during this process with a known source IP port. This
>>>is not exactly an anonymous attack.
>>>
>>>      
>>>
>>Again, how is a malicious actor identified automatically?
>>    
>>
>
>By logging the IP address of the source of the attack.
>  
>
Sorry, but what attack?  You have to identify the attack as an attack 
first; see above.

>
>  
>
>>>The argument makes no sense unless you can state which part of the
>>>DNS is going to be attacked and how such an attack would make it
>>>easier to send spam.
>>> 
>>>      
>>>
>>Same way taking down BLs works.  It makes 'em problematic (e.g 
>>unreliable and/or very resource intensive), so folks stop using 'em.
>>    
>>
>
>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 anything 
>like 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?

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.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Jun 2004 12:50:34 -0700

I am not going to play hunt the attack here. Each time I answer one set of
questions you redefine your position. Then you claim that your changed
position is unchanged and that it is my fault for misinterpreting the
original palimcest.

If you have 80k bots youcan cause real pain for pretty much any internet
site you choose. But the proposed attack is not the way to do it.

Clearly branching is not good if it is unbounded. It is not the branch ratio
that is the issue though it is the maximal permitted stack depth.

 -----Original Message-----
From: 	Douglas Otis [mailto:[email-masked]]
Sent:	Tue Jun 29 10:08:16 2004
To:	Hallam-Baker, Phillip
Cc:	'Matthew Elvey'; 'IETF MARID WG'
Subject:	RE: Will SPF/Unified SPF/SenderID bring down the 'net?

On Tue, 2004-06-29 at 03:53, Hallam-Baker, Phillip wrote:
> 80,000 spambots? Possible yes. Easy no way.
> 
> At 50 attacks a second this attack has revealled the ip addresses of the
> entire cluster in half an hour.

How? You make this assertion but provide no methods as to how these
machines are to be identified.  The attack would not exist without also
legitimate machines also making requests.  How do you go about
separating the wheat from the chaff? 

> It would be much easier to simply ddos the recipients public dns and make
> them unreachable. That would require far fewer bots and would not require
> the bots to use tcp and thus reveal their location. I doubt that many dns
> servers outside core dns can survive a ddos atack from a hundred or so
> broadband bots.

That is not the purpose of the attack however.

> Even under these assumptons the attacker can only ddos 800 sites at once
> with this cluster.
> 
> More machines will be offline for non attack reasons.  

Is this your way of saying it does not matter?

<snip>
> > So a DDoS attack on your own ability to send email. this can
> > be addressed by a security consideration. If you have to resolve
> > more than X records then consider the data spurious and reject
> > the mail.

Let me ask this again regarding the number of record indirections.  Do
you see a problem if there are on average 1.1 record indirections?  How
about 1.6,  2.1?  With these average indirections, what is the recursion
limits to resolve a permitted transversal path?  What algorithm defines
loop detection, tree pruning, etc?  What is the result if the tree is
pruned?

> Exactly.  The goal would be to slow reception and thereby allow greater
> distribution to a larger array of servers.  What is this limit?  What is
> the average number of references to other domains?
<snip>

-Doug