Introduction: of some diagnostic tools like ping and

Introduction:

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices,
including routers, to send error messages and operational
information indicating, for example, that a requested service is not available
or that a host or router could not be reached. ICMP differs from transport
protocols such as TCP and UDP in
that it is not typically used to exchange data between systems, nor is it
regularly employed by end-user network applications (with the exception of some
diagnostic tools like ping and traceroute).

 

ICMP datagram structure:

The ICMP packet is encapsulated in an
IPv4 packet. The packet consists of header and data sections.

Header:

The
ICMP header starts after the IPv4 header and is
identified by IP protocol number ‘1’. All ICMP packets
have an 8-byte header and variable-sized data section. The first 4 bytes of the
header have fixed format, while the last 4 bytes depend on the type/code of
that ICMP packet.

Type

ICMP type,
see Control messages.

Code

ICMP
subtype, see Control messages.

Checksum

Error
checking data, calculated from the ICMP header and data, with value 0 substituted
for this field. The Internet Checksum is used, specified in RFC 1071.

Rest of Header

Four-bytes
field, contents vary based on the ICMP type and code.

Data:

ICMP
error messages contain a data section that includes a copy of the entire IPv4
header, plus at least the first eight bytes of data from the IPv4 packet that
caused the error message. The maximum length of ICMP error messages is 576
bytes. This data is used by the host to match the message to the
appropriate process. If a higher level protocol uses port numbers, they are
assumed to be in the first eight bytes of the original datagram’s data.

The
variable size of the ICMP packet data section has been exploited. In the
“Ping of death”, large
or fragmented ping packets
are used for denial-of-service
attacks.
ICMP data can also be used to create covert channels for
communication. These channels are known as ICMP tunnels.

 

CONTROL MESSAGES:-

Notable
control message

Type

Code

Status

Description

0 – Echo Reply

0

Echo reply (used
to ping)

1 and 2

unassigned

Reserved

3 – Destination
Unreachable

0

Destination
network unreachable

1

Destination host
unreachable

2

Destination protocol
unreachable

3

Destination port
unreachable

4

Fragmentation
required, and DF flag set

5

Source route
failed

6

Destination
network unknown

7

Destination host unknown

8

Source host
isolated

9

Network
administratively prohibited

10

Host
administratively prohibited

11

Network
unreachable for ToS

12

Host unreachable for ToS

13

Communication
administratively prohibited

14

Host Precedence
Violation

15

Precedence cutoff
in effect

4 – Source Quench

0

deprecated

Source quench (congestion
control)

5 – Redirect
Message

0

Redirect Datagram
for the Network

1

Redirect Datagram
for the Host

2

Redirect Datagram
for the ToS & network

3

Redirect Datagram
for the ToS & host

6

deprecated

Alternate Host
Address

7

unassigned

Reserved

8 – Echo Request

0

Echo request
(used to ping)

9 – Router Advertisement

0

Router
Advertisement

10 – Router Solicitation

0

Router
discovery/selection/solicitation

11 – Time Exceeded

0

TTL expired in
transit

1

Fragment
reassembly time exceeded

12 – Parameter
Problem: Bad IP header

0

Pointer indicates
the error

1

Missing a
required option

2

Bad length

13 – Timestamp

0

Timestamp

14 – Timestamp
Reply

0

Timestamp reply

15 – Information
Request

0

deprecated

Information
Request

16 – Information
Reply

0

deprecated

Information Reply

17 – Address Mask
Request

0

deprecated

Address Mask
Request

18 – Address Mask
Reply

0

deprecated

Address Mask
Reply

19

reserved

Reserved for
security

20 through 29

reserved

Reserved for
robustness experiment

30 – Traceroute

0

deprecated

Information
Request

31

deprecated

Datagram
Conversion Error

32

deprecated

Mobile Host
Redirect

33

deprecated

Where-Are-You
(originally meant for IPv6)

34

deprecated

Here-I-Am
(originally meant for IPv6)

35

deprecated

Mobile
Registration Request

36

deprecated

Mobile
Registration Reply

37

deprecated

Domain Name
Request

38

deprecated

Domain Name Reply

39

deprecated

SKIP Algorithm
Discovery Protocol, Simple Key-Management for Internet Protocol

40

Photuris, Security failures

41

experimental

ICMP for
experimental mobility protocols such as Seamoby RFC4065

42 through 252

unassigned

Reserved

253

experimental

RFC3692-style
Experiment 1 (RFC 4727)

254

experimental

RFC3692-style
Experiment 2 (RFC 4727)

255

reserved

Reserved

 

Source quench:

Source Quench requests
that the sender decrease the rate of messages sent to a router or host. This
message may be generated if a router or host does not have sufficient buffer
space to process the request, or may occur if the router or host buffer is
approaching its limit.

Data
is sent at a very high speed from a host or from several hosts at the same time
to a particular router on a network. Although a router has buffering
capabilities, the buffering is limited to within a specified range. The router
cannot queue any more data than the capacity of the limited buffering space.
Thus if the queue gets filled up, incoming data is discarded until the queue is
no longer full. But as no acknowledgement mechanism is present in the network
layer, the client does not know whether the data has reached the destination
successfully. Hence some remedial measures should be taken by the network layer
to avoid these kind of situations. These measures are referred to as source
quench. In a source quench mechanism, the router sees that the incoming data
rate is much faster than the outgoing data rate, and sends an ICMP message to
the clients, informing them that they should slow down their data transfer
speeds or wait for a certain amount of time before attempting to send more
data. When a client receives this message, it will automatically slow down the
outgoing data rate or wait for a sufficient amount of time, which enables the
router to empty the queue. Thus the source quench ICMP message acts as flow
control in the network layer.

 

Where:

Type must
be set to 4

Code must
be set to 0

IP header and
additional data is used by the sender to match the reply with the associated
request

 

Redirect:

Redirect requests data packets be sent on an alternative route. ICMP
Redirect is a mechanism for routers to convey routing information to hosts. The
message informs a host to update its routing information (to send packets on an
alternative route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a
direct path from the host to R2 is available (that is, the host and R2 are on
the same Ethernet segment), then R1 will send a redirect message to inform the
host that the best route for the destination is via R2. The host should then
send packets for the destination directly to R2. The router will still send the
original datagram to the
intended destination. However, if the datagram contains routing
information, this message will not be sent even if a better route is
available. RFC 1122 states
that redirects should only be sent by gateways and should not be sent by Internet hosts.

 

 

Where:

Type must
be set to 5.

Code specifies
the reason for the redirection, may be one of the following:

 

IP address is
the 32-bit address of the gateway to which the redirection should be sent.

IP header and
additional data is included to allow the host to match the reply with the
request that caused the redirection reply.

 

Time exceeded:

Time Exceeded is generated by a gateway to
inform the source of a discarded datagram due to
the time to live field
reaching zero. A time exceeded message may also be sent by a host if it fails
to reassemble a fragmented datagram
within its time limit.

Time
exceeded messages are used by the traceroute utility
to identify gateways on the path between two hosts.

Where:

Type must be set to 11

Code specifies the reason for the time
exceeded message, include the following:

IP
header and first 64 bits of the
original payload are used by the source host to match the
time exceeded message to the discarded datagram. For higher level protocols
such as UDP and TCP the
64 bit payload will include the source and destination ports of the discarded
packet.

Timestamp:

Timestamp is used for time synchronization. The originating timestamp is set
to the time (in milliseconds since midnight) the sender last touched the
packet. The receive and transmit timestamps are not used.

Where:

Type must be set to 13

Code must be set to 0

Identifier and Sequence Number can
be used by the client to match the timestamp reply with
the timestamp request.

Originate
timestamp is the number of milliseconds since
midnight Universal Time (UT). If a UT reference is not available
the most-significant bit can be set to indicate a non-standard time value.

 

Timestamp reply:

Timestamp Reply replies to a Timestamp message.
It consists of the originating timestamp sent by the sender of the Timestamp as
well as a receive timestamp indicating when the Timestamp was
received and a transmit timestamp indicating when the Timestamp reply was
sent.

Where:

Type must be set to 14

Code must be set to 0

Identifier and Sequence number can
be used by the client to match the reply with the request that caused the
reply.

Originate
timestamp is the time the sender last
touched the message before sending it.

Receive
timestamp is the time the echoer first
touched it on receipt.

Transmit
timestamp is the time the echoer last
touched the message on sending it.

All timestamps
are in units of milliseconds since midnight UT. If the time is not available in
milliseconds or cannot be provided with respect to midnight UT then any time
can be inserted in a timestamp provided the high order bit of the timestamp is
also set to indicate this non-standard value.

 

Address mask request:

Address mask request is normally sent by a host to
a router in
order to obtain an appropriate subnet mask.

Recipients
should reply to this message with an Address mask reply message.

 

Where:

Type must be set to 17

Code must be set to 0

Address
mask can be set to 0

ICMP
Address Mask Request may be used as a part of reconnaissance attack to gather
information on the target network, therefore ICMP Address Mask Reply is
disabled by default on Cisco IOS.

 

Address mask reply:

Address mask reply is used to reply to an address mask request message with an
appropriate subnet mask.

Where:

Type must be set to 18

Code must be set to 0

Address
mask should be set to the subnet mask

 

 

Destination unreachable:

Destination unreachable is generated by the host or its inbound gateway to
inform the client that the destination is unreachable for some reason. A
Destination Unreachable message may be generated as a result of a TCP or UDP. Unreachable
TCP ports notably respond with TCP RST rather than a
Destination Unreachable type 3 as might be expected.

The
error will not be generated if the original datagram has a multicast destination
address. Reasons for this message may include: the physical connection to the
host does not exist (distance is infinite); the indicated protocol or port is
not active; the data must be fragmented but the ‘don’t fragment’ flag is on.

 

Where:

Type field (bits 0-7) must be set to 3

Code field (bits 8-15) is used to specify the
type of error, and can be any of the following:

 

 

Next-hop
MTU field (bits 48-63) contains the
MTU of the next-hop network if a code 4 error occurs.

IP
header and additional data is included
to allow the client to match the reply with the request that caused the
destination unreachable reply.

 

Written by