The security of IPv4 is roughly equivalent to IPv6. So why do we expect more from IPv6?
When people embark on learning about IPv6, they are intrigued with how different the IPv6 Neighbor Discovery Protocol (NDP) (RFC 4861) is from the IPv4 Address Resolution Protocol (ARP) that they are already familiar with. For instance, IPv6 uses multicast rather than broadcast (as with IPv4 ) and relies on ICMPv6 for both NDP and Multicast Listener Discovery (MLD). IPv6 NDP has far more functionality than simply binding IPv6 addresses and MAC addresses of local nodes. IPv6 NDP is critical to how nodes obtain their IPv6 addresses, join the network, and send their packets off-net.
When someone starts to learn about IPv6 and NDP, they are commonly introduced to the various security issues and attacks that can take advantage of the vulnerabilities of the protocol. It is trivial to spoof Router Advertisement (RA) messages causing hosts to engage IPv6, or to renumber an existing IPv6 network, or even perform a Man-In-The-Middle (MITM) attack. It is also possible to forge Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to confuse link-local nodes and corrupt neighbor caches. These problems are well documented in “Operational Neighbor Discovery Problems” (RFC 6583). These issues are far from new. The industry has been aware of the insecurities in NDP for almost 15 years.
Network and security administrators get really excited about these security vulnerabilities in IPv6 NDP. Their minds start to race thinking about the possibilities this represents for a determined attacker. Some even start to panic and consider halting their IPv6 deployment because of these security issues with NDP. My suggestion is similar to what Douglas Adams might say: “Don’t Panic.” Take a deep breath, learn more about the details of IPv6 and NDP, and then deploy security measures to help mitigate the vulnerabilities. In other words, Keep Calm and IPv6 On!
One important thing to keep in mind is that in order for an attacker to take advantage of the weaknesses in NDP, the attacker must be directly connected to that layer-2 network segment or have taken control over at least one computer on that LAN. That presumes that the attacker is already on the internal network. Typically an attacker who has gained access to an internal network does not want to raise awareness to their presence while they perform reconnaissance and pivot to other systems. The motivation for an attacker to perform DoS attacks or perform maneuvers (such as Rogue RA attacks) is low because these behaviors are easily detectable and leave traces of the attacker’s presence.
In response to these NDP vulnerabilities, much work has been done to monitor and help secure the use of IPv6 NDP. Some of this work to improve the situation has been done by the IETF. The first idea that was developed was the Secure Neighbor Discovery (SEND) protocol. Wired and wireless network equipment manufacturers have also developed functions into their products to block and alert on these types of NDP attacks. For example, Cisco has put tremendous effort into their First Hop Security (FHS) measures implemented in switches, routers, and wireless LAN controllers to help secure IPv6 nodes.
The Router Advertisement (RA) is an important part of how an IPv6-capable node will join an IPv6 network. It’s also a well-known and popular IPv6 weakness. The IETF RFC titled “Rogue IPv6 Router Advertisement Problem Statement” (RFC 6104) describes how an attacker can generate crafted RA messages to disrupt a LAN or gain an MITM position. In response to this problem, the IETF worked on IPv6 Router Advertisement Guard (RA Guard) (RFC 6105) as a technique within Ethernet switches and other network devices to permit only the legitimate RAs from the local IPv6 router to be forwarded. RA guard will then block any other RA packets originating from any downstream node on the LAN. The IETF has continued their work on the subject by publishing “Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)” (RFC 7113). Other improvements have come in the form of limiting fragmentation of NDP messages, outlined in “Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery” (RFC 6980).
This same technique can be implemented by Cable Modem Termination Systems (CMTSs), Wireless LAN Controllers (WLCs), or simply as a software application running on a node on the LAN. There are many software tools that can help detect rogue RA messages and detect NDP funny business. These tools include NDPMon, ramond, Kame rafixd, 6Guard, addrwatch, SLAACer, and 6MoN. This is a long list of tools that are aimed at helping organizations gain visibility into, and awareness of, inappropriate NDP and RA messages on a LAN. Judging by the length of this list, there is significant interest in this topic.
People sometimes get the impression that IPv6 is inherently more secure than IPv4. This has to do with the fact that IPsec was developed around the concept of IPv6 and its extension header convention. Authentication Headers (AH) and Encapsulating Security Payload (ESP) were originally conceived with IPv6’s header structure in mind. The inclusion of IPsec within the protocol specification has led many to assume that all IPv6 communications must use IPsec, which is not the case. IPsec was also applied to IPv4. However, due to the extensive use of NAT in IPv4 networks, AH is not used as often. Instead, ESP with ESP-HMAC and NAT Traversal is more common. One could argue that IPsec connections using both AH and ESP with IPv6 and global addresses is more secure than IPsec used with IPv4, ESP-only and NAT.
We should remind ourselves that both IPv4 and IPv6 are not intended to provide a secure network-layer transport service. Security is typically left to the lower layers or to the upper layers of the OSI model. The security of IPv4 and IPv6 are equivalent and should be secured equally. A knowledgeable attacker will try to leverage whichever protocol is least protected. The weakest link in the chain is the one that is most likely to break. All things being equal, the attacker will target the protocol that has not been defended properly.
While we are focused on improving the security of IPv6, we should remind ourselves that it is important to secure IPv4, too. In fact, securing IPv4 is probably more urgent because it is the protocol that is ubiquitously deployed in our current production network environments. While we consider the vulnerabilities in IPv6, we should remember that IPv4 ARP has many of the same insecurities. Chapter 6 of “LAN Switch Security: What Hackers Know About Your Switches” by Eric Vyncke and Christopher Paggen has a full description of the security weaknesses in ARP. ARP spoofing can be used to DoS a local LAN, perform an MITM attack, overload a switch CAM table and sniff traffic, and confuse nodes and disrupt traffic flow. Again, these attacks presume that the attacker is on-net or has already compromised a computer on the local segment.
The startling fact is that most organizations have not taken any steps to secure their IPv4 ARP usage. There are several IPv4 LAN security techniques that are not being widely used today. For example, most IPv4 networks are not using Dynamic ARP Inspection (DAI) as a method to detect, stop or rate-limit ARP attacks. DAI is available on traditional Cisco IOS LAN switches and Nexus NX-OS switches. DHCP Snooping is a method of detecting a stopping rogue DHCP servers, but few networks leverage this feature, already available with their Cisco IOS switches or NX-OS switches. IP Source Guard is a technique that can be used in conjunction with DHCP snooping to prevent nodes from sending traffic from any address other than the one assigned by the legitimate DHCP server. Even fewer organizations are using Unicast Reverse Path Forwarding (RPF) for their IPv4 networks. This is a best practice (BCP 84) for IPv4 networks and IPv6 networks alike. While you are deploying Unicast RPF for IPv6, why not deploy it similarly for IPv4 so that you have equal security protections for both protocols?
There are also several LAN switch security techniques that can be applied to networks running IPv4 or IPv6. The benefits of these methods is that they can provide security for both protocols at the same time. Private VLANs can be used to lock down a LAN segment that requires extra protections. IEEE 802.1X can authenticate nodes joining a network with Extensible Authentication Protocol (EAP), assigning the node to the proper VLAN or restricting the node’s communication in other ways. Cisco TrustSec (CTS) or IEEE 802.1AE MACsec are methods of providing authentication, authorization and confidentiality to communications on a LAN.
People should not fear the less-familiar IPv6 protocol. They should educate themselves about the weaknesses in IPv6 and remember the weaknesses in IPv4. Once they know more, then they can start to form a strategy to protect both protocols equally. People who have not taken basic steps to secure their vulnerable IPv4 implementations should not be overly concerned about the IPv6 NDP security vulnerabilities. They should not criticize IPv6 if they have not done their due diligence by first protecting their production IPv4 networks. Many network and security administrators sleep soundly while ignoring the fact that they have vulnerabilities in their IPv4 LANs, but then the next night are restless thinking about the vulnerabilities in IPv6. As we move forward with deploying IPv6 over the coming years, we should do so by leveraging the available techniques to secure NDP and RA messages. Along the way we should also shore up our IPv4 networks and strive for equal protections for both protocols.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/blogs/2015/02/10/holding-ipv6-neighbor-discovery-higher-standard-security.
