Pakhnyushchyy - Fotolia

IPv6 attack attempts and how to mitigate them

Compartmentalizing traffic and employing static entries can help enterprises block neighbor discovery-based attacks in their IPv6 networks.

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 fourth in a series of tips about IPv6 network management, explores some additional mitigation techniques for ND-based attacks.

The previous installment of this series discussed some IPv6 attack techniques -- including secure neighbor discovery (SeND) and monitoring ND traffic -- that can be used to mitigate ND-based attacks. In addition to those mitigation strategies, there are three other ways that engineers can mitigate ND-based attacks: traffic compartmentalization, router advertisement guard (RA-guard) and employing static entries in the neighbor cache.

Traffic compartmentalization. Virtually all ND attacks (modulo the remote Neighbor Cache Exhaustion attack) can only be performed by an attacker that is directly connected to the same network as the victim. This is the result of the ND specification (RFC 4861) requiring all ND packets to have a hop limit of 255: Packets sourced from a different network will arrive with a hop limit smaller than 255, and hence will be discarded. Thus, in an organizational network that comprises a single subnet, any system can launch an ND-based attack against any other system on that network. An organizational network that is based on multiple subnets, however, results in traffic compartmentalization, thus limiting the ability of nodes to attack nodes in other subnets of the same organizational network.

For obvious reasons, there is a limit in the extent to which traffic can be compartmentalized. Additionally, traffic compartmentalization comes at a price: It may increase both deployment and operational costs.

RA-guard. This packet-filtering policy is enforced by Layer 2 devices and parallels what is typically known as Dynamic Host Configuration Protocol-snooping in the IPv4 world. RA-guard works (roughly) as follows:

  • The network administrator configures which ports of the Layer 2 device are allowed to receive RA messages.
  • If an RA message is received on one of these ports, the message will be allowed.
  • If an RA message is received on any other port, it will be silently dropped.

While the idea behind RA-guard is somewhat elegant, this policy faces one key challenge: Because RA messages are encapsulated in IPv6 packets (rather than directly in the underlying link-layer protocol), RA-guard must be aware of IPv6 fragmentation and extension headers.

As a result, popular RA-guard implementations have been easy to evade by simply employing IPv6 extension headers. Fortunately, thanks to the publication of RFC 6980, the use of IPv6 fragmentation with ND messages is now forbidden. That means RA-guard will become a more effective tool to mitigate RA-message-based attacks because outdated IPv6 implementations are phased out.

Employing static entries in the neighbor cache. The goal of employing a protocol (such as ND) to resolve addresses is to avoid the need to manually configure address mappings on every single host on the local network. There may, however, be some specific network scenarios in which one may want to introduce (in some of the network nodes) some static entries in the neighbor cache so that ND need not be involved when traffic is sent to these addresses (i.e., such IPv6 addresses do not need to be dynamically mapped to link-layer addresses).

On BSD-derived operating systems, static entries can be added to the neighbor cache with the ndp command:

ndp -s 2001:db8::1 11:22:33:44:55:66

This command will add a static entry to the neighbor cache that maps the IPv6 address 2001:db8::1 to the MAC address 11:22:33:44:55:66.

On GNU/Linux systems, the same neighbor cache entry can be added with the following command:

ip -6 neigh add 2001:db8::1 lladdr 11:22:33:44:55:66 dev eth0

Both BSD-derived and GNU/Linux systems will show (when one inspects the contents of the neighbor cache) the added entry as a "permanent," differentiating it from the normal entries.

There are a number of limitations regarding this mitigation technique:

  • It is applicable only to specific network scenarios.
  • It does not scale. It would be virtually impossible (if at all desirable) to employ static entries in all the nodes of a large network.
  • Some (buggy) implementations have been found to ignore static entries and still employ ND to perform address resolution.

To that end, while static ND cache entries may prove to be a useful tool in some specific scenarios, they are not applicable to the general case.

Each installment of this four-part series has illustrated possible mitigation techniques for ND-based attacks. We have seen that while there are a number of techniques, their effectiveness varies and some can be difficult to deploy in real-world networks. However, recent IPv6 standardization efforts, together with subsequent implementation updates, will help boost the effectiveness of some of these mitigation techniques in the near term. And remember this: Most IPv4 networks currently operate without any protection from that protocol's version of these attack vectors. The lack of a silver bullet to mitigate ND-based attacks should not be deemed as a barrier against deploying IPv6.

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.

Next Steps

Avoiding neighbor discovery attacks

IPv6 address configuration dos and don'ts

Mitigation techniques you need to know

This was last published in February 2015

Dig Deeper on Network protocols and standards