IPv6 firewall security: Fixing issues introduced by the new protocol

As IPv6 gets rolled out on enterprise WANs, so will IPv6 firewalls. However, IT should be aware of IPv6 security loopholes to adequately protect WANs.

This Content Component encountered an error

As IPv6 gets rolled out on enterprise wide area networks (WANs), so will IPv6 firewalls. This article discusses some security issues introduced by IPv6 and what IT professionals should consider when deploying and operating an IPv6 firewall.

Introducing firewalls to IPv6

The first line of defense of most enterprise networks is a firewall that aims to prevent attacks from the public Internet to the enterprise network, and limits how local users can access the public Internet. As IPv6 is rolled out on enterprise networks, IPv6 firewalls will be deployed so that the same security policies that are currently being enforced in IPv4 are enforced in IPv6.

While IPv6 and IPv4 are very similar in terms of the service they provide -- a best-effort datagram service -- there are some subtle differences between these two protocols that have larger implications on firewall design and operation. This article discusses some of those differences and highlights how they affect the design and operation of IPv6 firewalls. It then explains how these differences might be leveraged for malicious purposes and offers ways to mitigate and eliminate security holes in the IPv6 firewall.

IPv6 header structure

One of the main changes in IPv6 is that the protocol header has a fixed-length rather than a variable-length header like IPv4. Any necessary options must be included in subsequent extension headers, which are inserted between the fixed IPv6 header and the upper-layer protocol encapsulated in IPv6. Different extension headers are used depending on which systems are expected to process the options. For example, options that are meant to be processed by the destination host(s) are included in a "destination options" header, while options meant to be processed by routers are included in a "hop-by-hop options" header. At least in theory, this allows routers and hosts to parse and process only the options meant to be processed by them -- as opposed to IPv4, where all options must be parsed by all nodes handling a packet.

This header structure leads to what is usually known as an IPv6 header chain, in which a number of headers are linked together, one after another, starting with the IPv6 header and ending with the upper-layer protocol. Each extension header contains the length of that specific header and the type of the header that follows next in the header chain. Thus, any IPv6 system can follow the entire IPv6 header chain and process the headers in which it is interested. The figure below features a diagram of an IPv6 header chain:

IPv6 header chain

Figure 1: Example of an IPv6 header chain

One particular type of extension header is the fragment header, which provides the necessary mechanism for implementing IPv6 fragmentation. Rather than have all the fragmentation-related information in the fixed IPv6 header -- as is the case with IPv4 headers -- IPv6 includes such information in an optional fragment header. Thus, hosts performing fragmentation will simply insert a fragment header into the IPv6 header chain, followed by a piece of the original packet that needs to be fragmented.

Security implications on theIPv6 firewall

The aforementioned IPv6 header chain structure allows for more flexibility than IPv4, in the sense that there is no limit on the number of options that any packet can include. However, this flexibility comes at a price.

Any system willing to obtain upper-layer information, such as TCP port numbers, will need to process the entire IPv6 header chain. And since the current protocol specifications allow for an arbitrary number of extension headers, including multiple instances of the same extension header type, it results in a number of implications for devices like firewalls:

  • A firewall may need to parse multiple extension headers in order to perform deep packet inspection (DPI), which could result in degraded WAN performance, denial of service (DoS) or firewall circumvention.
  • The combination of extension headers and fragmentation may prevent deep packet inspection.

As noted above, since the current protocol specifications allow for an arbitrary number of extension headers, including multiple instances of the same extension header type, a firewall must be prepared to gracefully handle packets that contain an unusually large number of IPv6 extension headers. This could be exploited by attackers who could intentionally include an arbitrarily large number of extension headers in their packets so that firewalls employ more resources when processing the aforementioned packets. Eventually, this could result in reduced firewall performance, or a DoS of the firewall itself. Additionally, some poorly implemented firewalls might fail to process the entire IPv6 header chain when trying to enforce a filtering policy, possibly allowing attackers to leverage extension headers to circumvent the corresponding firewall.

IPv6 fragmentation can also be leveraged for malicious purposes in similar ways to its IPv4 counterpart. For example, to circumvent a firewall's filtering policy, an attacker may send overlapping fragments to confuse how these fragments would be reassembled by the destination host. IPv6 exacerbates this problem, since the combination of multiple IPv6 extension headers and fragmentation might result in fragments that, despite their "normal" packet size, could manage to hide even basic information usually needed for enforcing filtering policies, like TCP port numbers. That is, the first fragment of a packet could contain a number of IPv6 options so large that the upper-layer protocol header would belong to some other fragment than the first one.

IPv6 transition/co-existence technologies

IPv6 transition/co-existence technologies present yet another challenge for IPv6 firewalls. Most transition technologies employ some form of tunneling mechanism where some network-layer protocol -- usually IPv6 -- is encapsulated in some other network-protocol, usually IPv4. This has a number of security implications for firewalls.

Firstly, a firewall might be unaware of a specific transition technology, and might fail to enforce the same filtering policy it enforces on native IPv6 traffic. For example, a site might be blocking outgoing packets destined to TCP Port 25 when native IPv4 or native IPv6 is employed, but it might fail to block such packets when a transition mechanism such as Teredo is employed.

Secondly, transition technologies may exacerbate the problem described in the previous sections, since not only could the encapsulated traffic use a combination of IPv6 extension headers and fragmentation, but the outer packet -- usually IPv4 -- might also be fragmented, thus greatly increasing the complexity of the resulting traffic. Such complexity would not only slow down network traffic, it would -- more importantly -- prevent firewalls from enforcing filtering policies. For example, a firewall might not be intelligent enough to process the entire header chain to find the TCP segment (see the figure below). As an example of how complex the resulting traffic might be, the following figure illustrates the syntax of a TCP/IPv6 packet employing Teredo:

TCP/IPv6 packet

Figure 2: Example of an TCP/IPv6 packet employing Teredo.

The structure of this packet would become even more complex if, for example, both the inner and outer packet were fragmented.

Possible IPv6 security mitigations

Clearly, in order to enforce an IPv6 packet filtering policy, firewalls should at the very least support processing of the entire IPv6 header chain. Such firewalls should ideally also support IPv6 transition technologies, so that the same filtering policies that are applied on native IPv6 traffic can be applied on transition traffic. That said, firewalls should implement a "default deny" policy, so that the firewall blocks traffic you didn't take into account, like transition traffic.

Potential resource exhaustion attacks, which leverage the use of multiple extension headers, could be mitigated by enforcing a limit on the maximum number of extension headers that the firewall will allow in any given IPv6 packet. A sensible limit could be to allow one instance of each of the currently defined extension headers. However, some other limit such as “16” could be enforced -- for instance, OpenBSD enforces such a limit. The limit should allow legitimate traffic, while not allowing a ridiculously large number of extension headers. Packets that exceed this limit should be dropped. While this would degrade performance, it would also prevent DoS.

Finally, firewall circumvention techniques that employ fragmentation could be mitigated by requiring the first fragment of an IPv6 datagram to contain the full packet headers needed to enforce a packet filtering policy. That is, if a firewall receives the first fragment of a datagram that fails to contain the full upper-layer header, such as the TCP header, the corresponding packet should be dropped. Firewall circumvention techniques could also be mitigated by having the firewall reassemble fragmented datagrams before applying its filtering policy. However, at least for network-based firewalls, this is generally a discouraged approach, since it introduces potential (DoS vulnerabilities.

Overcoming IPv6 firewall challenges

As noted throughout this article, IPv6 firewalling faces a number of challenges that can be overcome with careful firewall design and operation. IPv6 firewall support should be carefully evaluated when purchasing firewalling devices, since such support varies greatly from product to product, and suboptimal support could have a negative impact on the security of your enterprise network.

For more information: 

This was first published in November 2011

Dig deeper on IP networks

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close