The Neighbor Discovery Protocol (NDP) was originally designed to do the equivalent of ARP in IPv4. That is, to resolve layer three addresses into layer two addresses. Later the protocol was extended to handle other functions, like duplicate address discovery, router redirects, router advertisements and neighbor reachability.
In its normal form, NDP has almost no built-in security. It does some basic sanity checks on itself, and it requires that the hop limit in packets be 255, but that's it. This means that it is very easy to spoof, at least for an on-link attacker. It is much harder (though not impossible) to get a valid NDP packet onto a link through a router.
A hand-crafted neighbor advertisement, for example, could map an incorrect layer two address to a layer three address, causing traffic for the layer three address to be delivered to the wrong host. A malicious router advertisement could invalidate a prefix, leaving hosts on the link with no addresses. A more subtle attack might spoof duplicate address responses, blocking autoconfiguration. Hours and hours of fun!
These types of issues are not entirely new to IPv6. ARP spoofing can do much the same things in IPv4. Sometimes these techniques can be useful – consider proxy ARP, for example, or its IPv6 equivalent, ND proxy.
So what to do?
The original NDP specification called for IPSec to be used to secure every NDP transaction. This was quickly seen to be way too hard, and in its stead a protocol called SEND was specified – SEcure Neighbor Discovery. SEND uses cryptographically generated addresses and signs NDP packets, making it impossible to spoof them. SEND cannot prevent an on-link node from misbehaving, but it can prevent one on-link node from pretending to be another.
In the next installment we'll look at two specific NDP problems – rogue router advertisements and ND flooding.
Now to another kind of insider problem – automatic tunnelling. When Microsoft Vista was released, it came with Teredo, 6-to-4 and ISATAP tunnel drivers ready to go. Given the right environment, these protocols automatically provide IPv6 connectivity by tunnelling out to the IPv6 Internet over the existing IPv4 infrastructure – look Mum, no hands!
Tunnelling is not new – given ssh, an outside host and an open port, you can tunnel pretty much anything to anywhere. But automatic tunnels are different. An automatic tunnel means that an innocent user can, simply by starting his or her machine, set up with a new path between the outside world and your network, bypassing your security arrangements. The user doesn't even know it's happened. There is a good chance that any local firewall configurations are not set up to take this unexpected IPv6 connectivity into account, either. All this sounds bad, but luckily it's not as bad as it sounds.
Automatic tunnels are not deliberately trying to bypass your security; that's just a side-effect of their over-enthusiastic attempts to connect the user to the IPv6 Internet. They are not malicious or tricky. They can generally be stopped with a simple filter – for example, 6-to-4 tunnels can be interrupted by blocking the use of Internet protocol number 41, IP-in-IP. And if you have a standard operating environment (SOE), you can disable these unwanted features.
©Copyright 2011 Karl Auer
About the author: Karl is technical manager at IPv6Now , a company specialising in helping organisations get into and get the most out of IPv6. This is the second in a four-part series of articles on IPv6 security issues.
More articles from this author