EditWYSIWYGAttachPrintable
r2 - 2014-02-07 - 10:34:15 - HarlanStennYou are here: NTP >  Dev Web > DevelopmentIssues > NtpStartupAnalysis
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 Analysis

Related Topics: GSoC2013StartupAnalysisRahul, GSoC2013StartupAnalysisRahulDesign

History

With a good drift file, stable conditions, and iburst, ntpd can sync up in about 11 seconds' time.

Other conditions can cause this process to take closer to 5 minutes' time.

We want to try and "do better".

The thought is that we can do a least-squares fit and determine the offset and the drift. The key questions include for various network transport, what sort of intervals produce what sort of results?

 

Methodology

We must respect the "rate limit" considerations. This means we can send packets no faster than one every two seconds' time, and we can send no more than 8 packets in any 60-second interval.

It looks like we want to calculate y=(m-1)x+b, where m is the frequency correction and b is the offset correction. The reason for (m-1) is because we can expect m to be a floating-point value and the slope should be within parts-per-million of 1, and we'll lose a lot of precision waiting to get to the "interesting bits". So we get the "1" out of the way and are left with only the interesting bits.

The intercept will be a value that handles the offset correction.

The closer the intercept is to "now" the less correction will need to be applied to the calculated offset.

 

Testing

We need to know what the current offset and drift values are.

Once we know these, we want to stop all corrections and let the machine free-run while we run our tests.

At the end of that test, we should expect that by multiplying the drift value by the number of seconds between stopping corrections and the intercept time that we'll have the same offset and drift values that the startup analysis process determines.

For wired networks, we think want to see what sort of results we get when we go from, say, 20 to 120 seconds, increasing by 10 seconds on each test. Once we get an idea of where the "interesting" parts of the curve are we can look more closely.

Harlan has heard that for wireless networks, this will probably take several minutes.

 

GSoC 2013 work

On the psp-* machines, see the ofcalc/ subdirectories in:
  • ~katare/ntp-dev-ofcalc/
  • ~chen/ntp-dev-ofcalc/

"Next" to these directories is a copy of Dragonfly's NTP, in the dntpd/ subdirectory. Much can be learned from the study of this code...

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r3 < 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-2019 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