How practical is ICMP spoofing?

scenario 1: in a NAT environment, how does NAT keep track of ICMP sessions (not technically sessions since it's not connection-oriented?) For ECHO/ECHO response Windows use the same identifier (0x1) and sequence number with 256 increment for each packet. If two hosts are pinging the same outside server, how does NAT distinguish incoming ICMP packets? If the internal network does not filter source address, how difficult is it to forge an ECHO response? use case: icmp ping used for monitoring, a load balancer may take incorrect/unnecessary actions upon receiving forged ICMP responses (destination unreachable, high latency etc.)

scenario 2: Some IPS device, say the GFW, inspecting packets on the transit path. How practical is it to forge ICMP error messages kill a connection with stealth. Instead of sending TCP RST, it sends out destination port unreachable/packet too large (this might get interesting :)) with forged source ip (the legitimate IP on the other side or some hops further down the path). Keep tracking of the original IP header and first 64 bytes can be expensive but with the computing power available today, is it doable?

Basically either from either inside or outside NAT, how likely is it for forged ICMP to cause damages/confusions? I am not talking about ICMP flood.

BTW can NAT handle anything IP protocols other than TCP/UDP? I am actually not exactly sure how it handles different ICMP types.

  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 3, 2021 at 19:09

2 Answers 2


RFC 5508 "NAT Behavioral Requirements for ICMP" says (section 3.1):

ICMP Query mapping by NAT devices is necessary for current ICMP-Query-based applications to work. This entails a NAT device to transparently forward ICMP Query packets initiated from the nodes behind NAT, and the responses to these Query packets in the opposite direction. As specified in [NAT-TRAD], this requires translating the IP header. A NAPT device further translates the ICMP Query Id and the associated checksum in the ICMP header prior to forwarding.

So a NAT device can indeed put a unique value in the Identifier field when forwarding a request to the outside. Two machines on the inside using the same identifier is no problem, the NAT device will use two different values and remember the combination of the original ID and the internal IP address.

Some (old) Cisco specific information can be found here: http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=3. This page also includes a list of supported protocols/applications for NAT.

If an ICMP message is sent to notify of an error caused by a TCP connection, the ICMP message must include the header and part of the payload of the TCP segment that triggered the error. This is necessary to allow the receiving host to identify the TCP connection.

A NAT device can do exactly the same thing to figure out where to send ICMP errors it receives. If it has a mapping corresponding to the TCP header in the ICMP payload, it knows where to send the ICMP message.

An attacker wanting to spoof an ICMP error would need to know the source and destination IP addresses and ports to create his message. Because the ICMP message payload will also contain a TCP sequence number, the TCP endpoint could also verify if this sequence number is valid (i.e. sent and not yet acked). This will make spoofing much harder, but this validation might not be implemented in all systems.

You should probably have a good look at RFC 5927 "ICMP Attacks against TCP".

  • Cisco documentation didn't mention modifying ICMP identity number which leads to recalculate ICMP checksum. But I do think it's necessary to implement something to handle ICMP identity conflict between different hosts. RFC5508/BCP148 is fairly new and it's not an internet standard. I am wondering how this is actually implemented. There are plenty of devices made before this RFC. cisco.com/en/US/tech/tk648/tk361/… Jun 24, 2013 at 2:25
  • I added a link to some extra Cisco specific info.
    – Gerben
    Jun 24, 2013 at 6:19

In any modern stateful NAT implementation, connection tracking is generally a fundamental part of facilitating it. There's not really any limitations on what IP protocols can be handled by NAT - Linux Netfilter can happily NAT any ip protocol, but obviously, with the limitation that if there is no special handling for that protocol (i.e. additional discriminators) only one inside host is going to be able to communicate with a particular outside host at a time.

In the case of ICMP echo request, the identifier and timestamp field are highly unlikely to match that of another host pinging the same remote endpoint - thus, providing the NAT/connection tracking implementation is capable of utilising this data, it can differentiate between the two. For destination unreachable the NAT device would have to track payload data (namely the first 8 bytes) in order to assure the validity of the ICMP error message - but even so, the host endpoint should most definitely be validating such a message itself.

Generally speaking, assuming an RFC compliant network stack, forged ICMP messages should not be an issue due to the fact that several fields are unique... Unless the attacker is a direct man in the middle, at which point they can interfere pretty freely - of course, this is why things like IPsec, TCP-MD5 and TCP-AO exist.

nb: whilst a number of RFCs do exist regarding NAT, it should not be considered an agreed standard in the manner that things like routing protocols are.

  • For those who have not heard of TCP-AO, see RFC5925
    – Olipro
    Jun 24, 2013 at 9:20
  • I doubt TCP-AO can prevent the described attack to reset a connection with spoofed ICMP messages. The authentication data in the option part of the TCP header will not be in the ICMP payload, and thus cannot be verified.
    – Gerben
    Jun 24, 2013 at 12:07
  • Read section 7.8 of the RFC, it does.
    – Olipro
    Jun 24, 2013 at 17:16
  • OK, you'r right, it does, by recommending to ignore all such messages :)
    – Gerben
    Jun 24, 2013 at 22:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.