[ntp:questions] Very rapid polling
mills at udel.edu
Thu Feb 26 20:24:34 UTC 2009
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.
Danny Mayer wrote:
>>Thanks to all of you who responded to my initial post regarding very
>>polling. I have fixed this particular instance with some cooperation
>>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
>>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
>>attack more effective. Therefore, all of the NIST servers log the
>>the source ip but do not respond. I think it is not appropriate for a
>>timing laboratory to knowingly send the wrong time.
>> 3. This sort of stuff is really more general than NTP -- denial of
>>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
>>real trouble, and fixing that problem might reduce the impact of all
>>of service attacks.
>>Time and Frequency Division
>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?
More information about the questions