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 <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. >
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 _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions