Re: [Asrg] How will we manage IPv6 spam?

["Emanuele Balla (aka Skull)" <[e-mail]>]

On 8/17/12 10:22 PM, John R. Levine wrote:
> Hi.  Remember the ASRG?  I was hoping it might do a little research.
> 
> In talking to people about IPv6 mail, I'm still coming to the conclusion
> that anyone who thinks they know how they're going to handle it, beyond
> the current toy scale, doesn't understand the problem.  Things we might
> address include:
> 
> * Will DNSBLs that work like v4 BLs, with a query per IP, blow out DNS
> caches?  If so, can this be solved by hacks like partitioned caches that
> treat BL traffic separately?  Would something like my B-tree hack work
> better?

If this problem is going to raise, it's going to raise exactly the same
way with rDNS as well, so having v6 DNSBLs in place is going to make the
problem worse by just a factor related only with the number of DNSBLs in
place. 2x? 5x?

This is a small factor, compared to the size of the problem itself.

FWIW, the DNSBL case can be worked around using 0 as TTL for DNSBLs
(directly on the DNSBL side, or on the caching side for resolvers with
the ability to do that). This is going to increase the load to DNSBL
mirrors, but that would probably be much more easily worked with than
the cache blowout problem.


Another chance is to move part of the logic into the lookup tool and
make it query for the /64 network instead of the full address, and run
DNSBLs accordingly.

This would significantly reduce the size of the caching problem, but
would render listings much less granular and whiltelisting of single
hosts basically impossible...


> * Is there some reasonable way for networks to publish allocation
> granularity, e.g., this range is a /64 per user, that range is
> individual hosts?  If they can, how useful would it be to running BLs or
> otherwise making filtering decisions?

I already had the chance to tell you that, but RIPE DB provides an
"assignment-size" field with this explicit purpose:

inet6num:       2a02:09a8:FF00::/40
netname:        SPIN-IT-IPv6-SOHO-Trieste1
descr:          IPv6 SOHO residentials
country:        IT
admin-c:        AL6557-RIPE
tech-c:         SPIN3-RIPE
mnt-irt:        IRT-AS6734
status:         AGGREGATED-BY-LIR
assignment-size: 56
mnt-by:         AS6734-MNT
source:         RIPE # Filtered


IMHO encouraging a similar setup won't hurt.



> * Is there a practical way to do hard or soft whitelisting of V6 mail
> hosts?  (Hard: no body filtering, soft: with body filtering)

IMHO no real differences from IPv4 except those already cited above at
point 1.


> * Should large and small systems use the same filtering techniques? 
> Large systems have larger mail volume and so can build better models of
> incoming traffic, small systems can afford cruder filters like no mail
> from Korea

IMHO there's no real difference with IPv4 here.
Except that large systems will probably rely on local mirrors (and
sometimes on technologies that do not involve DNS at all) hence they'll
be less impacted by the caching problem: they can run everything with
TTL set to 0 without heavily impacting lookup latencies.
The same is not necessarily true for small systems.


> * Can we build models to predict this stuff now, since under the most
> optimistic scenario it'll still be years before the v6 mail volume
> approaches v4 mail volume.

DUNNO