Sergey Nivens - Fotolia
Editor's note: IPv6 neighbor discovery (ND) is a core part of the IPv6 protocol suite. It is employed for IPv6 address resolution and IPv6 stateless address autoconfiguration, among other things. This article, the third in a series of tips about IPv6 network management, explores some of the mitigation techniques for ND-based attacks.
Before getting into a discussion about the possible mitigation techniques for IPv6 neighbor discovery-based attacks, it is useful to help the reader learn how these attacks differ from similar attacks in the IPv4 world. Additionally, the reader must understand the technical challenges that will be faced when mitigating these attacks.
Neighbor discovery (ND) comprises both IPv6 address resolution and IPv6 stateless address autoconfiguration (SLAAC). While IPv6 address resolution is similar to its IPv4 counterpart, SLAAC is a new feature introduced by IPv6, and thus represents a new attack vector that doesn't exist in the IPv4 world. But even when considering features present in both protocol families (such as address resolution), there is a key difference between IPv6 and IPv4: the complexity in the resulting traffic. For example, since IPv4's Address Resolution Protocol (ARP) operates directly on top of the underlying link-layer protocol, it results in very simple protocol packets (albeit at the expense of reduced flexibility). On the other hand, IPv6 ND consists of Internet Control Message Protocol version 6 packets that are sent as IPv6 packets. This enables improved flexibility, but it also results in much more complex traffic -- something that is at odds with the ability to police or monitor such traffic.
There are a number of ways to mitigate ND-based attacks. Among them:
- Deploying secure neighbor discovery (SeND)
- Monitoring neighbor discovery traffic
- Traffic compartmentalization
- Deploying router advertisement guard (RA-Guard)
- Using static entries in the neighbor cache
SeND specification set to help mitigate ND-based attacks
The original specification of IPv6 neighbor discovery suggested that users should deploy IPsec on the event they were concerned about ND's security implications. Yet the potentially large number of IPsec security associations that would be needed -- in combination with the need to establish them in general deployments -- made such an approach unfeasible. As a result, the IETF later produced the secure neighbor discovery (SEND) specification, which aims to mitigate a number of ND-based attacks without the need to employ IPsec. SEND has been standardized in RFC 3971 and performs these functions: address ownership proof, message protection and router authorization.
- The first two functions (address ownership proof and message protection) are (roughly) achieved as follows: SEND uses cryptographically generated addresses (CGAs): These are IPv6 addresses that embed (in the interface identifier) a hash of a public key.
- A node can verify the association between the CGA and the public key from the CGA address itself and the public key and CGA parameters -- the latter two being provided by means of ND options in ND messages.
- A node protects its ND messages from tampering by signing them with its public key. This signature can be verified by the receiving node(s).
Finally, router authorization is achieved via certificate paths anchored on trusted parties, which authorize routers to act as such, and (optionally) authorize them to advertise a specific set of subnet prefixes. A more thorough introduction to SEND can be found here.
Despite SEND being usually regarded as a silver bullet for mitigating ND-based attacks, its deployment can be quite challenging -- for the following reasons:
- SEND is not widely implemented (for example, Microsoft Windows 8 does not ship with a SEND implementation), and because both SEND and CGA are patent-encumbered, it's possible that operating system developers will never actually implement SEND. Open source projects, for example, have expressed concerns about the issues associated with intellectual property rights woven within SEND and CGA.
- SEND cannot be used with SLAAC privacy extensions. These extensions are enabled by default in Microsoft Windows and other operating systems. The requirement of a public key infrastructure (PKI) is key challenge to SEND deployment.
- For accountability and audit reasons and/or ease of management, a number of organizations require the use of Dynamic Host Configuration Protocol (DHCP) version 6 for all nodes. However, SEND cannot work if DHCPv6 is required for host configuration.
Finally, there are a number of bigger problems that SEND does not address (nor is it meant to). For example, unless the domain name system server is secured, an attacker could simply subvert the DNS to perform man in the middle (MITM) or denial of service (DoS) attacks, rather than tamper with the address resolution mechanism of ND. Thus, the return of investment associated with deploying SEND is unlikely to be attractive in most network scenarios.
How to use ND traffic inspection
In its most simple form, ND traffic inspection does not really aim to mitigate ND-based attacks, but rather to detect them. Some tools (such as NDPmon) can simply inspect ND traffic and issue an alert that a mapping from IPv6 address to link-layer address has changed. These tools typically work as follows:
- Upon deployment, they can be run in a "learning mode," in which all local traffic is assumed to be legitimate. While operating in this mode, the tool listens to ND traffic and builds its own database of all the mappings from IPv6 addresses to link-layer addresses.
- Then they are run in "normal mode," where the tool listens to ND traffic and contrasts the mappings advertised in such traffic with the mappings stored in the database. If the mappings do not match, an alert is issued.
More elaborate implementations, such as Cisco's IPv6 snooping in switches, can inspect ND traffic, build a database of IPv6 addresses and their mappings to link-layer addresses (e.g., on a first-come, first-served basis) and then block ND messages that do not contain valid mappings. This functionality goes further than simply issuing alerts (as in the NDPmon case), and allows for actual attack mitigation.
As noted earlier, the complexity of ND traffic represents a challenge for ND traffic inspection. However, since RFC 6980 has prohibited the use of fragmentation with ND, this type of tool will become more effective over time as outdated implementations that still accept fragmented ND packets are phased out.
Next: Using traffic compartmentalization, router advertisement guard and static entries.
About the author: Fernando Gont currently works for SI6 Networks as an Internet security and engineering consultant. He is an active participant at the IETF (Internet Engineering Task Force), where he contributes to several working groups, and has authored a number of requests for comments and Internet drafts. Gont is a regular speaker at conferences, trade shows and technical meetings, discussing information security, operating systems and Internet engineering. More information is available at his website.
Ensuring our IPv6 environment is secure
Protecting address configuration