How does ICMP work?

How ICMP fits into everyday network communication

ICMP is part of the control plane of IP networking, not a transport for application data. Hosts and routers use it to report conditions such as unreachable destinations, time exceeded, and fragmentation-related problems, and to support reachability checks like echo request and reply. That makes it a diagnostic and signalling protocol, with behaviour that is tightly tied to routing and packet delivery.

The practical value of ICMP is that it lets devices explain why delivery failed or confirm that a path exists. Without it, troubleshooting would be much harder, because many failures would look like simple silence. At the same time, ICMP is not optional noise, it is a protocol with real operational consequences, so filtering it indiscriminately can break diagnostics or interfere with path discovery.

For the broader networking model, ICMP sits alongside IP as a control mechanism that helps the network surface errors back to the sender. That is why operators often treat it differently from application traffic. You normally want the specific ICMP messages that support reachability, PMTU discovery, and troubleshooting, while avoiding a blanket “allow everything” stance.

Why ICMP is useful, and why it is often restricted

ICMP is useful because it gives immediate feedback about network conditions. A destination-unreachable message can tell you that a host, subnet, or port path is not working, while echo-based checks help determine whether a device is responding at all. In practice, these messages are often the fastest way to separate a routing problem from a host problem or an ACL problem.

It is also commonly restricted because the same visibility helps attackers. ICMP can be used for host discovery, network mapping, and volume-based probing, and some abuse patterns use ICMP as a covert carrier for tunnelling or data exfiltration. Network controls therefore need to balance operational usefulness against unnecessary exposure, especially on edges, between zones, and across untrusted links.

Many defenders follow the principle of allowlisting only the ICMP types and codes their environment actually needs. That usually means preserving the control messages required for path reliability while limiting reflective or diagnostic variants that add little business value. The right answer depends on the environment, but the governing idea is consistent: keep the minimum useful ICMP surface, not an unconstrained default.

How to think about ICMP when you are troubleshooting or filtering it

When ICMP is functioning normally, you should see a small, understandable set of control messages that correspond to real network conditions. When it is abused or misconfigured, you often see unusually high rates, repetitive patterns, or messages that do not match expected routing and host behaviour. The difference between useful signal and abuse is usually in volume, direction, and whether the messages align with an active troubleshooting event.

ICMP filtering should therefore be based on purpose, not on fear of the protocol itself. Blocking all ICMP can hide important failure signals and make packet loss or path MTU issues much harder to diagnose. Allowing too much, on the other hand, can make reconnaissance and tunnelling easier. The best operational posture is to explicitly decide which message classes are needed, then monitor for exceptions and unusual patterns. For a network-control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls supports disciplined control selection and monitoring, while CIS Benchmarks help translate that intent into hardened device settings.

Risk and Threat Considerations

ICMP becomes risky when organisations assume it is harmless background traffic. The same protocol that helps diagnose reachability can also expose topology, assist host discovery, or carry traffic that evades normal inspection paths. If ICMP is left broadly open, the network can reveal more about live systems and routing behaviour than operators intend.

Failure mechanism: Attackers or misconfigured tools can abuse ICMP for discovery, probing, or tunnelling because it is often permitted for operational reasons and may receive less scrutiny than application protocols.

Impact: The result can be easier reconnaissance, noisier environments, reduced visibility into suspicious traffic, and in some cases a covert path around controls that were designed for TCP or UDP flows.

Practitioner Guidance

What to prioritise: Define which ICMP types your environment actually needs for reachability, diagnostics, and path behaviour, then block the rest by default. That is usually safer than trying to detect abuse after the fact.

What to verify: Confirm that your monitoring can distinguish normal troubleshooting activity from abnormal scan-like bursts, repeated echo patterns, or ICMP traffic that appears where no operational need exists. If you cannot explain the traffic, treat it as an investigation cue.

Practitioner takeaway: ICMP is most useful when it is intentionally constrained, because the same control messages that help operations can also give attackers low-friction visibility into your network.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?