skip to content

How do NTP's client-server, symmetric active/passive and broadcast modes differ in who synchronises whom, and where does each belong?

level: middleimportance: should knowfreq 22%

answer

  1. pull, push-pull, push
  2. mode field: 1, 2, 3, 4, 5
  3. ephemeral passive association on demand
  4. broadcast cannot measure delay alone
  5. trusted peers, trusted networks only

basics

~20 s

In client-server mode a client (mode 3) pulls time from a server (mode 4) that never takes time back; symmetric peers (modes 1 and 2) push and pull with each other; a broadcast server (mode 5) pushes time to listening clients.

solid answer

~40 s

NTPv4 (RFC 5905) carries a 3-bit `Mode` field. In **client-server** mode the client sends mode 3 and the server answers mode 4 without keeping state; servers give synchronisation but never accept it from clients. In **symmetric** mode a configured peer sends symmetric active (mode 1) packets, and a host with no matching association mobilises an ephemeral symmetric passive (mode 2) one, so both peers can synchronise each other - useful for same-tier backup. In **broadcast** mode a server sends periodic mode 5 packets that many clients hear; a client should first run a short client-server exchange to calibrate the propagation delay. RFC 8633 says to run broadcast only on trusted networks and to allow symmetric passive associations only with authenticated, trusted peers. Mode 6 is control and mode 7 private use, not time transfer.

go deeper

for a junior

Recall the three variants: clients pull time from servers, symmetric peers exchange time both ways, a broadcast server pushes time to listeners, all on UDP port 123.

for a middle

Explain the mode numbers, ephemeral symmetric passive mobilisation, why broadcast clients calibrate delay with a client-server exchange first, and RFC 9109's random client source port.

for a senior

Place each mode in a real hierarchy - client-server down the tiers, authenticated symmetric peering within a tier, broadcast only on trusted segments - and explain the attack surface each opens.

for a principal

Decide which modes an estate permits at all, weighing the resilience of same-tier peering against the trust and key-management cost RFC 8633 attaches to symmetric and broadcast modes.

## The Mode field Every NTPv4 packet carries a 3-bit `Mode`. RFC 5905 defines: | Value | Meaning | |---|---| | 0 | reserved | | 1 | symmetric active | | 2 | symmetric passive | | 3 | client | | 4 | server | | 5 | broadcast | | 6 | NTP control message | | 7 | reserved for private use | Modes 1-5 move time. Mode 6 is for monitoring and control, and mode 7 is for private use; their abuse is a matter for securing time sources. An **association** is the relationship one NTP speaker keeps with another. **Persistent** associations come from configuration and live for as long as the host runs; **ephemeral** ones are created when a packet arrives and removed on error or timeout. ## Client-server: clients pull - The client sends **mode 3** requests to a configured server; the server returns **mode 4** replies. - The server answers each request from its system variables **without retaining state** (RFC 5905's fast-transmit path), so one server can serve thousands of clients. - RFC 5905: servers provide synchronisation to clients "but do not accept synchronization from them". Time flows one way, down the tree. - This is the default for almost every host: the 2,000 clients of a data centre follow its four internal servers this way, and those servers follow two GPS-fed appliances the same way. ## Symmetric active/passive: peers push and pull - A host configured with a peer sends **symmetric active (mode 1)** packets. When a mode 1 packet reaches a host with no matching association, that host mobilises an **ephemeral symmetric passive (mode 2)** association and answers in mode 2. - Each peer can synchronise the other, so two or more servers at the same tier back each other up: if one internal server loses both appliances, it can follow a peer that still has one. - Both ends use the NTP port, **123**, in symmetric modes. - **Cost:** a passive peer can be asked by *anyone* to start an association, which gives an arbitrary sender a way to try to move its clock. RFC 8633 (the NTP BCP) says a host **SHOULD** allow symmetric passive associations only with trusted peers, **SHOULD** require each to be cryptographically authenticated, and **SHOULD** use a different key per association. ## Broadcast: one server pushes - A **broadcast server** sends periodic **mode 5** packets to a broadcast or multicast address; RFC 5905 records the IANA-assigned IPv4 group 224.0.1.1 for NTP. - A host receiving one with no matching association mobilises a **broadcast client** association. (Its association mode value is 6 - RFC 5905 stresses this is not the same thing as a mode 6 *packet*, which is a control message.) - One-way packets cannot measure propagation delay, so the RFC says implementations **SHOULD** first run a short client-server exchange to calibrate the delay, then switch to listening. - **Cost:** RFC 8633 notes that every broadcast client must hold the shared symmetric key, so any client could forge server packets; broadcast **SHOULD** run only within a trusted network. ## Ports Servers listen on **UDP port 123**. RFC 9109 updates RFC 5905: broadcast servers and symmetric peers **SHOULD** keep 123 as their source port, but a client-mode association **SHOULD** use a **randomized source port**, which makes off-path spoofing harder and lets a filter tell requests from replies. Why NTP rides UDP at all is a transport question, not a mode question. ## Placing each mode | Mode | Time flows | Fits | Watch out for | |---|---|---|---| | Client-server | server -> client | almost every host, every tier | nothing flows back up | | Symmetric | both ways between peers | same-tier server backup | unauthenticated passive peers | | Broadcast | server -> many listeners | trusted LAN segments of simple devices | shared key, delay must be calibrated | RFC 5905 also defines manycast, a discovery scheme where a client multicasts mode 3 requests and suitable servers answer in mode 4 - a way to find servers, not a different way to transfer time.

  • Why does an NTP broadcast client exchange a few client-server packets before it starts listening?
    Broadcast packets travel one way, so the client cannot measure the round trip from them. RFC 5905 says implementations SHOULD run a short client-server exchange first to calibrate the propagation delay, then set the association to broadcast client and listen. Without it the client must assume a delay, and any error there becomes offset error.
  • Why does RFC 8633 restrict NTP symmetric passive associations?
    A host mobilises a symmetric passive association whenever a symmetric active packet arrives with no matching association, so any sender can ask to become its peer and try to change its time. RFC 8633 says to allow symmetric passive only with trusted peers, authenticate each one cryptographically, and use a different key per association.

saying these in an interview costs you the question

  • An NTP server also adjusts its clock from the clients it serves
  • Symmetric mode is just client-server with longer polling
  • Broadcast clients can measure delay from mode 5 packets alone
  • NTP clients must use source port 123
  • Mode 6 packets are how broadcast clients receive time