[time] limiting client requests in NTP 4.2.0
Paul-Andrew Joseph Miseiko
Mon Nov 17 14:49:57 UTC 2003
Firstly multiple clients from the same IP is not really acceptable, NAT or
no NAT. However, the NTP rate-limiting code is based on an instance, for
example, NTP communicates via source port 123; while ntpdate might
communicate via an unregistered port. The rate limiting code uses an
instance of a connection to determine the limiting factor and since most
windows clients use random unregistered ports they would in fact be immune
to any limiting code. (Please correct me if I am wrong but based on the
monlist output this seems correct, I have not examined the code to verify
Secondly, the rate-limiting code ignores a client up until the minimum time
between packets reaches an acceptable level. So if an abusive client hits a
NTP server causing that client to be ignored due to rate limiting code; then
he reboots his computer taking perhaps 60 seconds to reboot, when his
computer comes back online it might be able to talk to the NTP server again
until the poorly configured NTP daemon once again triggers the rate limiting
and is ignored.
Lastly, if you are not comfortable with protecting your NTP server from
abuse and welcome the extra bandwidth then by all means, ignore rate
limiting settings; but for those of us with concerns, the default settings
are more then acceptable. They will limit clients from using burst mode at
minpoll 4, but will allow it at minpoll 5, and they also allow all of NTP
daemons standard poll values to be used.
From: timekeepers-bounces at fortytwo.ch
[mailto:timekeepers-bounces at fortytwo.ch] On Behalf Of Tapio Sokura
Sent: November 17, 2003 2:16 AM
To: timekeepers at fortytwo.ch
Subject: Re: [time] limiting client requests in NTP 4.2.0
>I'm inclined to limit the average interval to 34 seconds.
I haven't familiarized myself with the 4.2.0 rate limiting features, so I
may be a bit off here.. but a few thoughts anyway.
One thing to consider when limiting the rate of queries is the failure
modes of those clients that behave badly. We know that ntpd will take the
resulting(?) KoD-packet seriously and stop querying the server that issued
the packet. But do we know that those clients that behave badly won't
decrease their poll interval to 1 second when they get the KoD-packet or
no reply at all, for example? As many of you know, this happened a while
ago to one university, when a very badly written ntp client embedded in
network hardware started sending queries once per second if it did not
receive a reply.
I'd assume that most clients will handle the situation gracefully, at
least by not increasing their poll interval. I'd also guess that many
shareware/freeware ntp client-implementations (for windows) won't
understand the KoD-packet, because it is usually not seen. And if it's not
commonly seen, then those taking shortcuts implementing protocols skip
over it.. the result might be no change in client behavior or something
between stopping queries or retrying the query immediately.
Anothing thing is clients coming from behind a NAT-firewall. I haven't
looked at the rate limiting code in ntpd, but I would guess that it
assumes all packets coming from the same IP address as belonging to the
same client. This can lead to rate limiting triggering even if no one
client exceeds the limits. Of course one that actively uses NTP and has a
NAT-firewall with plenty of machines should probably run an NTP-server of
their own. But there are a lot of home networks that have a handful of
clients behind a simple NAT-firewall. On the other hand due to the DNS
round-robin feature, it's not likely that all clients behind the same
NAT-firewall end up querying the same server. On the other hand there are
some resolvers that don't properly rotate the results and instead always
return the same IP address..
Another thing that came to mind: once the rate limiting code triggers in
the ntpd serving the time, does it ignore queries from the same IP address
until the server is restarted? If an ISP has an abusive client that always
gets a different dynamically assigned IP address, this might not be what
you want. Some kind of timeout (days or maybe even weeks) might be useful
here. Again, I haven't checked the documentation/source code.
I'm not going to recommend a rate limiting setting, just wanted to point
out a few things.
timekeepers mailing list
timekeepers at fortytwo.ch
More information about the pool