On 10/25/12 2:14 PM, Martijn Grooten wrote:
Anyway, back on topic: I'm still not convinced we'd be talking about
IPv6-based blacklists if we didn't have a long and successful history
of IPv4-based blacklists.
IP-blacklists work well on IPv4 because the IP-space is small enough
to keep the lists small and large enough so that different IPs really
mean different senders.
I haven't really seen a suggestion on how to run IPv6-based
blacklists that convinced me. (That's a rather unscientific claim, I
know. I'd love for people to help John with his simulation so that we
get a better idea; note that he doesn't need IPv6 data. I'm afraid I
don't have the required data myself.)
The point, IMHO, is that *nobody* has those data yet...
The number of available IPs will explode with IPv6. The number of
"legit" distinct emitters is (probably) not.
At the end, everything will be about how fast abusive/infected machines
will move around the address space:
1) from one IP to another inside their own /64
2) from one /64 to another
3) from one ISP to another, particularly where showshoe-like schemes are
in place
For point 1, there will be a limit to this change rate, at least when we
speak about bots, and it's even been cited here already: a single
machine can't use too many addresses without saturating its router
neighbor table.
Which is a valid esteem for the number of different IPs the
IPv6-address-change-mechanism will be able to use effectively, then?
Truth is we don't know for sure...
For point 2, then. The ability of a bot to move from a /64 to another
will depend on its ISP policies and implementation (like the ability of
a bot to change its IP in IPv4 depends mostly on how the ISP implemented
its dynamic allocation). Which is a valid esteem for that?
Again, we don't know for sure: too few examples for having consistent
statistics.
For number 3, the number of different allocations will only depend on
the number of different machines owned by the spammer, while there may
be no "neighbor limit" here, if the ISP did it right, so he/she could
make full use of the entire allocation.
But again, we lack a lot of statistics here as well...
So, at the moment, the only thing you can simulate is what we already
have in IPv4.
But the real IPv6 scenario will depend mostly on policies and
implementations that are not in place yet... :-\
Can't we do something entirely different for IPv6? Like, use
domain-based filtering by making it mandatory to DKIM-sign a message
you send over IPv6 outside of your network? As long as IPv4 and IPv6
are running in parallel it should be possible for IPv6 MTA to refuse
messages that aren't DKIM-signed - and tell the sender to retry over
IPv4.
Theoretically this could be an option, but DKIM requiring the receiving
end to receive the message DATA before choosing a policy may prove to be
a limit.
I know this isn't an ideal solution either (one weakness is that it
allows you to DDoS an MTA by sending large numbers of messages with
an invalid signature), but perhaps it's better than trying to make
IP-blacklists work over IPv6? Or perhaps someone can come with a
better X now that MTAs can still afford to tell IPv6-senders "do X or
retry over IPv4".
Could be. We just need to find out a good X then ;-)
My personal opinion, FWIW, is that the DNSxL mechanism will still be
useful in the future if we can limit the lookup to the first 64 bits
instead of the full address.
This reduces the problem to something comparable to the current state of
IPv4: it's true that default user allocations are larger than IPv4 ones
(say a /56, AKA 256 "listing units", instead of a single one like in
IPv4), but it's something we can still work with, probably...
It it true that there are (and there will be) entities out there
assigning stuff like a /112 per-user instead of a /64.
But maybe it's not too late to come out with "an X" trying to disallow
this setup for wannabe-mailservers...
--
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg