The Internet is a packet switching network that uses IPv4 and/or IPv6 as its network communication protocol. Data that is being sent over the Internet is divided into smaller chunks that are individually sent in the form of packets. Sometimes the packets that are being sent are too big to be handled by the intermediate routers. The intermediate router needs to tell the sender to decrease his packet size. The way of telling the sender to decrease his packet size is via an ICMP error message.
This blog post will discuss the security implications of such communication from both an IPv4 and IPv6 standpoint.
The PMTU discovery process
The path between a sender and receiver can be built up from several different link technologies, each one of them capable of carrying a different amount of data in each packet. The maximum amount of data each link can carry is considered that links’ Maximum Transfer unit or MTU. The PMTU is determined by the MTU of the link that has the lowest MTU in the path, just like the strength of a chain is determined by the strength of its weakest link. For efficiency purposes it is of course good if the sender can use as high transfer unit as possible. Therefore a process is defined in both IPv4 and IPv6 to find out the maximum packet size that can be used. This process is called Path MTU discovery.
The PMTU discovery process works almost the same in IPv4 and IPv6. When a sender sends a packet towards the destination it will traverse several intermediate routers. If an intermediate router can’t handle the packet because it exceeds the MTU of the link, it will send an ICMP “packet too big” message back to the sender. When the sender receives the “packet too big” error message, it decreases the size and resends the packets. The new size is then used for all forthcoming packets to that destination. This behavior is about the same for both IPv4 and IPv6.
There are some security problems with the communication that is needed for PMTU to work:
First of all, the ICMP “packet too big” error message that the router is sending back has the source IP-address of the intermediate router. This is typically an IP-address somewhere inside of an operator’s network in the path between the source and destination. There is no way for the sending organization to keep track of all potential intermediate router IP-addresses for all possible paths to all possible destinations. Instead, this needs to be handled in firewalls as a wildcard rule that accept ICMP “packets too big” messages to ANY destination from ANY source. Obviously big holes in the firewalls need to be opened.
Secondly, this type of communication is different from most other communications as you typically only expect responses from the one you are communicating with and not with intermediate routers. Firewalls and other filtering products usually keep track of ongoing connections and only allow incoming packets that correspond to an already established connection.
Third, if Network Address Translation (NAT) is used somewhere in the path, there is no way for that NAT device/firewall to know to whom to forward the error message to. There is no translation state in the NAT device/firewall that has any data as this packet was created outside of any ongoing communication.
Looking at the above issues, it is obvious that it is very difficult to make the PMTU process work in a secure manner. This is why most IPv4 networks network administrators just block all incoming ICMP packets. The side effect is that the PMTU process stops working. However, there is a feature in IPv4 that saves the day. This feature is called fragmentation. In IPv4 an intermediate router can in most cases fragment a packet into two or more smaller ones. This can be done instead of sending an ICMP “packet too big” error message, thus avoiding the issues discussed above.
Fragmentation introduces a whole lot of other issues. The receiver must reassemble all the fragmented packages and deal with issues such as fragments arriving in different order, etc. Fragmentation can also be used by bad guys to trick security devices such as Intrusion Detection Systems to not detect attack patterns.
When IPv6 was designed it was decided to remove fragmentation as a possibility. Instead the PMTU process described above is mandatory and you can no longer blocks ICMP “packet too big” messages in the firewall without breaking things.
To open up your firewall for ICMP “packet too big” messages in IPv6 networks might seem harmless at first glance but once you examine the details you will find that there are some security issues. Let me first point out that ICMP packets, just like UDP, are trivial to spoof. There is no three way handshake like in TCP to prevent spoofed packets. So with ICMP it is possible for the sender to be anonymous.
A simple attack would be to send unsolicited ICMP “packet too big” messages to make the victim use a lower PMTU than possible. This would affect the performance of the victim but would in most cases not be considered a severe attack.
Another and more severe issue with the ICMP “packet too big” message is that it can carry payload. The RFC states that payload should be a copy of as much of the original packet as possible, but this is really hard for a firewall to check. It is possible for a bad guy to sneak in arbitrary messages in the payload, for example, to communicate and send commands or code to a Bot on a client inside of the firewall. This can, as I pointed out, be done anonymously.
This is very different from IPv4. In IPv4, a Bot inside a network would need to communicate outbound to be able to check if there is any new command or code to execute. This traffic is first of all detectable with firewalls and tools like webproxies (if you see a lot of traffic from your clients to an IP address in Bangladesh, you might want to investigate what is going on). Secondly, it reveals the IP-address of the bad guy’s update server. That piece of information is useful for law enforcers to track the bad guys down.
IPv6 has several advantages over IPv4. The most significant change introduced by IPv6 is that the address space increased from 32 bits to 128 bits. This is usually the only change people know about. There are many more changes IPv6 and some of them introduce new ways of handling traffic.
Vendors of IPv6 equipment must have a deep understanding of the underlying protocol to be able to secure the communication. To just retrofit IPv4 products to handle IPv6 packets doesn’t work. Firewalls and other equipment need to be able to filter packets in a completely new way.
When implementing IPv6 organizations must make a thorough analysis of the security impact. This along with other challenges make migrating to IPv6 a huge undertaking that will take several months, if not years for an average organization.
As we are running out of IPv4 addresses quickly I urge everybody to start addressing these challenges as soon as possible.