[ntp:questions] Thoughts on KOD

Magnus Danielson magnus at rubidium.dyndns.org
Sun Jul 6 12:28:09 UTC 2014

On 07/06/2014 12:38 PM, Terje Mathisen wrote:
> Rob wrote:
>> Harlan Stenn <stenn at ntp.org> wrote:
>>> Discussion appreciated.
>> I think it is best to remove KOD from ntpd.
>> It does not serve a useful purpose, because precisely the kind of
>> clients that you want to say goodbye to, do not support it.
>> In real life it has either no effect at all, or it even has a negative
>> effect because the client does not understand it and re-tries the
>> request sooner than it would when no reply was sent at all.
> I'm afraid this is exactly right:
> KOD is a way to "keep honest guys honest", i.e. it only helps against
> programmers/users why actually try (hard) to do the right thing.
> Currently it will cause a badly configured ntpd installation (burst +
> minpoll 4 + maxpoll 4) to possibly stop using any server which sends
> back KOD, but only if it also uses the pool directive to actively search
> out the best servers.

Maybe it's time to figure out how to "auto-tune" configurations as a 
better alternative than people keep following aged advice. In the 
meanwhile, make sure that good concrete advice with a section of "don't 
do this anymore" is on ntp.org.

> I don't want to think about users actively trying to generate as much
> traffic as possible. :-(

Unfortunately we need to. The use of NTP features as accelerator in DDOS 
attack happen this spring. We had to turn of nice features, which in 
itself becomes a form of DOS. If we rather had ways to protect a server 
(remember that clients also act as servers) so that proper use does not 
cause loss of service, but aggressive use cause block-out. Soft-state 
remembering signaling peers for some time and then forget them to keep 
statistics of packets per time-period, and if the signaling peer acts 
reasonably well it is stays, overtransmitting packets will cause 
black-listing. KOD is the least, but inserting drop rules into the local 
host should follow, and possibly push the block rule into the network to 
clear off the machine and part of the network with the offending traffic.

For cases like that, KOD won't help at all.


More information about the questions mailing list