r4 - 2018-04-28 - 09:58:16 - HarlanStennYou are here: NTP >

Dev Web > DevelopmentIssues > NtpVariablesAndNtpq

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 Variables and `ntpq`

Problem Summary
Possible Solutions
- Versioned headers
On-the-fly decoding
Other Discussion

Problem Summary

ntpd and ntpq exchange system, peer, clock and flash data.

Over the years the lists of these variables have changed from time to time.

When ntpq compiled with one 'release' of these values is run against ntpd compiled with a different 'release' of these values the data can be incorrectly decoded.

Possible Solutions

Versioned headers

In this case, if we need to change the names or strings or add/delete entries we do it with some sort of version bump. I'd expect that we'd have something like

 
  include/ntp_varsX.h

(where X is a version number)

and ntpd/ntp_control.c will #include the latest rev, and ntpq will #include and decode them all.

On-the-fly decoding

FrankKardel notes the varible list can be queried with by reading the sys_var_list variable:

 % ntpq -c 'rv 0 sys_var_list'
 assID=0 status=21f4 leap_none, sync_atomic/PPS, 15 events, event_peer/strat_chg,
 sys_var_list="leap,stratum,precision,rootdelay,rootdispersion,refid,reftime,poll,peer,state,offset,frequency,jitter,noise,clock,processor,system,version,stability,sys_var_list,flags,hostname,update,cert,expire,leapsec,tai,signature,ident,expire,daemon_version,settimeofday,contact,operational_status"

There are three variables: sys_var_list, peer_var_list, clock_var_list.

We would also have to get the required format definitions as well. This would entail having a sys_var_fmt variable with the formats matching the respective position in the sys_var_list variable list. Likewise for peer_var_list and clock_var_list. Then the problem is to have a static list of formats.

This is intriguing in that it would allow a common NTP control protocol with less reliance on implementation details allowing a greater chance of another implementation. Ideally, the whole control protocol should be independent of the implementation, just as the actual NTP protocol is.

BrianUtterback

I'm liking this idea more and more.

I think we'd also want to create flash_var_list and flash_var_fmt.

As far as the format list, we could also have a variable that contains the format name and a 'presentation format'.

I'm wondering if we should have sys_var_list and sys_var_fmt or if the sys_var_list 'response' should contain both the name and the presentation information.

-- HarlanStenn - 21 Aug 2007