We Need A Public NTS Pool

The Internet’s security model hinges on time synchronization as a fundamental security primitive. Since 1985, NTP has delivered time updates to nearly every computer, and it is usually served via a NTP pool, which is a group of computers that load-balance NTP requests.

However, it is high time that we switched this over to NTS, a new and secure time protocol that will make the synchronization of servers safe and private. It will also fix some NTP-specific vulnerabilities that are currently limiting the potential growth of NTP pools.

NTP Amplification Attacks

NTP runs is built on top of UDP, which is inherently stateless, so attempts to reply are best-effort without guarantees of delivery. When NTP servers get a request, it replies to whatever IP the packet says to use, and since it’s possible to spoof IP addresses it’s trivial for an attacker to use faked IP addresses to send an enormous volume of NTP packets to the victim¹. With a distributed pool of computers, this composes a simple and effective DDoS attack (against UDP targets, but that includes a lot of things).

Preventing these attacks isn’t something that can be done with NTP as-is; it is a fundamental weakness of NTP being based on UDP and being unencrypted. Some of this can be fixed at the network level by having networks implement BCP38, which requires that networks drops spoofed packets at edge routers, but in order for it to be effective it must be implemented by every network on the Internet, which is obviously not viable in the short-term (and given the slow adoption of relatively easy-to-deploy and important technologies like IPv6, suggests that this could take much longer to implement than it should).

These weaknesses mean that even those running modern, secure implementations of NTP behind something like the global NTP Pool can unwittingly become part of mass DDoS attacks or portscans of servers unless they are behind BCP38-protected networks (and only get traffic from such networks).

Don’t just take my word for it. This actually happened to one of my servers that was in the NTP pool, which forced me to remove it from the pool entirely:

The abuse log report also wasn’t helpful, since it was consistent of nothing but forged destination IP addresses, hiding the attacker’s true IP address from the logs:

#############################################################################
#      Portscan detected from host 0.0.0.0                                  #
#############################################################################

TIME (UTC)           SRC        SRC-PORT -> DST     DST-PORT SIZE PROT
---------------------------------------------------------------------------
2026-07-07 04:11:43  0.0.0.0.0  123 ->     1.1.1.1  49817    90   UDP
2026-07-07 04:10:47  0.0.0.0.0  123 ->     1.1.1.1  50470    90   UDP
2026-07-07 04:11:40  0.0.0.0.0  123 ->     1.1.1.1  55686    90   UDP
2026-07-07 04:11:02  0.0.0.0.0  123 ->     1.1.1.1  62303    90   UDP
2026-07-07 04:10:58  0.0.0.0.0  123 ->     1.1.1.1  63821    90   UDP
2026-07-07 04:11:24  0.0.0.0.0  123 ->     2.2.2.2  4097     90   UDP
2026-07-07 04:11:10  0.0.0.0.0  123 ->     3.3.3.3  54235    90   UDP
2026-07-07 04:11:12  0.0.0.0.0  123 ->     4.4.4.4  43671    90   UDP
2026-07-07 04:11:37  0.0.0.0.0  123 ->     5.5.5.5  38838    90   UDP
2026-07-07 04:11:51  0.0.0.0.0  123 ->     6.6.6.6  48670    90   UDP

(Note that these IPs have been redacted for privacy.)

Unfortunately, about another 100 requests followed after this before the automatic global rate-limit on the NTP port I had in my nftables configuration kicked in. Had this attacker been more persistent or more intelligent, it could have turned out a lot worse.

Rate-limiting for security usually decreases your “pool score”, or the odds that the pool selects your server for answering requests. These fundamental protocol-level flaws mean that unless you’re only getting requests from servers on networks where BCP38 is implemented (which is, admittedly, an increasingly large fraction of the Internet, but not everyone), then you won’t be able to maximize sharing to the global pool without potentially becoming a victim to one of these fundamentally unpreventable attacks.

NTP Is Insecure

NTP is fundamentally insecure as it lacks encryption. It’s one of the last big Internet protocols (like DNS) that is purely plaintext, meaning that adversaries over the wire can see your time synchronization requests.

While this isn’t a problem for the vast majority of people, those facing extreme threats from highly-motivated adversaries could have their connection broken by getting false time information from upstream. This is a lot more attack surface than you might think, and it only takes a few minutes of clock skew to break many forms of web security:

• TOTP breaks (2FA with time-based codes)
• TLS certificate timing can be exploited
• HSTS expires (downgrade site visits to HTTP)
• JWT expiration (login tokens fail)
• CAA record expiration (break TLS certificates)

In short, even if we deployed BCP38 everywhere, unencrypted time is deeply dangerous as an attacker could use our system clock to trivially break many forms of security. Accurate time is an underlying assumption of modern computer security in far more ways than people realize!

Let’s Pool & Use NTS!

Solving these problems is easy: let’s all switch to NTS and make a big NTS pool! NTS solves basically all of these problems out of the box: you can’t have amplification attacks since TLS is stateful (so no forging addresses)², you can’t have adversaries tamper with time, and it’s based on two proven technologies (it’s just NTP wrapped in TLS).

Unfortunately, there are some big roadblocks to NTS pooling and mass-adoption of NTS over NTP at the moment, although most are getting better:

• Older systems can’t learn to use NTS, and NTS is reliant on TLS to function, which not all systems may be able to handle. Modern time servers, like ntpd-rs and chronyd, fortunately have a dual-stack mode where both NTP and NTS can be served, so NTS can be used over the Internet with NTP on internal networks only.
• There’s no way to use NTS for time synchronization on consumer OSes as of the moment; Linux is the best for this at the moment. macOS, Windows, Android, iOS, and even the BSDs lack native support as of the moment, although this is largely because NTS is still in the IETF’s “Proposed Standard” phase. Third-party implementations of NTS-capable daemons now exist for Windows Server, and BSDs & macOS can use the Linux daemons, but more native versions need to be implemented for NTS to be widely adopted.
• NTS pooling is extremely new, because only Trifecta Tech Foundation is working on it. That said, they have gotten an experimental test pool up and running, along with the more stable Sectime pool.

Many private NTS servers exist in the wild since the NTS standard was released in 2020, with time.cloudflare.com being one of the largest providers to offer it.

We need a public NTS pool because time is the bedrock of computer security, and without NTS, there’s no truly safe way for servers and clients to share it. Hopefully, the NTS pool will grow so large that time can finally be done securely just about everywhere!