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 requi=
res '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

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

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

On 2016-09-05, ask@ntppool.org <ask@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

Miroslav Lichvar wrote:
> On 2016-09-05, ask@ntppool.org <ask@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.

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.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Miroslav Lichvar wrote:
> On 2016-09-05, ask@ntppool.org <ask@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"

On 2016-09-06, Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> Miroslav Lichvar wrote:
>> On 2016-09-05, ask@ntppool.org <ask@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.



>
> 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.
>>
>
>