The security of IPv4 is roughly equivalent to IPv6.\u00a0 So why do we expect more from IPv6?<\/p>\n
When people embark on learning about IPv6, they are intrigued with how different the IPv6\u00a0Neighbor Discovery Protocol<\/a>\u00a0(NDP) (RFC 4861<\/a>) is from the IPv4 Address Resolution Protocol (ARP) that they are already familiar with.\u00a0 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.\u00a0 IPv6 NDP is critical to how nodes obtain their IPv6 addresses, join the network, and send their packets off-net.<\/p>\n 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.\u00a0 It is trivial to spoof\u00a0Router Advertisement<\/a>\u00a0(RA) messages causing hosts to engage IPv6, or to renumber an existing IPv6 network, or even perform a Man-In-The-Middle (MITM) attack.\u00a0 It is also possible to forge Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages to confuse link-local nodes and corrupt neighbor caches.\u00a0 These problems are well documented in \u201cOperational Neighbor Discovery Problems\u201d (RFC 6583<\/a>).\u00a0 These issues are far from new.\u00a0 The industry has been aware of the insecurities in NDP for almost 15 years.<\/p>\n Network and security administrators get really excited about these security vulnerabilities in IPv6 NDP.\u00a0 Their minds start to race thinking about the possibilities this represents for a determined attacker.\u00a0 Some even start to panic and consider halting their IPv6 deployment because of these security issues with NDP.\u00a0 My suggestion is similar to what Douglas Adams might say: \u201cDon\u2019t Panic<\/a>\u201d.\u00a0 Take a deep breath, learn more about the details of IPv6 and NDP, and then deploy security measures to help mitigate the vulnerabilities.\u00a0 In other words,\u00a0Keep Calm<\/a>\u00a0and IPv6 On!<\/p>\n 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.\u00a0 That presumes that the attacker is already on the internal network.\u00a0 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.\u00a0 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\u2019s presence.<\/p>\n In response to these NDP vulnerabilities, much work has been done to monitor and help secure the use of IPv6 NDP.\u00a0 Some of this work to improve the situation has been done by the IETF.\u00a0 The first idea that was developed was the\u00a0Secure Neighbor Discovery<\/a>\u00a0(SEND) protocol.\u00a0 Wired and wireless network equipment manufacturers have also developed functions into their products to block and alert on these types of NDP attacks.\u00a0 For example, Cisco has put tremendous effort into their\u00a0First Hop Security<\/a>\u00a0(FHS<\/a>) measures implemented in switches, routers, and wireless LAN controllers to help secure IPv6 nodes.<\/p>\n The\u00a0Router Advertisement<\/a>\u00a0(RA) is an important part of how an IPv6-capable node will join an IPv6 network. It\u2019s also a well-known and popular IPv6 weakness.\u00a0 The IETF RFC titled \u201cRogue IPv6 Router Advertisement Problem Statement\u201d (RFC 6104<\/a>) describes how an attacker can generate crafted RA messages to disrupt a LAN or gain an MITM position.\u00a0 In response to this problem, the IETF worked on IPv6 Router Advertisement Guard (RA Guard) (RFC 6105<\/a>) as a technique within Ethernet switches and other network devices to permit only the legitimate RAs from the local IPv6 router to be forwarded.\u00a0 RA guard will then block any other RA packets originating from any downstream node on the LAN.\u00a0 The IETF has continued their work on the subject by publishing \u201cImplementation Advice for IPv6 Router Advertisement Guard (RA-Guard)\u201d (RFC 7113<\/a>).\u00a0 Other improvements have come in the form of limiting fragmentation of NDP messages, outlined in \u201cSecurity Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery\u201d (RFC 6980<\/a>).<\/p>\n This same technique can be implemented by\u00a0Cable Modem Termination Systems<\/a>\u00a0(CMTSs), Wireless LAN Controllers (WLCs<\/a>), or simply as a software application running on a node on the LAN.\u00a0 There are many software tools that can help detect rogue RA messages and detect NDP funny business. These tools include\u00a0NDPMon<\/a>,\u00a0ramond<\/a>,\u00a0Kame rafixd<\/a>,\u00a06Guard<\/a>,\u00a0addrwatch<\/a>,\u00a0SLAACer<\/a>, and\u00a06MoN<\/a>.\u00a0 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.\u00a0 Judging by the length of this list, there is significant interest in this topic.<\/p>\n People sometimes get the impression that IPv6 is inherently more secure than IPv4.\u00a0 This has to do with the fact that\u00a0IPsec<\/a>\u00a0was developed around the concept of IPv6 and its extension header convention.\u00a0 Authentication Headers (AH) and Encapsulating Security Payload (ESP) were originally conceived with IPv6\u2019s header structure in mind.\u00a0 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.\u00a0 IPsec was also applied to IPv4.\u00a0 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.\u00a0 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.<\/p>\n We should remind ourselves that both IPv4 and IPv6 are not intended to provide a secure network-layer transport service.\u00a0 Security is typically left to the lower layers or to the upper layers of the\u00a0OSI model<\/a>.\u00a0 The security of IPv4 and IPv6 are equivalent and should be secured equally.\u00a0 A knowledgeable attacker will try to leverage whichever protocol is least protected.\u00a0 The weakest link in the chain is the one that is most likely to break.\u00a0 All things being equal, the attacker will target the protocol that has not been defended properly.<\/p>\n While we are focused on improving the security of IPv6, we should remind ourselves that it is important to secure IPv4, too.\u00a0 In fact, securing IPv4 is probably\u00a0more\u00a0<\/em>urgent because it is the protocol that is ubiquitously deployed in our current production network environments.\u00a0\u00a0 While we consider the vulnerabilities in IPv6, we should remember that IPv4\u00a0ARP<\/a>\u00a0has many of the same insecurities.\u00a0 Chapter 6 of \u201cLAN Switch Security: What Hackers Know About Your Switches<\/a>\u201d by Eric Vyncke and Christopher Paggen has a full description of the security weaknesses in ARP.\u00a0\u00a0ARP spoofing<\/a>\u00a0can be used to DoS a local LAN, perform an MITM attack, overload a switch\u00a0CAM<\/a>\u00a0table and sniff traffic, and confuse nodes and disrupt traffic flow.\u00a0 Again, these attacks presume that the attacker is on-net or has already compromised a computer on the local segment.<\/p>\n The startling fact is that most organizations have not taken any steps to secure their IPv4 ARP usage.\u00a0 There are several IPv4 LAN security techniques that are not being widely used today.\u00a0 For example, most IPv4 networks are not using Dynamic ARP Inspection (DAI) as a method to detect, stop or rate-limit ARP attacks.\u00a0 DAI is available on traditional Cisco\u00a0IOS LAN switches<\/a>\u00a0and\u00a0Nexus NX-OS switches<\/a>.\u00a0 DHCP Snooping is a method of detecting a stopping rogue DHCP servers, but few networks leverage this feature, already available with their\u00a0Cisco IOS switches<\/a>\u00a0or\u00a0NX-OS switches<\/a>.\u00a0\u00a0IP Source Guard<\/a>\u00a0is 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.\u00a0 Even fewer organizations are using Unicast Reverse Path Forwarding (RPF<\/a>) for their IPv4 networks.\u00a0 This is a best practice (BCP 84<\/a>) for IPv4 networks and IPv6 networks alike.\u00a0 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?<\/p>\n There are also several LAN switch security techniques that can be applied to networks running IPv4 or IPv6.\u00a0 The benefits of these methods is that they can provide security for both protocols at the same time.\u00a0\u00a0Private VLANs<\/a>\u00a0can be used to lock down a LAN segment that requires extra protections.\u00a0 IEEE\u00a0802.1X<\/a>\u00a0can authenticate nodes joining a network with Extensible Authentication Protocol (EAP), assigning the node to the proper VLAN or restricting the node\u2019s communication in other ways.\u00a0\u00a0Cisco TrustSec<\/a>\u00a0(CTS) or IEEE\u00a0802.1AE MACsec<\/a>\u00a0are methods of providing authentication, authorization and confidentiality to communications on a LAN.<\/p>\n People should not fear the less-familiar IPv6 protocol. \u00a0They should educate themselves about the weaknesses in IPv6 and remember the weaknesses in IPv4.\u00a0 Once they know more, then they can start to form a strategy to protect both protocols equally.\u00a0 \u00a0\u00a0People who have not taken basic steps to secure their vulnerable IPv4 implementations should not be overly concerned about the IPv6 NDP security vulnerabilities.\u00a0 They should not criticize IPv6 if they have not done their due diligence by first protecting their production IPv4 networks.\u00a0 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.\u00a0 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.\u00a0 Along the way we should also shore up our IPv4 networks and strive for equal protections for both protocols.<\/p>\n","protected":false},"excerpt":{"rendered":" The security of IPv4 is roughly equivalent to IPv6.\u00a0 So why do we expect more from IPv6? When people embark on learning about IPv6, they are intrigued with how different the IPv6\u00a0Neighbor Discovery Protocol\u00a0(NDP) (RFC 4861) is from the IPv4 Address Resolution Protocol (ARP) that they are already familiar with.\u00a0 For instance, IPv6 uses multicast […]<\/p>\n","protected":false},"author":321,"featured_media":2788,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[16,38,15],"class_list":{"0":"post-3071","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-infoblox","9":"tag-ipv6","10":"tag-security","11":"entry"},"acf":[],"yoast_head":"\n