On Jun 17, 2009, at 7:59 AM, Steve Atkins wrote:
On Jun 16, 2009, at 4:17 PM, Daniel Feenberg wrote:
Because it would be impossible to maintain a DNSBL for IPV6,
I keep hearing people say this, but I've not seen any clear
justification for it. It seems to me to be no more difficult to run
a blacklist for IPv6 addresses than IPv4 addresses (neither is easy,
but the details of the address representation don't seem to make
more than minor differences).
Can you expand on why you think it's the case, or point me at some
discussion of it?
Factors that make managing an IPv6 block-listing service fairly
impractical go beyond 96 additional address bits. The term
impractical is used because, with enough money, anything is possible.
1) Publishing behavior based address lists require evidence collection
in the event of disputes, and this does not scale well. (expensive)
2) IPv6 to IPv4 and IPv6 to IPv6 NATs obfuscates who might be
involved. (problematic)
3) Reverse DNS scanning does not scale well. (slow)
4) Diverse and rapidly expanding address space allows bad-actor's
activity to stay ahead of the massive amounts of IP address related
information publishing. (futile)
5) An extremely low cost for IP addresses allows bad actors to persist
at sporadic use for many years. (futile)
The collection of evidence is often constrained by the related
identifier, such as the IP address. Unfortunately, IPv6 allows a new
IP address to be used for each message sent. Some countries already
place thousands of MTAs behind carrier grade NATs. Any scheme that
concludes the use or abuse of an IP address indicates which individual
originated a message makes it ill-equipped to deal with today's
evolving network environment. Block-listing must soon be replaced by
acceptance-listing. Things like CSV would permit a means to
consolidate the sources managed by acceptance-lists, where reputation
could be based upon MTA domains, rather than a vast array of IP
address or the domains controlled by their customers.
With email so heavily abused, attempting to acquire and process the
ten to two hundred SPF transactions per message is not possible at
today's magnitude of abuse per legitimate message. SPFs use of macros
and exists functions requires a process done in conjunction with
message acceptance, while at the same time placing DNS itself in
peril. Any strategy that attempts to place the customers of an email
provider responsible simply does not scale as an abuse deterrent.
Management efforts can be reduced a million fold when directly holding
the immediate outbound public MTA accountable, rather than attempting
to shift accountability toward one of a provider's many users, which
is the real (and admitted) motivation behind SPF/Sender-ID/A-R. This
Nast cartoon depicts the situation fairly well by changing the
question to asking who is responsible for email's dire situation and
having the men in the circle represent that of the providers.
http://en.wikipedia.org/wiki/File:Tammany_Ring,_Nast.jpg
Pushing responsibility to the edge does not work, and email provides
ample evidence. This nonsense is putting the Internet itself in peril.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
