Virtually all organizations now have IPv6-capable systems running on their networks. All modern mobile and computer operating systems run both IPv4 and IPv6 by default. These operating systems try to facilitate access to the IPv6 Internet, if at all possible, and may create IPv6-in-IPv4 tunnels to reach IPv6 content. Some of these processes take place regardless of user input, configuration, or notification (See RFC 7123, Security Implications of IPv6 on IPv4 Networks). This is what is commonly referred to as the “IPv6 latent threat.” There is an active protocol in the environment that administrators are not aware of and have not yet taken any steps to secure.
This is something to be concerned about, but is something that can be secured. One approach to mitigating the latent threat issue is to proceed to deploy IPv6. This proactive step helps put you in control of the IPv6 security situation. There are other approaches to mitigate these IPv6 security issues. These approaches are implemented on the local LAN and traverse the network perimeter.
This blog post will focus on the issues and security measures used to protect the use of IPv6 on a local access network. Knowing the network devices that are local and within the neighbor cache (the IPv6 equivalent of the IPv4 ARP cache) helps you learn who is on your network and using IPv6.
Don’t Be Overly Alarmed
The vast majority of organizations have not taken any steps to secure the IPv6-capable nodes in their environment. They are also unaware of how IPv6 operates on a LAN and how the protocol is different from the IPv4 protocol they have experience securing. IPv6 has some particular functional differences from IPv4 that may change your LAN threat-mitigation strategy.
We do not want organizations to be overly alarmed about these types of LAN-based IPv6 threats. For the most part, organizations do not implement any security measures to secure their IPv4 ARP or DHCP traffic on their access networks. Many of the same types of LAN-based attacks for IPv6 have similar or exactly the same vulnerabilities as IPv4 threats. If organizations have not implemented any IPv4 LAN protection measures, then they should not be holding IPv6 Neighbor Discovery to a higher standard of security.
It should also be mentioned that all of these IPv6 Neighbor Discovery Protocol (NDP) attacks occur on the local physical/virtual link. Therefore, the attacker must have physical access to the local network medium or have compromised and gained control of a system that is on the local network. The attackers’ motivation is to stay hidden and cover up their tracks as well as preserve the access they have achieved. The attackers definitely do not want to alert any IT administrator that they have gained access to an internal computer.
Reconnaissance of IPv6-capable nodes on a local LAN is not practical when the attacker uses brute-force techniques trying to guess the IPv6 addresses used by local nodes. However, there are methods that a resourceful attacker can use to accelerate finding IPv6-capable local nodes. Some of these methods are stealthy and quiet, while others are noisy and leave traces that the attacker is there. An attacker can pivot to other unprotected IPv4 nodes and IPv6 nodes on the local LAN if the attacker already has access to the local link.
IPv6 NDP Threats
Attackers are gaining familiarity with IPv6, but most enterprise security teams are unaware of the protocol and how it works on a LAN. The IPv6 Neighbor Discovery Protocol (NDP) (defined in RFC 4861) is the process that is used for IPv6 nodes on a LAN to facilitate communicating with each other. NDP uses Internet Control Message Protocol (ICMPv6) and link-local multicast communications to perform functions similar to IPv4’s Address Resolution Protocol (ARP). There are a variety of LAN-based vulnerabilities that a locally-attached attacker can try to take advantage of. These are also documented in IETF RFC titled “Operational Neighbor Discovery Problems” (RFC 6583). This Cisco document shows how these IPv6 FHS concerns can cause problems for end-nodes.
A link-local attacker could generate malicious ICMPv6 Neighbor Solicitation (NS) or Neighbor Advertisement (NA) messages to confuse node’s neighbor cache. This could result in a DoS condition or facilitate the attacker performing a man-in-the-middle (MITM) attack.
A local-connected attacker could also generate ICMPv6 redirect messages to change the direction of traffic from nodes on the local LAN. This could also result in a DoS or MITM situation.
The attack that should raise the most concern is one where an attacker crafts a rogue ICMPv6 Router Advertisement (RA) message and sends it out on a network that only runs IPv4. This RA message would cause all of the IPv6-capable devices on the local network to activate their IPv6 stacks, acquire an IPv6 address based on the information in the RA, and start to attempt to actively use IPv6. ICMPv6 RA messages are essential and are the first step in the address assignment phase (and provide the host with information about their local IPv6 default gateway). Spoofed RAs can renumber hosts, cause a DoS condition for a host, or launch a MITM attack. The problems related to Rogue RA messages are well-documented in the IETF RFC titled “Rogue IPv6 Router Advertisement Problem Statement” (RFC 6104).
Methods for Securing NDP
When we start to formulate our defensive strategy for these types of IPv6 NDP attacks, the first problem to solve is our lack visibility into how IPv6 is currently used on the LAN. Many organizations do not know which devices are connected to their networks. Knowing which nodes are connected and having an “inventory of authorized and unauthorized devices” are the first steps in the SANS top 20 Critical Security Controls (CSC). Common methods of determining what is on our networks involve asking the local IPv6-capable router for its IPv6 neighbor cache through either the CLI or with an SNMP GET to a specific MIB OID. Using something like Infoblox’s Switch Port Manager or Network Insight may also provide visibility. Having an IP address management (IPAM) system that is tied into our DHCP services also provides awareness of which IP addresses are in active use.
Organizations also lack capabilities to keep unwanted devices off their networks. Preventing unauthorized LAN access is typically an issue of physical security. Most organizations may only disable unused switch ports and connections in conference rooms and publicly-accessible spaces. Some organizations may use port-security to limit the number of MAC addresses learned on an access port. Fewer organizations use IEEE 802.1X or IEEE 802.1AE (MACsec), Cisco Identity Services Engine (ISE) with TrustSec. Most of the commercially-available network access control (NAC) network admission control (NAC) systems do not work with IPv6 and do not pay attention to IPv6-connected devices.
There are several host-based monitoring solutions that can observe NS/NA and RS/RA messages and detect and prevent NDP attacks. These open source utilities include NDPMon, Ramond, Kame rafixd, 6Guard, and 6MoN. The constraint of these solutions is that one system on every LAN would need to be running these functions. That may not be scalable for an organization that has many access networks.
A better approach is to put this detection and protection into the access network devices. These IPv6 security measures could be implemented into the Ethernet access switch or wireless controller and protect all the down-stream end-nodes. This detection within the access Ethernet switch is similar to how a switch performs DHCP snooping and IGMP snooping (identifying hosts interested in receiving multicast traffic) and PIM snooping (finding the local PIM routers).
An Ethernet switch could be configured to use a Port-based ACL (PACL) to prevent an access port from sending Router Advertisement (RA) messages to other link-local nodes and thus prevent an attacker from acting like a rogue DHCPv6 server.
An example of how this rogue RA detection and prevention can be performed within an Ethernet switch is documented in the IETF RFC titled “IPv6 Router Advertisement (RA) Guard” (RFC 6105). Ethernet switches would be able to learn which local IPv6 router should be legitimately sending RA messages to the nodes on the network and detect and drop RA messages being sent from end-nodes. Ethernet switches could also detect if RA messages are being flooded too quickly (more than the standard 200 second interval) and throttle them back.
Other IPv6 FHS features perform snooping DHCPv6 traffic and gleaning which nodes on the network have been allocated which IPv6 addresses. The switch can also snoop IPv6 packets and determine if those nodes are sourcing traffic from their allocated IPv6 addresses. If the IPv6 packets are using IPv6 addresses other than those detected through the snooping process, then the end-node may be creating spoofed packets and they should be blocked. Other features involve the switch monitoring the destination address of packets and detecting multicast and other attack types.
Vendor Support for IPv6 FHS
Some vendors have implemented these IPv6 FHS features into their Ethernet switch software by default. Therefore, customers have the flexibility to turn on these features at their leisure for no additional cost. Even organizations that have not implemented IPv6 might be curious if any of this nefarious NDP traffic is taking place on their LANs. Some vendors have been aggressive about incorporating IPv6 security features into their switches, while other vendors have been slower to embrace IPv6 FHS features and implement them. As with other aspects of IPv6, it is important to ask your vendor about their IPv6 features and assess if they have feature parity between what they can do to secure IPv4 and what they can do to secure IPv6.
Modern Cisco switches have these IPv6 FHS features available as part of the default IOS software. This page has a breakdown of the IPv6 FHS features and which IOS software version and platform support these features. This site has additional details about configuration of these IPv6 FHS features.
HP has several classes of their switches (HP K.15.07.0002 on the 5400, 8200, 3500 series) that have IPv6 security capabilities. H3C A5800 switches with OS version 5.20, among other switches in their line have RA Guard.
Brocade switches (ICX 6430/6450, FCX, ICX 6610/6650, FSX 800/1600, ICX 7450/7750 Release 08.0.20a) have RA Guard and provide examples of how to configure it.
However, there are many vendors that have no IPv6 security protection features within their Ethernet switches. Consumers should be aware if their network switches lack these features and prepare to obtain these capabilities to gain visibility into IPv6 activities on LANs, (and should definitely plan on doing so before they deploy IPv6).
This post originally appeared on the Infoblox blog at http://community.infoblox.com/t5/IPv6-Center-of-Excellence/Getting-to-Know-Your-Neighbors-with-IPv6-First-Hop-Security/ba-p/3561.
