[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Leinweber, James]

Fernando Gont:
>  We have uploaded the slides ...
Nice presentation; thanks for sharing.

>Many expect a transition to IPv6 will not occur soon.

And many would be wrong, though it's been 13 years in the making.
Rapid growth of the internet in the face of native v6 being better +
faster + cheaper than carrier NAT is going to change that.  IPv4
exhaustion matters.

On the IPSEC front, it might be worth pointing out that the
interesting  security issues such as rampant endpoint insecurity
regardless of network protocol, immature v6 protocol stacks, and lack
of v6 feature parity have nothing to do with IPSEC.  Meanwhile, if
those living in a Windows monoculture who find "direct access" VPN's
helpful might actually lead to a handful of IPSEC deployments.

In addition to the point that dual-stack hosts create v6
vulnerabilities in supposedly v4-only networks, it might
be worth emphasizing a few more of the implications of
living in a dual-stack world, such as:
  
  * Carrier-grade / Large scale NAT devices mean that v4 forensics
    has to change: you can't track an attacker based on IP address
    unless you also know the timestamp, protocol, and port numbers.
  
  * v6-mostly web sites aren't yet usually v6-only, so you need dual-
    stacked packet traces to see what clients actually pulled down.

  * The plethora of protocols and addresses (v4, v6; link-scope,
    global-scope; unicast, multicast) in simultaneous use means
    network forensics will have to be based on port-snooping.

Jim Small:
> ... RDNSS ... likely ... will be ... in WIndows 8

Anyone willing to bet against "happy eyeballs" (race parallel v6 and
v4, deliver the winner) also being in windows 8, given that Google
Chrome, Firefox, and OS-X 10.7 already have it?  I've been pleasantly
surprised by how fast it's deploying.

> ...  Those who think that IPv6 is years away [are] in for a rude
> awakening shortly.

Amen, brother.

Add AT&T U-verse customers to the list of those about to get IPv6 in
the US, too. World IPv6 day in France saw 3% v6 traffic on the
backbone; French ISP's have been earlier than most in completing v6
rollouts.  Sadly, my own ISP is dragging its feet; happily, my
employer already offers a dual-stacked VPN service.

As near as I can tell, if you have Asian customers, Asian supply
chains, mobile customers, or you are an IT supplier to major
governments, you should already have IPv6 rolled out.  Assuming
current growth rates, about 15% of the internet is likely to be v6-
only in 2013.   Consumer preference is liable to flip as soon as
December 2014, if some hot v6-only electronic toy comes out of a
pacific rim country in time for the holiday shopping season.  99% of
IP traffic could be v6 in 2017; Cisco reported that at Interop and
Cisco Live conferences this summer with a dual-stack native
environment and the current client mix 60% of traffic flipped to v6.
IPv4 backbone routing is likely to turn off in 2020 - and this is
already predicted in AT&T's roadmap.  There was no economic incentive
to start rolling out v6, but there is a very strong incentive to stop
routing v4. What does going v6-only save you on DFZ router load,
maybe 50% on memory and 95% on CPU?  We're seeing about a 7:1 ratio
between v4 routes and v6 routes currently out of the minority of
dual-stacked autonomous systems, right?

Meanwhile, transition plan A (dual stack "heavy") foundered on lack
of IPv4 address space, and plan B (dual stack lite) seems to be
ignored in favor of plan C: v6-only with NAT64/DNS64 converters to
the legacy v4 internet. Plan C is where the University of Wisconsin
expects to end up once it runs out of v4, probably in 2013.  I think
NAT64 is winning because for cell phones it's cheaper to be mono-
stack than dual stack, and for ISP's NAT64 keeps less state than
NAT44, and so scales better.  Phone companies and ISP's won't care
that v6-only customers have lousy experiences at v4-only web sites;
all the *big* sites in the US like google, bing, xbox, yahoo, facebook,
cnn,
youtube, netflix, etc. are already dual-stacked, or nearly ready.
Most peer to peer stuff clients and some gaming clients are already
dual-stacked. I know companies with advanced v6 rollout plans who
confidently expect that being early movers is about to yield them
competitive advantages.

I figure the dual-internet interregnum (the period where some people
don't have v4 and others don't have v6) runs 2009-2015.  Even if the
last v4 device isn't likely to disappear until 2036 or so, in 2016
pretty much everyone who wants v6 should be able to have it.

The analogy I'm using to explain v4 -> v6 to end users in the US is
that it's like the transition from analog TV to digital TV: new gear
(broadband modems, wifi routers) all around to get mostly the same
content.  Given the narrow product range and immaturity of
implementations, especially for DSL modems, I'm telling my fellow
Americans not to replace such gear till 2013, unless they like to
be on the bleeding edge.

v4 and v6 are both packet switched networks with best effort delivery
and next hop routing, so the threat models are basically identical.
The key security differences seem to me to be in areas like:

  1) Big v6 address space means reputation lists will have to based
     on blacklisting prefixes or whitelisting hosts; merely
     blacklisting hosts is not going to cut it. So don't v6-enable
     your mail server yet (do enable DNS and Web, obviously).

  2) Extend your wired layer 2/3 defenses beyond DHCPv4 spoof
     prevention to DHCPv6 and RA spoof prevention. RA's existed in
     ICMPv4, but no one ever used them. On Cisco switches this week I
     think I like parallel v4 and v6 ACL's on the ports for this.
     What are other people using?

  3) Block tunnels at your firewalls.  If you have native v6 you
     don't want them, and if you don't have v6 you probably aren't
     ready to cope with them.  In any case your network monitoring
     probably can't inspect tunnels effectively, even if your
     security infrastructure is dual stacked - which it should
     already be.  Forbidding protocol 41 and port 3544/udp is a very
     good start on this.
     
-- Jim Leinweber
State Laboratory of Hygiene, University of Wisconsin - Madison
<jim.leinweber at slh.wisc.edu>       phone +1 608 221 6281
PGP fp: D573 AF7D F484 EE2A F0B6  B7DB A870 7518 F87D A0D1