Geoff Huston looks at the network
time protocol, and efforts to secure it, in detail.
NTP operates in the clear, and it is often the case that the
servers used by a client are not local. This provides an
opportunity for an adversary to disrupt an NTP session, by
masquerading as a NTP server, or altering NTP payloads in an effort
to disrupt a client’s time-of-day clock. Many application-level
protocols are time sensitive, including TLS, HTTPS, DNSSEC and
NFS. Most Cloud applications rely on a coordinated time to
determine the most recent version of a data object. Disrupting time
can cause significant chaos in distributed network environments.While it can be relatively straightforward to secure a TCP-based
protocol by adding an initial TLS handshake and operating a TLS
shim between TCP and the application traffic, it’s not so
straightforward to use TLS in place of a UDP-based protocol for
NTP. TLS can add significant jitter to the packet exchange. Where
the privacy of the UDP payload is essential, then DTLS might
conceivably be considered, but in the case of NTP the privacy of
the timestamps is not essential, but the veracity and authenticity
of the server is important.NTS, a secured version of NTP, is designed to address this
requirement relating to the veracity and authenticity of packets
passed from a NTS server to an NTS client. The protocol adds a NTS
Key Establishment protocol (NTS-KE) in additional to a conventional
NTPv4 UDP packet exchange (RFC 8915).

