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.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
NTP Startup Issues
The usual perspective when starting NTP is that there are two "startup conditions", cold-start (boot) and warm-start (restart).
At cold-start, we don't know how long the machine has been "off" and we may not have a good idea of any needed frequency or offset correction.
No services requiring monotonic time are running.
At cold-start, it is expected we can safely make any changes to system time that we want.
At warm-start, we expect that time-sensitive processes may be running.
Under these situations, it may cause problems if any backward time steps are made.
The intention of the
was to provide a way to ignore the
limit at startup.
will exit or refuse to start if the system time differs from "known" time by more than 1000 seconds' time.
This is because a discrepancy of this amount is expected to be well-beyond the normal range, and is considered to be significant enough to require Attention.
While this situation can occur in a cold-start situation, it should never happen in a warm-start situation.
If it does
happen in a warm-start situation, we expect this to be an exceptional situation that requires Attention.
Is this a case where we are inappropriately forcing our "policy" choice on all users?
Always Step on Cold-Start
The overall model for offset corrections for NTP is to "slew" (slowly adjust) time corrections that are 128ms (by default) or less, and to "step" (immediately change) the time correction otherwise.
We have not yet identified any cases where there is any "downside" to performing all initial offset corrections in a cold-start condition with a "step", and there are situations where it is desirable to always step the cold-start correction.
We have some choices to make.
One choice is to have an option that says "We are doing a cold-start".
In this case, we'd want
to do the best it can to get the clock right as soon as possible.
And Harlan is reminded about the choices we had in DeprecatingNtpdate
sometimes we want to set the time once, as quickly as possible, and sometimes we want to set the time once, as well as possible.
Another choice is to specify each individual option.
We could even do both, provide specific options for each behavior, and also provide a "cold-start" option.
The "cold-start" option could have built-in defaults that could be overridden in the
If we do this, should we have a selector based on the version of NTP that is running? For example, if we add a
option it will only be available in version 4.2.8p3(?) or later. Or should we ignore unrecognized options?