Neighbor Discovery is equivalent to Router Discovery but for hosts. It performs operations such as address resolution, Duplicate Address Detection (DAD), Neighbor Unreachability (NUD), and redirection. As with Router Discovery, in IPv6 there are also Neighbor Discovery ICMPv6 messages that are responsible for network discovery. They are ICMPv6 Neighbor Solicitation (NS) and Neighbor Advertisement (NA). This section describes concerns related to Neighbor Discovery.
Address resolution is the process that an endpoint (shown as host A) follows when it wants to forward a packet to another endpoint (shown as host B) in the local link when it does not know its Layer 2 address. Host A resolves the IP address of host B into a MAC address and then forwards the packet by setting the host B MAC address as the Layer 2 frame's destination MAC.
In IPv4, Address Resolution Protocol (ARP) is responsible for address resolution; however, in IPv6, ICMPv6 is responsible for that service. In figure 3, Host A sends an ICMPv6 NS requesting the link-layer address for host B. When host B sends an ICMPv6 NA response, host A knows the MAC address that it will use to send the frame. At the same time, host A creates a neighbor cache entry for host B that binds the MAC for host B to its IPv6 address (similar to the ARP table in IPv4).
If malicious host T manages to insert itself in the link, it could impersonate host B and, in turn, intercept all packets that were originally destined for host B. Therefore, if proper FHS protections are not employed, host B can perform a man-in-the-middle attack or intercept traffic. Figure 3 illustrates the steps involved in deploying an address resolution attack.
Figure 3. Attack against IPv6 Address Resolution
Duplicate Address Detection (DAD) is a protocol in IPv6 that enables an endpoint to verify the uniqueness of an address. In essence, it is a probe message that the host sends to verify other hosts have not claimed the address. Figure 4 illustrates the steps involved in deploying a duplicate address attack. In IPv6, when host A wants to perform DAD it sends an ICMPv6 NS for the address it wants to claim (for example, 2001:DB8:600D::A). If other hosts do not respond with an ICMP NA stating the address has been taken, then host A is able to use the address.
In this scenario, DAD can be susceptible to attacks by malicious host T, which wants to prevent host A from receiving an IPv6 address. When host A sends its NS for 2001:DB8:600D::A, host T can then send an NA stating that the address is taken. If host A tries to claim another address (for example, 2001:DB8:600D::AA), host T can send an NS and claim it. Essentially, host T can claim every address that host A performs DAD and prevent host A from getting an IPv6 address to communicate with the network. Figure 4 illustrates the steps involved in deploying a duplicate address attack.
Figure 4: Attack against IPv6 Duplicate Address Detection (DAD)
When performing address resolution after receiving the ICMPv6 NA, host A creates a neighbor cache entry for the IP address it resolved to the host B MAC address. Given the size of the local link address pool, a host's neighbor cache can significantly increase in relation to the ARP table size in IPv4. In IPv6, the interface identifier of an address is 64-bits long, which means there could be as many as 264 hosts on the link, and thus, potentially 264 neighbor cache entries.
In this scenario, malicious host T can attack the neighbor cache of a host or routing device and attempt to fill it or cause a DoS condition. Let us assume that host T knows that RTR is connected to its link and to a link with hosts in the 2001:DB8:600D::/64 prefix. Host T can start scanning 2001:DB8:600D::/64 by sending a packet to the hosts one by one. Regardless of whether the destination host is present on the link, RTR will attempt to resolve their IPv6 addresses to forward the frame that is destined to them. For example, even if host 2001:DB8:600D::A is not on the link, while resolving it, RTR will create a cache entry that will be incomplete and remain in the RTR neighbor cache for a few seconds until it times out. Thus, if host T was fast enough and able to scan a large portion of the 264 hosts within a few seconds, it could succeed at filling the RTR cache entry and cause a DoS condition. Figure 5 illustrates the steps involved in deploying a neighbor cache attack.
Figure 5. Neighbor Cache attack
Note: The attack on the RTR neighbor cache does not require host T to be local to the RTR. If host T knows the links directly connected to RTR, it could launch the attack remotely.
In 2003, the IETF defined DHCPv6 in its RFC 3315. As in IPv4 DHCP, DHCPv6 describes how a host that comes up can acquire an IPv6 address and other configuration options from a server that is available on its local link. DHCPv6 is described as a stateful protocol that has compatibility with stateless address autoconfiguration as a design requirement. In other words, DHCPv6 can operate in a stateless fashion where it provides configuration information to nodes and does not perform address assignments (RFC 3736). In addition, it can operate in a stateful manner, where it assigns IPv6 addresses and configuration information to hosts that request it.
As in IPv4 DHCP, DHCPv6 is susceptible to rogue server attacks. In other words, if DHCPv6 was used to provide IPv6 addresses to the hosts, an attacker that managed to insert a rogue DHCPv6 server in the link could potentially assign addresses and configuration options to the link hosts as he wished. In turn, the attacker could deploy man-in-the-middle, traffic interception, or blackhole traffic, similar to those in the stateless address autoconfiguration scenario. Thus, it is important to use DHCP protections for both IPv4 and IPv6.
In conclusion, security has become one of the most popular subjects of IPv6 discussions. In particular, IPv6 raises a number of FHS concerns that were not present in IPv4. Those concerns stem from the protocol's unique manner in which it performs router and neighbor discovery, address assignment, and address resolution. These mechanisms could allow an attacker to deploy attacks such as traffic interception, DoS, or man-in-the-middle. Clearly, FHS should not be neglected and appropriate protection mechanisms should be employed when possible. Mitigation mechanisms for FHS concerns will be presented in a subsequent white paper.
Panos Kampanakis (pkampana[at]cisco[dot]com)
Cisco Applied Intelligence Engineer
Enterprise IPv6 Solution
Implementing First Hop Security in IPv6
IPv6 First-Hop Security Configuration Guide
IETF RFC 4861 Neighbor Discovery for IP version 6 (IPv6)
IETF RFC 5942 IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
IETF RFC 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IETF RFC 6104 Rogue IPv6 Router Advertisement Problem Statement
Book: IPv6 Security by Scott Hogg, Eric Vyncke, Cisco Press (2008)
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.