On 12/30/2010 9:13 AM, John Levine wrote:
Hi. I hear there's been some interest in my IPv6 DNSBL proposal. My
goal is that since there are (close enough to) no v6 BLs or WLs yet,
this is the time to switch to a query design that will scale. The
design I put in RFC 5782 isn't it, unfortunately, nor is anything
similar to it.
We'll have to change our software to handle v6 lookups no matter what,
so I don't see it as a big deal whether it's a small change or a
slightly larger change.
Thus, we can safely make the assumption that any mailserver is going
to follow the model of a single host per /64. ...
This strikes me as a poor idea for two reasons: it's probably not
true, and even if it is, it won't help.
The IPv6 address space is big. Very, very big. Even if you chop it
in half to /64s, it is still four billion times bigger than the v4
address space. Bad guys hopping around /64s will blow out your DNS
cache just as badly as hopping around /128s.
No, since the number of total host numbers in a /64 is vastly larger
than in a /128, if you hold to single number queries then it will blow
it out far far faster.
This is why I said SA needs to be modified to treat a single hit in a
/64 as the entire /64 is contaminated, and cease further queries on
numbers in that /64.
And at this point I
would not want to assume there is only one host per /64, or that a
/64 will contain all good hosts or all bad hosts, since there will
doubtless be cases where that's not true.
Well for starters it almost sounds to me like your not that
familiar with IPv6 to even say this. The lower 64 bits of
the address is the interface identifier, and the upper 64 bits
is the sub-network prefix. It is extremely abnormal for a host
to change it's MAC address every few milliseconds, so the idea
that a spammer could cycle through the lower /64 using 1 address
per message is in the realm of extreme improbability.
In my opinion you are arguing from a paradigm of the "politics of
scarcity" used in IPv4.
Having more potential numbers does not mean that the number of
spammers will magically increase. There will be the same number
of spammers as there have always been. The only reason to run
around saying the sky is falling is if your coming at this from
the point of view that it would be a normal thing to see
packets from the same /64 that have many different interface
identifiers, which there is no logical need for this to ever happen.
If you've read my proposal (if you haven't, please stop, visit
http://tools.ietf.org/html/draft-levine-iprangepub-01 and read it,
then come back) you'll see that maintaining a BL/WL is fairly
complicated, but the lookups are quite simple. Each lookup involves
about five DNS queries, but the design makes it very likely that most
if not all of the answers will already be in the local cache, since
the queries all start from the top of the same tree.
It also ensures that if you do a bunch of lookups to addresses that
are near each other, they'll probably all do the same queries, so
all after the first will be cached.
Another way to look at it is the size of zone: since each DNS record
holds 40 entries, the number of records is no more than 1/40th of the
size of a record-per-entry design. In the common case that entries
span a range of addresses, the number of entries will be even less, a
lot less. (Note that rbldnsd synthesizes records on the fly, so that
as far as a client can tell, even if the server knows something is a
/16, the client sees 64K different records.) And finally, in this
design, the client only looks for records that exist, so there should
be no negative entries in the cache at all. This tells me that this
would have performed better even for short 32 bit addresses.
I've given it a fair amount of thought, and I think I have gone
through all of the same band-aids everyone else is thinking of, e.g.,
truncate everything to 64 bits, do some sort of probe to find out the
granularity of a range, and they don't work.
wrong. You are just enamored with the idea of over engineering this
new paradigm you have dreamed up rather than seriously looking at
the rather easy and simple assumptions that can be made to make
the existing paradigm work with IPv6.
There is no reason that treating a /64 in IPv6 will not work the
same as treating a /32 works in IPv4.
When you consider the
length of the addresses, the number of queries, and the cache
behavior,
that is hand-waving.
I'm pretty sure this design is vastly better than anything
based on the traditional design, and is not an unreasonable amount of
work for clients.
You have started with the assumption that the existing design is
fundamentally flawed and that ANY new replacement design is going to be
better no matter how half-baked it is.
You would be better off starting with the assumption that the
existing design is fine, but that it needs adjusting for the new
circumstances for IPv6. Why don't you write an RFC that simply
says that with spam blacklists, a single positive response in a
/64 for a blacklist shall consider the entire /64 contaminated and
that the blacklist client shall not make further queries for IP's
in that /64 for a period of 24 hours and see how that flies? Then
if nobody likes it you can introduce this binary tree idea of yours.
Oh yeah, I know, because doing the simple and obvious fix doesn't
bring fame and fortune to the published, now does it?
I don't think it's perfect, and I'd be delighted to get suggestions,
but please don't start by assuming that spammers won't be maximally
hostile, or that managers will always configure their networks the
way you'd prefer.
If managers do not adhere to the principle that a /64 is assigned to
the same places they would assign a /32 to in IPv4, then IPv6 is going
to have a whole hell of a lot more problems than spam blacklists.
Ted
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
