Sky blocks Newzbin, important legal and technical questions need answering

[Ian Batten]

Roland writes:
> Of course, if the website were available on ipv6 this would be a non-discussion, as re-use is extremely unlikely.
> 
> ps I wonder if Cleanfeed etc are ipv6 enabled yet?

Several pieces of entertainment spring to mind.

Firstly, as of today, there are very few residential and SME customers within the reach of UK courts who have "native" IPv6.   There are a larger, but still small, set of people who have IPv6 via a tunnel broker.  Were Newsbin to set up shop on IPv6, blocking access would involve not only blocking IPv6, but also doing DPI into tunnel traffic to block tunnelled IPv6.  I can imagine that being redolent with legal problems, because the tunnel broker, to whom the traffic is addresses at the IPv4 layer, is not a party to the action and is almost certainly not a UK company.   If one of the tunnel brokers fancied a ruck, they could then offer IPSec, stand back, and watch the fun.

Secondly, imagine for the sake of argument someone plans to run an IPv6 hosting service (I'm sure they exist, but I've not seen one yet).  The standard allocation for an IPv6 residential or small business customer is a /64, because 2^64 IP addresses is enough for most households and you only need a larger allocation if you're planning to run multiple networks.  But that's not because anyone expects home users to user 2^64 addresses, it's just that it's a good fit with with EUI64 auto-configuration [1].   But there are some privacy concerns about that, and randomly generating IPv6 addresses is perfectly legitimate too [2].  However, there's no reason for a small hosting company to allocate each customer a /64, and equally there's nothing in the standards stopping an IPv6 endpoint changing its address very quickly.  There's a proposal using this designed to make DoS attacks on VPN servers difficult [3]

So if I'm told by my hosting provider to "sit in that /64 and play nicely with the other children", I've got a lot of options, none of them nice for the blocking systems.  I can change my IPv6 address every minute and rely on the DNS to keep up.  If a client connects, I keep that address on the interface (but not in the DNS) until the connection completes.  That requires the blocker to continuously poll my DNS, and it wouldn't be hard for me to escalate that arms race by blocking requests from any client that queries too frequently.

But more entertainingly, and ob.crypto, I can share with all my friends a key, and then generate IPv6 addresses by taking that key, combining it with the time and using 64 bits of that as my IPv6 address (with the same caveat as above about keeping in-use addresses live).  Given time-sync +/- 20ms is hardly difficult today, I could flux my IPv6 addresses every few hundred milliseconds, provided I keep a window of n+1, n and n-1 in use.  .  Occasionally I'll collide with someone else in the data centre, but assuming there are a million other customers (which is unlikely) and I switch my address every 100ms I will collide with one of them once in fifty thousand years, which seems a reasonable interval of time to tolerate 100ms's traffic loss.  The blocker then has to block and cleanfeed-proxy the entire /64 which, assuming there's at least one co-lo customer in the same /64 using https, is going to be massively disruptive.

The requirement to keep old addresses that have active clients on them in user can be removed by a bit of outbound NAT on the clients which is hardly difficult to sketch out, and of course the same module can flux the outbound address from the client at the same rate (although only within the client's /64, of course).  Frequency-agile IPv6 communications, with blocking entire /64s the only option for the blocker.  Fun for all the family.

ian



[1] put your 64 bit prefix in the top 64 bits, put a simple transformation of your MAC address in the bottom 64 bits then do some magic if by some ill-chance you've got duplicate MAC addresses on your home network. 

[2]  take the 64 bit prefix, then generate the next 64 bits (ish) randomly, and then try against if by some incredible ill-chance you collide with someone else (that's a grotesque simplification of RFC4941).

[3] http://vtip.org/availableTech/technology.php?id=418423