13.10 NTP

Time Synchronization in Networks

In many networked systems, accurate time is not a luxury, it is a requirement. Network Time Protocol, usually called NTP, is the standard protocol used on IP networks to synchronize clocks between devices. In this chapter you will learn what NTP is, why networks use it, how it behaves, and what to watch out for when you deploy it.

Why Time Synchronization Matters

Before looking at how NTP works, it is useful to understand why time is important in a networked environment.

Most modern systems rely on timestamps for security, logging, coordination, and troubleshooting. User logins, application errors, firewall decisions, and transactions are all tagged with dates and times. If different devices have clocks that disagree, it becomes very difficult to correlate events or prove what happened first.

In security, time also appears in authentication tokens, certificates, and session lifetimes. If a client thinks it is in the future compared to a server, or the server thinks it is in the past, authentication can fail even if the credentials are correct. Distributed systems such as databases, message queues, and file systems also depend on roughly aligned clocks to decide which update is the newest.

NTP exists to align the clocks of all participating devices so they share a common notion of time within a small margin of error.

What NTP Is

NTP is an application layer protocol that runs over UDP, most commonly on port 123. It lets a device act as a client that asks for the correct time, or as a server that provides the current time to other devices. A single device can be both a client and a server because it can learn time from an upstream source and then redistribute it to downstream clients.

NTP does not invent its own idea of time. It usually relies on an external authoritative time source, such as atomic clocks or GPS based time, and then spreads that time through the network in a hierarchy. This hierarchy helps avoid overwhelming a small number of highly accurate sources with too many direct requests.

Although there is a simpler variant called SNTP, or Simple NTP, this chapter focuses on the full NTP protocol, which is what you typically encounter in enterprise networks and servers.

Stratum and NTP Hierarchy

NTP organizes time sources in levels called stratums. The stratum of a device describes how far it is from a directly accurate reference clock rather than how accurate it is in absolute terms.

You can think of the NTP hierarchy like this:

A stratum 0 device is not an NTP server itself. It is a physical reference clock. The first real NTP servers that talk on the network and get their time from those reference clocks are at stratum 1. Each step away from the reference clock adds one to the stratum number.

NTP defines stratum values up to 15. A stratum 16 device is considered unsynchronized and should not be used as a reliable time source.

Basic NTP Operation

NTP clients and servers communicate by exchanging small messages that contain timestamps. These timestamps allow the client to estimate two things. First, how far away in time the server is compared to the client, called the offset. Second, how long messages take to travel between them, called the delay.

NTP does not simply take one message and set the clock. It collects multiple samples over time, compares responses from several servers if available, and then chooses a stable estimate. It also changes the clock gradually rather than all at once in most cases. This gradual change is often called slewing.

NTP Message Exchange

At a simplified level, a basic NTP exchange looks like this:

1. The client records the time when it sends a request, call this $T_1$.
2. The server receives the request and records the receive time $T_2$.
3. The server sends a reply, including its own timestamps, and records the send time $T_3$.
4. The client receives the reply and records the receive time $T_4$.

All four timestamps end up in the NTP reply that the client uses to compute offset and delay. The algorithms inside NTP are more advanced than a single formula, but at a high level you can think of them using relationships that involve those four times.

The client repeats this process regularly, which lets it track how its clock drifts compared to the server and apply small adjustments rather than big jumps. This is one of the key reasons NTP is better than simply setting time by hand or running a simple one shot time sync.

Clock Offset and Drift

No normal computer clock is perfect. Clocks run slightly fast or slow. This difference from the correct time is called drift. If you never correct it, even a small drift can become a large error over weeks or months.

NTP tracks this drift by observing how the offset between the local clock and the server changes over multiple exchanges. If the client repeatedly sees that its time is ahead, it will slightly slow down its clock. If it is always behind, it will slightly speed up the clock. Over time, the client learns a model of how its clock behaves and can keep it closely aligned even during short interruptions in connectivity.

NTP over UDP and Ports

NTP uses UDP as its transport protocol. The standard port number is 123. A typical client sends an NTP packet from some high ephemeral port to destination UDP port 123 on the server. The server replies from source port 123 back to the client.

Because NTP uses UDP, there is no connection establishment and no guarantee of delivery from the transport layer. NTP handles lost packets by simply trying again later. It does not need every single request because it is always averaging and smoothing over time.

When you design firewall rules or access control lists, you must allow UDP port 123 in the direction that matches your NTP design. In many networks, only servers in a special DMZ or management zone talk to public NTP servers. Internal clients then talk to those internal NTP servers.

Internal NTP Architecture

In a real network, you rarely want every device to talk directly to external time sources. Instead, you usually create a small NTP hierarchy inside your organization.

At the top, you have a few authoritative internal NTP servers. These servers might be:

1. Directly connected to reference devices, such as GPS receivers.
2. Or configured as clients of several public stratum 1 or stratum 2 servers on the internet.

These top level internal servers often run on robust hardware and are placed in secure, well controlled locations. They provide NTP service to the rest of the internal network.

Below them, you may have other devices that act as secondary NTP servers. Typical examples are core routers, distribution switches, or domain controllers in a Windows environment. These devices synchronize to the main NTP servers and then provide time service to other devices further out.

End hosts such as user PCs, phones, access points, printers, and application servers then point at the nearest reasonable NTP server, often at stratum 3 or 4. This design gives you scalability, reduces external dependencies, and lets you keep a consistent time base even if the internet connection is down for a while.

Time Sources and Accuracy

NTP itself does not enforce how accurate your time is. The quality of your time in the network depends heavily on the source and the path.

Common primary time sources include:

1. GPS receivers that listen to satellite signals.
2. Radio clocks that receive signals from national time services.
3. Direct connections to laboratory atomic clocks in some special environments.

Public internet NTP servers usually get their time from such primary sources and then distribute it at stratum 1 or 2. When you use these public servers, your accuracy also depends on network conditions, especially latency and jitter.

Latency is simply the delay in each direction. Jitter is variation in that delay over time. NTP algorithms are designed to handle some jitter, but large or very unstable delays reduce accuracy. For example, an NTP client that talks to a server on the other side of the world over a busy link will usually be less accurate than a client that talks to a server inside the same data center.

The good news is that for most business applications, sub second accuracy is more than enough, and NTP can often reach millisecond level precision on well connected networks.

NTP in Security Context

Time is deeply integrated into many security protocols. Certificates used in HTTPS, SSH, and other systems all have validity periods defined by start and end timestamps. Kerberos tickets and many token based authentication systems also depend on reasonably accurate clocks.

If a client clock is far in the future, it may think a certificate has expired even though it is valid. If a server clock is far in the past, it might believe a new ticket is not yet valid. In both cases, the end user often sees confusing authentication errors.

Security devices also rely on consistent time for correlation. When you investigate an incident, you might look at logs from firewalls, intrusion detection systems, domain controllers, and application servers. If they are all synchronized using NTP, event timelines line up nicely. If they are not, it becomes very hard to reconstruct what happened.

Because NTP affects security indirectly through time, some environments pay special attention to securing their NTP infrastructure. They may restrict which clients can use internal NTP servers and may avoid allowing arbitrary public servers.

NTP Security Considerations

Classic NTP was designed in a more trusting era of the internet. It assumed that the time servers you contacted were honest. In modern networks, you need to think about NTP as a possible point of attack.

An attacker who can influence your time source might try to push your clocks forward or backward. This can impact logging, forensics, authentication, and even some scheduled jobs. In extreme cases, attackers might try to exploit NTP servers as amplification points for distributed denial of service if NTP is misconfigured.

There are several approaches to reduce these risks:

1. Prefer internal, well controlled NTP servers instead of random external servers.
2. Use access control lists on NTP servers so that only approved clients can query them.
3. Restrict NTP on firewalls so only specific servers can reach the internet on UDP port 123.
4. In more advanced setups, use NTP authentication features that let clients verify that a reply really comes from a trusted server.

NTP authentication uses shared keys or other mechanisms so that the client can check the integrity and origin of NTP messages. It does not encrypt the time, but it prevents simple spoofing of responses.

NTP on Network Devices and Servers

Most operating systems and network devices include NTP clients and can also act as NTP servers. When you configure routers, switches, and firewalls, you usually specify one or more NTP servers that they should use. Many devices can then redistribute time further, which helps you build your internal hierarchy.

Typical configuration choices include:

1. List of NTP server IP addresses or hostnames.
2. Whether the device should also serve NTP to others.
3. Options related to authentication keys, if used.
4. Local reference clocks or fallback behaviors if external servers are unreachable.

In some enterprise environments, domain controllers are treated as authoritative time sources for domain joined machines. In others, separate dedicated NTP appliances or services are used.

It is usually wise to monitor NTP status. Many systems can show you which NTP server is currently selected as the best source, what the estimated offset is, and whether synchronization is stable. This information is very useful during troubleshooting when timestamps look wrong or when logs from different devices do not align.

NTP and Troubleshooting

Incorrect or unstable time can cause many subtle problems. In troubleshooting, you may not immediately suspect NTP, but it can be an important underlying cause.

Common symptoms that point toward NTP issues include:

1. Authentication failures that appear only on some clients or at certain times.
2. Logs that show events in an impossible order, such as logout before login.
3. Scheduled jobs that run at unexpected times.
4. Monitoring systems that show alert timestamps that do not match reality.

When that happens, it is helpful to check:

1. Whether the devices are synchronizing to the expected NTP servers.
2. Whether there are large offsets between their clocks.
3. Whether some devices have incorrect time zones or daylight saving settings, which are separate from NTP but show up in formatted timestamps.

NTP itself does not manage time zones. It works in Coordinated Universal Time, often abbreviated as UTC. Local time zone conversions are handled by each device. So when you see time differences, make sure to separate pure clock offset issues from formatting and time zone configuration issues.

Key Practical Guidelines

NTP is a rich protocol with many options, but a few practical guidelines will take you a long way.

First, plan which devices will be your main time servers. Give them reliable connectivity and protect them. Second, configure every device in your network that supports it to use NTP rather than manual clock setting. Third, provide multiple NTP servers for redundancy and comparison. Finally, limit NTP exposure at your network edge and consider authentication in more sensitive environments.

By understanding NTP at this level, you can make sensible design decisions and recognize when time synchronization might be the hidden factor in network problems.