On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn <st...@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.
Cheers,
Magnus
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
