What to do with ICMPv6 (part 1)

All in Context

It has been an established security practice that most, if not all, ICMP messages should be dropped at the firewall. Network reconnaissance and covert channels are two reasons that this is a recommended best practice. With IPv6 and ICMPv6 this changes. The IETF no longer recommends that an "overly aggressive" ICMP filtering policy be in place. ICMPv6 is necessary for the proper functioning of an IPv6 network. RFC 4890 has some excellent recommendations for selectively filtering ICMP traffic at the firewall level.In the next few posts I would like to look at some of the recommendations. First, I need to put these recommendations in context. I will be assuming the user is in a fairly common scenario. A stateful firewall is protecting a subnet of hosts. It is also acting as a router. Hosts behind the router will have both a link-local address (fe80::/10) and a global unicast address (2001:0db8::/32). The rules that I will cover are those that are traversing the firewall. That is traveling from the inside to the outside or vice versa.

What to Allow

By way of review an ICMPv6 message has four fields; Type (1 byte), Code (1 byte), Checksum (2 bytes), and Message Body (variable). Error messages have a Type between 0-127. Informational messages have a Type between 128-255. Within each type there are various codes available. This allows for more granular information to be conveyed.

There are only four basic types of messages that should never be dropped when associated with an existing connection; Destination Unreachable, Packet Too Big, Time Exceeded, and Parameter Problem. We will look at each one.

The first type of messages are Destination Unreachable. There are six codes available for this type of ICMPv6 message. The RFC recommends that they all be allowed through when associated with associated connections. The diagram above is a type code three which is a code of Address Unreachable. Deep packet inspection might be necessary for the detection of covert messages. In the diagram above the unused portion is empty. It should contain as much of the packet that invoked the message as possible to help with debugging. However, there is no reason it could not contain other information such as below.

Packet Too Big messages must also be allowed through the firewall. In IPv6 it is up to the sender to create packet sizes that do not exceed the MTU of any of the links between the source and destination. Therefore, Type 2 ICMPv6 Error Messages should be allowed through the firewall. There is only one Code for these types of messages and it is set to 0.

In IPv6 the TTL header field has been replaced with the Hop Limit field. This makes more sense as the TTL was used to count hops anyway in IPv4. ICMPv6 error messages of Type 3 and Code 0 should be allowed through the firewall. There is a Code 1 for fragment reassembly time exceeded. This should not be allowed.

Finally, error messages of Type 3, Codes 1 (unrecognized next header type encountered) and 2 (unrecognized IPv6 option encountered) should be allowed through. The IPv6 implements the Next Header field in its header to identify the upper lay protocol, such as UDP or TCP, or to identify an extension header, such as a routing header or fragment header. If the host at the other end is unable to process one of these headers it could be possible that it might return a Code 1. ICMPv6 Type 3 and Code 2 applies to the Destination Options and Hop-by-Hop Options. Below is an example of a packet with the Next Header field set to 145. According to IANA this is still unassigned and unlikely to be implemented.

Some of the examples above could be used for probing a network to discover live hosts. With IPv6 this is unlikely to be effective because the address space is so large. However, a more granular policy per host might be in order if the administrator feels it is appropriate.

IPv6 and NAT 2

Many of the new features in IPv6 rely on end-to-end connectivity. Consider the following:

• Fragmentation is no longer handled at the router level. It is negotiated by the hosts before hand.
• Therefore, it is necessary for firewalls to allow Path MTU Discovery (PMTU) (RFC 1981) between communicating hosts.
• Mobile IPv6 requires a consistent Home Address (which must be a global unicast address) and a Care-of Address (which also must be a global unicast address) for our mobile devices to operate when moving between networks.
• Although computationally expensive workarounds are possible, IPSec prefers end-to-end connectivity for confidentiality and integrity.

Network Address Translation is a burden on all of these. I found an interesting presentation by David Kessens and Teemu Savolainen with Nokia about the impact that IPv6 will have on batterly life. In order to keep track of the many private addresses, a NAT device has to maintain a mapping state when a connection is established. In order to keep this mapping state established the end node must send keep-alive packets to let the NAT device know that it isn't finished with the connection. For mobile devices, which are often behind NAT firewalls, this can be a real battery drain. With an IPv6 global unicast address this won't be necessary.

As a side note, firewalls could require a keep-alive for reasons other then NAT. Many stateful firewalls will make use of reflexive ACLs. These will open up a reverse connection inbound for clients behind the firewall that are making a connection outbound. These reflexive ACLs will only be open for a limited amount of time; until the connection is gracefully terminated or a timeout is reached. I mention all of this for completeness sake. IPv6 will not be able to completely eliminate keep-alive packets.

-Chris

IPv6 and NAT 1

As this is my first post on IPv6 security I thought I would tackle a topic that I believe seems to be causing a lot of confusion about IPv6; Network Address Translation. NAT is discouraged in the IPv6 world for a number of reasons which we will get into later. This seems to be scaring a lot of people who are use to the hiding the private addresses of the nodes on the inside of their firewall. With IPv6 every computer can get its own publicly routable IPv6 address. Therefore, the reasoning goes, every host could be reachable by any other host on the outside world.

We should first consider what NAT is, what it was designed for, and what it is not. NAT was created as a fix for the IPv4 address exhaustion. It allowed many computers to share a single IP address through state tables in a NAT firewall. It was NEVER designed for the security of the internal nodes. What it provided was security through obscurity. An attacker didn't know all the internal addresses of a target network. NAT is also not a stateful firewall. While this might seem obvious, I mention because some of the stuff I read from people assume this is going away. This is absolutely not the case, while NAT is discouraged in IPv6 best practices, a stateful firewall is still very much essential. The only difference is that hosts on the inside of it will have a publicly routable IP address. This means attackers will not be able to initiate a connection with them if a stateful firewall is in place and has no other applicable rules.

"Well isn't it better if the attacker doesn't know the IP address of all my clients?"
The answer is that in all likelihood he won't. First let us consider what the attacker will know about you. For the most part IPv6 addressing will be hierarchal. This means that your ISP will be assigned a chunk of addresses that is probably on the order of billions of times greater then the entire IPv4 Internet is now. The idea with hierarchal routing is that the Internet backbone routing tables will be simpler. By using a who is lookup the attacker will be able to tell what prefixes were assigned to your company. Bad news because now he can start scanning them, right? Wrong, remember, this isn't IPv4. The size of the address block that your organization is assigned will make scanning hosts practically impossible and even if you were assigned an address block that was small enough to be effectively scanned you still should have a stateful firewall between you and the attacker.

"But many of my clients still initiate connections to the Internet..."

A big concern is that the anonymity of the hosts on the inside of the firewall could be compromised. Particularly, that websites could track hosts browsing to them because their IP address will never change. This could happen if the address configuration method on the internal network allows it to. In IPv4 there were basically two methods for configuration of an IP address. The administrator can configure each host manually or use DHCP. Both of these are still available in IPv6 but a new feature called stateless address autoconfiguration (SLAAC) allows a host to automatically configure its IPv6 address based on whatever network prefix a router is advertising. SLAAC and DHCPv6 can be configured to have short leases on the address so that they expire quickly. With the huge network space that IPv6 provides selecting a new address should not be a problem. The lower order 64 bits of the 128 bit IPv6 address are called the Interface ID. It can be based on the devices MAC address or it can be generated randomly. For privacy concerns it obviously make sense to do this randomly.

In my next post we will continue to explore more of the IPv6 security considerations given the absence of NAT and why a world without NAT is a better place.