[ntp:questions] Very rapid polling

David Mills mills at udel.edu
Thu Feb 26 20:24:34 UTC 2009


Danny, Judah,

There might be some misunderstanding here. The current KoD scheme is 
part of a larger strategy for rate managment. The input packet rate and 
rsponse rate including KoD are components in an overall strategy. The 
input rate is  monitored and packets dropped to achieve an overall 
fairness strategy. If a KoD reponse is enabled by configuration, the KoD 
rate is itself policed not to exceed the target rate. This means that 
not every packet will be accepted and not every accepted packet will 
result in a response or  KoD. Just to remind folks, the current behavior 
when a rate exceeded situation is found is to return the packe with all 
fields unchanged. Thus, whatever packets do get ruturned are not useful 
for timekeeping purposes.

Frankly, the KoD was never intended as a quick fix, only a strategy that 
might help in a few cases where a responsible but possibly misguided 
implementor was at fault. On the other hand, the rate management/crafted 
discard policy has been a real help with our busy public servers. These 
don't get even close to the NIST/USNO servers in volume, but then indeed 
the rate management strategy does kick in.

Dave

Danny Mayer wrote:

>jlevine wrote:
>  
>
>>Thanks to all of you who responded to my initial post regarding very
>>rapid
>>polling. I have fixed this particular instance with some cooperation
>>from the
>>ISP. However, the generic problem remains and is likely to re-appear.
>>I don't know of a good general solution to this problem because:
>>
>>   1. the KOD packets are generally not effective. Either the remote
>>software
>>does not recognize them or it chooses to ignore them. The KOD method
>>obviously would not work against an attack.
>>   2. Sending any reply at all doubles the network traffic and makes
>>an
>>attack more effective. Therefore, all of the NIST servers log the
>>event and
>>the source ip but do not respond. I think it is not appropriate for a
>>national
>>timing laboratory to knowingly send the wrong time.
>>   3. This sort of stuff is really more general than NTP -- denial of
>>service
>>attacks can use many different protocols and a more general network
>>solution is going to be needed.
>>   4. A serious denial-of-service attack probably requires a botnet to
>>cause
>>real trouble, and fixing that problem might reduce the impact of all
>>denial
>>of service attacks.
>>
>>Judah Levine
>>Time and Frequency Division
>>NIST Boulder
>>
>>    
>>
>
>We should go through BCP 38 (RFC 2827) and see if there is something
>that we can do on the basis of that document. It will take time for
>review. Did you discover anything specific about the abusive clients?
>
>Danny
>
>  
>




More information about the questions mailing list