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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

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.

NTP Startup Issues

The usual perspective when starting NTP is that there are two "startup conditions", cold-start (boot) and warm-start (restart).

Cold Start

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.

---

Warm Start

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.

---

-g issues

The intention of the -g option to ntpd was to provide a way to ignore the panic_gate limit at startup.

Ordinarily, ntpd 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.

• NtpStartupStepChoices

---

Startup Options

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 ntpd 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 ntp.conf file.

If we do this, should we have a selector based on the version of NTP that is running? For example, if we add a -G option it will only be available in version 4.2.8p3(?) or later. Or should we ignore unrecognized options?

---