NTP: Network Time Protocol

What is NTP?

NTP (Network Time Protocol) is one of the oldest protocols still in active use on the internet. Its purpose is straightforward but critical: synchronize clocks across networked devices so that every machine agrees on the current time. Created by David Mills at the University of Delaware in 1985, NTP has been continuously refined over four decades and remains the backbone of time synchronization for the vast majority of internet-connected systems.

The current version, NTPv4, is defined in RFC 5905 and was published in 2010. NTP operates over UDP on port 123, which keeps it lightweight and fast. Over the public internet, NTP can achieve accuracy within a few milliseconds of Coordinated Universal Time (UTC). On local area networks, that accuracy improves to the sub-millisecond or even microsecond range.

Time synchronization may sound like a simple problem, but it is surprisingly difficult. Every clock drifts at a slightly different rate depending on temperature, voltage, and hardware quality. Network latency adds further uncertainty because a time message takes a nonzero amount of time to travel between client and server. NTP accounts for all of these factors through a combination of statistical filtering, hierarchical trust, and continuous adjustment.

NTP Stratum Hierarchy

NTP organizes its time sources into a layered hierarchy called the stratum model. Each stratum level represents one degree of separation from a highly accurate reference clock. The lower the stratum number, the closer the server is to the authoritative time source.

• Stratum 0: these are the reference clocks themselves. They are not network devices but rather high-precision timing sources such as GPS receivers, atomic clocks (cesium or rubidium), or radio receivers tuned to national time signals (like WWVB in the United States or DCF77 in Germany). Stratum 0 devices do not participate in NTP directly. Instead, they feed time to stratum 1 servers through a direct hardware connection.
• Stratum 1: primary time servers that are directly connected to a stratum 0 reference clock. These servers receive their time from GPS antennas, atomic clocks, or other precision sources with minimal delay. Stratum 1 servers are the highest level of NTP server that participates in the network protocol. Major institutions, government agencies, and network operators maintain stratum 1 servers.
• Stratum 2: servers that synchronize their clocks from stratum 1 servers over the network. These are one step further from the reference clock and introduce a small amount of additional uncertainty due to network latency. Most public NTP servers that end users connect to are stratum 2 or stratum 3.
• Stratum 3 through 15: each successive stratum level synchronizes from the level above it. Every additional hop introduces a small amount of timing error. NTP supports up to stratum 15. Any device reporting stratum 16 is considered unsynchronized and should not be used as a time source.

This hierarchical design provides both accuracy and redundancy. If a stratum 1 server becomes unavailable, stratum 2 servers can continue operating based on other stratum 1 or stratum 2 peers. NTP clients typically query multiple servers and use algorithms to select the most accurate and reliable source.

How NTP Time Synchronization Works

NTP uses a four-timestamp exchange between client and server to calculate both the clock offset (how far off the client's clock is) and the round-trip network delay. This elegant mechanism allows NTP to compensate for variable network latency without requiring synchronized clocks to begin with.

The exchange works as follows:

1. T1 (Originate Timestamp): the client records its local time and sends a request packet to the NTP server.
2. T2 (Receive Timestamp):the server records the time it receives the client's request.
3. T3 (Transmit Timestamp): the server records the time it sends its response back to the client.
4. T4 (Destination Timestamp):the client records the time it receives the server's response.

With these four timestamps, the client calculates two values. The round-trip delay is (T4 - T1) - (T3 - T2), which is the total network transit time excluding processing time on the server. The clock offset is ((T2 - T1) + (T3 - T4)) / 2, which represents how far ahead or behind the client's clock is relative to the server.

NTP does not simply jam the clock to the correct time. Instead, it uses two adjustment strategies. For small offsets (typically under 128 milliseconds), NTP uses slewing, which gradually speeds up or slows down the system clock until it converges on the correct time. This avoids sudden time jumps that could disrupt running applications. For large offsets (over 128 milliseconds by default), NTP uses stepping, which sets the clock immediately to the correct time. Stepping is generally only needed during initial synchronization or after a long period of disconnection.

To improve accuracy, NTP clients poll multiple servers and apply statistical filtering to discard outliers. The intersection algorithm identifies the largest group of servers that agree on the time, and the cluster algorithm selects the best candidates from that group. This makes NTP resilient against individual servers that may be inaccurate or compromised.

NTP Modes of Operation

NTP supports several operational modes to accommodate different network topologies and requirements. The mode determines how two NTP endpoints interact with each other.

NTP Pool Project

The NTP Pool Project (pool.ntp.org) is a massive volunteer-driven network of time servers that provides free NTP service to millions of clients worldwide. Instead of relying on a handful of well-known NTP servers (which could become overloaded), the pool distributes the load across thousands of volunteer-operated servers.

When a client queries pool.ntp.org, the pool's DNS system returns a different set of server IP addresses through round-robin DNS. Each response includes a small subset of servers selected from the pool, and the selection rotates so that load is spread evenly. The pool monitors each server's accuracy and availability, automatically removing servers that become unreliable.

Regional pools allow clients to connect to geographically nearby servers for lower latency. Common regional prefixes include us.pool.ntp.org for the United States, europe.pool.ntp.org for Europe, and asia.pool.ntp.org for Asia. Most Linux distributions configure the NTP pool as the default time source out of the box. For example, Ubuntu uses ntp.ubuntu.com, which itself is part of the NTP pool infrastructure. The pool currently consists of over 4,000 active servers handling billions of queries per day.

NTP vs Other Time Protocols

NTP is not the only time synchronization protocol available. Depending on accuracy requirements and deployment environment, other options may be more suitable.

SNTP (Simple Network Time Protocol) is a simplified subset of NTP that omits the complex filtering and selection algorithms. It is defined in RFC 4330 and is suitable for devices that only need rough time accuracy. PTP (Precision Time Protocol, IEEE 1588) uses hardware timestamping and can achieve nanosecond-level precision, but it requires specialized network hardware and is typically used in data centers, financial exchanges, and telecom networks. Chrony is not a separate protocol but rather a modern NTP client and server implementation. It has replaced the traditional ntpd daemon in most Linux distributions because it handles intermittent connections, large clock drifts, and virtual machine environments more gracefully.

NTP Security

Because NTP is a UDP-based protocol with no built-in authentication in its original design, it has been the target of several types of attacks over the years. Securing time synchronization is important because many security mechanisms (TLS certificates, Kerberos, TOTP tokens) depend on accurate clocks.

NTP amplification attacks exploit the monlist command, which was a debugging feature in older NTP implementations. An attacker sends a small forged request with a spoofed source IP address, and the NTP server responds with a much larger reply directed at the victim. Amplification factors of 500x or more were observed in the wild. Modern NTP servers have disabled the monlist command, and network operators use BCP 38 (ingress filtering) to prevent IP address spoofing.

NTS (Network Time Security), defined in RFC 8915, is the modern solution for authenticated NTP. NTS uses TLS to establish a secure association between client and server, then provides cryptographic authentication for subsequent NTP packets. Unlike the older symmetric key approach (which required manual key distribution), NTS integrates with the TLS public key infrastructure, making it practical to deploy at scale.

The NTPsec projectis a security-focused fork of the reference NTP implementation. It removes legacy code, applies modern secure coding practices, and supports NTS out of the box. For organizations that need trustworthy time, using NTS-capable servers and keeping NTP software up to date are essential practices. It is also important to configure multiple independent time sources so that a single compromised server cannot shift the client's clock undetected.

Common Use Cases for NTP

• Log correlation and forensics: when investigating security incidents or debugging distributed systems, logs from multiple servers must have consistent timestamps. Even a few seconds of clock skew can make it impossible to reconstruct the correct sequence of events.
• TLS certificate validation:TLS/SSL certificates have validity periods defined by start and end dates. If a client's clock is wrong, it may reject a valid certificate as expired or accept an expired certificate as valid, breaking secure connections.
• Distributed systems consensus: protocols like Raft and Paxos rely on timeouts and ordering guarantees. Databases such as Google Spanner use tightly synchronized clocks (via TrueTime) to provide globally consistent transactions. Without accurate time, distributed consensus becomes unreliable.
• Financial transactions: regulatory requirements in many jurisdictions mandate that financial trading systems maintain time accuracy to specific thresholds. MiFID II in Europe, for example, requires timestamps accurate to 100 microseconds for high-frequency trading.
• Kerberos authentication: the Kerberos protocol uses timestamps in its ticket-granting mechanism and rejects requests when the clock skew between client and server exceeds 5 minutes by default. Synchronized clocks are a hard requirement for Kerberos to function.
• Cron jobs and scheduled tasks: automated tasks triggered by time (backups, report generation, batch processing) depend on accurate system clocks. Clock drift can cause jobs to run at the wrong time or overlap with each other.
• Database replication: many database replication schemes use timestamps to order writes and resolve conflicts. Clock skew between replicas can lead to data inconsistencies, lost updates, or replication failures.

Frequently Asked Questions About NTP

What happens if clocks are not synchronized?

Unsynchronized clocks can cause a wide range of problems. Log files from different servers become impossible to correlate because events appear out of order. TLS certificates may be incorrectly rejected as expired. Kerberos authentication fails when clock skew exceeds the allowed threshold. Distributed databases can produce inconsistent results, and scheduled tasks may execute at the wrong time. In security-sensitive environments, clock discrepancies can mask or complicate forensic investigations.

What is the difference between NTP and SNTP?

SNTP (Simple Network Time Protocol) uses the same packet format as NTP but omits the sophisticated clock discipline algorithms. A full NTP implementation polls multiple servers, applies statistical filtering, and gradually adjusts the clock to maintain long-term stability. SNTP simply takes the time from a single server response and sets the clock accordingly. SNTP is appropriate for devices that need only rough accuracy (within a second or so) and lack the resources to run a full NTP implementation.

How accurate is NTP?

Over the public internet, NTP typically achieves accuracy within 1 to 10 milliseconds of UTC, depending on network conditions and the quality of the time source. On a well-configured local area network, NTP can achieve accuracy of 100 microseconds or better. For applications that need sub-microsecond or nanosecond precision, PTP (Precision Time Protocol) with hardware timestamping is the better choice.

What is the NTP pool?

The NTP pool (pool.ntp.org) is a large, volunteer-run network of time servers that provides free time synchronization service. It uses DNS round-robin to distribute clients across thousands of servers worldwide. The pool automatically monitors server health and accuracy, routing clients away from servers that are unreliable. Most Linux distributions and many network devices use the NTP pool as their default time source.

Can NTP be used for attacks?

Yes. NTP has been exploited in two main ways. First, NTP amplification DDoS attacks abuse the monlistcommand in older implementations to generate massive traffic volumes directed at a victim. Second, time-shifting attacks attempt to manipulate a target's clock to undermine security mechanisms that depend on accurate time, such as certificate validation or replay protection. Both attack types are mitigated by using modern NTP software, enabling NTS authentication, and disabling unnecessary features like monlist.

What is the difference between ntpd and chrony?

Both ntpd and chrony are NTP implementations, but they differ in design philosophy. ntpd is the original reference implementation maintained by the NTP Project. It is well-tested but assumes a stable, always-connected environment. chrony was designed for modern use cases including laptops that sleep and wake frequently, virtual machines with unstable clocks, and systems with intermittent network connectivity. Chrony typically synchronizes faster after startup and handles large clock drifts more effectively. Most major Linux distributions (including RHEL, Fedora, and Ubuntu) now ship chrony as the default NTP client.

Related Protocols

• UDP: the transport protocol used by NTP for its lightweight, low-latency time queries on port 123
• DNS: used by NTP clients to resolve pool server hostnames like pool.ntp.org into IP addresses
• TCP: used by NTS (Network Time Security) for the initial TLS handshake that establishes authenticated NTP sessions
• SSH: secure remote administration protocol that depends on synchronized clocks for logging and key-based authentication