Is ICMP spoofing practical?

Question

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.

Answer 1

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".

Answer 2

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.