[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Jim Small]

James,

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.
[JRS>] The problem I see with IPsec, especially remote access or "endpoint" IPsec is key management/distribution.  PKI is sufficiently difficult to scare off many.  Furthermore since it is poorly understood many think the sky is falling after the Dutch CA was compromised, apparently few understand the idea of revocation - but that's another story.  Outside of PKI, I don't know of any great way to distribute and manage keys.  This is what seems to limit its usefulness.  There are actually some other problems yet to be solved but this seems the biggest.

Meanwhile, if those living in a Windows monoculture who find "direct access" VPN's
helpful might actually lead to a handful of IPSEC deployments.
[JRS>] What I find interesting about DirectAccess is that it requires IPv6.  I have spoken with many who insist it doesn't only to discover they are running 6to4 at the edge and ISATAP internally, but that's not IPv6 right?  :-)

Meanwhile, transition plan A (dual stack "heavy") foundered on lack
of IPv4 address space,
[JRS>] I think for enterprises and most organizations dual stack will be the approach, but I don't disagree with your comments.

 and plan B (dual stack lite) seems to be
[JRS>] I think some carriers are doing this.  This one is less clear to me, I think we'll see a lot more detail on the underlying infrastructure next year.

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. 
[JRS>] NAT64 is great for http and applications that don't require "fixups."  However, for anything like FTP/SIP/H.323/RTSP/etc... it won't work or will require the NAT64 vendor to develop fixups.  It's like we're back in the mid to late Ninetys with NAT44.

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.
[JRS>] Agreed - T-Mobile is going this way and for cellular/mobile providers it makes perfect sense.

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.
[JRS>] By phone companies I'm assuming you mean DSL providers?  I guess in this space I'm not sure but this sounds like a reasonable theory.

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.
[JRS>] It's refreshing to hear that some really get it.

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.
[JRS>] I guess the first big question is when does IPv4 get retired from the Internet.  Conservative estimates are 2020.  Mr. Huston would predict earlier and he has some compelling information.  Since it will start to seriously ramp up next year, perhaps 2017???

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.
[JRS>] Agreed, consumer CPEs are still an issue.

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).
[JRS>] This one is tricky - I'm not sure blacklisting will work.  I'm not sure whitelisting is scalable, from what I have seen it seems to only work in tightly controlled environments which are typically not too large.

  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?
[JRS>] I know DHCPv6 snooping is coming.  Fernando has some great papers explaining the shortcomings of RA guard - hopefully this will be fixed to deal with fragmentation/extension headers.  I believe the ACLs can be bypassed by fragmentation - again, Fernando's papers explain this is excellent detail.

  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.
[JRS>] Agreed but many of these are dynamic so you'll need some kind of IPS/DPI to deal with dynamic tunnels.

I especially like your statistics on IPv6 ramp up on the Internet - possible to share how you developed those?
  --Jim