ietf-mxcomp
[Top] [All Lists]

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

2004-06-29 02:50:08

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:matthew(_at_)elvey(_dot_)com]
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.