r2 - 2015-03-30 - 11:29:03 - HeikoGerstungYou are here: NTP >  Dev Web > DevelopmentIssues > NtpStartupStepChoices
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.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

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 "step" choices

When ntpd is started an offset correction may need to be applied. How that is done depends on the operational state of the machine.

Note that NTF's General Timestamp API should obviate the need for this level of process, as it has a way to provide for monotonic time even in the face of backward time adjustments.

Related Topics: bug_small.png Bug #2763


We should soon be able to put the following information into a table.

Some people like to set the time before starting ntpd. Harlan would love to understand why this is needed or desirable.

If one does set the time before starting ntpd it should probably/always be done with a step. Otherwise there is a good chance that a small offset correction will not completely apply before ntpd starts and that correction will be lost.

Cold Start

When a machine boots, ntpd has the expectation that no time-critical services are yet running. We can "step" any needed time adjustments.

Traditionally, ntpd will step any offset correction greater than 128 milliseconds, and slew these smaller corrections. Since ntpd applies corrections at the rate of 500ppm, that means a 128 millisecond correction will take 256 seconds (4 minutes and 16 seconds) to complete.

Generally, this is a non-issue for most situations. But if you have a Stratum 1 server and want it to be serving accurate time at the 10 microsecond level as soon as possible, you don't want to wait up to several minutes' time to see your offset get down to that level.

We note that there are systems out there where the time cannot be set this precisely, and there could also be a noticeable amount of jitter when setting the time. This could well be true, and the question is: Is there any harm in our attempt to precisely set the initial time, or is it just not very useful on some machines?

The bottom line is there would seem to be no harm in stepping all cold-start corrections.

We recommend ntpd -g ... at cold-start, done as early as possible in the boot sequence, as -g says "accept an arbitrary offset adjustment on the very first time correction." However -g does not currently make any statement about "step/slew" of that initial correction.

 
  • I proposed a new command line option -G which controls whether the initial offset should be adjusted with a step even when this offset is smaller than the step threshold (128ms). After the initial correction, everything should continue as in the current ntpd version (step/slew decision based on step threshold). -- HeikoGerstung - 30 Mar 2015

Warm Start

Ideally, if ntpd is restarted on a box that is already up and running where there are applications running where applications that require monotonic time are running we would want no backward time steps.

 
  • The question I have is: do we want ntpd to automatically recognize whether it is performing a warm start or cold start ? If not (I assume this is something that could be handled in a rc script), I would think that ntd should not be started using -g and -G in a warm start situation. We should probably also add a way to tell ntpd to not step backwards and recommend using that possibility (e.g. another commandline option) for warm start scenarios. -- HeikoGerstung - 30 Mar 2015

When the system clock is very wrong

ntpd has a panic threshold, which defaults to 1000 seconds. This means that if ntpd sees that the time is off by more than this amount it will log an error and exit, because something is Seriously Wrong.

By default, this will also be checked when ntpd is first started. So if the clock is "way" off, unless there is a way to override this check ntpd will not even start if the time is off by more than this value.

The -g flag to ntpd overrides this check.

The intent is to quickly get the attention of a human in case of a problem of this magnitude with the clock.

There are conflicting problems here.

On the one hand, we want to be alerted if the clock is badly off, and in that case ntpd will exit because it doesn't want to make anything worse, and it doesn't want to be "in your way" when you try and diagnose and repair the problem.

On the other hand, we want to be able to quickly understand any underlying problem (if possible) and then get the system clock operating correctly again as soon as possible.

For me there are two different scenarios: a) the clock is badly off at startup (cold start) which can be caused by a bad CMOS clock or the fact that there is no RTC at all. OR b) the clock is badly off during normal operation, which in 99% of all cases I experienced was caused by a human setting the time manually to test whether ntp corrects the offset or not. While I see that a) is something that we should be able to take care of, b) is something that is caused by a lack of knowledge how ntpd works.

As far as I can see, ntpd covers the two situations correctly with the -g switch. On most NTP clients there is an RTC or some other way to get an idea of the current time before NTP is started. Therefore I currently see no need to change the behavior of ntpd (see below for a discussion whether the standard behavior of ntpd should imply -g).

-- HeikoGerstung - 2015-03-30

 

Questions

Should startup always imply -g?

If ntpd is starting, should it always imply -g and should it just log its initial correction, perhaps at a higher severity level if the adjustment is large?

 
  • I do not think so. I see no huge benefit in changing this for a future version of ntpd. The -g switch has been widely adopted and is in use on a huuuge number of machines. Those who do not use it may have a good reason for this. Although I appreciate the approach to choose the default behavior to reflect what most people want, I appreciate the concept of backwards compatibility even more. -- HeikoGerstung - 30 Mar 2015

General Comments

 

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback