Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

On Nov 10, 2008, at 7:18 AM, Keith Moore wrote:

> John Levine wrote:
>
> > As I said a few messages up in this string, although the structure  
> > of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs  
> > aren't that mature yet and one of my goals was to make them  
> > interoperate equally well so, for example, if you find you're using  
> > cruddy ones you can easily switch to better ones.
> I suspect it will be very difficult to make IPv6 DNSxLs work  
> anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly  
> easy to use a different address for every SMTP conversation.
Agreed.   One might hope that the future will use DKIM domains and "on- 
behalf-of" tuples as an alternative to that of an IP address blocking  
list.  Ideally, the "on-behalf-of" would be an opaque value assigned  
by the provider, that is changed whenever a problem is corrected.   
This would eliminate the need for coordination between those that run  
reputation services and the senders.  Those that abuse this freedom  
would be at risk of finding their entire domain blocked instead.  The  
problem that needs solved is how to block compromised systems, more  
than blocking individuals.  Frankly, it would be best not to have any  
personably identifiable values used.
Unfortunately, being able to detect misbehavior at a sufficient level  
to safely conclude whether an outbound MTA is poorly managed requires  
rather extensive infrastructure. This infrastructure is often several  
times larger than the typical infrastructure of a client being  
protected.  These services address the problem of scaling email  
defenses.  Assessments are fairly difficult when the MTA being judged  
has little volume, since even an occasional misidentification of NDN  
as spam might create a profile fairly similar to those created by bot- 
nets.  Bot-nets represent a sizable portion of today's spam sources.
IMHO, the goal of the black-hole list should be to inform ISPs and  
have them remove bad actors from their network and hopefully to  
encourage them to better monitor their own traffic.  ISPs will not  
agree with this.  Even the largest decoy infrastructure sees only a  
tiny fraction of the overall traffic.  A desire to rapidly block any  
IP address that appears to be actively spamming provides bad actors a  
simple way to locate decoys and render the system less effective.   
While there are ways to deal with this problem, it both increases the  
infrastructure required, and the duration of a listing applied to  
problematic addresses.
While there may be some concern that DNSxLs use A records as a flag,  
normally these records are limited to an address range of  
127.255.255.255 - 127.0.0.2 (only  23 bits worth of data).  It seems  
unlikely that the use of these IP addresses will lead to any problem.   
The reason for suggesting that the document be published as  
Informational has to do with there not being _any_ real experience yet  
in attempting to block IPv6 addresses.  Routers will only be handling  
a faction of the total IP address space that IPv6 makes available.  
IPv6 DNSxL entries will not represent the same number of routes  
managed by routers.  This would suggest that entire networks are to be  
blocked whenever a significant level of abuse is detected that  
warrants blocking.  This would be a rather bunt tool.
There are a few points that this draft attempts to answer in a  
reasonable way.  The software used by the DNS servers is not going to  
change to support the IPv6 address space.  The servers will continue  
in the same fashion as before.  Instead of a query address of  
127.0.0.2, this draft suggest the value ::FFFF:7F00:2 to test the  
existence of the list.  Until there is some greater experience in  
handling IPv6 address space, do not get ahead of the problem by  
concluding how this service is to resolve the practical challenges  
ahead.  When a network handles a mixture of legitimate and abusive  
traffic, it may be impossible to cope with the volume of tracking data  
that will be required.
After all, evidence MUST BE retained for everything blocked to squelch  
erroneous customer complaints and the occasional law suit threat.   
While SANs are getting bigger, to scale these systems for tracking  
addresses within an IPv6 network is unlikely to be economically all  
that practical.  This might be wrong, but it should be less expensive  
for reputation services to use DKIM domains and an opaque "on-behalf- 
of" value instead.  DKIM would also create less danger with respect to  
collateral blocking.  MTAs may need to be equipped with crypto  
hardware to deal with foo signature abuse.  At least MTAs should be  
able to rate limit any IP address sending foo signatures.
-Doug




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf