This was originally a course report written on 2024-12-09. It has been edited for publishing online.

Introduction

The Network Time Protocol (NTP) is one of the few protocols that have been continuously used from the early Internet to the present. Its current version is NTPv4, standardized through IETF as RFC 5905 in 2010. It is a client/server protocol. The server listens at UDP port 123. The protocol was designed by Professor David L. Mills (Dave Mills thereafter) in the 1980s.

NTP solves the basic issue of accurately distributing time over the Internet. It is generally said to provide millisecond-level accuracy over the Internet. For applications needing higher accuracy, Precision Time Protocol (PTP) would fulfill the need. However, PTP would need timestamping support in NIC hardware to work well, switches along the way should also support PTP to account for delay in forwarding.¹ PTP is not designed to work on public Internet.

Basic operation of NTP

The task of NTP is to synchronize the time on a local computer with a time server over the Internet. The process NTP uses is described in Section 8 of RFC 5905, which is remarkably simple (only one round trip is needed):

The client initiates the process by first sending a packet containing its local timestamp (t₁). The server records the moment it receives the packet (t₂), and later responds by sending a packet containing t₁, t₂ as well as the transmission time (t₃). Next the client will receive the packet with t₁, t₂ and t₃ at timestamp t₄.

Denote the advance of time the server to the client as θ, the round-trip delay as δ. Consider the relationship between timestamps for the two packets, assuming the link is symmetrical (one-way delay is δ/2):

From the equation, it can be seen that the round-trip time (RTT) is objectively calculated without assumptions about the link. However, the symmetry assumption might not hold on the public Internet, degrading the accuracy of time offset estimation. This can result from asymmetrical routing paths, where the outgoing and incoming packets travel through different physical links due to routing policies. It’s also quite common for residential access networks to have asymmetrical latency between uplink and downlink due to queuing delay caused by their use of shared media. A notable example is DOCSIS (using coaxial TV cable), which employs TDMA in the uplink. Uplink transmission opportunities must be requested and granted every few milliseconds, leading to 4-8ms extra delay compared to the broadcast-style downlink.² The asymmetrical transmission delay caused by slower uplink speed in ADSL is another example.

Another interesting feature of NTP is its timestamp format. Instead of the ubiquitous UNIX timestamp one might expect in Internet protocols, NTP uses its custom timestamp format to represent a time in UTC. The format transmitted over the wire is the 64-bit timestamp format, consisting of a 32-bit unsigned integer for seconds since the NTP epoch, followed by a 32-bit fixed-point fraction representing parts of a second. 2³² - 1 seconds is around 136 years, which becomes the length of an NTP era. We are currently in era 0, whose epoch is set to 1900-01-01 00:00:00 and will end on 2036-02-07. The era is not indicated in the wire format, therefore could cause overflow issues similar to the Y2K, 2038, or GPS rollover problems, if not properly handled. The overflow issue is implicitly addressed through the time difference calculation algorithm, under the condition that the time on the client is within ±68 years of the server time.³

Hierarchy of NTP service

The hierarchy of NTP is envisioned to be a tree-like structure, similar to that of DNS. The hierarchy level, called stratum, indicates a device’s distance from an authoritative time source. Atomic clocks and GPS/GNSS receivers serve as authoritative time sources (stratum-0), though they are not part of the NTP network itself. NTP servers directly connected to these sources are stratum-1 servers. Machines synchronizing directly with stratum-1 servers become stratum-2, and so on. Each synchronization level introduces additional timing uncertainty, so servers at stratum-2 and above are called secondary NTP servers. The NTP protocol specifies stratum 16 as MAXSTRAT, indicating an unsynchronized state. The stratum is an 8-bit integer in the wire format. This hierarchical structure enables the NTP service to scale (not putting all the load on primary NTP servers), while maintaining the confidence in accuracy.

The wire format contains a 32-bit field for “Reference ID”, which describes the kind of time reference used for a server. Primary NTP servers (stratum-1) set this field to the name (in ASCII) of time source, which is usually GPS/GNSS, but could be some radio clock signal in earlier times, or an atomic clock if it’s available for the owner of the server. For secondary servers, this field is customarily set to the IPv4 address of the server it is synchronized to. This is used to prevent timing loops within the same stratum. It can also provide traceability for the time results. Since IPv6 addresses are 128 bits and cannot fit in this field, NTPv4 specifies using a truncated MD5 hash of the IPv6 address instead.

Implementations of NTP

The reference implementation of NTP is the ntpd, originally written by Dave Mills. Since network jitter on the Internet is a random process, accurate synchronization requires continuous measurements rather than single updates. The NTP specification extensively details both the server selection algorithm for identifying reliable time sources and the filtering algorithm for tracking time accurately. ntpd can estimate and compensate for the local computer’s clock frequency error in software. By default, it operates in slew mode, gradually adjusting the system time to avoid sudden changes that could disrupt running applications.

As Dave Mills’ health declined, the development of ntpd transferred to his long-time collaborator Harlan Stenn in the 2000s. Stenn was the sole developer of ntpd for some years.⁴⁵ ntpd suffers from the same viability issue as other classical open source software projects like openssl: While being an important piece of software infrastructure, it is overlooked and lacks a business model. The age of the software also deters newcomers from participation. Stenn has since found the Network Time Foundation to support the development of ntpd. Compared to the last time I checked back in early 2023, the development still happens in a BitKeeper repository, but a GitHub mirror appears to have been set up. However, the project still faces infrastructure maintenance challenges, as evidenced by persistent 502 errors from the support.ntp.org website.

Another popular NTP implementation is chrony. It is included as the default NTP server in RHEL since RHEL 7. Developed by Red Hat employees, chrony is a newer piece of software and is more actively developed, compared to the mature but stagnant state of ntpd. In a comparison page made by chrony, they claim to have better performance in terms of convergence (synchronization) speed and accuracy than ntpd.⁶

Other prominent NTP server implementations include OpenNTPD, developed by the OpenBSD team, as well as NTPsec, forked from ntpd with clean ups.

On modern desktop Linux distributions, time synchronization is typically handled by systemd-timesyncd. This is actually not a full NTP implementation, but a Simple Network Time Protocol (SNTP) client. SNTP is a subset of NTP that is oriented towards one-off operation. It does not implement the complex tracking algorithms as a full NTP implementation does.

Security issues with NTP

The early Internet environment had a sense of trust and was much friendlier than today’s Internet, which is plagued by bots and malicious infiltrations. Early Internet protocols tend to be designed without security and defense mechanisms. Following the trend of encrypting Internet traffic (as seen with the uptake of HTTPS after 2015), Network Time Security (NTS) is an extension to NTP that uses TLS-based encryption to defend against man-in-the-middle (MITM) attacks. However, no major operating system has yet shipped NTS support in their default time synchronization services.

NTP shares a common vulnerability with DNS: UDP-based protocols can be exploited for reflected amplification DDoS attacks through IP spoofing. Unlike TCP, which requires a bilateral handshake, UDP’s connectionless nature makes such attacks possible. The attack’s effectiveness is measured by the bandwidth amplification factor, which is the ratio between response and request packet sizes. Since late 2013, a feature in ntpd called “monlist” has been exploited as a vector for reflection attack, with amplification factor as high as 206x.⁷⁸ While this problematic feature has since been disabled by default in newer ntpd releases, the fundamental vulnerability of UDP to IP spoofing remains. This risk has been partially mitigated by increased adoption of network filtering practices, particularly BCP 38, which prevents source address spoofing at network boundaries.

Old and poorly maintained software often contains vulnerabilities that can be exploited to compromise a system. ntpd experienced such a critical vulnerability in 2014. The widespread impact of the OpenSSL Heartbleed vulnerability that same year increased industry awareness about the security risks of under-maintained infrastructure software, leading to funded security audits of several critical open-source projects.

Ecosystem of NTP service

NTP is the standard method to obtain time over the Internet. Major operating systems ship with default NTP servers operated by their respective companies, including time.windows.com, time.apple.com and time.android.com. National research institutes concerning time often provide a NTP server to serve the public. Several technology companies have also built and made available their own public NTP infrastructure, including Cloudflare, Facebook (currently known as Meta), Amazon, and others.

Individuals can also set up NTP servers themselves using various time sources: In the past there were radio clock or second-hand atomic clock. It has been easier nowadays with the wide availability of GPS/GNSS receivers, which provide nanosecond-level accuracy as long as there is a clear view of the sky. The NTP Pool Project serves as the major collective organization for these volunteer-operated NTP servers and is used by default in many Linux distributions. The project continuously monitors participating servers, removing those that fail to maintain sufficient time accuracy.⁹ The clients are directed to servers in the same country or region by a custom GeoDNS software.

However, volunteer-run services are more susceptible to attacks and more likely to cease services. The growth of participant number stalled in 2014 due to the rise of NTP-based DDoS attacks. Abuses caused poorly configured devices or software have often made it into news, a collection of those can be found in Wikipedia.

While the NTP Pool Project does not publicly list participating server IP addresses on its website, researchers have compiled datasets of the network’s composition.¹⁰ Volunteers can choose which country zones to serve, and notable imbalance in server availability between countries can be observed.¹¹

Besides operational challenges, the NTP Pool is largely maintained by one man Ask Bjørn Hansen, and changes happen slowly. A longstanding issue was the reliance on a single monitoring location, which sometimes incorrectly flagged servers as unreliable due to network-specific connectivity issues. A new distributed monitoring system was finally deployed in 2023.¹² Another ongoing challenge is IPv6 support: currently, only 2.pool.ntp.org provides AAAA records,¹³ despite community requests to enable IPv6 for all endpoints.

The author would like to express his condolences to the memory of Professor David L. Mills.