Should I block ICMP?



No!!




The Problem

Many network administrators feel that ICMP is a security risk, and should therefore always be blocked at the firewall. It is true that ICMP does have some security issues associated with it, and that a lot of ICMP should be blocked. But this is no reason to block all ICMP traffic!

ICMP has many important features; some are useful for troubleshooting, while some are essential for a network to function correctly. Here are details of some of the important ICMP traffic that you should know about, and consider allowing through your network.


Echo Request and Echo Reply
IPv4 - Echo Request (Type8, Code0) and Echo Reply (Type0, Code0)
IPv6 - Echo Request (Type128, Code0) and Echo Reply (Type129, Code0)

We all know these ones - ping is one of the first troubleshooting tools that we all learn. Yes, if you enable it, it means that your host is now discoverable - but wasn't your web server already listening on port 80 anyway? Sure, block this if you really want at your border to your DMZ, but blocking ping traffic inside your network isn't going to get you much, except harder troubleshooting ("Can you ping your default gateway?", "No, but I never can, so that doesn't tell me anything!").

Remember you can also allow this with a given direction in mind; you could decide to let Echo Requests out from your network to the Internet, and Echo Replies from the Internet to your network, but not vice versa.


Fragmentation Required (IPv4) / Packet Too Big (IPv6)
IPv4 - (Type3, Code4)
IPv6 - (Type2, Code0)

These ones are important. VERY important. They are an essential component in Path MTU Discovery (PMTUD), which is an essential part of TCP that allows two hosts to adjust their TCP Maximum Segment Size (MSS) value to one that will fit in the smallest MTU along the path of links between the two hosts. If two hosts have a smaller MTU than their own local link on the path between them, and have no means of discovering this, traffic gets silently black-holed; in other words, "you're gonna have a bad time".

IPv4 packets with the DF bit set (that's most of them!), or IPv6 packets (remember there's no fragmentation by routers in IPv6), that are too large for a router to transmit across an interface will result in that router dropping the packet, and generating a Fragmentation Required / Packet Too Big ICMP error back to the source, which also contains the MTU of the too-small link. If this error cannot get through to the sender, then the sender will just interpret the lack of ACKs from the receiver as congestion/loss and re-transmit, which of course will also get dropped. This kind of behaviour is tough to troubleshoot because of course the TCP handshakes all work fine, as they are small packets, but then the session appears to stall as soon as any bulk data transmission occurs.

RFC 4821 was developed to help hosts get around this problem using Packetization Layer Path MTU Discovery (PLPMTUD), which discovers the path MTU by incrementally increasing the MSS to try to find a suitable value for the path. This removes the dependency on ICMP, and is available in most OS network stacks, but is not as efficient as learning directly what the maximum MTU should be. So please just allow these ICMP messages through in the first place, okay?


Time Exceeded
IPv4 - (Type11, Code0)
IPv6 - (Type3, Code0)

Traceroute is a very useful tool for troubleshooting network connections between two hosts, detailing each hop on the path. It does this by sending a packet with a TTL of 1 so that the first hop sends back a Time Exceeded message (including its own source IP), then sending a packet with a TTL of 2, and so on, to discover each hop on the path.

Remember when you've run it before, and you get a hop or two that can't be discovered in the middle of your trace? Or even worse, you try to traceroute to a host and *every* hop can't be discovered. Annoying, right? That's because the person running those routers (or your local firewall) decided to block ICMP Time Exceeded messages. Don't be that guy, okay?


NDP and SLAAC (IPv6)
Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)

While IPv4 used Address Resolution Protocol (ARP) for layer 2 to 3 mappings, IPv6 takes a different approach, in the form of Neighbour Discovery Protocol (NDP). NDP provides many functions, including router discovery, prefix discovery, address resolution, and many more besides. In addition to NDP, StateLess Address AutoConfiguration (SLAAC) allows a host to be dynamically configured on the network, similar in concept to DHCP (although DHCPv6 does exist for finer-grained control).

These five ICMP types should be permitted within your network (not across your border) in order for these features of IPv6 to function correctly.


A Word About Rate Limiting

While ICMP messages like the ones covered on this page can be very useful, remember that generating all of these messages takes CPU time on your routers, and generates traffic. Do you really expect that you should be getting 1000 pings a second through your firewall in a normal situation? Would that be considered legitimate traffic if you saw it? Nope, probably not. Rate limit all of these ICMP traffic types as you see fit for your network; it's a good line of defence that should not be ignored.


Read, Research, Understand

Given that the "to block or not to block" discussion for ICMP seems to always result in confusion, anger, and borderline fanatical disagreements, go ahead and read up on the topic yourself. Spend time understanding it as fully as you can; there are plenty of links throughout this page alone. Then you can form your own opinion and make an informed choice about what is best for your network.