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

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

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

Danny
> -- 
> 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 mailing list