Today we continue with part 2 of the 10 part series on IPv6 Security Myths by debunking one of the myths I overhear people propagating out loud far too much: That you don\u2019t need to worry about security because IPv6 has it built into the protocol. In this post, we\u2019ll explore several of the reasons that this is in fact a myth and look at some harsh realities surrounding IPv6 security.<\/p>\n
Myth: IPv6 Has Security Designed In<\/strong> The IPv6 protocol was primarily developed in the late 1990\u2019s. In fact, RFC 2460, the \u201cInternet Protocol, Version 6 (IPv6) Specification\u201d is dated December 1998. This was a time when the commercial Internet had just started to flourish; security threats at this time were not anywhere near the sophistication and scale of threats common today.<\/p>\n While updates have been made to the protocol since 1998, the bottom line remains that relying on developers working well over a decade ago to protect you from security threats today and into the future is simply irresponsible.<\/p>\n This is the point where someone invariably points out that IPv6 requires IPsec (Internet Protocol Security), but\u2026<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> IPsec, which provides end-to-end per-packet IP layer authentication and encryption, has worked with both IPv6 and IPv4 since it was first standardized in RFC2401. This means that IPsec exists for IPv4 and that deploying it in IPv6 brings feature parity, not necessarily an enhancement.<\/p>\n The fact that IPv6 requires IPsec does mean that it\u2019s available for use on all IPv6 capable devices, which is a step up over IPv4. It does not, however, guarantee the use of IPsec, which is what actually provides security. The responsibility remains with the application developer, the systems administrator, and the end user to actively apply IPsec for authentication and encryption.<\/p>\n [Correction 26 January: IPv6 no longer requires IPsec. Section 11 of RFC 6434<\/a>, which obsoletes RFC 4292 on IPv6 Node Requirements, now states that IPsec SHOULD be supported (vs. the previous MUST). When I speak on this topic I usually point out that IPsec was required when many devices and applications with existing IPv6 support implemented it and that new implementations are still recommended<\/a> to include IPsec support. These two facts combine to mean that although IPsec is no longer strictly required in every IPv6 node, it is still generally available pretty much everywhere it would be useful. The fact remains:]<\/em><\/p>\n You must actively use IPsec for it to provide any security whatsoever.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> In order to make IPv6 as simple and interoperable as possible, it uses a minimalist standard packet header<\/a>. In order to make IPv6 as extensible as possible, it allows \u201cextension headers,\u201d additional chunks of meta-data that can be strung behind the IP header to provide additional features and functionality. IPsec leverages the extension header mechanism to carry necessary authentication and encryption data, for one example.<\/p>\n Unfortunately, having extension headers designed into the protocol for extensibility also means having security flaws designed in along with them.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> The first example of this is Routing Header Type 0 (RH0), which is an extension header that facilitates source routing. That is, allowing the sender to determine the path the packet takes across the network, rather than allowing the routers to route the packet naturally.<\/p>\n This functionality can be abused. For example you could potentially \u201cprogram\u201d a packet, or a string of packets, to \u201cbounce\u201d back and forth between two routers \u2013 potentially exhausting the available bandwidth on that link. Luckily, this threat was identified and RH0 was deprecated in RFC 5095<\/a>:<\/p>\n The functionality provided by IPv6’s Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic.<\/p><\/blockquote>\n Although RH0 has been deprecated, there is always a chance of older or unpatched networking gear being affected by a source routing attack using RH0. Therefor, you should always discard packets using RH0, and any other extension headers that may be deprecated in the future as well.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> Another potentially problematic extension header is the Hop-by-Hop option header. As the name implies, this header is intended to provide options at every hop along the packet\u2019s path. In other words, every IPv6 node that inspects, routes, or otherwise looks at the IP header must process the Hop-by-Hop option header. Most interestingly, perhaps, is that the Hop-by-Hop option header is generic and is designed to be filled with sub options, or TLVs (Type-Length-Values). These TLVs are unrestricted and unlimited, meaning you can stuff virtually any amount of virtually any data into the Hop-by-Hop option header.<\/p>\n In sum, this means that the Hop-by-Hop option header can be used to pull off an effective low-bandwidth Denial of Service (DoS) attack. The threat is detailed in an expired IETF Internet Draft, \u201cThe case against Hop-by-Hop options<\/a>:\u201d<\/p>\n The denial of service attack can be carried out by forming an IP datagram with a large number of TLV encoded options with random option type identifiers in the hop-by-hop options header.<\/p><\/blockquote>\n This extension header has not been deprecated and may have valid uses on your network, so each network will need to deliberately decide how to mitigate this threat. Two popular options are discarding packets with the Hop-by-Hop header and rate-limiting packets with the Hop-by-Hop header, particularly when router CPE usage is high.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> Beyond the two specific extension header types detailed above, there are vulnerabilities that come with using extension headers at all. Stuffing tons of bits into an unnaturally large header, adding multitudes of individual headers to a single packet, and using invalid extension headers are all methods of attack.<\/p>\n Because extension headers are part of the IP packet, they must be identified and dealt with by at least some of the nodes on any IPv6 path. This means that IPv6 routers, firewalls, and other networking devices can have their CPU and memory resources exhausted dealing with malicious extension headers.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> Another one of the major enhancements to IPv6 (beyond address length and header structure) is Neighbor Discovery<\/a> (ND). ND basically replaces the smattering of ICMP and ARP used by IPv4 with a more comprehensive, unified approach.<\/p>\n Unfortunately, as you may have guessed, there are some potential vulnerabilities in ND. Due to its trusting, on-net focus, attackers who gain access to a victim\u2019s Local Area Network (LAN) can use ND to attack other hosts on that LAN. Forged ND messages can be used to glean information about other hosts, re-direct traffic, renumber other hosts, and even intercept traffic or launch a man in the middle attack. ND can also be exploited<\/p>\n Rogue Router Advertisements (RAs) have the potential to be particularly problematic. That threat is detailed in RFC 6104<\/a>:<\/p>\n However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem.<\/p><\/blockquote>\n Your primary defense against most ND based attacks is preventing unauthorized LAN access (and misconfigurations) in the first place.<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> There is another NDP attack that does not necessarily require LAN access (although it makes it much easier). Just like ARP tables in IPv4, IPv6 routers and switches must keep track of LAN hosts. This is all done with NDP in IPv6. The problem arises from the fact that IPv6 networks have many, many more addresses than many switches and routers have NDP entries, so firing off packets with random source and\/or destination addresses can trivially flood many devices\u2019 neighbor cache. This results in a form of DoS on the network under attack.<\/p>\n Because Secure Neighbor Discovery (SeND) is not widely implemented, possible mitigations include using devices that are not vulnerable, blocking the source of the malicious traffic, using subnets smaller than a \/64 (this has it\u2019s own complications currently), and\/or using static NDP entries. Beyond that, we need to demand more NDP configuration knobs from our vendors, to provide more granular control (logging, limiting, policing).<\/p>\n Myth: IPv6 Has Security Designed In<\/strong> Finally, with all of that said, it is crucial to remember that buffer overflows, database injections, cross-site scripting, phishing, SPAM, DNS amplification, and many more of the most common attacks happen at layers above, or below, the IP layer. In other words, many attacks are completely unaffected by which version of IP you are using.<\/p>\n The bottom line is that securing an IPv6 host or IPv6 network does not happen automagically. It takes the same forethought and diligence required to secure any valuable asset. We\u2019d like to give you a head start in that process with our IPv6 security resources<\/a>, part of the Deploy360 portal<\/a>.<\/p>\n This post also appears on the Deploy360 blog<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
\n Reality: IPv6 was Designed 15-20 Years Ago<\/strong><\/p>\n
\n Reality: IPsec is Not New<\/strong><\/p>\n
\n Reality: Extension Headers are Designed In<\/strong><\/p>\n
\n Reality: Source Routing was Designed In<\/strong><\/p>\n
\n Reality: The Hop-by-Hop Option Header is Designed In<\/strong><\/p>\n
\n Reality: Extension Headers are Vulnerable in General<\/strong><\/p>\n
\n Reality: Neighbor Discovery is Vulnerable to LAN Attacks<\/strong><\/p>\n
\n Reality: Neighbor Discovery is Vulnerable<\/strong><\/p>\n
\n Reality: Many Attacks have Nothing To Do with IP<\/strong><\/p>\n