NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to use in a distributed denial-of-service (DDoS) attack. Please also take this opportunity to defeat denial-of-service attacks by implementing ingress and Egress filtering through BCP38. See JavaSntpClientDev for discussion of this topic.
ntp-4.2.8p4 was released on 21 October 2015, and addresses 13 low- and medium-severity security issues and provides about 100 bugfixes and enhancements over 4.2.8p3.
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:
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.
File like the original "NtpMessage.java" adjustments made in order to reconcile the class to run on embedded devices with J2ME .
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.
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?
- 22 Jan 2004