restrict source available from which version?

[Ask Bjørn Hansen]

Which version of ntpd included 'restrict source'?

I'm updating the instructions on http://www.pool.ntp.org/use.html and would like to include the appropriate 'restrict' lines. The 'pool' keyword requires 'restrict source' (as far as I understand), so to make the instructions simpler I wanted to include 'restrict source' in the instructions. However reading through the (pretty confusing) 'CommitLog' it's not clear to me if 'restrict source' was only added after 4.2.6.


Ask

[Martin Burnicki]

Ask Bjørn Hansen wrote:
> Which version of ntpd included 'restrict source'?
>
> I'm updating the instructions on http://www.pool.ntp.org/use.html and would like to include the appropriate 'restrict' lines. The 'pool' keyword requires 'restrict source' (as far as I understand), so to make the instructions simpler I wanted to include 'restrict source' in the instructions. However reading through the (pretty confusing) 'CommitLog' it's not clear to me if 'restrict source' was only added after 4.2.6.

According to this announcement
https://lists.ntp.org/pipermail/questions/2010-April/026304.html
'restrict source' was introduced in 4.2.7p22, which is a developer
version. So it should be available in the subsequent stable release,
which is 4.2.8.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

[a...@ntppool.org]

Great, thank you!

I'll make separate sections for 4.2.8 and later and 4.2.6 and earlier on http://www.pool.ntp.org/use.html and recommend using 'pool ...' for 4.2.8.

My draft has the following as the recommendation for someone using the pool (on 4.2.8 or later):

driftfile /var/lib/ntp/ntp.drift

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict source notrap nomodify noquery
restrict 127.0.0.1
restrict -6 ::1

pool 0.pool.ntp.org

Does that seem reasonable?


Ask

[Miroslav Lichvar]

On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
> My draft has the following as the recommendation for someone using the
> pool (on 4.2.8 or later):
>
> driftfile /var/lib/ntp/ntp.drift
>
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery

I think this line shouldn't be necessary as restrict default specified
without -4 and -6 should apply to both.

> restrict source notrap nomodify noquery
> restrict 127.0.0.1
> restrict -6 ::1
>
> pool 0.pool.ntp.org

How many servers should the client use at the same time? The default
value of tos maxclock is 10, so it would use 10 servers. That seems a
bit excessive. If it should be equivalent to the current recommendation,
the config would need to include

tos maxclock 4

Would it make sense to use 2.pool.ntp.org in the config instead of
0.pool.ntp.org in order to get IPv6 addresses?

Also, how about adding the iburst option? Considering that a significant
part of NTP traffic is from ntpdate (which sends four packets in 2s
interval) and that most Linux distributions seem to use iburst in their
default ntp.conf, I think it could be recommended to everyone.

--
Miroslav Lichvar

[Martin Burnicki]

Agreed, and AFAIK the "kod" flag has no effect unless the "limited" flag
is also specified, and the behavior of "limited" in turn can be
controlled by the "discard" keyword.

See http://doc.ntp.org/current-stable/accopt.html

So either add at least the "limited" keyword, or remove "kod".

There seem 2 be at least 2 general opinions whether using "kod" is
useful, or not.

If a server has been configured to use it and the server sends a kod
packet to a client then AFAIK only ntpd (eventually chrony?) honors this
packet. However, these implementation have been designed to behave well
anyway, so it's usually not necessary to send them a kod packet.

Other implementations running on clients may not behave so well, and if
they receive a kod packet, or no reply at all, they may start to behave
even worse, e.g. sending retries at a higher rate.

So you can have a lot of discussion whether configuring a server to
support kod is useful, or not.

[Terje Mathisen]

Miroslav Lichvar wrote:
> On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
>> My draft has the following as the recommendation for someone using the
>> pool (on 4.2.8 or later):
>>
>> driftfile /var/lib/ntp/ntp.drift
>>
>> restrict default kod nomodify notrap nopeer noquery
>> restrict -6 default kod nomodify notrap nopeer noquery
>
> I think this line shouldn't be necessary as restrict default specified
> without -4 and -6 should apply to both.
>
>> restrict source notrap nomodify noquery
>> restrict 127.0.0.1
>> restrict -6 ::1
>>
>> pool 0.pool.ntp.org
>
> How many servers should the client use at the same time? The default
> value of tos maxclock is 10, so it would use 10 servers. That seems a
> bit excessive. If it should be equivalent to the current recommendation,
> the config would need to include
>
> tos maxclock 4

tos maxclock should probably be at least 5 or 6!

This is because you want enough so that even when the algorithm tosses
the two worst exvery hour and retires the pool DNS in order to pick up
new candidate servers, it should not drop below 3 or 4 usable servers.

Terje

>
> Would it make sense to use 2.pool.ntp.org in the config instead of
> 0.pool.ntp.org in order to get IPv6 addresses?
>
> Also, how about adding the iburst option? Considering that a significant
> part of NTP traffic is from ntpdate (which sends four packets in 2s
> interval) and that most Linux distributions seem to use iburst in their
> default ntp.conf, I think it could be recommended to everyone.
>


--

- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[William Unruh]

On 2016-09-06, Terje Mathisen <terje.m...@tmsw.no> wrote:
> Miroslav Lichvar wrote:
>> On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
>>> My draft has the following as the recommendation for someone using the
>>> pool (on 4.2.8 or later):
>>>
>>> driftfile /var/lib/ntp/ntp.drift
>>>
>>> restrict default kod nomodify notrap nopeer noquery
>>> restrict -6 default kod nomodify notrap nopeer noquery
>>
>> I think this line shouldn't be necessary as restrict default specified
>> without -4 and -6 should apply to both.
>>
>>> restrict source notrap nomodify noquery
>>> restrict 127.0.0.1
>>> restrict -6 ::1
>>>
>>> pool 0.pool.ntp.org
>>
>> How many servers should the client use at the same time? The default
>> value of tos maxclock is 10, so it would use 10 servers. That seems a
>> bit excessive. If it should be equivalent to the current recommendation,
>> the config would need to include
>>
>> tos maxclock 4
>
> tos maxclock should probably be at least 5 or 6!

Why not 1000? After all something could make 997 of them inoperative for
some reason, and then where would you be if there were not three left
over?
3 is already and insurance policy, in case one fails. 4 in case 2 fail,
but you can keep entending this ad absurdum.

[Ask Bjørn Hansen]

On Tuesday, September 6, 2016 at 1:41:10 AM UTC-7, Miroslav Lichvar wrote:
> On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
> > My draft has the following as the recommendation for someone using the
> > pool (on 4.2.8 or later):
> >
> > driftfile /var/lib/ntp/ntp.drift
> >
> > restrict default kod nomodify notrap nopeer noquery
> > restrict -6 default kod nomodify notrap nopeer noquery
>
> I think this line shouldn't be necessary as restrict default specified
> without -4 and -6 should apply to both.

Ok, thank you. Is that the case for older versions of ntpd, too? There's obviously a bit of cargo cult going on here, I appreciate the help getting to an actual best practices recommendation. :-/

For Martin's comment about kod and limited:

I'm not sure if 'limited' works on a reasonably busy NTP server (hundreds to a few thousand queries a second) and I don't think anyone has shown that KoD packets does something useful for a meaningful number of the "bad clients", so I should probably just take 'kod' out.

> > restrict source notrap nomodify noquery
> > restrict 127.0.0.1
> > restrict -6 ::1
> >
> > pool 0.pool.ntp.org
>
> How many servers should the client use at the same time? The default
> value of tos maxclock is 10, so it would use 10 servers. That seems a
> bit excessive. If it should be equivalent to the current recommendation,
> the config would need to include
>
> tos maxclock 4

How does that work if the client is dual-stack? I'd like to avoid the client (sometimes) just getting IPv6 if it's dual-stack.

> Would it make sense to use 2.pool.ntp.org in the config instead of
> 0.pool.ntp.org in order to get IPv6 addresses?

My plan is to make the "bare" name have IPv6 soon. I've also been planning to change it to have explicit "I'm an SNTP client" vs "I'm an NTP client" names though.

> Also, how about adding the iburst option? Considering that a significant
> part of NTP traffic is from ntpdate (which sends four packets in 2s
> interval) and that most Linux distributions seem to use iburst in their
> default ntp.conf, I think it could be recommended to everyone.

Hmm, I could get convinced of that.


Ask

[Brian Inglis]

On 2016-12-30 16:32, Ask Bjørn Hansen wrote:
> On Tuesday, September 6, 2016 at 1:41:10 AM UTC-7, Miroslav Lichvar wrote:
>> On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
>>> My draft has the following as the recommendation for someone using the
>>> pool (on 4.2.8 or later):
>>> driftfile /var/lib/ntp/ntp.drift
>>> restrict default kod nomodify notrap nopeer noquery
>>> restrict -6 default kod nomodify notrap nopeer noquery
>> I think this line shouldn't be necessary as restrict default specified
>> without -4 and -6 should apply to both.
> Ok, thank you. Is that the case for older versions of ntpd, too?
> There's obviously a bit of cargo cult going on here, I appreciate the
> help getting to an actual best practices recommendation. :-/
> For Martin's comment about kod and limited:
> I'm not sure if 'limited' works on a reasonably busy NTP server
> (hundreds to a few thousand queries a second) and I don't think
> anyone has shown that KoD packets does something useful for a
> meaningful number of the "bad clients", so I should probably just
> take 'kod' out.

Works with typical bad clients but most ignore KoD packets anyway
so just avoid the MRU list overhead and sending KoD - see
http://doc.ntp.org/current-stable/rate.html for how it works.

>>> restrict source notrap nomodify noquery

restrict source added with pool in 4.2.7p22 2010/04/02,
docs updated in 4.2.7p24 2010/04/13.

>>> restrict 127.0.0.1
>>> restrict -6 ::1
>>>
>>> pool 0.pool.ntp.org

Add preempt to pool statements to drop unselected servers and
acquire new servers to maintain a majority clique - see below.

>> How many servers should the client use at the same time? The
>> default value of tos maxclock is 10, so it would use 10 servers.
>> That seems a bit excessive. If it should be equivalent to the
>> current recommendation, the config would need to include
>>
>> tos maxclock 4

Keep it odd - tos maxclock 5 - for sync, majority clique requires
truechimers *>* falsetickers - truechimers == falsetickers is
*unsynced* - 5 allows 2 servers "off" in some way at the same time
(e.g. during weekend maintenance windows when servers often drop
out - YMMV) see http://doc.ntp.org/current-stable/select.html .

>> Also, how about adding the iburst option? Considering that a
>> significant part of NTP traffic is from ntpdate (which sends four
>> packets in 2s interval) and that most Linux distributions seem to
>> use iburst in their default ntp.conf, I think it could be
>> recommended to everyone.
>
> Hmm, I could get convinced of that.

Also add iburst to pool statements.

And only use minpoll and/or maxpoll on local ref clocks.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
_______________________________________________
questions mailing list
ques...@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[Brian Inglis]

May also want to unrestrict all LAN addresses - safe for small
home or business LANs, not for e.g. campus situations - or add
but comment out?

restrict 10.0.0.0 mask 255.0.0.0 # private net allow all packets
restrict 172.16.0.0 mask 255.240.0.0 # private net allow all packets
restrict 192.168.0.0 mask 255.255.0.0 # private net allow all packets

[Miroslav Lichvar]

On Fri, Dec 30, 2016 at 03:32:51PM -0800, Ask Bjørn Hansen wrote:
> On Tuesday, September 6, 2016 at 1:41:10 AM UTC-7, Miroslav Lichvar wrote:
> > On 2016-09-05, a...@ntppool.org <a...@ntppool.org> wrote:
> > > restrict default kod nomodify notrap nopeer noquery
> > > restrict -6 default kod nomodify notrap nopeer noquery
> >
> > I think this line shouldn't be necessary as restrict default specified
> > without -4 and -6 should apply to both.
>
> Ok, thank you. Is that the case for older versions of ntpd, too? There's obviously a bit of cargo cult going on here, I appreciate the help getting to an actual best practices recommendation. :-/

I think the last version that needed that -6 line was 4.2.4.

> For Martin's comment about kod and limited:
>
> I'm not sure if 'limited' works on a reasonably busy NTP server (hundreds to a few thousand queries a second) and I don't think anyone has shown that KoD packets does something useful for a meaningful number of the "bad clients", so I should probably just take 'kod' out.

Makes sense to me.

> > How many servers should the client use at the same time? The default
> > value of tos maxclock is 10, so it would use 10 servers. That seems a
> > bit excessive. If it should be equivalent to the current recommendation,
> > the config would need to include
> >
> > tos maxclock 4
>
> How does that work if the client is dual-stack? I'd like to avoid the client (sometimes) just getting IPv6 if it's dual-stack.

That probably won't work. If the client selects only IPv6 addresses
from all addresses the name has resolved too, I think it will replace
them with IPv4 addresses only when they are unreachable.

> > Would it make sense to use 2.pool.ntp.org in the config instead of
> > 0.pool.ntp.org in order to get IPv6 addresses?
>
> My plan is to make the "bare" name have IPv6 soon. I've also been planning to change it to have explicit "I'm an SNTP client" vs "I'm an NTP client" names though.

The difference being that SNTP clients resolve the name before each
NTP query? I'm not sure if all SNTP clients do that.

--
Miroslav Lichvar

[Miroslav Lichvar]

On Sat, Dec 31, 2016 at 01:09:46AM -0700, Brian Inglis wrote:
> On 2016-12-30 16:32, Ask Bjørn Hansen wrote:
> >>> restrict 127.0.0.1
> >>> restrict -6 ::1
> >>>
> >>> pool 0.pool.ntp.org
>
> Add preempt to pool statements to drop unselected servers and
> acquire new servers to maintain a majority clique - see below.

Does the preempt option actually do anything in the pool directive? I
thought servers added from pool are always "preemptable".

> >> How many servers should the client use at the same time? The
> >> default value of tos maxclock is 10, so it would use 10 servers.
> >> That seems a bit excessive. If it should be equivalent to the
> >> current recommendation, the config would need to include
> >>
> >> tos maxclock 4
>
> Keep it odd - tos maxclock 5 - for sync, majority clique requires
> truechimers *>* falsetickers - truechimers == falsetickers is
> *unsynced* - 5 allows 2 servers "off" in some way at the same time
> (e.g. during weekend maintenance windows when servers often drop
> out - YMMV) see http://doc.ntp.org/current-stable/select.html .

Is it common to get two falsetickers at the same time?

--
Miroslav Lichvar

[Charles Elliott]

> And only use minpoll and/or maxpoll on local ref clocks.

Have you ever watched NTPD output when the polling interval reaches 10 (= 1024 seconds) or higher? NTPD acts just like the integral term in PID control, i.e., the yo-yo effect: Over several hours the offset drops to between -2 and -3 milliseconds; then over a period of 10 hours, or so, it reaches about +2 milliseconds offset. Then over the next 8 hours it slowly and fitfully drops to between -2 and -3 milliseconds again. It that 8 hour decline from +2 to -2 to -3 millis, in each case when I looked at it (11/24-11/27/16), it made a sudden (2 hour) spurt at the midpoint of the 8 hours to zero offset, but then resumed its slow and fitful decline to between -2 and -3 millis. Given that it is not hard to maintain sub-millisecond offsets (if the NTPD client is using stratum 1 timeservers and has a fast (over 20-25 Mbps) connection to the Internet), a constant swing of ~5 milliseconds in offset from the correct time is discouraging. I would wager that the offsets are larger with pool servers.

Charles Elliott