NTPv5 and Updated Time Security: What Changes for Network Operators#

Antonio Marcos Moreiras (NIC.br)

• Why: Time is a load-bearing security dependency — RPKI ROA validity windows, TLS certificates, Kerberos' 5-minute skew, log forensics; NDSS 2016 showed a few days of clock shift suffices to attack RPKI. And time rides on routing: ~2M NTP servers use a single upstream, and the 14,153 ASes hosting those upstreams publish no ROAs (IMC 2025), so a prefix hijack could set the time.
• What: NTS (RFC 8915) is deployable now (chrony ≥4.0, ntpd-rs; Ubuntu 25.10+ ships chrony with NTS by default) — yet 374 of 583 NTS servers are misconfigured (blocked TCP 4460, size filters dropping NTS packets on UDP 123). NTPv5 (draft 09, last call end-2026): client-server only, explicit timescale (UTC/TAI/UT1/smeared) and era fields, client cookies replacing request timestamps, 120-bit reference IDs. The 2035–2038 wall: leap seconds end by 2035, NTP era 0 ends 7 Feb 2036, 32-bit time_t overflows 19 Jan 2038 — equipment in service today will still be running. Plus NTP Pool research: ~10 well-weighted servers could capture most countries' time traffic (NDSS 2026), and some pool servers scan clients' IPv6 addresses (CCS 2026); Khronos (RFC 9523) and Roughtime as complements.
• How: NTS = TLS 1.3 key exchange on TCP 4460 with stateless cookies. Concrete checklist: allow 4460, review UDP 123 size filters, NTS on clients and servers with auto-renewed certificates, 4 or more identified independent sources by name, ROAs (and eventually ASPA) for your time servers; test NTPv5 in the lab within 12–24 months and inventory devices that will live past 2036.
• Where applicable: Any operator of time infrastructure or of anything time-dependent (PKI, RPKI, Kerberos, SIEM). Fully general, with an IETF document-status table (RFCs 8915, 9523, 9769, 10030; drafts for NTPv5, NTS pools, Roughtime, NTS4PTP).