Editor's note: The structure of IPv6 packets has been designed to enable virtually unlimited extensibility of the...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
next-generation networking protocol for the foreseeable future. Unfortunately, experience has shown that the aforementioned flexibility comes at a price -- and that price includes security implications. Leading IPv6 security expert Fernando Gont discusses the security risk posed by IPv6 extension headers and options to reduce that risk.
There are two main limitations in the IPv4 packet structure when it comes to extensibility.
First, IPv4 has a limited option space (of at most 40 bytes), and therefore the packet structure already limits the number and type of extensions that can be implemented with IPv4. Second, all IPv4 options (whether they are meant for routers or hosts) share the same "container," meaning every router forwarding an IPv4 packet must process all IPv4 options, just in case one of the options is meant to be processed by IPv4 routers.
Comparatively, the IPv6 packet structure has changed significantly. When it comes to extensibility, IPv6 options are conveyed in IPv6 "extension headers," rather than in the mandatory IPv6 header (which has a fixed size). An IPv6 extension header is inserted between the mandatory IPv6 header and the upper-layer protocol header. The following diagram illustrates the structure of an IPv6 packet, with two extension headers.
It should be clear from this figure that an IPv6 packet follows a "daisy-chain" structure, in which each IPv6 extension header specifies the type of header that follows (via a "Next Header" field), and each extension header specifies its own length (or has an associated fixed length). Thus, it is possible to traverse the entire IPv6 header chain up to the upper-layer protocol header by starting from the mandatory IPv6 header and following the extension headers one at a time.
The following table illustrates the Next Header values corresponding to some of the most common types of IPv6 extension headers (from the IANA Protocol Numbers registry):
|IPv6 Hop-by-Hop Options||RFC 2460|
|IPv4 encapsulation||RFC 2003|
|IPv6 encapsulation||RFC 2473|
|Routing Header for IPv6||RFC 2460|
|Fragment Header for IPv6||RFC 2460|
|Encap Security Payload (ESP)||RFC 4303|
|Authentication Header (AH)||RFC 4302|
|No Next Header for IPv6||RFC 2460|
|Destination Options for IPv6||RFC 2460|
Options are conveyed in different types of IPv6 extension headers, based on the type of node they are meant to be processed by. For example, options that are expected to be processed by all nodes along the path to the destination are included in a Hop-by-Hop Options extension header. Options that are meant to be processed only by the destination node(s) are conveyed in a Destination Options extension header. Other extension headers may have different uses. For example, the Routing Header is meant to affect how a packet is forwarded toward the destination node(s), and the Fragment Header is employed for the fragmentation/reassembly mechanism.
Some of these extension headers are required to follow a specific order. For example, if a Hop-by-Hop Options header is present, it must be the first extension header following the mandatory IPv6 header. The idea is simple; an extension header that needs to be processed by all nodes along the path to the destination node(s) must come before (in the IPv6 header chain) an extension header that must be processed only by the destination node(s). Thus, an IPv6 router does not need to process all the headers in an IPv6 header chain, but rather stop at the last extension header that contains options to be processed by IPv6 routers.
Furthermore, since a Hop-by-Hop Options header contains only options that must be processed by all nodes along the packet's delivery path, the router will not waste resources processing unnecessary options.
In IPv6, all the fragmentation-related header fields have been removed from the mandatory IPv6 header, and moved to the (optional) "Fragment Header." Conceptually speaking, an original (or "unfragmented") packet is always constructed at the sending node, and only then (if required) will fragmentation occur. The following diagram describes the conceptual structure of an original IPv6 packet:
An original packet is composed of an "Unfragmentable Part" and a "Fragmentable Part." The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by all nodes along the path to the destination node(s), that is, all headers up to (and including) the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. The Fragmentable Part consists of the rest of the packet; that is, any IPv6 extension headers that need to be processed only by the final destination node(s), plus the upper-layer header and data. The Unfragmentable Part will be present in all of the resulting fragments, while the Fragmentable Part will be split into multiple fragments. Each of the fragments is thus constructed by "concatenating" the Unfragmentable Part of the original packet with a Fragment Header and a piece of the Fragmentable Part. The following figure illustrates how a packet is fragmented into multiple IPv6 fragments, based on the logic described above:
Finding upper-layer protocol information
Every router or middle-box that is required to enforce a simple access control list (ACL) on IP packets must be able to find the upper-layer protocol header that typically contains source and destination port numbers. The packet structure of IPv4 makes it easy for a node to find the upper-layer protocol header: The processing node can simply "skip" the option space by skipping as many bytes from the IPv4 header as indicated by the "Internet Header Length" field of the IPv4 header.
In the case of IPv6, however, there is no "pointer" to the upper-layer protocol header. Therefore, the only way to find the upper-layer protocol header is to start at the mandatory IPv6 header and process/follow each of the extension headers in the IPv6 header chain until the last header is found.
It should be noted that, until recently, the process used to be even trickier than that: The IPv6 header chain itself could be fragmented, with the extension headers and the upper-layer protocol header being split into multiple fragments. Thus, it was impossible for a stateless device (i.e. a device that did not perform fragment reassembly prior to inspection) to obtain the upper-layer protocol information. For example, the following packet used to be considered valid:
Fortunately, RFC 7112, published in early 2014, has declared such packets illegal, and hence up-to-date implementations do not need to worry about them (and can instead drop them).
Security implications of IPv6 extension headers
The security implications of IPv6 extension headers generally fall into one or more of these categories:
- Evasion of security controls
- Denial-of-service conditions due to processing requirements
- Denial-of-service conditions due to implementation errors
- Issues that are specific to each extension header
As discussed in the previous section of this article, finding the upper-layer protocol header in an IPv6 packet can prove to be a difficult task. Even worse, some middle-boxes and security devices are known to expect the upper-layer protocol header to follow the mandatory IPv6 header, and hence fail to find or recognize the upper-layer protocol when IPv6 extension headers are employed. For example, such security device or middle-box could fail to recognize that the following packet is a TCP segment, simply because a Destination Options extension header is being employed:
The reason for such failure is that, rather than processing the entire IPv6 header chain to find the upper-layer header, the aforementioned devices assume that the upper-layer protocol type is described/indicated by the "Next Header" field of the mandatory IPv6 header. Thus, the packet in the figure above would be considered to be a "Destination Options" packet rather than a TCP segment.
Security devices that implement this (buggy) logic and that have also been configured to enforce a "default-allow" policy (i.e., allow all packets unless they match one of the specified rules) will be subject to evasion attacks. A simple variation of this attack is one in which a packet employs multiple IPv6 extension headers, or one large extension header to trigger a different issue at a number of implementations. Some implementations enforce a limit on the number of extension headers they will process, or have an implementation-specific limit regarding "how many bytes into an IPv6 packet" they can inspect. Such scenarios are illustrated in the following figures:
An implementation that enforces one or both of these limits and also enforces a "default-allow" policy will also be subject to evasion attacks. Ambiguity in how some corner-case packets can be processed represent yet another vector for the evasion of security controls.
IPv6 fragmentation can also be leveraged to perform evasion attacks by concealing either the upper-layer protocol type (as explained in the previous section) or by concealing the application data stream. During the last few years, different implementations have been found to be vulnerable to many of these evasion techniques. For example, RFC 7113 describes this issue for the RA-Guard case, but the same techniques can be employed for circumventing some IPv6 firewalls. Additionally, inconsistencies in how some packets may be processed may result in the evasion of security controls, as noted in detail by Panos Kampanakis of Cisco Systems Inc. and researcher Antonios Atlasis.
IPv6 extension headers may have a negative performance effect on the handling of devices. While this may not seem like a security concern, it requires careful consideration. For example, IPv6 router implementations typically process packets that contain a Hop-by-Hop Options extension header in software (rather than in hardware). Other IPv6 router implementations are known to process packets employing IPv6 extension headers in software when they are configured to enforce ACLs. This means that, unless appropriate mitigations (such as packet filtering and/or rate-limiting of packets employing extension headers) are in place, an attacker could simply send large amounts of IPv6 traffic employing IPv6 extension headers to perform a denial-of-service (DoS) attack.
While the IPv6 protocol itself (and many implementations) have been around for many years already, bugs in the processing of IPv6 extension headers have been recently found in a number of implementations. A likely reason for why such bugs have been found only recently is that most extension headers are not really employed in real-world traffic, and hence the corresponding code is rarely exercised. For that reason, it should not be surprising that bugs in the processing of IPv6 extension headers still remain to be discovered in some implementations.
Finally, besides the general security implications of IPv6 extension headers, each extension header type tends to come with its own specific implications. For example, security researchers reported in 2007 how the use of the (now deprecated) Routing Header Type 0 could be employed to perform DoS attacks. Another extension header with well-known security implications is the Fragment Header, which is employed for the fragmentation/reassembly function in IPv6. While many of the security implications of the fragmentation/reassembly mechanism are known from the IPv4 world, many of the related issues have crept into IPv6 implementations, ranging from DoS attacks to information leakage or evasion attacks (for more detail, see my recent IETF draft on predictable fragment identification values and a Black Hat Europe 2012 presentation by Antonios Atlasis.
Many -- if not most -- of the security implications arising from IPv6 extension headers tend to be associated with how the corresponding support has been implemented: from buggy code, to devices that process extension headers in software (rather than in hardware). Some implementations may offer mitigation techniques, such as the ability to rate-limit packets that employ IPv6 extension headers (thus dropping the excess traffic before a DoS condition is met). In other cases, an administrator may have no other option other than filtering the corresponding traffic. Clearly it represents an area of concern that enterprise network security professionals must follow closely as IPv6 network rollouts continue.
About the author:
Fernando Gont currently works for SI6 Networks as an Internet security and engineering consultant. He is an active participant at the Internet Engineering Task Force, where he contributes to several working groups, and has authored a number of RFCs (Request for Comments) and Internet-Drafts. Gont is a regular speaker at a number of conferences, trade shows, and technical meetings, about information security, operating systems, and Internet engineering. More information is available at his website: http://www.gont.com.ar