Why do firewalls often block ICMP, and what breaks when an IPv4 network drops all of it?
answer
- abused for floods and mapping
- errors are not optional plumbing
- type 3 code 4 carries next-hop MTU
- time exceeded drives traceroute
- fail fast versus wait for timeout
basics
~20 sICMP gets blocked because it has carried floods, Smurf amplification, forged redirects, covert tunnels and network mapping. Dropping all of it breaks path-MTU discovery, traceroute and fast error reporting, so large transfers stall and failed connections hang until timeout.
solid answer
~50 sICMP (IP protocol 1, RFC 792) earned its reputation: echo floods, Smurf amplification through directed broadcasts, forged type 5 Redirects that divert a host's traffic, data tunnelled inside echo payloads, and echo sweeps that map live hosts. So the reflex is to drop all of it. But ICMP is how IPv4 reports errors. Drop type 3 code 4 (fragmentation needed and DF set) and a sender doing path-MTU discovery never learns the path is narrower, so small requests work while large transfers stall. Drop type 11 (time exceeded) and traceroute goes dark. Drop the unreachables and clients wait for timeouts instead of failing at once. A sound policy keeps the errors that belong to your own flows, rate-limits echo, and drops what has no business crossing an edge: Redirects, Source Quench and the deprecated types.
go deeper
Recall that ICMP carries error reports as well as ping, list two or three attacks that made it unpopular, and name what breaks when all of it is dropped.
Explain the mechanisms behind the breakage: type 3 code 4 carrying the next-hop MTU, type 11 for traceroute, and unreachables that let applications fail fast instead of timing out.
Show the production judgment: recognise the large-transfer stall as an ICMP filtering symptom, and propose a policy that keeps flow-related errors, rate-limits echo and drops Redirects and deprecated types.
Frame the trade-off as who pays: the firewall owner gains a simple rule, while application teams absorb black holes and slow failures. Argue for a shared, documented ICMP policy rather than per-team exceptions.
## Two kinds of ICMP message The **Internet Control Message Protocol** (ICMP, RFC 792) travels directly inside IPv4 with protocol number `1`. RFC 792 calls it an integral part of IP: it is how routers and hosts tell a sender that something went wrong, and how anyone can ask a node a simple question. Its messages fall into two families: - **Error messages** report a problem with a datagram someone sent: Destination Unreachable (type 3), Time Exceeded (type 11), Parameter Problem (type 12) and Redirect (type 5). Each quotes the offending datagram's IP header plus at least the first 64 bits of its payload, which is how the sender's stack matches the error to a connection. - **Query messages** ask and answer: Echo (type 8) and Echo Reply (type 0), which is what ping uses, and Timestamp (type 13) and Timestamp Reply (type 14). ## Why security teams reach for a blanket block Many ICMP message types have been abused at some point: | Abuse | Message involved | What it does | |---|---|---| | Ping flood | Echo (type 8) | Volume of requests, and the target's replies, consume link capacity and CPU | | Smurf amplification | Echo sent to a directed broadcast with a forged source | Every host on a subnet replies to the victim | | Redirect hijack | Redirect (type 5) | An attacker on the link tells a host to send traffic through it | | Covert tunnel | Echo payload | Arbitrary data rides in requests and replies | | Reconnaissance | Echo, Timestamp, unreachables | Reveals live hosts, clocks and filtered ports | A single "drop ICMP" rule answers all of these at once, is easy to audit, and its costs are often invisible to whoever writes it. The costs show up later, in other teams' tickets. ## What a blanket block breaks 1. **Path-MTU discovery.** Under RFC 1191 a sender sets the DF (don't fragment) bit and starts with its first-hop MTU. A router that cannot forward a datagram that large drops it and returns **type 3, code 4 — fragmentation needed and DF set**, carrying the next-hop MTU. If the firewall eats that message, the sender keeps sending datagrams that die silently. The classic symptom is a "black hole": the TCP handshake and small requests succeed, large responses stall. 2. **Traceroute.** It works by sending probes with increasing TTL and collecting **type 11, code 0 — time exceeded in transit** from each router; the classic UDP form ends when the destination answers with a port unreachable. Without those messages every hop is silent. 3. **Fast failure.** A **port unreachable** (type 3, code 3) from the destination host, a **net or host unreachable** (codes 0 and 1) from a router, or **communication administratively prohibited** (code 13, added by RFC 1812) lets an application give up at once. Dropped, the same failure becomes a wait for the application's own timeout. 4. **Liveness checks.** RFC 1122 says every host MUST implement an echo server. Answering ping is protocol behaviour; a firewall that drops it is applying local policy on top, and every monitoring system that relies on echo goes blind. IPv6 is less forgiving still: routers never fragment, so its Packet Too Big message is the only way a sender learns about a narrower link, and address resolution itself runs over ICMPv6. Blanket ICMPv6 filtering breaks the network, not just its diagnostics. ## Where to draw the line - **Permit errors that belong to your own flows.** A stateful firewall can compare the header quoted inside an inbound type 3, 11 or 12 against connections it already tracks. - **Permit echo, with a rate limit**, rather than dropping it; the flood is a rate problem, not a message-type problem. - **Drop what cannot be legitimate at an edge:** inbound Redirects (they are only valid from an on-link router), Source Quench (RFC 6633 requires firewalls to silently discard it), the types RFC 6918 deprecated (such as Information Request/Reply, types 15–16, and Address Mask Request/Reply, types 17–18), and echo aimed at a directed-broadcast address. ## Common traps - Assuming TCP's MSS option replaces path-MTU discovery: MSS reflects each endpoint's own link, not the narrowest link in the path. - Believing that dropping echo hides hosts: probes to open or closed TCP ports, and UDP probes answered with port unreachables, still reveal them. - Testing only small requests after a firewall change, which is exactly the traffic a PMTUD black hole leaves working.
- Is an IPv4 host required by the standards to answer ICMP echo requests?Yes. RFC 1122 says every host MUST implement an echo server that answers echo requests, and only echo sent to a broadcast or multicast address MAY be silently discarded. RFC 1812 likewise requires routers to answer echo and says they SHOULD offer an option to ignore it, defaulting to answering. A firewall that drops echo is applying local policy; the protocol itself does not make echo optional.
- Does dropping inbound ICMP echo requests at the edge hide a network's hosts?Only partly. A host still reveals itself by answering a TCP connection attempt (with a SYN-ACK or a RST), by returning a port unreachable to a UDP probe, or by answering Timestamp requests if those pass. Dropping echo removes the cheapest sweep, not discovery. For IPv6, RFC 4890 argues echo need not be filtered at all, because the address space makes sweeping impractical.
saying these in an interview costs you the question
- ICMP is only ping, so blocking it just disables ping.
- Blocking all ICMP is a harmless hardening step with no side effects.
- Path-MTU discovery works without ICMP because TCP negotiates the MSS.
- Dropping echo requests makes the network's hosts invisible to scanners.
- A closed UDP port answers with a TCP reset, so ICMP is not needed.