ietf-asrg
[Top] [All Lists]

Re: [Asrg] please review draft-irtf-asrg-bcp-blacklists-07

2011-01-18 22:07:23
On 1/18/11 4:53 PM, Daniel Feenberg wrote:
In the rather critical matter, "2.2.1. Listings SHOULD Be Temporary", this makes a questionable assumption that listing/de-listing churn will not become damaging whenever expiration is used. Whether one is talking about v6 prefixes, or interface addresses, bad actors have access to virtually an endless supply of prefixes and interface addresses. This means an address may never repeat over a bad actor's life.

I am confused about why 2.2.1 is critical.
Back in October of 2008, it was apparent this group had strong expectation that DNSBL listings are to be fully automated with an emphasis on listing expiry. Unfortunately, automated listings make it easy for bad actors to determine spam trap locations, where expiry also permits routine reuse of an often large and diverse IP address space. Some spammers cycle targets into different geographic regions often served by different listing services as well.

The Introduction states:

,--
This document is not applicable to some DNSBLs in some areas (mentioned as 
appropriate) but it is the authors' belief that most of the practices are 
applicable to almost all DNSBLs.
'--

In addition, this draft describes a requirement to delineate listing criteria with auditing to be made available. It even suggests exclusion of information that might reveal the location of a spam trap. Any audit information reveals spam trap locations. There is now an increase level of abuse emitted by bulk senders that "wash" their lists of detected spam traps. :^(

The draft also wants disclosure whether a range of IP addresses might be listed that could include undetected addresses, and then describes such listings as a "mistake". It also makes _no_ reference to a boundary of such ranges not crossing those controlled by different Autonomous Systems (network providers). It also claims fast listing mechanisms benefit from very short expiration intervals. Once again, this wholly ignores problems related to the disclosure of the spam trap infrastructure.

This draft also claims that listings based upon longer time periods have higher error rates and states that responses to removal requests SHOULD occur within 2 days and MUST occur within 7 days. This draft also suggests that network operators should not be required to resolve abuse issues because this requires "impractical amounts of effort" and even recommends "no questions asked" removals. This draft further states that removals should be possible in absence of DNSBL Operators. This does not describe policies that are appropriate for IPv4, and certainly it would be wrong to suggest these policies might also be applied against IPv6.

The only reference to listings methods references rfc5782 which does not directly expose CIDRs used to make the listings.
Whether listings are temporary or permanent, an IPv6 DNSBL is totally impractical and probably worthless. I believe we agree there. There are lots of things that can't be successfully distributed over DNS, this is only one of them. I might favor singling it out on the grounds that there are a few people who want to try it, but I wonder why it is so necessary to do so, since circumstances will defeat them soon enough.
This nonsense serves as a distraction where valuable time is lost in getting ready for the use of IPv6.
Is there a special reason an IPv6 DNSBL which listed spam sources would interfere with legitimate traffic? Wouldn't it just get very large without actually ever blocking much traffic, legitimate or spam?
Yes. Standards organizations need to clearly state that IPv6 REQUIRES the use of domain name authentication as a basis for acceptance. Negative listings represent an impossibility, and positive listings will likely be problematic unless based upon cryptographically authenticated domain names.

-Doug




_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>