ICMP stands for Internet Control Message Protocol. What does it do? You may be surprised after reading this article, at just how much ICMP actually does for us. Call it the unheralded hero of the four core protocols. The four core protocols being IP, TCP, UDP, and ICMP. If you think about it, all of these protocols, in actuality, are the work horses of the computer-to-computer communications world.

In this article on ICMP we will define just where ICMP resides in the OSI reference model, and go over various packet types containing the ICMP protocol. Lastly, the various error conditions being communicated by this protocol will be explained so as to expand upon them. You may have come to the conclusion by now that the more you learn about computer protocols, the more you will be able to understand just how a computer communicates. Much like any field of study it helps to first achieve a critical mass of knowledge. Once this critical mass has been achieved a great many other concepts become clearer, and therefore understood at the theoretical level. Hopefully once you have finished reading the series of articles that I have written about the TCP/IP core protocols you will have attained just that; a critical mass of knowledge.

Using the OSI reference model once again as our template to bring some order to this mass of knowledge, just where does ICMP fit in? Well many consider it to be part of the network layer where IP resides. Though that being said some ICMP error conditions may be acted upon at the Transport layer i.e.: TCP and UDP. In case you have never seen the OSI reference model included below is a slimmed down version of it.

Application Layer Protocols like HTTP, SMTP, FTP
Presentation Layer Protocols like JPEG, MPEG
Session Layer Protocols like NFS, SQL, RPC
Transport Layer Protocols like TCP, and UDP
Network Layer Protocols like IP and ICMP
Data Link Layer Protocols like HDLC and PPP
Physical Layer No protocols at this layer

Now ICMP error messages are themselves actually encapsulated in an IP datagram. It is a rather funky looking packet actually, and tends to be confusing to those just starting to learn about ICMP. Fear not though, for we will cover various types of ICMP error messages at the packet level. The first four bytes of an ICMP error message always have the same format. What follows though can vary as it is dependent upon the error condition being reported. That being said the ICMP echo request, echo reply packet is different as it relates to the header itself. The ping packet as ICMP echo request/echo are also known as, have a header size of eight bytes vice four. This is because other specific information is required. More on that ICMP quirk to follow later on. On that note let’s see the layout of the first four bytes that remain the same.

1 byte   1 byte   2 bytes
_____________________
| Type  | Code  |Checksum |
——————————–

So we can see that there are four bytes in an ICMP error message that remain constant. If you check the TCP/IP and tcpdump flyer that I recommended you download, you will see a representation like the one above. Please remember that it is found under “Additional Resources” at the bottom of the page.

Behold, the ICMP packet!

00:00:09.696930 192.168.1.100 > 192.168.1.200: icmp: echo request (ttl 126, id 6655, len 60)
0x0000      4500 003c 19ff 0000 7e01 1ce8 c0a8 0164  E..<….~…….
0x0010      c0a8 01c8 0800 d9c3 0300 7889 3031 3233  ……….x.0123
0x0020      3435 3637 3839 6162 6364 6566 6768 696a  456789abcdefghij
0x0030      6b6c 6d6e 6f70 7172 7374 7576            klmnopqrstuv

What we have above us is probably one of the best known types of ICMP packet. Care to take a guess as to what this type is? This ICMP packet is the much talked about “ping” packet. What is the “echo request” used for though? Well primarily the ping packet is used to confirm if an IP address is assigned or not i.e.: is there a computer at a specific IP address? If there is then a reply will be issued by that IP address, and if not then an ICMP error message will be generated and returned. This is one of the few instances where an ICMP packet will elicit an ICMP error message in return. Normally an ICMP error message will not in turn generate another one. Would be a bit of an endless loop wouldn’t it, if that could happen. The exception to this rule is the above seen ICMP echo request packet.

Well what does the response to an ICMP echo request look like though? Not only that, but how does the computer who sent the originating ICMP echo request know that the incoming ICMP response is for its initial echo request? That is a very good question actually. Let’s look at the packet below to get an answer then!

00:00:09.697192 192.168.1.100 > 192.168.1.200: icmp: echo reply (ttl 255, id 6655, len 60)
0x0000      4500 003c 19ff 0000 ff01 9be7 c0a8 01c8  E..<…………
0x0010      c0a8 0164 0000 e1c3 0300 7889 3031 3233  ……….x.0123
0x0020      3435 3637 3839 6162 6364 6566 6768 696a  456789abcdefghij
0x0030      6b6c 6d6e 6f70 7172 7374 7576            klmnopqrstuv

Let’s quickly recap what the metrics seen above are. From the first line on the left we have our timestamp as noted by the receiving computer. Then the source address, and source port. This is followed by the destination address and destination port. The actual ICMP message as noted in ASCII. Then we have the ttl value, the ID number assigned to the ICMP error message, and overall packet length.

So, let’s now look at the ICMP packet header, and go through the values. They are underlined as seen in the packet directly above.

0000

The first two bytes seen above relate to the type and code field in the ICMP packet header. If you go to the bottom of the TCP/IP cheat sheet that I recommended you download you will see a section for PING (Echo/Echo Reply). The 00 then means that this is a Echo Reply, and the following byte of 00 breaks out to the code value. The code value of 00 then is as it should be 00. The other hex values are what is being sent in the ASCII payload ie: x.0123456 and so on as seen in the ASCII. That will wrap up this article, and in the last part we will cover other types of ICMP error messages at the packet level, and explain what they actually mean. Till then!

 

 

Well we now know that ICMP is actually a very important protocol in the grand scheme of things. Without it we would never know what happened in the case of an error encountered by our packets on the network, or Internet for that matter. That is why ICMP is one of the four core protocols. All TCP/IP stack implementations have these four core protocols in them for that very reason. They are needed for the operating system to function, and communicate effectively. Without them computers would not function and the Internet would not be as we know it today.

On that note, how about we take a look at some other ICMP error messages that we are likely to encounter. Encounter that is, if you were sniffing your connection, and thereby collecting packets.

There is nobody listening

We know that if you send a TCP/IP packet to a port that does not have a service listening on it, that you will get a RST packet back. This lets you know that there is no service there. What happens if you send a UDP/IP packet to a port that has no UDP based service listening on it? Well something completely different then what happens to a TCP based connection. Let’s take a look at the packet below for an explanation of what happens.

00:00:05.579927 192.168.1.100 > 192.168.1.200: icmp: 192.168.1.100 udp port 64032 unreachable(DF) (ttl 50, id 64521, len 56)
0x0000      4500 0038 fc09 4000 3201 97fc c0a8 0164  E..8..@.2….’Z.
0x0010      c0a8 01c8 0303 01c9 0000 0000 4500 00f2  …………E…
0x0020      d385 4000 f011 01b6 c0a8 0164 c0a8 01c8  ..@……….’Z.
0x0030      0035 fa20 00de 0000                      .5……

When you send a UDP based packet to a port such as port 53 (DNS protocol listens on port 53) but there is nothing there, the destination computer would generate an ICMP based packet. The packet would pretty much exactly look like the one above. It is time to realize now that UDP, and ICMP have a sort of symbiotic relationship. Whereas TCP will have RST packets, and the such sent back, UDP will however have ICMP error messages instead. Those messages will indicate what happened to the packet that was sent.

So what does “udp port 64032 unreachable” actually mean? Well, it means that the destination computer does not actually have a service running on it. For example if the destination port number was 53, then that would mean that there is no DNS server running on that computer. This is how the source computer would find out that there is no such service. The resulting ICMP error message would tell it as much.

That is all well and good, but how does that ICMP error message tell the source computer exactly what packet it was that caused the ICMP error message to be generated? That is an excellent question. The way that ICMP works is that it will use IP to carry it around, and following the actual ICMP header will be the IP header, and first eight bytes of the transport protocol that actually caused the error to begin with. A tad confusing, I realize, but please look at the packet above. I have underlined the portion, which shows the original packet that caused the ICMP error message to begin with. That, in turn, is being returned to its owner via IP, and the ICMP packet header.

This way when the source computer receives this ICMP error message it will look at the IP header being carried, and the transport protocol as well. Remember now, that within the first four bytes of the transport protocol, are the port numbers. Both source and destination are there. This way the source computer is able to tell which process it was that needed to be made aware of the error i.e.: port 1124, and this is the ephemeral port that was assigned to Internet Explorer was it started up by the user.

Now we can also tell what exact type of ICMP error message this is by the type and code. This is seen in the above bolded part of the packet. This is the standard ICMP header. Please now refer to your TCP/IP cheat sheet, to break out the fields.

0303

The first 03 refers to the type of ICMP error message, and in this case the sheet tells us that is Type “Destination Unreachable”.  Following that is another 03 and that refers to the code, which is “Port Unreachable”. So far so good, as this is exactly what the packets tells us in the ascii in the header part.

01c9

This value is the checksum of the ICMP header. If you remember every core protocol has a checksum field. This is computed by the source computer, and then recalculated by the destination computer. It basically is used to make sure that the protocol header itself was not corrupted on the way to its destination. The only exception is UDP, which does not have to use the checksum value in its header. The last four bytes as shown by the 0000 0000 are simply set to zero as there is nothing message specific to be conveyed in the header.

That pretty much wraps up the destination unreachable error message. The last one we will look at is the “admin prohibited filter” error message.

00:00:13.953415 192.168.1.100 > 192.168.1.200: icmp: host 192.168.1.200 unreachable – admin prohibited filter (ttl 255, id 57951, len 56)
0x0000      4500 0038 e25f 0000 ff01 81e6 c0a8 0164  E..8._………a
0x0010      c0a8 01c8 030d fcf2 0000 0000 4500 001c  ..Y………E…
0x0020      30f2 0000 3a01 6848 c0a8 0164 c0a8 01c8  0…:.hH..Y…1.
0x0030      0800 6f16 a8c3 e025                      ..o….%

This type of message was in all likelihood generated by a router. In all likelihood, the router which has the destination source IP shown above. That configuration would be done by the administrator of the router who has perhaps set an ACL barring communication attempts from the source IP in question. This is often done by some companies if they find repeat offenders trying to penetrate their networks. They will simply set up an ACL denying access to the IP in question. That would in turn generate the message above.

Once again, I have bolded the ICMP header, and underlined the IP and protocol that IP was carrying when the original error was created. Can you figure out what the protocol was that followed the IP header in this packet? I have bolded the first two bytes of the protocol. It was actually a ICMP Echo request that was sent, and that resulted in the router saying NO! we do not allow ICMP echo requests to be accepted. That is why we saw the “admin prohibited filter” message. The admin set up the router to deny any inbound ICMP Echo request packets.

Well as you can now see there is actually a lot to the ICMP protocol. There are plenty more ICMP error messages, which can be generated. I would encourage you to try your hand at packet crafting. This will allow you to put theory into practice. That way you can simulate various packet conditions, and then study the responding packets. It is a great way to learn more about TCP/IP. On that note, I sincerely hope you found this article of use to you, and I welcome your comments. Till next time!