[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Cameron Byrne]

On Sep 23, 2011 11:24 AM, "Jim Small" <jim.small at cdw.com> wrote:
>
> 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 have not had any troubles in this area.  I asked my nat64 vendor to
support ftp and rtsp and they delivered the ALGs, just like those protocols
work on nat44. Ymmv.

As was noted before, native ipv6 benefits everyone: user, isp, content, p2p
....

Cb

> 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
>
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers