[ntp:questions] better rate limiting against amplification attacks?

William Unruh unruh at invalid.ca
Thu Jan 16 23:24:21 UTC 2014

On 2014-01-16, Steve Kostecke <kostecke at ntp.org> wrote:
> On 2014-01-16, Greg Troxel <gdt at ir.bbn.com> wrote:
>> Harlan Stenn <stenn at ntp.org> writes:
>>> William Unruh writes:
>>>> I do not mean the default in the config file, I mean the default if
>>>> there is no config file or if nothing is set in the config file.
>>> Then ntpd won't connect to anything and there will be no data to report.
>> This is a ridiculous strawman.   The ntp project is abdicating its
>> responsibility to provide sane default behavior by claiming that no
>> default behavior can make everyone happy and therefore it's not their
>> fault.  The notion that OS packagers somehow have a better idea of usage
>> is also specious.
>> Really, ntpd should, when run with a config file of only
>>   server 0.pool.ntp.org
>>   server 1.pool.ntp.org
>>   server 2.pool.ntp.org
>> behave relatively sanely, including declining to respond to packets that
>> could be amplification attacks,
> The majority use case for ntpd is to synchronize your clock to UTC (i.e.
> a leaf-node client). So an ntpd ought to have the following defaults:
> driftfile /path/to/ntp.drift
> pool pool.ntp.org iburst
> restrict -4 default kod notrap nomodify nopeer noquery
> restrict -6 default kod notrap nomodify nopeer noquery
> restrict
> restrict ::1
> This would enable the majority use case without the need for a
> configuration file.

Then this should probably be made the default (all except the second
perhaps) with the ability to override the defaults (NOt sure how you
would override a "restric" default mind you)

>> while being usable as a s2/s3 to other nearby nodes.
> Operation as a LAN time server is probably a secondary use case. But the
> defaults listed above would also enable that usage.
>> This notion of good behavior under minimal config seems
>> really obvious to me, yet there is a huge resistance to it, with the
>> notion that every end user should invest the time to be an expert.
> This.

More information about the questions mailing list