NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p12 was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

2. Proxies, Tunnels, and VPNs

Proxies, Tunnels, and VPNs -- Oh, My!
Proxies, Tunnels, and VPNs -- Oh, My!

Shamelessly stolen from The Wizard of Oz.

Table of Contents

2.1. UDP vs. TCP

Most proxies and tunnels support only TCP/IP protocols -- i.e., protocols that require setting up a relatively long-lived connection, doing buffering, handling two-way communications, dealing with packet loss, retransmissions, and re-ordering, etc....

However, NTP is inherently a UDP/IP protocol. This has been done for a variety of reasons, but one of the most important is that TCP is ... well ... TCP, and it would be impossible for a program to accurately determine the true delay between two given systems with such a heavy protocol. It would be impossible for a program to create or maintain an accurate system clock based on external input from other machines across a TCP/IP network.

2.2. Proxies and Tunnels

Unless you can guarantee that your proxy or tunnel supports UDP as well as TCP packets, you're not going to get it to carry NTP. One tunnel that is believed to be capable of carrying UDP traffic is rq2proxy. However, configuring a tunnel or proxy to carry UDP and support NTP is an exercise left to the reader.

Some proxies or tunnels require compiling and/or linking with an alternative networking library, in order to get your binary to transmit your packets across their alternative network connection (e.g., SOCKS). Compiling and/or linking ntpd and all related utilities to support such an alternative network connection is another exercise left to the reader.

2.2.1. ssh Tunnels

If all you've got is an ssh tunnel to a remote server and you want to try to sync the time across that tunnel, then NTP is not the protocol you should be looking at. Try rdate or daytime instead.

Note that these are much less accurate and precise than NTP, and do not have any of the features for detecting falsetickers or selecting truechimers, etc.... But, they are programs/protocols that use TCP, and you should be able to get them to work over an ssh tunnel without too much trouble.

2.3. VPNs

VPNs (Virtual Private Networks) are a different kind of beast. By definition, they attempt to provide a complete alternative network solution, and should carry all types of IP packets, including TCP and UDP.

You will likely suffer higher jitter and reduced clock accuracy/precision, but once you get the underlying network up and running, it should not be too difficult to get NTP working across that network -- after all, NTP is about as simple as an UDP protocol can get.

-- BradKnowles - 03 Mar 2005