The Internet Control Message Protocol (ICMP) delivers message packets, reporting errors and other pertinent information to the sending station or source. Hosts and infrastructure equipment use this mechanism to communicate control and error information, as they pertain to IP packet processing.
ICMP Format, Encapsulation, and Delivery
ICMP message encapsulation is a two- fold process. The messages are encapsulated in IP datagrams, which are encapsulated in frames, as they travel across the Internet. Basically, ICMP uses the same unreliable means of communications as a datagram. This means that ICMP error messages may be lost or duplicated.
The ICMP format includes a message type field, indicating the type of message; a code field that includes detailed information about the type; and a checksum field, which provides the same functionality as IP’s checksum (see Figure 1.20). When an ICMP message reports an error, it includes the header and data of the datagram that caused the specified problem. This helps the receiving station to understand which application and protocol sent the datagram. (The next section has more information on ICMP message types.)
Like UDP, ICMP does not include flow control or error recovery, and so can be easily duplicated.
Figure 1.20 Illustration of an ICMP datagram.
Figure 1.21 ICMP message chart.
ICMP Messages, Subnet Mask Retrieval
There are many types of useful ICMP messages; Figure 1.21 contains a list of several, which are described in the following list.
• Echo Reply (Type 0)/Echo Request (Type 8). The basic mechanism for testing possible communication between two nodes. The receiving station, if available, is asked to reply to the ping. An example of a ping is as follows:
STEP 1: BEGIN ECHO REQUEST
Ping 206.0.125.81 (at the command prompt) STEP 2: BEGIN ECHO REPLY
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128 (from receiving station 206.0.125.81) Reply from 206.0.125.81: bytes-32 time<10ms TTL=128
Reply from 206.0.125.81: bytes-32 time<10ms TTL=128 Reply from 206.0.125.81: bytes-32 time<10ms TTL=128
Destination Unreachable (Ty pe 3). There are several issuances for this message type, including when a router or gateway does not know how to reach the destination, when a protocol or application is not active, when a datagram specifies an unstable route, or when a router must fragment the size of a datagram and cannot because the Don’t Fragment Flag is set. An example of a Type 3 message is as follows:
STEP 1: BEGIN ECHO REQUEST
Ping 206.0.125.81 (at the command prompt) STEP 2: BEGIN ECHO REPLY
Pinging 206.0.125.81 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
• Source Quench (Type 4). A basic form of flow control for datagram delivery. When datagrams arrive too quickly at a receiving station to process, the datagrams are discarded.
During this process, for every datagram that has been dropped, an ICMP Type 4 message is passed along to the sending station. The Source Quench messages actually become requests, to slow down the rate at which datagrams are sent. On the flip side, Source Quench messages do not have a reverse effect, whereas the sending station will increase the rate of transmission.
• Route Redirect (Type 5). Routing information is exchanged periodically to accommodate network changes and to keep routing tables up to date. When a router identifies a host that is using a nonoptional route, the router sends an ICMP Type 5 message while forwarding the datagram to the destination network. As a result, routers can send Type 5 messages only to hosts directly connected to their networks.
• Datagram Time Exceeded (Type 11). A gateway or router will emit a Type 11 message if it is forced to drop a datagram because the TTL (Time-to-Live) field is set to 0. Basically, if the router detects the TTL=0 when intercepting a datagram, it is forced to discard that datagram and send an ICMP message Type 11.
• Datagram Parameter Problem (Type 12). Specifies a problem with the datagram header that is impeding further processing. The datagram will be discarded, and a Type 12 message will be transmitted.
• Timestamp Request (Type 13)/Timestamp Reply (Type 14). These provide a means for delay tabulation of the network. The sending station injects a send timestamp (the time the message was sent) and the receiving station will append a receive timestamp to compute an estimated delay time and assist in their internal clock synchronization.
Figure 1.22 ICMP header sniffer capture.
Information Request (Type 15)/Information Reply (Type 16). As an alternative to RARP (described previously), stations use Type 15 and Type 16 to obtain an Internet address for a network to which they are attached. The sending station will emit the message, with the network portion of the Internet address, and wait for a response, with the host portion (its IP address) filled in.
• Address Mask Request (Type 17)/Address Mask Reply (Type 18). Similar to an Information Request/Reply, stations can send Type 17 and Type 18 messages to obtain the subnet mask of the network to which they are attached. Stations may submit this request to a known node, such as a gateway or router, or broadcast the request to the network.
If a machine sends ICMP redirect messages to another machine in the network, it could cause an invalid routing table on the other machine. If a machine acts as a router and gathers IP datagrams, it could gain control and send these datagrams wherever programmed to do so. These ICMP-related security issues will be discussed
in more detail in a subsequent chapter.
ICMP Header Snapshots
Figure 1.22 on page 35 contains snapshots of an ICMP Header. The first was extracted after the IP portion of an ICMP ping test transmission; the second was extracted during an unreachable ping test.