[ntp:questions] Re: NTP Server abuse
mayer at gis.net
mayer at gis.net
Wed Dec 1 13:32:26 UTC 2004
----- Original Message Follows -----
> At 9:50 PM -0500 2004-11-30, Danny Mayer wrote:
> > To accomplish that, you first to define what is an abuser.
> In this case, it's actually pretty easy to do that. Barring
> short startup periods, an abuser is anyone who makes more than one
> query roughly every 1024 seconds. You might want to be generous and
> allow them to make queries as frequently as every 512 or 256 seconds.
That would shut out just about eveeryone since the standard startup
interval is 64 seconds, but lets assume we make that suitable
> I think that this much has already been done, and simple
> prototype scripts have already been developed for some OSes to detect
> excessive traffic and to automatically generate firewall rules to
> send that somewhere else.
> > 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's all well and good to say this, but ntpd doesn't support SRV,
> does it?
I'm suggesting implementing it.
> What do we do for all the old NTP clients (such as our own
> ntpd-4.2.0) that don't support SRV?
Nothing. We still have plenty of NTP V3 clients/servers out there.
With pool moved to SRV, they don't get the benefit of the pool.
> How many years would be a reasonable time to wait for all
> "reasonable" clients to update to an SRV-aware implementation?
> Until that time comes along, what do we do -- just shut down
> pool.ntp.org altogether?
NTP V4 supports KOD. The people running the pool can demand that anyone
who wants to use it obeys the rules or they won't get service.
> > 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.
> That's a nice idea. When could we expect that to be tested,
> working, and in the field?
Couple of years if we don't get more programming talent to help
define the architecture, lay out the implementation, and get things
> In the meanwhile, do you have any suggestions for what we could
> do with the code as it exists today?
The pool servers should be running the latest code as far as is
possible and they should drop abusive (too frequent) clients.
I believe that's already implemented in the code, from what I recall
Dave Mills saying.
> Brad Knowles, <brad at stop.mail-abuse.org>
> "Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety."
> -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
> Assembly to the Governor, November 11, 1755
> SAGE member since 1995. See <http://www.sage.org/> for more info.
More information about the questions