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.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

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.

13.3. Java SNTP Client

This is a Java implementation of an NTP client, and is released under the GPL license. It handles NTP parameters as native Java types, making it Java-programmer-friendly. The algorithm used to calculate the local clock offset is the SNTP algorithm as specified in RFC2030. However, this code may be easily updated to use the more complex RFC 1305 NTP algorithms with no change to NtpMessage class.

The Java implementation consists of the following two classes:

• NtpMessage.java
  Represents an NTP message, exposing members as native java types. Include a NtpMessage(byte[] array) constructor to import a raw NTP message, and a toByteArray() method to export a raw NTP message.
• NtpMessageJ2ME.java
  File like the original "NtpMessage.java" adjustments made in order to reconcile the class to run on embedded devices with J2ME .
• SntpClient.java
  NTP client which instances an NtpMessage and uses the SNTP algorithm to calculate local clock offset. Note that this class merely performs the NTP process and displays the results - it does not actually modify the system clock.

Limitations

This implementation is a first attempt, and is possibly naïve in its approach. In particular, it is subject to the following issues:

• SntpClient.java determines the current time of day using System.currentTimeMills(). Firstly, the value returned is of millisecond accuracy. How accurate should the client timestamps be? Secondly, under Win32 the value is limited to a precision of 10ms. What impact does this have on precision?

• Timestamps are maintained as double values. Timestamps are converted from fixed point format to double during NtpMessage creation and back to fixed point format again during toByteArray(). How much error does this introduce?

-- AdamBuckley - 22 Jan 2004