Re: DNS Loading Comparison

At 10:16 AM 4/13/2005 -0700, Dave Crocker wrote:
> David MacQuigg wrote:
> >
> >  The CSV folks will insist on discussing the *worst case* for SPF, and that
> >  looks like maybe 100X more queries than CSV, but even with all those
> >  queries, the result is typically a few records for a sizable domain, so
> >  caching should still be effective.
>
> 1. Concerns about SPF are held by a rather larger body of folk than just the
> few of us who are developing CSV.  So, compartmentalizing such criticism to
> just the "CSV folks" might be comforting in the short-term but it serves only
> to trivialize informed, serious feedback, rather than use it to highlight
> issues that need attention.
I did not mean to imply that *only* CSV folks are criticizing SPF for 
vulnerability to DNS abuse.  The criticism is widespread, and I am 
disappointed that the SPF folks aren't taking it more seriously.  I am also 
disappointed that the CSV folks would only discuss the worst-case for SPF, 
and dismissed my attempt to compare the best case CSV with the best case 
SPF.  Best case is relevant, because I believe there are ways to encourage, 
and maybe even enforce, best-case SPF.
If I had to chose right now between SPF and CSV for a final standard, I 
would slightly favor CSV.  This is based on my current understanding of the 
DNS loading problem.  That understanding is incomplete, partly because it 
is difficult to get either side to drop the dogma and talk objectively 
about the potential for abuse.
My current understanding is that SPF can have as many as 100 queries per 
authentication, and as few as 0.001, depending on the effectiveness of the 
cached records.  CSV is a constant one query per authentication.  In the 
scenario at the start of this thread, one is still too many.
SPF has an opportunity to leap ahead of CSV on this issue, and respond in a 
very positive way to the legitimate criticism of its potential for DNS abuse.
> 2. The Internet is about scaling.  Predicting the future is always risky and
> it is particularly difficult for the Internet, since there is no way to
> guarantee the behavior of future, independent entities.  So Internet planning
> is about scaling.  To quote Paul Vixie: what happens if everyone on the
> Internet uses the mechanism?  What happens if the Internet is 10, or 100 or
> 1000 times larger?
I hate to think what would happen if we scaled up the current volume of 
spam by 1000X.  Yet I think that may be a side effect of efficient 
authentication.  Anyone who doesn't want spam will block those domains that 
send it.  They won't care that all the major backbone providers get 99% of 
their income from spammers.  The spammers will be free to buy as much 
capacity as they want, and that could easily be 1000X todays levels.
My spam filter was down for two hours yesterday, and in that two hours I 
got a dozen spams in my inbox.  Imagine the Internet of the future as a 
giant cooker filled with spam under high pressure, waiting for the smallest 
leak.  Two hours of downtime for your filter, and your disk is full.  It is 
this situation where I can see a problem for CSV.  Think of those 
150,000,000 DNS queries in my E2 scenario multiplied by 1000, and that is 
just one spam run.
> If valid use of a mechanism can bring down an Internet infrastructure
> mechanism -- even if the expectation is that is an unlikely use -- then folks
> should worry a great deal about the design of the mechanism.
Agree 100%.  The burden of proof is on those who say it can't happen.  If I 
see better than 1 in 10 chance that it might happen, I look for a solution.
By the way, the CSV website http://mipassoc.org/csv/CSV-Comparison.html has 
a good description of the DNS loading problem.  Previously, I had dismissed 
this problem as FUD, because most of the arguments against SPF seemed like 
hysterical rants.  Again, however, the comparison is only against 
worst-case SPF.
--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************     *