ICMP Type 13 and Type 14 — Timestamp Request / Reply

These are two of the original ICMP message types defined in RFC 792 (1981), alongside echo (ping) and destination-unreachable. They were designed for clock synchronization across a network, back before NTP existed.

What they do

• Type 13 — Timestamp Request
  Sender asks the target: “What’s your clock?”
• Type 14 — Timestamp Reply
  Target answers with up to three timestamps, each in milliseconds since UTC midnight.

The reply carries three 32-bit timestamp fields:

Field	Set by	Meaning
Originate Timestamp	Sender	Time the request left the sender
Receive Timestamp	Receiver	Time the request arrived at the receiver
Transmit Timestamp	Receiver	Time the reply left the receiver

With those three values plus the time the reply is received, you can compute clock offset and one-way delay — the same math NTP later formalized.

Packet layout (both messages share it)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type (13/14) |     Code=0    |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identifier            |        Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Originate Timestamp                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Receive Timestamp                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Transmit Timestamp                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Total ICMP payload: 20 bytes. Code is always 0.

Why anyone still cares (the security angle)

In modern networks nothing legitimate uses these messages — clock sync is done by NTP/PTP, not ICMP. But many OS kernels (Linux, older Windows, BSD) still answer type 13 by default. That’s a problem because the reply leaks information:

1. System clock disclosure — exact wall-clock time on the target, which:

• confirms the host is alive even when echo (ping) is filtered;
• helps fingerprint the OS and uptime;
• can weaken time-based protocols (e.g. predicting TCP ISN, Kerberos ticket timing, certain auth tokens).

1. Bypasses ping filters — firewalls that block type 8 (echo request) but forget type 13 still expose host liveness.
2. Host enumeration in mass scans — nmap -PP uses exactly this to find hosts that are “stealth”-pinged.

That’s the entirety of CVE-1999-0524 — a finding that’s been in the catalogue since 1999 and just won’t die because it’s the default behavior of most stacks.

Who actually replies?

OS	Default behavior
Linux (all modern kernels)	Replies — no sysctl to disable; must filter at firewall
Windows (since Vista/2008)	Does not reply by default
BSD / macOS	Replies, controlled by net.inet.icmp.tstamprepl
Most network gear (Cisco IOS, Juniper)	Replies unless explicitly filtered

How to see them on the wire

# Watch type 13/14 with tcpdump
sudo tcpdump -ni any 'icmp[icmptype] == 13 or icmp[icmptype] == 14'

# Send one with hping3
sudo hping3 --icmp --icmptype 13 -c 1 <target>

# Send one with nmap (host discovery)
sudo nmap -sn -PP <target>

A typical capture line:

IP A > B: ICMP time stamp query id 1234 seq 1, length 20
IP B > A: ICMP time stamp reply id 1234 seq 1 : org 00:00:00.000 recv 09:48:21.412 xmit 09:48:21.412, length 20

Notice the receive/transmit timestamps in the reply — that’s the leak.

Should you ever leave them enabled?

In practice, no. Filter both directions at the firewall:

• Inbound type 13 — so the host stops getting asked.
• Outbound type 14 — defense in depth, in case something internal asks.

That’s the whole content of the standard CVE-1999-0524 remediation. There’s no legitimate modern use case for these messages on a production server, and removing them costs nothing.

See also: Mastering the Linux Command Line — Your Complete Free Training Guide

TL;DR

• Type 13 = “tell me your clock” (timestamp request).
• Type 14 = “here’s my clock” (timestamp reply, with three timestamps in ms-since-UTC-midnight).
• Defined in RFC 792, obsoleted in practice by NTP.
• Still enabled by default on Linux/Unix; leaks host time + liveness; filter both at the firewall.