NTP, PTP, NTS, and Time-Sensitive Networking

Why Time Is a Network Service

Time services are invisible until they break, and then they break everything at once. Certificate validation compares the not-before / not-after dates against the client clock; Kerberos authentication rejects tickets whose timestamp is outside the default five-minute window; logs, backups, monitoring, and distributed databases all assume synchronized clocks. When many users hit certificate or logon errors simultaneously, clock drift is a prime suspect.

The practical lesson is that time is a shared dependency, not just a clock readout. A single device whose battery-backed clock drifts can still pass traffic but will quietly fail TLS handshakes, reject Kerberos tickets, and stamp logs with the wrong time, sending you chasing application bugs that do not exist. On the exam, any scenario where many unrelated services fail at once - especially security and authentication services - should make you check time before anything else.

NTP, Stratum, and a Reference Design

Network Time Protocol (NTP) synchronizes clocks over IP on UDP port 123. Servers are ranked by stratum - their distance from an authoritative reference clock.

Other terms you must know: offset is how far local time differs from the reference; drift is the gradual rate at which a clock wanders; jitter is the variation between successive measurements.

A typical enterprise design:

1. Core or edge time servers sync to approved stratum 1/2 sources (or a local GPS appliance).
2. Internal servers, switches, routers, and clients sync only to those internal servers.
3. Firewalls permit UDP 123 only along the required paths.
4. Monitoring alerts when offset or reachability crosses a threshold.

This tiered approach matters for two reasons. First, every device pointing at the same internal source guarantees they agree with each other even if the upstream internet source hiccups. Second, blocking direct internet NTP from clients removes a spoofing surface - a client that trusts a random public server can be fed a poisoned time. Note also that a lower stratum number is better (closer to the reference), but stratum is a quality hint, not a guarantee; a misconfigured stratum 2 server can still drift if its upstream is unreliable, which is why monitoring offset is more meaningful than trusting the stratum label alone.

PTP, NTS, and TSN

Precision Time Protocol (PTP), IEEE 1588, is used when NTP's millisecond accuracy is not tight enough. PTP reaches sub-microsecond to nanosecond accuracy and is common in finance (trade timestamping), telecom, broadcast/media production, and industrial control. Switches participate as boundary clocks (terminate and regenerate timing) or transparent clocks (measure and correct for their own forwarding delay) to strip out network jitter - far more involved than pointing hosts at an internet NTP pool.

Network Time Security (NTS) layers authentication and integrity onto NTP so an attacker cannot inject spoofed time. The exam-level idea: a manipulated clock cascades into apparent certificate expiry, failed authentication, misleading logs, and mistimed scheduled changes - NTS hardens that trust boundary.

Time-Sensitive Networking (TSN) is the IEEE 802.1 set of standards that adds deterministic, bounded-latency delivery on standard Ethernet.

For ordinary business clients, NTP is the relevant service; PTP and TSN appear only where strict timing determinism is required.

Drift Symptoms and a PBQ Scenario

The fingerprint of a time problem is broad, simultaneous failures that look like authentication or security issues:

• Certificates report expired or not-yet-valid even though they are fine.
• Users cannot log on to a domain after a clock jumps.
• Logs from different devices cannot be correlated.
• Scheduled tasks run early, late, or twice.

PBQ-style time scenario

Facts: a domain authentication service rejects logons from one branch; branch workstations are 12 minutes behind headquarters; branch firewall logs are hard to correlate; the branch firewall recently blocked outbound UDP 123. Best actions: (1) restore approved NTP (UDP 123) from the branch to internal time sources, (2) point branch clients and devices at those sources, (3) verify offset returns within tolerance (well under the five-minute Kerberos skew), (4) confirm the authentication and certificate errors clear, (5) re-review logs once clocks agree.

The combination of widespread auth failure plus a known UDP 123 block points to time synchronization - fix that before chasing unrelated application causes.