IPv6 Focus Month: Filtering ICMPv6 at the Border
Paulgear1 asked on twitter: "help on interpreting RFC4890. I still haven't turned on IPv6 because I'm not confident in my firewall."
First of all, what is RFC4890 all about [1]? The RFC is considered informational, not a standard. Usual guidance for IPv4 is to not block ICMP error messages, but one can get away with blocking all ICMP messages.
The situation is a bit different when it comes to ICMPv6. At first sight, the protocols look very similar. There is a type, a code and a checksum making up the header. But as you dig deeper, the differences become more obvious. First of all, the protocol number for ICMPv6 is 58 (0x3a), not 1 as for ICMPv4. Secondly, the types are defined differently. In part, the ICMPv6 types are defined with firewalls in mind: Messages with a code of 1-127 are considered error messages, and 128 and up are informational messages. [2]
ICMPv6 adds two very important features. It is used for neighbor discovery instead of ARP, router advertisements which are an important part of IPv6 auto configuration. Blocking these link local ICMPv6 messages at a host based firewall is of course a very bad idea, like blocking ARP. But blocking ICMPv6 at the border is an option. Blocking ND and RA messages at a border is usually not necessary as these are sent using link local addresses, and a TTL of 255 is required for the messages to be accepted.
RFC4890 suggests that Destination Unreachable (Type 1), Packet Too Big (Type 2), Time Exceed (Type 3) and Parameter Problem (Type 4) messages must not be dropped. Among these messages, the one that is the most important in IPv6, and different from IPv4 is the "Packet Too Big" message. In IPv4, routers fragment packets and packet too big messages are only used by path MTU discovery. Blocking them will typically not disrupt connections, but harm performance. In IPv6, routers no longer fragment packets. Instead the source does, after receiving a Packet Too Big ICMPv6 message. If they are blocked at the firewall, connection can not be established.
Now there is one trick you can play to eliminate fragmentation of outbound traffic in IPv6: Set your MTU to 1280 bytes. This is the minimum allowed MTU for IPv6, and a packet 1280 bytes long will not require any fragmentation. But this comes at the cost of having to use more and smaller packets, again a performance penalty.
So in short: Is it a good idea to block all ICMPv6 traffic coming into your network? Probably not. The performance penalty has to be carefully weighted against the risk of allowing the packets, which is small. But then again, this is pretty much the case for IPv4 as well.
[1] http://www.ietf.org/rfc/rfc4890.txt
[2] https://tools.ietf.org/html/rfc4443
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments