NTP and PTP: Agreeing What Time It Is When Physics Says You Can't

Every computer on the planet needs to know what time it is, and exactly zero of them actually do. They have oscillating crystals that drift, kernels that lose interrupts, virtualization layers that pause them for unknown durations, and they are separated from the nearest authoritative time source by a network that lies about how long packets take. The solution to this mess is a family of protocols that measure round trips, assume the network is symmetric (it isn't), apply some clever math, and arrive at timestamps accurate enough to run financial markets, cellular networks, and the electrical grid. It works. Most of the time. Let's explore why it works, why it shouldn't, and why the next generation of time synchronization involves hardware that timestamps packets before the operating system knows they exist, radio signals from satellites 20,000 kilometers overhead, and in the long run, maybe, pairs of entangled photons.

Let's talk about network time protocols. The problem they exist to solve sounds trivial. Two computers want to know what time it is. The first computer asks the second computer. The second computer sends back a timestamp. The first computer updates its clock. Done. Except at no point in that exchange does either computer actually know what time it is right now, because the packet took some amount of time to cross the network, and neither side knows how much time. Unless you can measure the propagation delay, the timestamp you got back is already wrong by the time you read it. And you cannot measure the propagation delay, because to measure propagation delay you need synchronized clocks, which is the thing you were trying to build in the first place. Welcome to the most recursive problem in networking.

The Physics of Now, or Why "What Time Is It" Doesn't Have an Answer

Before we get into the protocols, a short detour through why this problem is hard at the physical level.

A clock is an oscillator. It ticks at some frequency, and you count the ticks. Your wristwatch has a quartz crystal tuned to 32,768 Hz. Your computer has a crystal too, usually running around 25 MHz, multiplied up by phase-locked loops to run the CPU. Some specialized hardware uses atomic clocks, which measure the oscillation of electrons in cesium or rubidium atoms. The fanciest clocks on Earth are optical atomic clocks that wouldn't lose a second in the age of the universe. None of these clocks agree with each other.

Quartz crystals drift. They are manufactured with tolerances of about 20 parts per million, which means a cheap computer clock can lose or gain almost two seconds per day just from the crystal being slightly wrong. Temperature changes make it worse. The crystal in your server at 20°C oscillates at a different rate than the same crystal at 38°C. Age makes it worse. Crystals shift their oscillation frequency over their lifetime as the physical structure of the silicon dioxide changes. Your server's clock is slowly becoming a different clock. Congratulations.

And even if you had a perfect clock, special relativity says that two clocks at different altitudes will tick at different rates because of gravitational time dilation. A GPS satellite's clock ticks about 38 microseconds per day faster than an identical clock on the ground, and GPS receivers actively correct for this or the whole system would be useless within hours. So when we say "what time is it," we are asking a question that physics refuses to answer in any universally correct way. The best we can do is pick a reference, usually Coordinated Universal Time (UTC), and ask everyone to align to it as best they can.

This is the problem network time protocols are trying to solve. Nobody actually knows what time it is. We just try to all be wrong in the same direction, by the same amount, as little as possible.

NTP: The 1985 Protocol That's Still Somehow Running Everything

The Network Time Protocol was designed by David Mills at the University of Delaware, with the first specification published as RFC 958 in 1985. NTPv1 arrived in RFC 1059 in 1988, NTPv2 in RFC 1119 in 1989, NTPv3 in RFC 1305 in 1992, and the current NTPv4 in RFC 5905 in 2010. If you are thinking "wow, a protocol from 1985 is still in production and on its fourth revision, that sounds a lot like every other core Internet protocol," congratulations, you are correct. NTP is approximately as old as the commercial Internet itself, and it has survived by being flexible enough to absorb improvements while maintaining backward compatibility with implementations that have been running since the Reagan administration.

Dave Mills deserves an enormous amount of credit here. He didn't just invent a protocol, he invented a way of thinking about clocks on networks that is still the intellectual foundation for everything that came after. The NTP design includes concepts (stratum hierarchy, selection algorithms, clock discipline) that PTP and its descendants all borrow from, usually without attribution. Mills passed away in January 2024, and a lot of people had to stop and acknowledge that the guy who made sure your computer knew what time it was had been doing it for longer than many engineers had been alive. If your system boots up and finds NTP just works, you are benefiting from roughly four decades of one man's careful thinking.

Stratum, or how we pretend time has a hierarchy

NTP organizes time sources into a tree. At the root are stratum 0 devices, which are the actual physical time references: atomic clocks, GPS receivers, radio signals from stations like WWV in Colorado and DCF77 in Germany. These aren't on the network directly. They feed into stratum 1 servers, which are computers with a direct connection to a stratum 0 source (usually a serial cable or PPS signal from a GPS receiver on the same rack). Stratum 1 servers are considered primary time sources. Stratum 2 servers sync from stratum 1 over the network. Stratum 3 servers sync from stratum 2, and so on, up to stratum 15. Stratum 16 means "unsynchronized, do not trust."

The deeper you go, the less accurate your time gets, because you are accumulating error at every hop. This is why you want your servers talking to stratum 2 sources at the worst, and ideally multiple of them, so the algorithm can figure out which sources are lying or broken. Also, stratum 1 operators tend to get grumpy when random consumer devices point at them directly, because stratum 1 is supposed to feed infrastructure, not your laptop.

The NTP packet exchange, or four timestamps in search of a truth

NTP's cleverness is in how it measures time over a network it cannot trust. The client sends a packet at time T1 (measured on the client's clock). The server receives it at time T2 (measured on the server's clock). The server sends a response at time T3 (server's clock). The client receives the response at time T4 (client's clock).

Four timestamps. Two clocks. From these, you can derive two quantities:

• Round-trip delay: (T4 - T1) - (T3 - T2). Total elapsed time on the client, minus the time the server spent holding the packet. What's left is the time the packet spent on the wire in both directions.
• Clock offset: ((T2 - T1) + (T3 - T4)) / 2. The average of the two one-way offsets, which gives you how far off the client's clock is from the server's, assuming the network is symmetric.

That "assuming the network is symmetric" is doing a massive amount of work in that sentence. If the forward path takes 5 milliseconds and the return path takes 15 milliseconds, the math thinks the one-way time is 10 milliseconds each, and the offset calculation is wrong by 5 milliseconds. NTP has no way to detect this, no way to measure it, and no way to fix it. It just assumes symmetry and hopes for the best. This is fine across the open Internet, where paths are mostly symmetric on average and NTP's accuracy targets (tens of milliseconds) can absorb the error. It falls apart the moment you need microseconds or nanoseconds, which is why PTP exists. More on that later.

Selection and clustering, or how NTP decides which clocks are lying

An NTP client typically talks to multiple servers simultaneously. The reason is simple: any one server might be wrong. The clock could be broken. The network path could be pathological. The admin could have configured it to point at the wrong upstream. So NTP grabs samples from many sources and runs them through a series of algorithms designed by Mills:

1. Selection algorithm: Discards "falsetickers," servers whose advertised time disagrees with the majority. This uses an intersection algorithm (the Marzullo algorithm, later refined into the "Byzantine agreement" style selection) to find a set of servers that agree with each other.
2. Cluster algorithm: Takes the surviving "truechimers" and narrows them down further based on who has the lowest jitter and variance.
3. Combine algorithm: Merges the outputs of the remaining servers into a single estimate of offset.
4. Clock discipline: Gradually adjusts the local clock toward this estimate, using a phase-locked loop to avoid time jumping around.

This is why NTP feels like magic when it works. You point it at a pool of servers, some of which are probably broken, and it figures out which ones to trust, adjusts your clock smoothly so your logs don't jump backward, and keeps everything in sync within a few milliseconds. All this from a protocol designed when floppy disks were cutting-edge storage.

Clock discipline, or why you shouldn't just set the clock

When NTP decides your clock is off by 200 milliseconds, it does not just set the clock forward by 200 milliseconds. This might sound like the obvious thing to do, but it's wrong, for reasons that took people a while to learn.

First, if you jump the clock backward, any application watching for monotonic time can freak out. Databases use timestamps for transaction ordering. Logs use timestamps for sequencing. If two events appear to happen in the past, you get bugs that are extremely fun to debug at 3 AM.

Second, jumping the clock forward means you skip over time that has elapsed on other clocks. If you had a cron job scheduled to run at 2:30 AM and you jump from 2:29 to 2:31, the job might not run. Or it might run twice. Nobody is happy.

So NTP uses "slewing." Instead of jumping, it subtly speeds up or slows down the clock by tweaking the rate at which it increments. You want to add 100 milliseconds? You run the clock 0.01% faster for 1000 seconds. The clock ends up in the right place, monotonic time is preserved, and nothing explodes.

There's a threshold, usually 128 milliseconds by default, above which NTP gives up on slewing and just steps the clock. This is called "panic mode" in the NTP docs, and it's generally what happens right after your virtual machine wakes up from being paused for an hour, at which point all bets are off anyway. Nobody expects monotonic time to survive a suspended VM. They just hope nothing important was running.

The NTP Pool, the Abuse, and Why You Should Not Hard-Code Time Servers

The NTP Pool Project (ntp.pool.org) is a volunteer-run collection of time servers that most operating systems point to by default. If you've ever seen pool.ntp.org in a config file, you've been using it. As of writing, the pool has somewhere between 4,000 and 5,000 servers worldwide, contributed by individuals and organizations who just run a time server on their infrastructure out of goodwill.

The pool works because the default config ships in Linux distributions, macOS, and countless embedded devices, and those clients query a pool server every few minutes. This is a beautiful example of the kind of infrastructure the Internet quietly depends on and almost nobody pays for. It is also a beautiful example of how that infrastructure can be trivially overwhelmed.

In 2003, a Netgear router bug caused routers to query the University of Wisconsin's stratum 1 server (ntp-1.cs.wisc.edu) every second, generating hundreds of thousands of queries per second from consumer devices around the world. The university had to block the traffic upstream because their time server was being DDoSed by a poorly-written embedded firmware. Netgear eventually shipped a firmware update, but a lot of the affected routers never got updated, because consumer routers famously don't.

In 2005, D-Link did basically the same thing, this time hammering Poul-Henning Kamp's Danish stratum 1 server. Kamp (a FreeBSD developer) went public, D-Link eventually paid him, and the whole thing became a cautionary tale about why embedded vendors should maybe not hardcode a single university's time server into their firmware. Lessons learned: not really, they keep doing it, just with different servers.

Then in 2014, researchers discovered that NTP could be used for amplification attacks. The monlist command in older NTP servers would return a list of up to 600 recent clients, and the response was much larger than the request. Attackers could send a small spoofed packet with the victim's IP as the source, and the NTP server would dutifully send a huge response to the victim. Amplification factors of up to 556x were reported, which briefly made NTP one of the worst DDoS amplifiers on the Internet. Most servers have long since disabled monlist and similar unauthenticated queries, but the scars remain. If you want to ruin a sysadmin's afternoon, tell them their NTP server is still answering monlist.

PTP: When Milliseconds Aren't Good Enough

NTP's accuracy is usually in the low milliseconds over the open Internet, and can get into the hundreds of microseconds on a well-tuned LAN. For most computing, this is fine. Your laptop doesn't need to know what time it is better than a millisecond. Neither does your web server, your database (usually), or your phone.

Some things do need better. Financial trading systems care about microseconds because regulations like MiFID II require trades to be timestamped to microsecond accuracy, and some venues demand nanoseconds. 5G cellular base stations need to be synchronized within 1.5 microseconds, because the whole technology depends on precisely coordinated transmission timing. Power grids use synchrophasors to monitor grid state, and the phasor measurements need to be aligned within about a microsecond or the measurements are noise. Industrial control systems and factory automation often need similar precision. NTP cannot deliver this. Full stop.

Enter the Precision Time Protocol, specified in IEEE 1588. The first version dropped in 2002, PTPv2 in 2008, and PTPv2.1 in 2019. PTP is designed for local area networks and specific domains where you have some control over the network equipment. It can get you to sub-microsecond accuracy, and with hardware timestamping and careful engineering, nanoseconds.

The fundamental trick, or timestamping at the wire

The single biggest reason PTP can be two or three orders of magnitude more accurate than NTP is that PTP expects the network hardware to help. Specifically, PTP assumes you have hardware timestamps.

In NTP, timestamps are taken in software. The kernel gets a packet, at some point runs the NTP daemon, and reads the current time. The gap between the packet actually arriving on the wire and the daemon reading the clock is nondeterministic. It depends on interrupt latency, CPU load, scheduling, the phase of the moon, whether the kernel is doing garbage collection on some slab cache at that moment. On a busy server, this jitter can be hundreds of microseconds, which sets a hard floor on how accurate NTP can ever be.

In PTP, the network interface card timestamps the packet as it enters or leaves the physical layer. The timestamp is inserted into the packet (or transmitted in a follow-up packet) before the operating system is even involved. This eliminates essentially all of the jitter from the OS and application stack. The timestamp reflects when the packet actually crossed the wire, not when some daemon got around to noticing.

Hardware timestamping requires NIC support. Most modern data center NICs have it (Intel E810 and X700 series, Mellanox/NVIDIA ConnectX, Broadcom NetXtreme, many others). Consumer NICs usually don't, although some gaming and prosumer cards have started including it. Without hardware timestamping, PTP falls back to software timestamping and you get NTP-tier accuracy, which defeats the point.

Masters, boundary clocks, and transparent clocks, or a small menagerie of network devices

PTP organizes the network differently from NTP. Instead of a stratum hierarchy where each node independently syncs to its upstream, PTP treats the network as a set of clock domains with devices playing specific roles.

A grandmaster clock is the top of the tree. It's the authoritative time source, usually fed by GPS or an atomic clock. Everything else in the domain syncs to it.

An ordinary clock is a single-port device, either a master or a slave.

A boundary clock has multiple ports, acts as a slave on one port (syncing from an upstream master), and acts as a master on its other ports (distributing time downstream). Boundary clocks break up large networks into manageable segments. They also break the end-to-end relationship between source and destination, because each boundary clock introduces its own error, which you have to trust.

A transparent clock is the clever one. It's a switch or router that, instead of syncing its own clock to the master, measures how long each PTP packet spends being forwarded through it, and writes that residence time into a field in the packet. The end device then subtracts the accumulated residence times from its offset calculation, eliminating the switch's contribution to network delay. Transparent clocks are why PTP can survive being forwarded through a dozen switches and still deliver sub-microsecond accuracy, as long as every switch in the path supports PTP transparent clocking.

If one of your switches is not PTP-aware, you have a "dumb switch" in the middle of your PTP domain, and its queuing delays become indistinguishable from propagation delay. Your accuracy goes out the window. This is why PTP deployment requires end-to-end network planning, and why running PTP over an arbitrary enterprise LAN usually doesn't work. "We'll just turn on PTP" is a sentence that has preceded many disappointing afternoons.

The Best Master Clock Algorithm, or how PTP decides who's in charge

When a PTP network boots up, multiple devices might be claiming to be the grandmaster. PTP uses the Best Master Clock Algorithm (BMCA) to figure out who wins. BMCA compares clock attributes like priority (user-configured), clock class (how good is the underlying oscillator), clock accuracy, and variance, and picks the highest-quality source. If the grandmaster fails, BMCA automatically elects a new one from the surviving candidates.

This makes PTP more automatic than NTP in some ways (you don't have to manually configure every client with a server list), but it also makes it more vulnerable, because a malicious device advertising itself as a high-priority grandmaster can hijack the domain. PTP has some security features to mitigate this (more on that later, spoiler: not enough), but out of the box, PTP trusts BMCA the way early BGP trusted AS announcements. We know how that story goes.

One-step versus two-step, or why we can't have nice things

There are two ways PTP can deliver a timestamp. In one-step mode, the hardware writes the egress timestamp directly into the outgoing Sync message as it leaves the NIC. Simple, efficient, and requires the hardware to modify packets in flight.

In two-step mode, the hardware timestamps the Sync message as it leaves, but the timestamp is sent separately in a follow-up message called Follow_Up. This is less efficient (more packets) but requires simpler hardware (you don't need to modify packets in flight, just notify the CPU of the timestamp).

Most modern hardware can do one-step, but many PTP deployments run two-step because some of the gear doesn't support one-step, or the administrators don't trust in-flight modification, or inertia, who knows. The protocol supports both. Pick your poison.

PTP profiles, or how every industry decided to make their own version

IEEE 1588 is a framework, not a single protocol. It specifies a bunch of options (transport: UDP over IPv4, UDP over IPv6, or Ethernet directly; delay mechanism: end-to-end versus peer-to-peer; one-step versus two-step; domain numbers; lots of others) and leaves the specific combinations to "profiles" defined by user communities.

• Default Profile: Generic, defined in IEEE 1588 itself. Most people don't use it directly.
• Telecom Profile (ITU-T G.8275.1, G.8275.2): Used by cellular networks for 4G and 5G sync. PTP over Ethernet with specific BMCA modifications to ensure deterministic master selection.
• Power Profile (IEC 61850-9-3): Used in electrical substations. Designed for harsh electromagnetic environments and high availability.
• 802.1AS (gPTP): The profile used by Audio Video Bridging and Time-Sensitive Networking. Also used by automotive Ethernet and some industrial control systems. This is the one that gets the most attention from the "please make industrial Ethernet work for real-time" crowd.
• Enterprise Profile (IETF draft): A more Internet-friendly profile that tries to make PTP behave like something you can deploy alongside normal traffic.

Each profile tweaks which options are mandatory, what message intervals are used, and how BMCA behaves. The result is that "does your gear support PTP" is not actually a yes or no question. The real question is "does your gear support the specific PTP profile I need." Two PTP implementations can both be IEEE 1588 compliant and completely unable to sync with each other. This is exactly as fun as it sounds.

White Rabbit, or What Happens When PTP Isn't Fast Enough

PTP's accuracy, even with hardware timestamps and transparent clocks, tops out at tens of nanoseconds over a well-engineered network. For CERN's Large Hadron Collider, this was not good enough. The LHC needs sub-nanosecond sync across kilometers of cabling, because particle detection timing depends on knowing when a proton bunch crossed a specific point relative to when a detector fired, and the particles in question are moving at 99.99% of the speed of light. When your subject matter moves that fast, nanoseconds are sloppy.

So CERN, along with GSI Darmstadt and various collaborators, built White Rabbit. Now part of IEEE 1588-2019, White Rabbit extends PTP with Synchronous Ethernet (SyncE, which distributes a frequency reference through the Ethernet physical layer) and with precise phase measurement via digital dual mixer time difference (DDMTD) hardware.

The result is time synchronization accurate to about 1 nanosecond over 10 kilometers of fiber, and roughly 100 picoseconds in a lab setting. For reference, light travels about 30 centimeters in 1 nanosecond. White Rabbit lets physicists measure the time of flight of particles across their detectors with accuracy that matches the physical scale of the apparatus.

White Rabbit has since escaped particle physics and landed in financial trading, radio astronomy, telecom, and defense. It requires specialized hardware (you cannot run White Rabbit on a normal NIC), but when you need to know what time it is at the sub-nanosecond level, White Rabbit is the current state of the art. It also has one of the better project names in networking, which has to count for something.

GPS, GNSS, and the Satellite You're Secretly Depending On

Every serious time infrastructure has a physical reference somewhere, and for most of them that reference is GPS, or one of its siblings: GLONASS (Russia), Galileo (EU), BeiDou (China), QZSS (Japan), collectively GNSS for Global Navigation Satellite Systems. The reason is that GNSS satellites carry atomic clocks, they broadcast precise timing signals, and a receiver with a clear view of the sky can recover time to within about 100 nanoseconds of UTC, for free, anywhere on Earth.

This is both a miracle and a massive single point of failure for the planet's timing infrastructure.

GPS works by trilateration. Satellites broadcast their position and the current time. Your receiver picks up signals from at least four satellites and solves a system of equations to figure out where and when it is. The "when" is almost a side effect of the "where," but for timing applications it's the main product. Commercial GPS timing receivers output a PPS (pulse per second) signal that a stratum 1 NTP or PTP grandmaster uses as its reference.

Almost every cellular base station has a GPS antenna on the roof. Almost every financial exchange does. Almost every data center has at least one GPS-disciplined oscillator feeding a grandmaster clock. Power grids, broadcast networks, scientific instruments, military systems, all GPS. If GPS were to go down (jamming, spoofing, solar flare, orbital debris, nation-state shenanigans), most of the planet's time synchronization would drift off UTC within hours to days, depending on the stability of the local oscillators.

This is why some people are building alternatives. The US government has been fitfully funding eLORAN as a terrestrial backup to GPS for timing and navigation. Fiber-based timing distribution (White Rabbit, PTP over private fiber) doesn't need GPS at the endpoints if the source is fiber-connected. Some data center operators are investing in local rubidium or cesium clocks so their infrastructure can hold accuracy for weeks without GPS. But at the scale of the global Internet, GPS is the heartbeat, and it's a single vendor (effectively the US Department of Defense) running a constellation of satellites that are, in network engineering terms, a massive external dependency with no SLA.

Leap Seconds, or the Dumbest Thing in Computing

You cannot talk about network time without addressing leap seconds, which are both a fascinating piece of physics and the single most annoying problem in operational computing.

The Earth's rotation is slowing down, very slightly, due to tidal friction with the moon. Our official time unit, the SI second, is defined by atomic clocks and is constant. Our clock-on-the-wall time, UTC, is supposed to approximate mean solar time, which is getting longer. Every so often, these two things diverge by a noticeable amount, and the International Earth Rotation and Reference Systems Service (IERS) announces that we're going to insert an extra second into UTC. This has happened 27 times since 1972.

At the moment of a leap second, UTC does something very strange. The clock reads 23:59:59 as usual. Then instead of rolling to 00:00:00, it rolls to 23:59:60. Then to 00:00:00. For one second, UTC has a value that the ISO 8601 timestamp format was barely designed for, and that most software libraries silently hope will never be encountered.

In practice, leap seconds have caused real problems. In 2012, a leap second caused many Linux servers to hang because of a kernel bug in the leap second handling. Reddit, Mozilla, LinkedIn, Foursquare, Gawker Media, Qantas, and assorted Java applications went down or behaved strangely. The bug was fixed, but the pattern repeats. Every leap second causes some percentage of production systems to misbehave. 2015 was not as bad as 2012. 2016 was not as bad as 2015. The trend line is "people getting tired of this."

Google's response was elegant and slightly heretical. Instead of inserting a 61-second minute, Google "smears" the leap second across a 24-hour window. Their public NTP servers advertise a clock that runs 1/86400 slower for 24 hours around the leap second, absorbing the extra second gradually. No 23:59:60. No sudden jumps. No kernel panic. Other large operators (Amazon, Meta, Cloudflare) have adopted similar smearing approaches, with varying details. They don't all smear the same way, which is its own comedy.

The good news is that leap seconds may be going away. In November 2022, the General Conference on Weights and Measures (CGPM) voted to effectively end leap seconds by 2035. The plan is to let UTC and UT1 (solar time) diverge more, and only make corrections on a much longer cadence (maybe every few decades, maybe as a "leap minute"). Network engineers rejoiced. Astronomers grumbled. Nobody has figured out exactly what happens when UT1 and UTC differ by several minutes, but that is a problem for future humans. Specifically, future humans who are not us.

Security, or the Part Where Nobody Thought Anyone Would Attack a Time Protocol

For the first 30 years of NTP's existence, security was essentially an afterthought. The assumption was that time was not sensitive, so nobody would bother attacking it. This assumption turned out to be very wrong, for several reasons.

Why time matters for security

Many cryptographic systems depend on time. TLS certificates have validity periods. Kerberos tickets expire. OAuth tokens have issuance times. HSTS preload lists have max-age fields. Your smartphone's two-factor authentication codes (TOTP) are literally derived from the current time. If an attacker can convince your system that it's 2014, then TLS certificates that were valid in 2014 but have since been revoked or expired will suddenly validate again. If an attacker can move your clock forward, short-lived tokens might expire prematurely. If they can move it backward, logs can be manipulated, one-time codes can be replayed, cache entries can come back from the dead.

Researchers have demonstrated practical attacks using NTP spoofing to bypass certificate validation, cause TLS downgrades, and forge timestamps for forensic purposes. Time is, it turns out, load-bearing. The whole TLS ecosystem quietly depends on clients knowing roughly what day it is, and NTP is how they find out.

The attacks

The simplest attack is running a malicious NTP server and getting victims to query it. If you can MITM the victim's NTP traffic (which is easy on unprotected networks, because NTP is plaintext), you can feed them whatever time you want. They will adjust their clock accordingly, unless they have multiple sources that disagree enough to trigger the falseticker detection.

A more sophisticated attack is slowly drifting the target's clock. NTP clients, by design, resist large jumps. But if you can shift the clock by a few milliseconds per poll interval, you can move the clock by minutes or hours over days, and the discipline algorithm will smoothly track your lies. Aalto University and Boston University researchers published a paper in 2016 ("Attacking the Network Time Protocol") that laid out several practical variants of this attack, along with a few that exploited specific NTP implementation bugs.

Then there are the amplification attacks mentioned earlier, which are a different category, using NTP servers to attack third parties rather than attacking NTP clients. Those have largely been mitigated by disabling the offending commands, but the underlying issue (NTP protocol was not designed with authentication) remained.

NTS: the authenticated version nobody's deployed yet

Network Time Security (NTS) is an extension to NTPv4, specified in RFC 8915 (2020). It provides cryptographic authentication of NTP responses, using a TLS-protected key exchange on a separate port to bootstrap shared keys, which are then used to authenticate UDP NTP packets.

NTS is clean, well-designed, and pretty much nobody is using it. The reasons are mostly operational. NTS requires both client and server support, most NTP clients don't enable it by default, configuring TLS on NTP servers adds complexity, and the benefits are not visible to end users. A few vendors (Cloudflare, Netnod, Ubuntu) run public NTS servers, but NTS adoption remains in the low single digits percentage-wise for most observable populations.

This is a problem because the underlying issue (unauthenticated time) is still there, still exploitable, and still largely ignored. Sooner or later, a major breach will be traced back to an NTP spoofing attack, and NTS deployment will suddenly become urgent. Until then, most of the Internet's time is delivered in plaintext, over UDP, with whatever authentication your paranoia level requires. Which is usually zero.

PTP security, or the part where the spec says "we'll get to that"

PTP's security story is worse than NTP's. IEEE 1588-2008 had an experimental security extension nobody implemented. IEEE 1588-2019 added Annex K (TLV-based integrity) and Annex P (prong-based architecture for key management), and adoption of both remains rare in practice. Most PTP deployments rely on network isolation (PTP traffic runs on dedicated VLANs or physically separate networks) and assume the attacker can't get in. Which is sometimes true and sometimes extremely not true. Industrial control networks have been famously bad at this, and PTP is increasingly deployed in industrial settings, so the risk surface is growing.

GPS spoofing, or when you attack the time source itself

If you can't attack the protocol, you can attack the signal. GPS timing signals are weak (they come from 20,000 km up), unauthenticated in the civilian L1 signal, and vulnerable to spoofing with equipment that now costs a few thousand dollars. Researchers have demonstrated GPS spoofing against ships, drones, and financial trading infrastructure. In 2017 and again in 2019, ships in the Black Sea reported GPS telling them they were on land, several kilometers inland, which was widely attributed to Russian spoofing operations. In 2022, a truck full of GPS jamming equipment drove past the University of Texas at Austin and took down GPS reception for several blocks of Austin. Some of these incidents were criminal, some were state actors, some were idiots with AliExpress orders. All of them worked.

Galileo has added authentication to some signals (OSNMA), and GPS is supposed to eventually add civilian authentication (Chimera), but for now most GPS timing receivers will happily accept a spoofed signal and feed fake time into whatever infrastructure is downstream.

Best practice in hardened environments is to use multiple independent timing sources (GPS plus an atomic clock, or GPS plus a fiber-delivered reference, or multiple GNSS constellations) and to monitor for disagreements. This is expensive and complicated, which is why most people don't do it, which is why GPS spoofing is a real threat.

Quantum Entanglement and the Very Long Game

If you read about network timing for long enough, you eventually run into people talking about quantum entanglement as a way to distribute time. Let me explain what this actually means, what it doesn't mean, and why it might matter.

Entangled photons are pairs of particles whose quantum states are correlated, no matter how far apart they are. Measuring one instantly determines the state of the other. This is the thing that Einstein called "spooky action at a distance" and which generations of physicists have confirmed is, in fact, how the universe works.

The popular science headline version is "entanglement lets you communicate faster than light." This is, strictly, false. You cannot send a message using entanglement alone, because the measurement outcomes are random, so you cannot encode information in them. What you can do is use entangled pairs as a correlation resource: if two parties both measure their halves of an entangled pair, they can agree on a shared random result, and with classical communication plus entanglement, they can do things classical communication alone cannot do. One of those things is time distribution with error characteristics that classical protocols cannot match.

Current research on quantum timing, sometimes called "quantum clock synchronization," comes in a few flavors.

Quantum-enhanced two-way time transfer uses entangled photon pairs to establish a correlated measurement at two stations, then uses the correlation to eliminate some sources of noise in the round-trip delay measurement. Experiments have demonstrated picosecond-level synchronization over tens of kilometers of fiber. Not dramatically better than White Rabbit yet, but with different error characteristics, which is useful for certain measurement applications.

Entanglement-assisted clock comparison uses entangled pairs to compare the frequency of remote atomic clocks with precision beyond the classical shot noise limit. This matters for fundamental science (testing relativity, searching for dark matter, redefining the SI second) more than it matters for Internet infrastructure. But it matters.

Quantum networks with entanglement distribution are longer-term projects. The European Quantum Communication Infrastructure, the Chinese Micius satellite (which in 2017 demonstrated entanglement distribution across 1,200 kilometers of free space, embarrassing a lot of Western programs), and various lab-to-lab fiber quantum networks are working on distributing entangled pairs across continental distances. If these networks become practical (big if), they could support globally-synchronized optical atomic clocks with accuracy that nothing else can touch.

The honest answer is that none of this will replace NTP or PTP in any normal computer for the foreseeable future. Your laptop will not get a quantum time sync. Your data center will not deploy entangled photon pairs. What quantum timing might do is provide an ultra-precise backbone at the top of the timing hierarchy, feeding classical clocks that then distribute time to normal infrastructure via the same PTP and NTP we've always used. Stratum 0 might eventually be a quantum-linked pair of optical clocks, and everything else will stay the same.

Also, quantum timing depends on optical fiber or free-space optical links, and it is extremely sensitive to loss and noise. It is not a solution for distributing time over the open Internet. It's a solution for connecting a handful of major national labs with ultra-high precision, and maybe, eventually, financial exchanges that will pay anything for a picosecond of edge. So if you're a network engineer, quantum timing is something to read about and not something to budget for. Yet.

The Operational Reality

After all this, here is what actually runs in most production environments:

• A handful of NTP servers synced to GPS, or to time.google.com / time.cloudflare.com / one of the big public NTS providers.
• Those servers feed a larger pool of secondary NTP servers inside the infrastructure.
• Every normal host runs chrony or ntpd or systemd-timesyncd pointed at those internal servers.
• Anything that needs better than millisecond accuracy (financial trading, 5G, industrial control) runs PTP on dedicated hardware with PTP-aware switches and boundary clocks.
• Everyone hopes GPS keeps working.
• Almost nobody is using NTS.
• Almost nobody is using PTP security features.
• Leap seconds are handled by a smear, or a crossed-fingers prayer, or a weekend on-call shift.
• Time monitoring tooling is an afterthought that becomes critical the first time clocks drift and nobody notices until transactions start failing.

This is fine. It works. It has been working since before most readers of this article were born. The failure modes are well understood, the tooling is mature, and the people who maintain it are among the quietly indispensable engineers whose work you only notice when it breaks. They deserve more beers than they get.

The Uncomfortable Truth About Network Time

Let's be honest: network time is a hack. We are trying to answer a question physics doesn't really allow ("what time is it, exactly, right now, at that location 5,000 kilometers away") using a network that cannot measure the one thing that would let us answer it (the one-way propagation delay). We assume symmetry when it isn't symmetric, we smear time when leap seconds don't fit, we pretend the clock is monotonic when we've just stepped it, we run multi-billion-dollar industries off a GPS signal from a satellite constellation designed during the Cold War, and somehow we get an entire planet's computers to agree on the time to within a few tens of milliseconds, usually. It should not work as well as it does.

The protocols work because they were designed with humility. NTP doesn't trust any single source. PTP uses hardware to eliminate the software jitter it can't control. Both assume failure is normal and build in enough redundancy to survive it. The result is a system that is precise enough for most applications, robust enough to survive bad actors and bad networks, and cheap enough to run on a Raspberry Pi in someone's basement contributing to the NTP pool.

The gaps are real. Security is weak. GPS is a single point of global failure. PTP deployment requires end-to-end network planning that almost nobody actually does. Quantum timing will be a niche solution for the foreseeable future. Leap seconds will continue causing problems until 2035, and then stop causing problems, and then start causing different problems.

But the alternative is not having synchronized time, and the alternative is worse. Modern computing, modern communications, modern finance, modern physics all depend on a planet full of clocks that almost agree. NTP and PTP are how they almost agree. The math is clever, the engineering is impressive, the history is long, and the person who made most of it work (Dave Mills) didn't get quite the recognition he deserved while he was alive.

Time is terrible, time is essential, time is never exactly what your computer thinks it is. Welcome to network time.