skip to content

An NTP exchange crosses a path taking 40 ms out and 10 ms back; how wrong is the computed offset, and why can the client not tell?

level: seniorimportance: must knowfreq 30%

answer

  1. the symmetry assumption
  2. half the difference between legs
  3. same timestamps, different truth
  4. bounded by half the delay

basics

~20 s

The offset comes out 15 ms too high, half the 30 ms gap between the legs. The same four timestamps fit a symmetric path with another offset, so the exchange cannot reveal it; the error is bounded by half the 50 ms delay.

solid answer

~50 s

NTP's offset `((T2-T1)+(T3-T4))/2` equals the true offset plus half of (outbound transit minus return transit). With 40 ms out and 10 ms back that is `(40-10)/2 = +15 ms`: the client believes the server is 15 ms further ahead than it is. The delay `(T4-T1)-(T3-T2)` only sees the sum, 50 ms, so it looks normal. Worse, the four timestamps are identical to those of a symmetric 25/25 ms path with a 15 ms larger offset, so the client has nothing to tell the two apart, and repeating the exchange changes nothing while the asymmetry stays constant. What it can say is how bad it might be: the gap between legs can never exceed the round trip, so the error is at most half the delay, 25 ms here. The defences are operational: short, symmetric paths to servers, and timestamps taken close to the wire.

go deeper

for a junior

Recall that the offset formula assumes the trip out and the trip back took the same time.

for a middle

Derive that the error is half the difference between the legs, and show the delay only measures their sum.

for a senior

Show two worlds that produce identical timestamps, bound the error by half the delay, and name the operational causes and levers.

for a principal

Turn the bound into an accuracy promise: choose server placement and paths so half the round trip fits inside the error budget the business needs.

## Where the error comes from Let the true offset be `theta0` (server minus client), the outbound transit `d_out` and the return transit `d_back`. Then, in NTP's four timestamps: - `T2 - T1 = d_out + theta0`, because the server's clock reads `theta0` more than the client's. - `T3 - T4 = theta0 - d_back`, for the same reason in the other direction. The offset formula from RFC 5905 adds these and halves them: `theta = ((T2-T1) + (T3-T4)) / 2 = theta0 + (d_out - d_back) / 2` So the computed offset is the truth plus **half the difference between the legs**. The delay formula, `delta = (T4-T1) - (T3-T2) = d_out + d_back`, sees only the **sum** of the legs and is unaffected by how that sum is split. ## The 40 ms out, 10 ms back case worked Say the server really is 20 ms ahead and holds the request for 5 ms. 1. The client sends at `T1 = 1000` on its clock, which is 1020 on the server's. 2. After 40 ms the server reads `T2 = 1060`. 3. It replies at `T3 = 1065`. 4. After 10 ms the server's clock reads 1075, which is `T4 = 1055` on the client's. Delay: `(1055 - 1000) - (1065 - 1060) = 55 - 5 = 50 ms`. Offset: `((1060 - 1000) + (1065 - 1055)) / 2 = (60 + 10) / 2 = 35 ms`. The true offset is 20 ms, so the result is **15 ms too high**, which is `(40 - 10) / 2`. If the legs were reversed, 10 ms out and 40 ms back, the result would be 15 ms too low. A longer outbound leg always makes the server look further ahead. ## Why the client cannot detect it Now take a different world: a symmetric path of 25 ms each way and a true offset of 35 ms. The client sends at 1000 (1035 on the server), the server reads 1060, replies at 1065, and the reply lands when the server's clock reads 1090, which is 1055 on the client's. The four timestamps, `1000, 1060, 1065, 1055`, are **identical** to the asymmetric case. | World | Out / back | True offset | T1, T2, T3, T4 | Computed offset | |---|---|---|---|---| | A | 40 / 10 ms | 20 ms | 1000, 1060, 1065, 1055 | 35 ms | | B | 25 / 25 ms | 35 ms | 1000, 1060, 1065, 1055 | 35 ms | Since the client's only evidence is the four numbers, and both worlds produce the same numbers, nothing in the exchange can tell them apart. Repeating the exchange does not help while the asymmetry stays constant: every sample is shifted by the same 15 ms, so the samples agree with each other and look trustworthy. Measuring a fixed asymmetry takes something outside the exchange: an independent reference that knows the true time, or a separate measurement of each leg. ## The bound the client can still compute The client does know the sum of the legs, the delay. Neither leg can be negative, so the difference between them is at most their sum, and the error is at most **half the round-trip delay**: 25 ms for a 50 ms delay. RFC 5905 builds this into its **peer synchronization distance**, `lambda = delta/2 + epsilon`, where `epsilon` is the dispersion, and it carries the same idea up the chain as the root synchronization distance. NTP's source-selection algorithms then use that distance; how they do so is a separate subject. ## Where asymmetry comes from, and what an operator can do - **Different routes each way.** The request and the reply can follow different paths through the network. - **One-directional queueing.** A congested uplink delays requests while replies on the downlink pass freely. - **Timestamps taken away from the wire.** RFC 9769 notes that asymmetry in where the transmit and receive timestamps are captured causes an offset error; a timestamp taken in user space misses time spent in the system before the packet leaves. - **An on-path delayer.** RFC 8915, Network Time Security, says a man-in-the-middle that delays packets asymmetrically cannot be stopped by cryptography, because the packets are unmodified; the error it can cause stays bounded by half the round trip. The operator's levers follow from the bound: prefer servers with **short round trips**, since a smaller delay means a smaller worst case; keep the path to time servers simple and symmetric; capture timestamps as close to the wire as the hardware allows; and use several servers over different paths, so a skewed path disagrees with the others instead of passing unnoticed.

  • Does authenticating NTP traffic with Network Time Security remove the asymmetric-path error?
    No. RFC 8915 explains that a delay attack does not modify or reorder packets, so cryptography cannot detect it; NTS proves who sent the timestamps, not how long they took. The error an attacker can add is still bounded by half the round-trip delay, and RFC 8915 points to multiple sources or paths as mitigation.
  • How can asymmetry arise inside the hosts rather than on the network path?
    If a timestamp is captured in software well before the packet actually leaves, or well after it arrives, that hidden time acts like a longer leg in one direction. RFC 9769 says timestamping asymmetry causes an offset error, and its interleaved modes let a server send the more accurate transmit time of its previous packet.
  • Does the asymmetry bound stop at the client's own server?
    No. The server's own time came over paths with their own asymmetry. RFC 5905 accumulates delay up to the primary server as the root delay and defines the root synchronization distance as root dispersion plus half the root delay, the maximum error from all causes.

saying these in an interview costs you the question

  • Running more exchanges over the same path averages a fixed asymmetry out.
  • Authenticating NTP with NTS or symmetric keys protects the offset from asymmetric delay.
  • The asymmetry error can be larger than the whole round-trip delay.
  • A longer outbound leg makes the client think the server is behind.
  • An asymmetric path shows up as an unusual delay value.