[ntp:questions] NTP Server abuse
mayer at gis.net
Wed Dec 1 02:50:30 UTC 2004
(I changed the subject)
At 08:43 PM 11/30/2004, Brad Knowles wrote:
>At 8:31 PM -0500 2004-11-30, Danny Mayer wrote:
> The problem is that some clients become excessively abusive (a la
> Netgear/UWisc), and while some pool server operators may be able to
> withstand such an assault from a somewhat lower volume traffic generator,
> there are plenty who cannot.
>> If the pool operator doesn't want literally anyone and
>> everyone to access their NTP server then they really should not be
>> putting it in the list.
> The problem is not the normal, legitimate use of the servers. The
> problem is the abusers, and what you can/should do to protect yourself
> against them.
To accomplish that, you first to define what is an abuser. If you can't
define that then you will never be able to create a program to detect
an abuser never mind deal with it. In that sense it's no different than
the spam-detection problem.
> Now, if you're saying that anyone who can't withstand the abuse
> should get out of the pool, then that's pretty much the end of the entire
> pool.ntp.org project right there.
What may be better is to use SRV records instead (along with the
programming involved), so that only those developers keeping up
with the standards get to find out what's in the pool. It will then
keep out the abusers at least for a while. Most of the abuse comes
from badly written apps and getting SRV records would be much
harder to do especially as there's no standard api for it. In that
sense it's not like spam.
One idea I had was for a non-authorized client to be returned a
KOD and a timestamp to indicate that their clock was too
fast and keep moving it further and further back. A properly written
ntp app would notice quickly that it was getting a KOD and ignore
the bad time and quickly prefer a different server. A badly written
one would merrily accept the timestamp anyway and finding itself
further and further away from the accurate time. After a while any
use would notice how far off it was and switch to a different server.
Okay so then it would repeat the cycle. Eventually the user would
decide that the app is bad and replace the app.
>Brad Knowles, <brad at stop.mail-abuse.org>
More information about the questions