Yesterday’s 6th Slovenian IPv6 Summit was (as always) full of awesome presentations, this time coming straight from some of the IPv6 legends: check the ones from Eric Vyncke (and make sure you read his IPv6 Security book), Randy Bush and Mark Townsley. The epic moment, however, was the “I was getting bored” part of Eric’s presentation (starts around 0:50:00). This is (in a nutshell) what he did:

He was connected to a public WiFi hotspot and started an equivalent of radvd. In seconds, he had more than 50 IPv6 neighbors – everyone in the airport using the same public WiFi started using IPv6 after hearing an RA message from Eric.

By itself, that’s nothing new. We know a rogue IPv6 “router” can wreak havoc in your network (that’s why you should always enable RA guard in your switches) – that was one of the major concerns some people had before World IPv6 Day. However, at that moment Eric could easily do man-in-the-middle attack on any IPv6 traffic – anything going to any dual-stack web server would be intercepted by his workstation.

To make matters worse, he could use DHCPv6 to advertise DNS server address, start a fake DNS server (some hosts prefer IPv6 DNS over IPv4 DNS) and create fake dual-stack DNS replies attract even more traffic. DNSsec would prevent that (yeah, everyone is using that) as would SSL (you’re using Facebook and Twitter over SSL, aren’t you?), but he would still be able to do significant damage.

As I said, the man-in-the-middle attack using fake RA messages should be well known, but there are a few other security implications:

Some IPsec clients don’t enforce split tunnel policy on both protocols. Even though your company’s policy requires your VPN client to send all Internet traffic to the central firewall/IDS, IPv6 traffic can bypass that (making you a perfect entry point into your company’s network);

Unix-based operating systems usually have two different firewalls – iptables for IPv4 and ip6tables for IPv6. If someone gives you unexpected IPv6 connectivity, you might become wide open to the Internet at large unless you’ve configured ip6tables.

You might argue the situation is no better in the IPv4 world – a lot of hotspots are totally unprotected against ARP spoofing attack, but at least some access points give you the option to configure DHCP guard and DHCP/ARP inspection. Having no wireless experience, here’s a question for the experts: how many access points support RA guard (assuming they even know what IPv6 is)? Please share your experience in the comments.

Related Posts by Categories

14 comments:

Simplest solution I can think of isn't an IPv6 solution at all - wireless client isolation. A lot of APs/controllers support it and it simply prevents traffic from one wireless client being forwarded by the AP back out to another. Really should be turned on in public access locations for this and other more obvious reasons.

Great post always an eye opener. For wireless one should consider turning off or to disable any P2P in the service set. As for the IPv6 nice reporting Ivan, great stuff as always. I am turning the knobs on IPv6 protocol(s) on a v6 research project I am on. I know of the DHCP man in the middle but what about the possibility of a dhcp v6 lease queary/response from dhcp server to local (dhcp relay)edge router(router) exploit - poisoning or changing the lease?

The IP tables for v6 is great didn't even consider that one from the UNIX side.

That nicely solves a single AP issue (thank you for the pointer, you just gave me a troubleshooting idea for my home WiFi), but you still have the same problem if you have multiple access points and an IPv6-clueless engineer configuring the backhaul network.

If you combine it with carefully implemented private vlans on the switches (which is basically the same thing the APs are doing with client isolation), then you can extend to multiple access points. That gets hard on bigger networks, though, plus people do occasionally want to connect to each other on the same network.

Indeed, AP isolation is the easiest way to solve this IPv6-related problem as well as IPv4 rogue DHCPv4 & ARP spoofing. Having done this 'test' in a couple of hot spots, a (small) majority of hot spots do AP isolation.

Some other VPN clients (AnyConnect) do the exact opposite in regards to IPv6.They will cut off any local IPv6 connectivity regardless of whether the remote endpoint(asa) is configured to send/receive IPv6 traffic over the tunnel or not.So basically if you're working in an IPv6 environment and start a VPN connection with AnyConncet to somewhere, the client will disconnect all your current IPv6 sessions.According to Cisco this is a "feature not a bug".

A lot of these deployments use wireless controllers which tunnel traffic back between the AP and the controller over L3 networks allowing for exactly this kind of restriction across all APs (or alternatively the controller can tell APs to restrict the traffic to the controller without the L3 tunneling). This also means that the controller can then be used as the portal for guest access management (handling billing etc if needs be) without having to tag the guest VLAN across the entire LAN/WAN to each AP.

wouldn't the anyconnect path use Teredo or 6to4 tunnel for IPv6? Ip in IP proto 41 encap(nat issues) or Teredo using IP udp IPv6 encap to get past nat. and the anyconnect tunnel may not even know. Of course your teredo needs to be set up.

FYI Cisco lightweight wireless currently does IPv6 really, really badly. There are a few issues, but chief amongst them are NO FILTERING AT ALL - no RA guard, no access lists, no nothing. This means that a rogue router can cause complete havoc. This is more common than you might think, because Microsoft Internet Connection Sharing in Vista/Windows 7 is an IPv6 router, and will advertise itself as such - even when the windows machine has only one network interface up!

It's also worth noting that vlan assignment doesn't work with IPv6 - it only affects IPv4

The only way to even disable IPv6 on these things is to disable layer2 multicasts. This of course breaks IPv4 multicast, but does at least stop IPv6 working.

Apparently this is unfixable in the 1st gen controllers / wisms. You need 5500/wism2 and a new software image (that we are promised "soon") which will support full IPv6 parity, including RA guard (a later image will support LWAPP over IPv6, if you care)

I would concur with Cisco knowingly implementing that (i.e. a feature). In previous versions (2.x I think) IPv6 was still enabled when connecting to an IPv4 only VPN. It was great to be able to get to websites via IPv6 and avoid the draconian corporate filtering on the IPv4 VPN :)

Ivan Pepelnjak, CCIE#1354 Emeritus, is an independent network architect. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net,
has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.