Department of Defense
High Performance Computing Modernization Program

The Neighbor Discovery Protocol (NDP) for Internet Protocol version 6 (IPv6) is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4861 (as further updated by 5942, 6980, 7048, 7527, and 7559). It effectively replaces the Address Resolution Protocol (ARP) used by IPv4. Subsection 3.5.3 of the National Institute for Standards and Technology (NIST) publication Guidelines for the Secure Deployment of IPv6 briefly describes the NDP and its improvements over the ARP, and Subsection 3.5.4 of that publication briefly describes some of the security ramifications. In addition, RFC 6105 Router Advertisement Guard (RA-Guard) updated by 7110, 7113, and Internet Draft ND-Shield have been published. They describe mitigations for the various NDP threats as originally identified in RFC 3756 published in 2004 and described in the remainder of this article. RA-Guard is also discussed in Definition and Prevention of rogue Router Advertisements in the DHCP and SLAAC on IPv6 Networks article in the Infrastructure section. References in the Best Practices article in the Security section also describe mitigations for various NDP threats.

The SEcure Neighbor Discovery (SEND) protocol described in RFC 3971, as further updated by 6494, 6495, and 6980, has been defined which can counter many of the threats to the NDP described in the remainder of this article. Subsection 5.4.2 of the above NIST publication briefly describes the SEND protocol. Subsection 5.4.3 states that to date the SEND protocol has been neither widely implemented nor deployed. This presentation discusses why this is the case, and offers some solutions.

This remainder of this document presents a summary of security threats associated with the IPv6 Neighbor Discovery protocols as described in RFC 3756. The designers of these protocols initially proposed IPsec as a mechanism to secure the protocols and the process of autoconfiguration. Since these protocols generally involve the bootstrap process, where a node does not know its full IPv6 address, automatic key management (via IKE) is not possible. This requires IPsec Security Associations (SAs) for these protocols to be manually configured. This manual configuration is tedious, error-prone, and scales poorly for even small networks. The vulnerabilities presented here warrant the use of some other mechanism to secure these processes.

RFC 3756 pays particular attention to the threat levels of each of these vulnerabilities in different environments. The environments considered are:

A. A corporate network where clients are expected to be well-behaved and not perform attacks on other nodes. The exception to this is if a node is compromised by a malicious user. Most workplace networks will fall into this category.

B. A public network where the infrastructure is generally trusted to be well-behaved, but other clients on the network are not trusted. This environment is typical of home users connecting to a public ISP or to a known wireless network.

C. An ad-hoc network where the network infrastructure as well as the attached nodes cannot be trusted to be well-behaved.

1. Neighbor Solicitation / Neighbor Advertisement Spoofing

Attacking node sends neighbor advertisement with bogus binding of IP address and MAC address. This is similar to ARP spoofing. Node A now sends traffic destined for Node B to this arbitrary MAC address. If there is no response from the arbitrary MAC address, node A will eventually perform Neighbor Unreachability Detection (NUD) at which time the bogus binding will be flushed from it’s cache. Attacking node must respond to the NUD or issue another neighbor solicitation to continue the attack.

Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known

2. Neighbor Unreachability Detection (NUD) failure

An attacking node may spoof Neighbor Advertisements, which can cause the NUD process to fail to recognize an unreachable node. The result is a denial of service attack, which keeps the attacked node from realizing that another node is, in fact, unreachable.

Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known

3. Denial of Service while obtaining address

Attacking node sends bogus neighbor solicitation during Duplicate Address Detection (DAD) of node. Node A attempts to detect of an address is currently in use before assigning that address to its interface. Attacking node replies with bogus response to make node A think that it’s address is already in use. The result is that node A cannot use that address. This attack can be continued for all of node A’s DAD attempts resulting in the failure for node A to acquire an address.

Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known

4. Malicious Last-Hop Router

An attacker can multicast bogus router advertisements (RA) on a link or send bogus RAs (unicast) in response to router solicitations. If a node selects a bogus RA, the attacker can masquerade as a router and may perform man-in-the-middle attacks at the IP layer or discard legitimate traffic.

The attacker may also spoof router advertisements that appear to come from the legitimate router that specify a lifetime of zero, which will trick the node into thinking that the legitimate router will not route packets. This threat is partially mitigated by careful inspection of the lifetimes in RAs.

Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched

5. Eliminating all legitimate routers

If an attacker can make a node believe that all routers are unavailable (by crashing them, performing denial of service attacks, or by convincing nodes that all routers are inaccessible), the node will assume that all destinations are “on-link” (per RFC 2461). This will cause a node that wishes to send packets to a node that is really off-link to attempt a Neighbor Discovery to find the node as if it were on-link. At this point, attacks are feasible for on-link nodes only can be extended to off-link hosts.

Environment “A”: Susceptible, at least one solution known, further solution being researched
Environment “B”: Susceptible, at least one solution known, further solution being researched
Environment “C”: Susceptible, solution being researched

6. Spoofed Redirect Message

An attacker may spoof a redirect packet that appears to come from a legitimate router. This will instruct the node to redirect packets for any given destination to an arbitrary link-layer (MAC) address.

Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched

7. Bogus On-Link Prefix

An attacker can send a spoofed Router Advertisement (RA) specifying that a particular prefix is on-link. When other on-link nodes try to communicate with a node that is on the spoofed prefix, it will attempt to communicate as if it were on-link (using Neighbor Discovery). The result is a denial-of-service, since local nodes attempt to communicate via the local link, instead of through a router to get to destinations that are really off-link. This attack can have a large impact if the advertised prefix is short.

This attack can be extended to perform man-in-the-middle attacks or other denial of service attacks if the attacking node masquerades as the target destination node.

Additionally, this attack can be extended to insert a large number of bogus routing table entries on all nodes, exhausting resources required to store the
routing entries.

Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched

8. Bogus Address Configuration Prefix

An attacking node can spoof a Router Advertisement (RA) message with a bogus prefix. Nodes performing address autoconfiguration with this RA may assign a bogus address to their interface. When the attacked node attempts to use the bogus source address to send packets off-link, responses will not be successfully routed back to the node.

This attack can further be expanded if the attacked node automatically performs a dynamic DNS update with the new (bogus) address. If this happens, other nodes performing DNS name resolution may get a bogus address, which will not get to the intended node. If the attacker specifies his own prefix in the bogus RA, application requests from anywhere on the Internet that use the DNS name may be routed to a node under control of the attacker. It may be simple for the attacker to insert a reverse-lookup entry to map the bogus address back to the hostname of the attacked host.

A variation of this attack is to advertise the prefix of a link that will be the target of a Denial-of-Service attack. Nodes will use the bogus source address, and all replies to traffic sent from those nodes will be routed to the targeted network prefix causing a DoS.

Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched

9. Router Advertisement Parameter Spoofing

A bogus router advertisement (RA) may specify an extremely low “Cur Hop Limit” field that nodes will use when sending packets. If this value is set low enough, packets sent off-link might not reach their final destination before the hop-limit is exceeded causing a Denial-of-Service.

Another form of bogus RA can have the ‘M’ or ‘O’ bit set, which causes a node to use stateful address autoconfiguration (such as DHCPv6). An attacker can set up a bogus stateful address autoconfiguration service (e.g. a fake DHCPv6 server) that can assign arbitrary addresses to nodes.

Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched

10. Replay Attacks

None of the Neighbor Discovery or Router Discovery messages have fields that could be used to prevent replay attacks. Previously transmitted legitimate packets can be replayed, supplying configuration or state information that may be out of date. This could lead to denial of service or redirection of traffic attacks as previously described.

Any security mechanism applied to Neighbor Discovery or Router Discovery messages should address replay attacks.

Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known

11. Neighbor Discovery Flood DoS

Any host on the Internet can send a packet to an arbitrary address on a given prefix. If the last hop router has no recollection of the address in the packet, it is required to perform a neighbor solicitation in an attempt to find a node at that address. An attacker can flood the last hop router with packets, each requiring a neighbor discovery action, which uses up resources on the router. This is similar to TCP SYN flooding.

A variant of this is tricking an application flood its link with packets for non-existent nodes (virus or Trojan could invoke rogue application behavior).

Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known


Top