Re: SPF and IPv6 (was: Last Call: draft-klensin-rfc2821bis: Permitted an

On Jan 8, 2008, at 9:40 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > The http://dns.measurement-factory.com/surveys/200710.html show  
> > 12.6% of domains with name servers publish SPF records.
> "Percentage of domains" and "percentage of mails" (incl. spam) are  
> different.  Not all domains send mails (really or forged, I'm not  
> going to explain again why forging domains that can't receive mails  
> is likely not what the spammer wants).  The SPF deployment for  
> "relevant domains" (defined by Alexa) is good enough, see <http://utility.nokia.net/~lars/meter/spf.html 
> >
Agreed.  The distribution of SPF use is heavily biased toward larger  
domains.  However, this distribution should increase concerns  
pertaining to targeted DDoS permitted by SPF macro exploits, owing to  
the typical size of networks utilizing SPF. : (
> > When 4% of those then offer a possibility for FAIL, this represents  
> > less than half a percent of domains overall.
> It is likely better measured in "mails" instead of "domains".  If  
> folks dare not publish FAILing IPs their PASSing IPs are still  
> relevant.  After a PASS receivers can delay their spam analysis and  
> bounce later without causing backscatter.
This strategy still results in DSNs being dropped for a majority of  
the domains!  The size of a domain does not alter the importance of a  
DSN.  Even for those domains registering their IP address path, a  
significant portion of email is forwarded, where being off the  
registered path reduces the integrity of DSNs when SPF PASS represents  
an added requirement.
Alternatively, TPA-SSP represents a path independent, single  
transaction (by-name) means for ensuring DSNs are not dropped.  TPA- 
SSP avoids inducing a DDoS risk, and remains compliant with RFC 1123.
> > SPF does not use different record types to verify IPv6 or IPv4 SMTP  
> > client authorizations.
> SPF supports both IPv4 and IPv6 natively.  Its job is to match the  
> IP (IPv4 or IPv6) of an alleged sender (HELO or envelope sender)  
> against an enumeration of "permitted" or "forbidden" IPs to get a  
> PASS or FAIL result.
SPF combines everything into one response, without a specific initial  
record type, and without a means to segregate records sets for IPv4  
and IPv6 clients.  SPF's lack of resource record certitude means not  
finding TXT or type 99, or A or AAAA must be accommodated.
Even if a "no answer" or "no domain" limitation were to become  
specified as a recommended limitation for SPF parsing routines, the  
number of transactions occurring per cached SPF must still accommodate  
this protocol's inherent lack of record type specificity.  The number  
of transactions that can be induced by a cached SPF record remains  
critically relevant to a DDoS concern that results from an SPF macro  
related exploit.  Again, this exploit does not require an attacker to  
expend their resources.  Instead the attacker is able to leverage the  
resources of larger networks utilizing SPF. : (
> It's no rocket science to look at AAAA records when trying to match  
> an IPv6, or at A records for an IPv4, as far as a policy contains  
> any "by name" mechanisms.  For the two SPF "by address" mechanisms  
> matching IPs is straight forward.
While a routine parsing SPF records should know whether finding an  
IPv6 or IPv4 address is desired, SPF remains a exploitable mixed set.   
There is not any indication whether an MX mechanism host names  
resolves IPv4 or IPv6 addresses, or how SPF CIDR masks should be  
applied when a mixture of addresses is returned.  SPF did not  
considered how its macro feature could be exploited, or the impact of  
combining both IPv4 and IPv6 records into one sequence of SPF records.
-Doug