When is 'Timestamp' and 'Timestamp Reply' are used in ICMP protocol?

Question

I started the packet capture in my laptop through Wireshark application. Now through cmd, I pinged some server (say, www.google.com). And i stopped packet capture and analysed the packets being capture corresponding to the ping operation.

Packet capture looked like-

I see only 'echo request' and 'echo response' pair!

I was expecting the ping utility would also use 'Timestamp' and 'Timestamp Reply' types as well to measure the RTT value. I guess the ping utility would be calculating the RTT in a state-full manner, by remembering which packet was sent at what time, and considering the time at which that packet was received back.

Well, in that case, in what scenario do we use - 'Timestamp' and 'Timestamp Reply' type of ICMP packets? Or, how can we generate one?

Answer 1

The usual ping command uses ECHO REQUEST and ECHO REPLY, as you've seen. It does indeed locally keep track of sent time and matches with the incoming reply to determine the round trip time.

TIMESTAMP and TIMESTAMP REPLY are pretty rare, and many sites simply don't answer, as many systems managers believe it to be a security issue, albeit minor. The purpose of the packets is to separate out the the times of the outgoing trip, the far end processing time, and the return trip. ICMP in general is subject to all kinds of manipulations and blockages by intervening routers, so it can be hard to read much into the results if you're using this across a network you don't control.

To send them you can use a utility such as nping from the nmap set of tools. It can be used for all kinds of exotic ping-like tests.

nping --icmp --icmp-type 13 www.google.com

www.google.com won't reply to these, but your packet capture will show them being sent.

Answer 2

The use of the ICMP Timestamps is optional, and may, or may not, be implemented. You may find many hosts or network devices do not implement this option. RFC 1812 explains that NTP is a better option to synchronize clocks.

RFC 1122, Requirements for Internet Hosts -- Communication Layers

(e) Timestamp Option

Implementation of originating and processing the Timestamp option is OPTIONAL. If it is implemented, the following rules apply:

• The originating host MUST record a timestamp in a Timestamp option whose Internet address fields are not pre-specified or whose first
  pre-specified address is the host's interface address.
• The destination host MUST (if possible) add the current timestamp to a Timestamp option before passing the option to the transport layer or to ICMP for processing.
• A timestamp value MUST follow the rules given in Section 3.2.2.8 for the ICMP Timestamp message.

• and -

3.2.2.8 Timestamp and Timestamp Reply: RFC-792

A host MAY implement Timestamp and Timestamp Reply. If they are implemented, the following rules MUST be followed.

The ICMP Timestamp server function returns a Timestamp Reply to every Timestamp message that is received. If this function is implemented, it SHOULD be designed for minimum variability in delay (e.g., implemented in the kernel to avoid delay in scheduling a user process).

The following cases for Timestamp are to be handled according to the corresponding rules for ICMP Echo:

• An ICMP Timestamp Request message to an IP broadcast or IP multicast address MAY be silently discarded.

The IP source address in an ICMP Timestamp Reply MUST be the same as the specific-destination address of the corresponding Timestamp Request message.

• If a Source-route option is received in an ICMP Echo Request, the return route MUST be reversed and used as a Source Route option for
  the Timestamp Reply message.
• If a Record Route and/or Timestamp option is received in a Timestamp Request, this (these) option(s) SHOULD be updated to include the current host and included in the IP header of the Timestamp Reply message.
• Incoming Timestamp Reply messages MUST be passed up to the ICMP user interface.

The preferred form for a timestamp value (the "standard value") is in units of milliseconds since midnight Universal Time. However, it may be difficult to provide this value with millisecond resolution. For example, many systems use clocks that update only at line frequency, 50 or 60 times per second. Therefore, some latitude is allowed in a "standard value":

(a) A "standard value" MUST be updated at least 15 times per second (i.e., at most the six low-order bits of the value may be undefined).

(b) The accuracy of a "standard value" MUST approximate that of operator-set CPU clocks, i.e., correct within a few minutes.

RFC 1812, Requirements for IP Version 4 Routers

(e) Timestamp Option

Routers MAY support the timestamp option in datagrams originated by the router. The following rules apply:

o When originating a datagram containing a Timestamp Option, a router MUST record a timestamp in the option if

• Its Internet address fields are not pre-specified or
• Its first pre-specified address is the IP address of the logical interface over which the datagram is being sent (or the router's router-id if the datagram is being sent over an unnumbered interface).

o If the router itself receives a datagram containing a Timestamp Option, the router MUST insert the current time into the Timestamp Option (if there is space in the option to do so) before passing the option to the transport layer or to ICMP for processing. If space is not present, the router MUST increment the Overflow Count in the option.

o A timestamp value MUST follow the rules defined in [INTRO:2].

IMPLEMENTATION

To maximize the utility of the timestamps contained in the timestamp option, the timestamp inserted should be, as nearly as practical, the time at which the packet arrived at the router. For datagrams originated by the router, the timestamp inserted should be, as nearly as practical, the time at which the datagram was passed to the Link Layer for transmission.

The timestamp option permits the use of a non-standard time clock, but the use of a non-synchronized clock limits the utility of the time stamp. Therefore, routers are well advised to implement the Network Time Protocol for the purpose of synchronizing their clocks.

You can write your own application to use timestamps (assuming your devices support this option). Otherwise, product or resource recommendations are off-topic here.

Answer 3

According to the RFC: https://www.ietf.org/rfc/rfc0792.txt

**The data received (a timestamp) in the message is returned in the reply together with an additional timestamp. The timestamp is 32 bits of milliseconds since midnight UT. **

So I can't tell what it would be useful for, but it's not required nor used for echo.

Since echo request and echo reply packets contain a sequence number, no stateful identification is required to track the replies.