1

Today when I test running a tracert command (windows + Wireshark) I see a outbound ICMP_ECHO_REQUEST packet that has sourceIP as "192.168.1.55" - my local IPAddress.

It is followed by a ICMP_TTL_EXCEEDED packet sent from an internet wild host as reply to me that my EchoRequest packet died halfway. The reply-packet "quotes" first 28 byte of my "original packet" in the payload section where I can see the sourceIP staying "192.168.1.55" - my local ipAddress.

A question immediately pops out of my head: "The NAT did not rewrite the "local" sourceIP in IP-Header or did him rewrite it in payload "?

AFAIK in case of TCP or UDP packets, the NAT will replace the local "ip:port" with external "IP:PORT" in the IP-Header of the packet. So I am wondering:

1 - Whether NATs are replacing them in the payload section of packets? (Or just do that with ICMP packet of type TTL_Exceeded only?)

2 - If 1 is not true, is this a kind of security threat?

vantrung -cuncon
  • 135
  • 6

2 Answers2

3

The answer is that it depends.

I have received ICMP messages from systems with a NAT device that let internal IP addresses leak through ICMP messages.

However in order for the receiver of an ICMP message to reliably associate it with a previously sent packet, the ICMP message need to contain the triggering packet essentially as it looked originally. This means if a packet triggers an ICMP message after being modified by a NAT, the NAT has to reverse the modifications inside the ICMP payload. And some NATs get this right.

There are more subtle aspects to notice. When a NAT modify IP addresses it also has to modify checksums inside the packet. However the ICMP payload is usually a truncated IP packet, thus transport layer checksums cannot be verified. For that reason they are rarely used, and leaving checksums inside ICMP payloads unmodified won't cause breakage. However this does cause checksums to be modified in one direction and not the other. That way a little bit of information about internal IP addresses can leak.

These leaks can be considered security vulnerabilities. This is just one kind of leaks a NAT can cause. More serious leaks are also possible including the possibility of sending packet fragments to another host than the intended recipient. Those are some of the reasons NATs are not a great idea. Replacing the NAT with a firewall without NAT will provide overall better security. But that of course requires more IP addresses.

kasperd
  • 30,455
  • 17
  • 76
  • 124
  • So rewriting the icmp's payload is optional ? I know it's still arguable now that NATs should or should not rewrite ip:port in payload of icmp or even UDP/TCP. Some NATs are even mapping icmp's id to another id. But in your experience, can you tell the bahavior of majority of NATs regading ip rewriting in payload? – vantrung -cuncon Mar 29 '16 at 10:52
  • @vantrung-cuncon I don't know if any standards say whether a NAT has to rewrite the ICMP payload. But many NATs don't follow standards anyway. I haven't tested enough different NATs to make meaningful statements about the majority. I wonder if [this study](http://www.cs.helsinki.fi/group/wiseciti/nat-study/) I heard about a few years back may cover that aspect. ICMP does not have any ID field, so I don't know which IDs it is you are thinking about. – kasperd Mar 29 '16 at 11:18
  • About the ID of icmp packet, it's called "identifier" if you look close enough to a icmp packet dump in wireshark. Cause icmp doesn't use Port concept as udp/tcp - icmp field "identifier" differentiates the mappings of different out-bound icmp instead. But some NAT producers thought that icmp's id can someday coincidentally conflicts cause it's randomly generated by different hosts behind same NAT, they try mapping even the icmp's id to another id & then translate it back to original id for icmp-replies. – vantrung -cuncon Mar 29 '16 at 11:33
  • @vantrung-cuncon ICMP does not have an ID field. ICMP has a 4 byte auxiliary field which is used for different purposes depending on the type of ICMP message. None of the ICMP types carrying an IP packet as their payload uses the auxiliary field for an ID. Some ICMP types are used to request that the other endpoint send an ICMP packet in response, those need to use part of the auxiliary field for an ID to match requests and responses, but that only applies to a few specific ICMP types. – kasperd Mar 29 '16 at 12:08
  • LOL ! I think nowaday almost all networking-terminologies that I know are from wireshark coder team. I call them the way wireshark calls them. Thanks for your knowledge sharing. But anyway I've read in the RFC 5808 they suggest NAT to map the id to another id. – vantrung -cuncon Mar 29 '16 at 12:16
  • @vantrung-cuncon No you don't. Wireshark decodes the auxiliary field differently depending on the ICMP type. (And for types where the auxiliary field is unused Wireshark simply skips the auxiliary field altogether in the decoded view, but you can of course still see it in the hexdump). If you look at TTL exceeded message in Wireshark, there will be no identifier field in the decoded ICMP header. – kasperd Mar 29 '16 at 12:19
  • 1
    Yes you're right. It's for echo request only. I've just checked it again. Thanks ! – vantrung -cuncon Mar 29 '16 at 12:25
0

NAT does not touch the payload of packets. It touches only IP and TCP/UDP headers. IP addresses are included in IP header (source and destination). TCP header include source and destination ports, similarly for UDP header.

For ICMP case, you can look at this page. It states that in case of error message (such as TTL Exceeded), the packet includes IP header (20 bytes) + 8 bytes from payload = 28 bytes you have seen.

Khaled
  • 36,533
  • 8
  • 72
  • 99
  • So you are saying that the inbound ICMP_TTL_EXCEEDED packet's payload is left as original as it was generated from the "wild internet host"? That leads to another fact that the internet host really knows my localIP cause it quoted my original packet that contains my localIP. This fact itself leads to another fact that my localIP was not translated at NAT when my original packet go out – vantrung -cuncon Mar 29 '16 at 09:41