How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

Fri Oct 2 18:31:02 UTC 2015

> On Oct 1, 2015, at 20:58 , Rob McEwen <rob at invaluement.com> wrote:
> 
> On 10/1/2015 11:44 PM, Mark Andrews wrote:
>> IPv6 really isn't much different to IPv4.  You use sites /48's
>> rather than addresses /32's (which are effectively sites).  ISP's
>> still need to justify their address space allocations to RIR's so
>> their isn't infinite numbers of sites that a spammer can get.
> 
> A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster assigns various /64s to DIFFERENT customers of theirs... that is a lot of collateral damage that would be caused by listing at the /48 level, should just one customer be a bad-apple spammer, or just one legit customer have a compromised system one day.
> 
> Conversely, if a more blackhat ESP did this, but it was unclear that this was a blackhat sender until much later.. then LOTS of spam would get a "free pass" as individual /64s were blacklisted AFTER-THE-FACT, with the spammy ESP still having LOTS of /64s to spare.. remember, they started with 65 THOUSAND /64 blocks for that one /48 allocation (Sure, it would eventually become clear that the whole /48 should be blacklisted).

It seems to me that treating this as a binary all-or-nothing approach isn’t particularly useful.

What about a system where each /48 and each /32 maintained a “content score”.

Treat /64s as you currently treat /32s (or even /24s) in IPv4.

For every hour that elapsed without sending spam, the score would decrement by one.
For each unblocked spam transmitted from within the block, the score would increment by one. (IOW, new spam from an already blocked /64 won’t increment the counter).

If the score for a /48 reaches 16, block the /48 and put the /48 into the block timer mode.
If the score for a /32 reaches 64, block the /32 and put the /32 into the block timer mode.

Block timer mode: In block timer mode, look for 24 consecutive hours with an allowable outbound spam send rate, then unblock.

Allowable outbound spam rate could be anything >0 and would probably require some tuning. For a /32, I’d say up to 256 messages per day or maybe even 1024 is probably within reason. For a /48, probably more like 16/day.

> other gray-hat situations between these two extremes can be even more frustrating because you then have the same "free passes" that the blackhat ESP gets... but you can't list the whole /48 without too much collateral damage.

In the proposal above, to achieve a score of 16, you have to have 16 different /64s from within your /48 sending bad stuff. Sure, you get a little bit of a free pass until the spammer cycles through 16 blocks of addresses, but not much because each of those blocks gets shut down fairly quickly. If a site has 16 independent /64s compromised or spamming, then the collateral damage really isn’t that heavy and for legitimate sites it should serve as reasonable motivation to clean things up. For the spammers, they’re going to need a new /48 pretty quickly and that’s going to be hard to explain to their service provider. Especially since that new /48 won’t last long, either.

For the /32, yes, we’re talking about lots of collateral damage. Maybe 64 is too low of a threshold, maybe it should be 256 or even higher, but this can be tuned. The point is shut down the individual nets quickly at the /64 level to minimize collateral damage, but when “enough” /64s within a block are shown to be offensive, consider the entire block offensive and move on.

> SUMMARY: So even if you moved into blocking at the /64 level, the spammers have STILL gained an order of magnitudes advantage over the IPv4 world.... any way you slice it. And blocking at the /48 level WOULD cause too much collateral damage if don't indiscriminately.

I’m not convinced of this. A /48 should be a single end-site. As such, any ISP that suffers significant collateral damage from having /48s blocked isn’t allocating addresses according to best operating practices. They can easily fix this. Every RIR allows end-site assignments at /48 with no questions asked.

> And this is assuming that individual IPs are NEVER assigned individually (or in smaller-than-/64-allocations) . (maybe that is a safe assumption? I don't know? regardless, even if that were a safe assumption, the spammers STILL have gained a massive advantage)

It’s not a completely safe assumption, but it’s safe enough.

Owen