[ntp:questions] NTPD concurrent clients limit

Phil phil at xxxxxxxxx.xxx
Fri Aug 1 06:24:47 UTC 2008

For some reason I was under the false impression that kod packet would be 
equivalent to inserting several leap seconds. If that were the case, I could 
potentially be in trouble should I accidentally activate it. I'm guilty of 
taking ntpd for granted since it simply works and haven't studied the 
mechanics or security of it in detail. That is soon to change.

I may have an application that could conceivably hit timeservers by the tens 
of thousands, and potentially far far greater.  It would be from different 
ip's but my concern, should that be the case, it may or could be considered 
a rouge script or equipment causing an attack. I certainly don't want you 
and the rest of the Calvary to be hunting me down.  If we follow through on 
this project, we intend to use our own timeservers not only to keep the 
Calvary at bay; I can have better and more accurate control using gps 
disciplined rubidium timebases for the servers.

Regard that U Wisconsin incident; I was first made aware of it from the U 
Wisconsin side. The article I referenced was put together by one of the 
Wisconsin group detailing the whole experience from discovery through 
resolution. I'll take a look at your papers, should be a good read too.

Thanks for the time, (take that either way !)

"David L. Mills" <mills at udel.edu> wrote in message 
news:g6u0nu$83r$1 at scrotar.nss.udel.edu...
> Phil,
> You refer to the U Wisconsin incient, but there have been several others, 
> including those at NIST and USNO reported in the PTTI paper in my list of 
> publications. The rate controls can be used to selectively drop abuse 
> packets or to return a KoD in the hope that abusers will listen and reduce 
> the rate. Frankly, in the culture of modern times I doubt very much the 
> abuser will listen. After some discussion with my friends here, a further 
> defense was implemented with result the KoD time returned reveals no 
> influence of the server. It's not wrong, it just doesn't result in a time 
> adjustment.
> Dave
> Phil wrote:
>> David, Thank you.
>> I'll explore it further when I get some time. After learning of this 
>> "kod" packet and since these servers vend time to my applications, I 
>> would prefer or need the correct time (no kod) even if something went 
>> haywire banging the fool out of a server. To me, no time is better than 
>> wrong time. An "excessive use" type of problem should be easily seen from 
>> the increased bandwidth.
>> I understand why you implemented "kod" and other safeguards. I have read 
>> articles about ntp abuse like that series of cheap routers that had an ip 
>> embedded in the firmware that was banging I believe the ucar.edu ntp 
>> servers. Seems like you may have been involved in helping isolate that 
>> problem. Considering how adaptive the ntpd software has to be, I'm sure 
>> it's a delicate balancing act to make it serve the whole of the time 
>> community.
>> Phil
>> "David L. Mills" <mills at udel.edu> wrote in message 
>> news:g6t5g2$o9$1 at scrotar.nss.udel.edu...
>>>In the clash of titans one of your questions about whether a canned 
>>>version of the rate management stuff exists. There are quite a number of 
>>>products using the reference implementation in one form or another, but 
>>>not usually a later version. I know that Meinberg even has Autokey in 
>>>their product, for example. But, I wouldn't count on any product to 
>>>support anything beyond the NTPv4 specification, and that doesn't require 
>>>the particulare schemes in the reference version. Another implementation 
>>>might do it differently.
>>>Phil wrote:
>>>>The replies around here sure separate the professionals like David Mills 
>>>>and Steve Kostecke from the seemingly arrogant ones like Unruh.
>>>>Considering my use of timing is rather critical to my applications I 
>>>>don't even depend on the "pool" servers for time. I use my own 
>>>>Symmetricom gps disciplined ntp servers, my own Datum/Symmetricom gps 
>>>>disciplined rubidium standards for 1PPP and 10 MHz all using 
>>>>HP/Symmetricom gps antennas and gps splitters. Sorry, I only have some 
>>>>ten GPS based time receivers.
>>>>Unruh said "If it is in hardware only it may be some hack
>>>>written by someone whose knowledge of ntp was gained in kindergarten 
>>>>I guess that depends on what you think of the Symmetricom designers, 
>>>>engineers, and programmers. I also run the latest release of ntpd 
>>>>software on several HP/Compaq Servers.
>>>>I'm certain I'm a small fish time user, but I feel with this investment 
>>>>I have graduated a little past the sundial and perhaps even a little 
>>>>above the average time user.
>>>>Phil Harwood
>>>>"Unruh" <unruh-spam at physics.ubc.ca> wrote in message 
>>>>news:pUlkk.2876$%b7.390 at edtnps82...
>>>>>"David L. Mills" <mills at udel.edu> writes:
>>>>>>See the limit and kod restrict options in the Access Control Options
>>>>>>page in the current web documentation.
>>>>>Since the current web documentation refers to the current version of 
>>>>>and since the OP has never told us what version of ntpd he is running 
>>>>>even if it is  ntpd he is running, that may not be helpful.
>>>>>In fact he may not know. If it is in hardware only it may be some hack
>>>>>written by someone whose knowledge of ntp was gained in kindergarten 
>>>>>>Phil wrote:
>>>>>>>Can the kiss-o'-death packet be disabled ?
>>>>>>>Is this packet also implemented in a "canned" or hardware only ntp 
>>>>>>>Phil Harwood
>>>>>>>>>j. wrote:
>>>>>>>>>>Hi all,
>>>>>>>>>>I'm testing an embedded linux device, which implement an NTP 
>>>>>>>>>>based on the ntpd demon.
>>>>>>>>>>It looks like ntpd accepts only a limited number of requests from 
>>>>>>>>>>test clientIi've set up.
>>>>>>>>>>Do you know if there's such limit or what's the logic behind it?
>>>>>>>>>>Maybe ntpd rejects bursts of requests coming from the same IP?
>>>>>>>>>>Thanks in advance,
>>>>>>>>>>Gianandrea Gobbo.
>>>>>>>>>If you poll the server continuously at intervals of less than 64
>>>>>>>>>seconds, most modern NTP servers will send you a "Kiss of Death" 
>>>>>>>>>Polling this frequently is considered abusive!  It's also 
>>>>>>>>>NTP is designed to work with poll intervals between 64 seconds and 
>>>>>>>>>seconds and will adjust its poll interval within that range as 
>>>>>>>>His question can be rephrased, what does ntpd do after it has sent 
>>>>>>>>Kiss of Death?
>>>>>>>>does it drop all subsequent packets? -- That sounds like a huge cost 
>>>>>>>>ntp server-- ie imagine a popular server with 10,000 machines it has 
>>>>>>>>the KoD to. It then has to scan that whole list for each packet to 
>>>>>>>>see if
>>>>>>>>it is in there-- something which takes time and destroys the ability 
>>>>>>>>to deliver its time base rapidly.
>>>>>>>>Note that how ntpd handles this situation depends on which version 
>>>>>>>>of ntpd
>>>>>>>>you are running.
>>>>>>>>>There are two exceptions to the above.  You may specify the 
>>>>>>>>>keyword for a server and NTPD will send an INITIAL burst of eight
>>>>>>>>>request packets at intervals of two seconds.  This is designed for 
>>>>>>>>>startup.  After the initial burst, polling continues at intervals
>>>>>>>>>between 64 and 1024 seconds.
>>>>>>>>So how does the server know whether this burst is an iburst or is a 
>>>>>>>>client to which it should send a KoD?
>>>>>>>>>If you are using a dialup telephone connection for short periods 
>>>>>>>>>or four times a day, you may specify the "burst" keyword which 
>>>>>>>>>eight requests two seconds apart at EACH poll interval.  "Burst" is 
>>>>>>>>>be used ONLY for brief periods with LONG intervals between them!
>>>>>>>>>It is customary to request permission from the owner of the server
>>>>>>>>>before using "burst".

More information about the questions mailing list