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).

https://lwn.net/Articles/1061930/
--- SBBSecho 3.37-Linux
 * Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (618:250/24)
SEEN-BY: 1/0 100/1 2 200/1 10 12 14 34 36 48 54 250/1 10 19 23 24 25 26 32
SEEN-BY: 250/33 37 39 40 42 44 45 46 47 48 300/1 400/1 500/1 520/1 618/0 1
SEEN-BY: 618/10