How NTP Works: Network Time Protocol and Clock Synchronization

NTP (Network Time Protocol) is the protocol that synchronizes clocks across computers on the internet, achieving accuracy within milliseconds over wide-area networks and microseconds on local networks. Accurate time is foundational to distributed systems: TLS certificate validation checks expiration timestamps, DNS DNSSEC signatures have validity periods, distributed databases use timestamps for conflict resolution, financial systems require nanosecond-precision audit trails, and BGP route collectors rely on synchronized clocks to correlate updates across different vantage points. NTP, defined in RFC 5905 (NTPv4, published 2010), has been keeping the internet's clocks synchronized since 1985, making it one of the oldest protocols still in active use.

The Stratum Hierarchy

NTP organizes time sources into a hierarchical system of strata. Stratum 0 devices are the reference clocks themselves — atomic clocks, GPS receivers, radio clocks synchronized to national time standards. These devices are not directly accessible over the network. They connect to stratum 1 servers via serial, PPS (pulse per second), or other local interfaces.

Stratum 0 — reference clocks. GPS receivers (which receive time from atomic clocks on GPS satellites, accurate to ~10 nanoseconds), cesium and rubidium atomic clocks, and radio receivers tuned to time signal broadcasts (DCF77, WWVB, MSF). These are hardware devices, not network servers.

Stratum 1 — primary time servers directly connected to a stratum 0 reference clock. These servers (like time.nist.gov, time.google.com, time.apple.com) are synchronized to within microseconds of UTC. They serve time to stratum 2 servers and are typically operated by national standards laboratories, large technology companies, or research institutions.

Stratum 2 — servers synchronized to stratum 1 servers over the network. They achieve millisecond-level accuracy. The pool.ntp.org project coordinates thousands of volunteer stratum 2 and 3 servers worldwide. Cloud providers (AWS, Google Cloud, Azure) run their own stratum 2 servers accessible to instances within their networks.

Stratum 3 through 15 — each level is synchronized to the stratum above. Accuracy degrades slightly at each level. Stratum 16 means "unsynchronized" and is used to indicate that a server has lost its upstream reference.

Servers at the same stratum level can peer with each other, exchanging time information to improve accuracy and provide redundancy. If a stratum 2 server loses its stratum 1 upstream, it can maintain reasonable accuracy through its stratum 2 peers until the upstream is restored.

The NTP Packet and Timestamp Exchange

NTP uses UDP port 123 for all communication. The choice of UDP is deliberate: TCP's connection establishment overhead (three-way handshake) would add latency that directly degrades time accuracy. NTP packets are small (48 bytes minimum) and self-contained — no connection state is needed.

The core of NTP is a four-timestamp exchange that measures both the clock offset between client and server and the round-trip delay of the network path:

     Client                    Server
       |                         |
  t1 --|---- request ---------->|
       |                    t2 --|
       |                    t3 --|
       |<---------- response ---|-- t4
       |                         |

  t1 = client transmit timestamp (origin)
  t2 = server receive timestamp
  t3 = server transmit timestamp
  t4 = client receive timestamp

  Round-trip delay:  d = (t4 - t1) - (t3 - t2)
  Clock offset:      θ = ((t2 - t1) + (t3 - t4)) / 2

The offset formula assumes that the network delay is symmetric — the time for the request to travel from client to server equals the time for the response to travel back. This assumption is often imperfect (asymmetric routing, buffering, queuing), and asymmetric delay is NTP's primary source of error. The round-trip delay d provides a bound on the error: the offset cannot be wrong by more than d/2.

The NTP packet contains several critical fields beyond the timestamps:

• Leap Indicator (LI) — 2 bits signaling whether a leap second will be inserted or deleted at the end of the current month
• Version Number (VN) — NTP protocol version (currently 4)
• Mode — 3 bits: client (3), server (4), broadcast (5), symmetric active/passive (1/2)
• Stratum — the server's stratum level (1-15, or 16 for unsynchronized)
• Poll Interval — log2 of the polling interval in seconds (typically 6-10, meaning 64-1024 seconds)
• Precision — log2 of the system clock precision in seconds (e.g., -20 for ~1 microsecond)
• Root Delay — total round-trip delay to the stratum 1 source
• Root Dispersion — total dispersion (error bound) to the stratum 1 source
• Reference ID — identifies the server's time source (IP address of upstream server, or GPS/PPS for stratum 1)
• Reference Timestamp — when the server's clock was last set or corrected

NTP timestamps are 64-bit values: 32 bits for seconds since January 1, 1900 (the NTP epoch), and 32 bits for the fractional second. This gives a resolution of approximately 233 picoseconds (2^-32 seconds). The 32-bit seconds counter will roll over on February 7, 2036 — NTPv4 implementations are required to handle this using the era number mechanism defined in RFC 5905.

Clock Discipline Algorithm

NTP does not simply set the clock to the measured offset. Raw time samples are noisy — they include jitter from network queuing, operating system scheduling, and interrupt latency. The clock discipline algorithm filters this noise and adjusts the local clock gradually:

Clock filter algorithm — NTP maintains a window of the last 8 time samples from each server. For each sample, it records the offset, delay, and dispersion. The algorithm selects the sample with the minimum delay (which has the highest probability of being accurate, since minimum delay implies minimum network asymmetry) and uses it as the server's representative offset.

Selection algorithm — When the client has multiple upstream servers (best practice is 4 or more), it must determine which servers are providing accurate time and which might be faulty (falsetickers). The selection algorithm uses the intersection method: it finds the largest intersection of confidence intervals from all servers. Servers whose confidence intervals do not overlap with the intersection are classified as falsetickers and excluded from further calculation.

Clustering algorithm — Among the surviving servers (truechimers), the clustering algorithm selects the best subset based on root distance (a combination of root delay and root dispersion). It iteratively removes the server with the largest root distance until a minimum set remains (typically 3 servers).

Combining algorithm — The selected servers' offsets are combined into a single system offset using a weighted average, where each server's weight is inversely proportional to its root distance.

Clock adjustment — The system offset is applied to the local clock through one of two mechanisms:

• Slew — for offsets less than 128 milliseconds, NTP adjusts the clock rate (running slightly fast or slow) to gradually converge on the correct time. This produces a smooth, monotonic time progression with no jumps. Slewing typically corrects at a rate of 0.5 ms/s, so a 100 ms offset takes about 200 seconds to correct.
• Step — for offsets greater than 128 milliseconds, NTP steps (jumps) the clock to the correct time. This is necessary because slewing a large offset would take too long (a 1-second offset would take ~33 minutes to slew). However, stepping can break applications that assume monotonic time — log timestamps can go backward, timer calculations can produce negative durations, and distributed consensus algorithms can malfunction.

The threshold between slew and step (128 ms) is configurable. Some deployments set tinker panic 0 to disable the panic threshold entirely, or tinker step 0 to prevent stepping and only allow slewing (at the cost of potentially never converging for large offsets).

NTP Modes of Operation

NTP supports several operational modes, each suited to different network architectures:

Client/Server mode is the most common. The client sends a request, the server responds with its timestamps and stratum information. The client does not serve time to anyone. This is what most desktop and server operating systems use when configured with server pool.ntp.org.

Symmetric (peer) mode is used between servers at the same stratum level. Both sides exchange time information and each can adjust its clock based on the other. This provides redundancy: if one peer loses its upstream reference, the other keeps it synchronized. Configured with the peer directive.

Broadcast/multicast mode allows a server to broadcast time to an entire network segment without individual client requests. The server periodically sends NTP packets to a broadcast or multicast address. Clients on the network receive these and discipline their clocks. This reduces server load and network traffic but provides lower accuracy (because the client cannot measure round-trip delay) and is vulnerable to spoofing. Broadcast mode is mostly used in isolated, trusted LAN environments.

Manycast mode combines client/server and multicast: the client sends a request to a multicast address, and all NTP servers on the network respond. The client then selects the best servers and establishes normal client/server associations with them.

The NTP Pool Project

The NTP Pool (pool.ntp.org) is a volunteer-run project that provides NTP service to millions of clients worldwide. Instead of running their own NTP servers, most Linux distributions, embedded devices, and consumer routers are configured to use the pool.

The pool operates through DNS-based load balancing. When a client resolves pool.ntp.org (or a region-specific name like 0.us.pool.ntp.org), the DNS server returns a small set of IP addresses selected from the pool's thousands of volunteer servers. The selection is based on server health monitoring: the pool continuously checks each server's stratum, offset, and reachability, and removes servers that fall out of specification.

Vendor-specific pool zones (like 0.ubuntu.pool.ntp.org, 0.centos.pool.ntp.org) allow the pool operators to track which operating systems are generating load. The DNS TTL is short (typically 300 seconds) so that clients rotate through different servers over time, distributing load and preventing dependence on any single server.

NTS: Network Time Security

NTP was designed without authentication. A man-in-the-middle can modify NTP packets in transit, shifting a client's clock forward or backward. This has security implications: shifting a client's clock forward can cause it to accept expired TLS certificates, and shifting it backward can cause it to accept revoked certificates that have not yet reached their not-before date.

Several security mechanisms have been developed:

Symmetric key authentication (RFC 5905) uses pre-shared keys to authenticate NTP packets with HMAC-SHA1 or similar. This prevents spoofing but requires distributing keys to every client — an operational burden that prevented widespread adoption.

Autokey (RFC 5906) attempted public-key authentication for NTP but was found to have fundamental security flaws and is not recommended.

NTS (Network Time Security), defined in RFC 8915 (published 2020), is the modern solution. NTS uses a two-phase protocol:

1. NTS Key Establishment (NTS-KE) — the client connects to the NTS-KE server over TLS (port 4460 by default). During this TLS handshake, both sides derive symmetric keys using the TLS key exporter mechanism. The server also provides the client with a set of encrypted cookies. This phase happens infrequently (every few hours or days).
2. Secured NTP — normal NTP packets include an NTS extension field containing a cookie (opaque to the client, encrypted for the server) and an AEAD (Authenticated Encryption with Associated Data) authenticator computed with the derived keys. The server validates the authenticator, decrypts the cookie to recover the keys, and returns an authenticated response with a new cookie.

NTS provides authentication (preventing spoofing), integrity (preventing modification), and unlinkability (cookies change with each exchange, preventing tracking of clients). It does not encrypt the NTP timestamps themselves — they are still visible to passive observers — but an observer cannot modify them without detection.

NTS deployment is growing. Cloudflare (time.cloudflare.com), Netnod, and several other providers offer NTS-enabled NTP servers. NTS support is available in ntpd-rs, chrony, and NTPsec.

NTP vs SNTP vs PTP

SNTP (Simple Network Time Protocol) is a simplified implementation of NTP that uses the same packet format but does not implement the clock discipline algorithm, selection algorithm, or peer management. SNTP clients simply take the offset from the most recent server response and apply it directly. This is sufficient for devices that need ±100ms accuracy and cannot afford the complexity of full NTP — embedded devices, IoT sensors, consumer electronics. Most devices that claim to use "NTP" are actually using SNTP.

PTP (Precision Time Protocol, IEEE 1588) operates at a fundamentally different level than NTP. While NTP achieves millisecond accuracy over the internet and microsecond accuracy on LANs, PTP achieves sub-microsecond (often sub-nanosecond) accuracy on local networks using hardware timestamping:

PTP's hardware timestamping is the key differentiator. NTP timestamps are recorded by the operating system when the packet passes through the network stack — subject to interrupt latency, context switches, and queue delays. PTP timestamps are recorded by the NIC hardware at the exact moment the packet crosses the wire, eliminating software-introduced jitter. PTP-aware network switches (boundary clocks and transparent clocks) compensate for queuing and forwarding delay at each hop, ensuring that asymmetric network delays do not corrupt the time measurement.

For applications that need nanosecond-level accuracy — financial exchanges (MiFID II requires 1 μs accuracy for trade timestamps), 5G base station synchronization, and power grid phase alignment — PTP is the only option. For everything else, NTP is sufficient and vastly simpler to deploy.

Leap Second Handling

Earth's rotation is irregular. To keep UTC aligned with astronomical time, the International Earth Rotation and Reference Systems Service (IERS) occasionally inserts (or theoretically deletes) a leap second. When a leap second is inserted, the clock counts: 23:59:58, 23:59:59, 23:59:60, 00:00:00. The second "23:59:60" does not normally exist — its appearance is the leap second.

NTP handles leap seconds through the Leap Indicator (LI) field in the NTP packet header. When a leap second is upcoming, stratum 1 servers receive notification from their reference clocks (GPS receivers include leap second information in their signal) and set the LI field to warn clients. The client's kernel then inserts the leap second at the end of the UTC day.

The standard approach (used by ntpd) inserts the leap second as a repeated second: the system clock ticks 23:59:59, then ticks 23:59:59 again, then 00:00:00. During the repeated second, the POSIX time value is ambiguous — two different instants have the same time_t value.

Google introduced leap second smearing: instead of inserting a discrete leap second, they spread the extra second over a 24-hour window, running the clock slightly slow so that it naturally absorbs the extra second without any discontinuity. This eliminates the ambiguous-timestamp problem but means Google's time disagrees with UTC by up to 0.5 seconds during the smearing window. AWS, Microsoft, and other cloud providers have adopted similar smearing approaches.

In November 2022, the General Conference on Weights and Measures (CGPM) voted to abolish leap seconds by 2035. After that date, UTC will be allowed to drift from astronomical time (UT1) by more than one second, and the leap second machinery in NTP will become unnecessary. Until then, leap second handling remains a source of bugs: the 2012 leap second caused widespread Linux crashes due to a kernel timer bug, and several leap seconds have caused outages at airlines, financial exchanges, and cloud providers.

NTP on Modern Operating Systems

Modern operating systems have moved away from the reference ntpd implementation toward lighter alternatives:

• chrony — the default NTP implementation on RHEL, Fedora, CentOS, and Amazon Linux. Chrony is designed for environments where the system is not always connected (laptops, VMs that get suspended) and converges faster than ntpd after network changes. It also supports NTS.
• systemd-timesyncd — a minimal SNTP client included with systemd (Ubuntu, Debian, Arch). It only operates in client mode (cannot serve time) and does not implement the full NTP clock discipline algorithm. Sufficient for desktops and simple servers.
• ntpd-rs — a Rust implementation of the NTP client and server with NTS support, developed by the NTP-rs project with sponsorship from the Internet Security Research Group (ISRG, the organization behind Let's Encrypt). Memory-safe, modern, and actively developed.
• W32Time — Windows Time Service. Uses SNTP for domain-joined workstations (synchronized to the domain controller) and can be configured for full NTP mode. Domain controllers in an Active Directory forest synchronize time hierarchically, with the PDC emulator at the forest root as the authoritative time source.
• Apple clockd — macOS and iOS use a proprietary NTP implementation that synchronizes with time.apple.com.

NTP Security Considerations

Beyond the packet authentication problems that NTS addresses, NTP has several security considerations:

NTP reflection/amplification attacks — NTP's monlist command (removed in modern implementations) returned a list of up to 600 recent clients, turning a small request into a large response. This made NTP servers attractive for DDoS amplification attacks. The infamous 400 Gbps attack against Cloudflare in 2014 used NTP amplification. Modern NTP servers disable monlist and restrict the mode 6 (control) and mode 7 (private) packet types.

Time-shifting attacks — Without NTS, an on-path attacker can modify NTP responses to shift a client's clock. Practical attacks include: causing TLS clients to accept expired certificates, defeating DNSSEC signature validation (which has expiration timestamps), manipulating Certificate Transparency log verification, and disrupting distributed consensus protocols that depend on synchronized time.

NTP fragmentation attacks — because NTP uses UDP, attackers can inject forged fragments into an NTP response. The IP fragment reassembly mechanism on the client does not authenticate which fragments belong together. An attacker off-path can inject a crafted fragment that is reassembled with a legitimate NTP response, modifying the timestamps. Using NTS or restricting NTP to unfragmented packets mitigates this.

Summary

NTP is the invisible infrastructure that keeps the internet synchronized. Its stratum hierarchy provides a scalable distribution of accurate time from atomic clocks to billions of devices. The four-timestamp exchange measures both offset and delay, and the clock discipline algorithm filters noise from multiple servers to produce a stable, accurate time estimate. The selection and clustering algorithms identify and exclude faulty servers automatically.

NTS (Network Time Security) adds cryptographic authentication to NTP, preventing the time-shifting attacks that have long been possible against unauthenticated NTP. PTP (Precision Time Protocol) provides sub-microsecond accuracy where NTP's millisecond accuracy is insufficient, at the cost of specialized hardware. And the impending abolition of leap seconds in 2035 will eliminate one of NTP's most operationally challenging edge cases.

Accurate time synchronization is critical for BGP route correlation: when the god.ad BGP Looking Glass receives route updates from multiple collectors worldwide, synchronized timestamps are what allow correlating updates for the same prefix across different vantage points. You can explore the timing of BGP changes by looking up any IP address or ASN in the looking glass.