ICMP and Security in IPv6
In the previous installment of our series of IPv6 posts, we covered some common myths regarding IPv6. In this post, we’ll talk about how the role of ICMP has changed in IPv6 compared to IPv4.
In IPv4, ICMP provides error reporting, flow control and first-hop gateway redirection. This functionality, which is also available in IPv6, is usually not essential to the operation of your network. With IPv6, however, ICMP has gained a much more significant and essential role because of new functionality that is now performed through ICMP. Fragmentation, Neighbor Discovery, and StateLess Address AutoConfiguration (SLAAC) represent essential functionality which is now performed using ICMP messages. Furthermore, many ICMP messages are designed to be sent to multicast addresses instead of only unicast addresses. Therefore, ICMP in IPv6 gains a whole new importance along with a new set of security concerns.
In IPv6, fragmentation is only performed by end hosts. So, if a router receives a packet that is too large for a link, then it drops the packet and notifies the originating system that the packet needs to be fragmented. It does this by sending an ICMP Type 2 “Packet Too Big” message to the originating host. Therefore, in IPv6 networks, ICMP traffic needs to be allowed throughout the entire data path to support fragmentation. This means that even from external networks, you must allow at least ICMP Type 2 packets into your network. This will require a change in the access control lists used on your network, which can potentially lead to opening your network up to flooding attacks.
IPv4 utilized ARP to handle the translation of addresses from Layer 3 to Layer 2. IPv6 eliminates ARP and replaces it with RFC 2461, Neighbor Discovery Protocol (NDP). NDP enables functions such as address resolution, next-hop discovery, router discovery, address prefix discovery, parameter discovery, neighbor unreachability detection and duplicate address detection. IPv6 also provides StateLess Address AutoConfiguration (SLAAC), RFC 2462, to allow hosts to automatically generate addresses with no end user interaction. NDP and SLAAC are performed using the following five ICMP messages:
- Type 133 – Router Solicitation (RS)
- Type 134 – Router Advertisement (RA)
- Type 135 – Neighbor Solicitation (NS)
- Type 136 – Neighbor Advertisement (NA)
- Type 137 – Route Redirection
Most of these messages can be sent to either a unicast or multicast address, which enables NDP and SLAAC to happen efficiently. For instance, whenever a host automatically generates an IPv6 address (either link local or global), the host sends a NS message to the all-nodes multicast address (FF02::1). If any host is using the address, then it will respond with a NA message to indicate that the address is already in use. Hosts can also automatically locate routers on the local segment by sending out a RS message to the all routers multicast address (FF02::2). The local router(s) will respond with a RA message, providing prefix addresses, as well as the address of the local router and other network parameters. Using RA messages, routers can also easily and efficiently update the prefix address used by all of the hosts on the network.
Although efficient, NDP and SLAAC represent a significant security risk in IPv6. IPSec, which is mandated by the IPv6 specifications, is not suited to easily secure these ICMP messages because of the need to manually configure the IPSec keys. Without IPSec protection, each of these ICMP messages is easily spoofable (similar to ARP spoofing in IPv4). This leaves NDP and SLAAC open to various attacks, such as the following:
- Attacker can claim to be another host’s address using Neighbor Solicitation Messages
- Attacker can claim to be the default router using Router Advertisement Messages
- Attacker can claim all addresses using Neighbor Solicitation Messages, preventing hosts from getting an address
- Attacker can advertise false prefixes using Router Advertisement Messages
You can get more information on these attacks by reviewing RFC 3756, “IPv6 Neighbor Discovery (ND) Trust Models and Threats.” To help overcome these threats, Secure Neighbor Discovery (SeND) was developed.
RFC 3971, Secure Neighbor Discovery (SeND), is a mechanism to secure NDP and SLAAC without using IPSec. Basically, SeND uses RSA key pairs instead of IPSec to secure the various ICMP messages. When SeND is used, each host generates a cryptographically generated address (CGA) in the lower 64 bits of the IPv6 address (Interface Identifier). The host also adds a CGA Option to the ICMP messages that enable other hosts to verify that the message came only from the host that has the corresponding RSA private key. Through the addition of two new Neighbor Discovery-specific ICMP options (Timestamp and Nonce), SeND also prevents replay attacks. Although SeND is a good start at providing stronger security to the ICMP messages, it is not without limitations. First, not all devices currently support SeND. Unless all of the devices on a local network support SeND, the network will still be potentially vulnerable to attack. Furthermore, deploying SeND has various issues to consider based on your network topology. Simply deploying SeND without providing the ability for hosts to verify that a device is designated as a router and allowed to offer specific address prefixes still leaves your network open to router impersonation attacks.
Well that’s all for now. Hopefully this post has provided you with an understanding of ICMP in IPv6 that you can use when deploying IPv6 on your network. Securing ICMP in IPv6 is definitely a much more complicated task than securing ICMP in IPv4 was. Stay tuned for the next IPv6 post on how addressing has changed in IPv6.