[ntp:questions] Thoughts on KOD

detha detha at foad.co.za
Sun Jul 6 13:23:39 UTC 2014


On Sun, 06 Jul 2014 12:28:09 +0000, Magnus Danielson wrote:

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

A proper default configuration (i.e. no fiddling) already auto-tunes
sufficient for >90% of the cases. 

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

All the state table/KOD/filter rules mitigation approaches I have seen so
far are limited to one server. Maybe time to take a look at a DNSBL-type
approach for abusive clients; that way, once a client is labeled
'abusive', it will stop working with any of the pool servers that use the
blacklist.

Policies (for how long to auto-blacklist, how to prevent DoS by
blacklisting the competition, how to 'promise to behave and
express-delist' etc.) to be defined.

-d



More information about the questions mailing list