ICMP maximum delay between echo request and reply sustained by a router NAT

Question

I was trying to slow down network on my server (arch linux vm) with netem

sudo tc qdisc add dev eth0 root netem delay 1600ms

With 1600ms delay client doesn't receive the echo reply packet though the packet is generated from the serverside. However It can withstand till 1500ms delay. If delay is less than that the echo reply is received in the client side.

But In the RFC does it specify any fixed max latency between echo request and echo reply ?

I have used ping as well as scapy to generate ICMP echo request packets and tcpdump to check the incoming echo reply packets. So it is not the problem of ping program.

So I think somewhere in the intermediate router the ECHO reply packets are being dropped due to the delay. So what is the maximum ammount of delay between echo request and reply that common routers sustain ?

Answer 1

There are recommendations in RFC 5508 "NAT Behavioral Requirements for ICMP", as to how long a router should retain state for ICMP packets, but there's no guarantee that anyone follows them.

Answer 2

Context: ICMP is not a stateful protocol.

In a scenario where you are sitting behind a router that NATs your traffic and you are pinging a device at the other side of the router, the router needs to keep track of your ICMP echo requests in order to let the respective ICMP echo replies in. How to do this if ICMP is not stateful? Just write an entry in the NAT table and keep it for a while.

The vendor of your router decided that 1500ms was a good compromise between functionality (ICMP works) and security:

1) The router can free up memory fast instead of keeping potentially millions of entries for one-sided ICMPs.
2) The router blocks unwanted ICMP echo replies potentially used for probing, fingerprinting, etc.

As side notes, the default ping timeout for Windows is 4 seconds and for many Linux distros is 10 seconds (in reference to the default "ping" tools in both OSes).