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.

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.

The new ntp.conf file format

Please add your comments following the appropriate point of discussion following the existing format (e.g. add your signature at the end of your comment and use --- as a separator.) General Comments should go in the section set-up for them. Please add another discussion heading if needed.

General Comments

---

(Discuss here...)

---

Where should we allow each configurable item to be specified?

• ntp.conf file
• command-line

---

(Discuss here...)

---

Allow configuration of (up to) N IPs for a given server/peer.

• Do we really need this for peers?
• Make restrict handling easier?
  • Automatic for every server/peer?
• Also see Bug #376

---

(Discuss here...)

---

Improved logging/debug facility

---

(Discuss here...)

---

Memory locking

• Overriding default settings for locking ntpd in memory
• Also see Bug #220, Bug #477

---

There might be something to be said for a command-line override too, but that is getting "busy".

-- HarlanStenn - 24 Jul 2004

---

Make "exit if things get rough" an option (Wolfgang Rupprecht)

---

Audio refclock variables

Make hardcoded values (volume, ???) in icom.c configurable here

Also see Bug #291, Bug #406 and Bug #407

-- SteveKostecke - ???

---

Modem driver

We should allow folks to override the defaults for the setup string, the connect timeout, etc.

I'd like to find a useful library that handled this, and I'd rather not re-implement "expect". My preference would be a BSD-licensed thing, as opposed to a GPL thing.

-- HarlanStenn - 10 Dec 2004

---

Minpoll,maxpoll driver/user preferences

(From GregDowd 2005-02-16) Are you saying that if the max and min poll values are initialized in the driver, they overwrite any ntp.conf server options? ... But, doesn't that violate the least astonishment principle? It would be nice to have the driver suggest baseline values and have the user override them if desired...

(From MarkMartinec 2005-02-16) I very much second that. I had issues with hard-coded minpoll at the driver-29 (Trimble Palisade) so I had to keep a patch and reapply it for every ntp version upgrade.

(From DavidLMills 2005-02-16) Greg, ...The maxpoll/minpoll values are initialized in newpeer() in ntp_peer.c before the refclock code. It's the same with all associations. You get to set it from the configuration file. While the defaults are inappropriate for the ACTS driver, I'm reluctant to take away the means to change the values. The user can't override the default values in the driver either, unless as you suggested they are fixed...

The values from the command line are set by newpeer() before the refclocks get ahold if it. It would be messy, to say the least, to do this during driver initialization.

-- MarkMartinec - 2005-02-16

---

More options (fudge) for non-refclocks

I would very much like to see 'fudge time1' being applicable to network reference servers. Like JohnPettitt, I see a very predictive and stable offsets for network peers due to an asymmetric cable connection.

(From DavidLMills 2005-02-15) It would be nice to expand the fudge to non-refclocks, but this requires rewrite of the configuration code as well as changes in the remote configuration protocol. This in turn requires an asynchronous DNS implementation. Besides providing a broader fudge application, this would provide a really neat automatic pool capability. Nothing wildly difficulat about this, but really down and dirty. Previous broad hints for help in this area haven't raised any hands.

-- MarkMartinec - 2005-02-16

I initially thought this would make more sense on a per-interface basis, but I can see that it might be more useful per-peer.

-- HarlanStenn - 18 Feb 2005

---

Individual huff'n'puff buffers for each network reference

(From DavidLMills 2004-12-20) You correctly concluded the huffpuff is global, not association specific. Naughty me; I intended to say that in the documentation, but at least the ntpd page doesn't say that. I thought about doing it (only) for the prefer peer. Do you have a preference?

(From MarkMartinec 2004-12-20) The current assumption for huffpuff is that all reference clocks are on the other side of a single network connection, and it is the single 'last mile' line that gets into asymmetric congested state. It clearly isn't the case for local reference clock like atom, which have roundtrip delay of 0. More generally, it also isn't so for other peers, each of them may have a differently behaving network leading to it, and sometimes the congested lines are on the remote server side.

The best solution would be for each peer to have its own huffpuff buffer. Apart from costing some memory, I don't think this is a heavy price to pay. If huffpuff could be configurable (at least: enabled/disabled) individually on each 'server' config line, so much the better.

-- MarkMartinec - 2005-02-16

Is this an issue for ntp.conf or is it an issue for ntpd itself? If the latter, please consider opening an "enhancement" request at http://bugs.ntp.org .

-- HarlanStenn - 18 Feb 2005

Harlan,

It's not as simple as you think. In fact, it's not as simple as I thought. The scheme is a maximim a-posteriori (MAP) statisical estimation method. The estimator thinks it has a good measure of the correct value and then collects samples that reinforce that value.

The trick is to reliably estimate the minimum delay over a sufficient time span that insures at least one minimum delay sample is found. From theory, other samples tend to be found at the limbs of what I have called the wedge scattergram, where the limbs are at slopes of +-0.5. On the assumption the samples are on the limbs, just determine the sign and correct for the additional delay. It works equally well for one-sided or two-sided congested paths.

But, this works only if the apex of the wedge can be reliably determined, which is where the MAP method comes in. To do this successfully for different associations would require a separate pseudo-discipline for each association. This would be incredibly intricate, but in principle possible.

-- Dave Mills - 11 Oct 2008

---