spf-discuss
[Top] [All Lists]

RE: What else to go into the pot?

2004-07-08 15:31:05
Wayne wrote:

<snip>


All in all, I don't like position dependant modifiers very much.


I understand your reticence to use this, and your issues with the
Language used to "parse" the record but all in all I feel it beats the
"v=spf2" argument, and it satisfies the "reduce the DNS query"
folks.

In your implementation, do you not scan the SPF policy left to right
to extract the modifiers & mechanisms? Surely if you did this, it should
be fairly simple to keep a "current scope" modified that you apply to
each mechanism as you insert it into your data set.

6.2 Processing Limits
  
  During process, and SPF client may perform DNS lookups and
  additional SPF subqueries due to the "include" mechanism and the
  "redirect" modifier.

  In order to prevent Denial-of-Service attacks, the total DNS
  lookups must be limited.  The subject of a Denial-of-Service attack
  can be either the SPF client directly, or some third party domain
  that is referenced in the SPF record.  For example, a malicious
  person could create an SPF record with many references to a victim
  domain, send many emails to different SPF clients and the SPF
  clients would create a DoS attack.  In effect, the SPF clients are
  being used to amplify the attacker's bandwidth by using few bytes
  to send the email than is generated by the DNS queries.

  As a result, limits that may seem reasonable for an individual mail
  server can still allow an unreasonable amount of bandwidth
  amplification.  Therefore the processing limits need to be quite
  small. 

  SPF implementations MUST limit the number of mechanisms that do DNS
  lookups to at most 20.  For example, the "mx" mechanism requires a
  DNS lookup, so will count against this limit, while the "ip4"
  mechanism does not require any DNS lookups.

I've costed out the mechanisms in "rough" terms since my implemenation
optimizes the policy during load to reduce the number of DNS lookups
for a "match". It does this by re-ordering the mechanisms such that ip4
are processed first, then "a" then "mx" etc. (Don't panic this passes
all the tests, and the optimization is only done in mechanism clusters
that share the same prefix so that a -ip4:1.2.3.4/32 followed by 
+ip4:1.2.3.0/24 still retains it's specific IP rejection characteristic.



  When evaluating the "mx" mechanism, there MUST be a limit of no
  more than 20 mail looked up and checked for matching IP addresses.

And "a" mechanisms ?


  When evaluating the "ptr" mechanism or the %{p} macro variable,
  there MUST be a limit of at most 10 PTR DNS records looked up and
  checked for a validated hostname.

  SPF implementation SHOULD limit the total amount of data obtained
  form the DNS queries.  For example, when DNS over TCP is available,
  there may need to be an explicit limit to how much data will be
  accepted to prevent excessive bandwidth usage or memory usage.

I'd worry that this can't be realistically achieved in some implementations. 
(Like mine for instance :-) There is no way to tell the DnsQuery API what is
an acceptable quantity of data). Also, what value would you set here? 

I'd prefer to only use UDP and accept the truncated response and then 
return "unknown" if it were truncated. Wouldn't this alleviate the 
problem you are trying to solve here?


  MTAs or other processors MAY also impose a limit on the maximum
  amount of elapsed time to perform an authentication.  Such a limit
  SHOULD allow at least 20 seconds.  If such a limit is exceeded, the
  result of authentication SHOULD be "error".

Seth recons this should be user configurable and I kind of agree since 
the other limits are hard limits placed by the publisher of the policy
and there should be ways to check that it functions, but if you are on
the end of a slow link and keep getting timeouts, you might need to
have a local increase in this time. 


These limits are based on my attempts to actually try and 
create a DoS attack via SPF.  It turned out that my gut feel 
for the limits were smaller than they needed to be, but I 
don't think they can be much larger than what I quote above.


This is good work and exactly what is needed. I've spent a good deal
of time working on DoS & DDoS prevention using your hints and tips - Thanks!

-Gary