How NTP Controls Access (Computer Network Time Synchronization)

Most NTP servers provide service to an intended client population usually defined by a geographic or organization affiliation. In the case of public NTP servers, this is specified in the lists of public servers maintained at http:// www.ntp.org. If all NTP clients obeyed the rules specified in these lists, server access controls would not be needed. Unfortunately, such is not the case in modern life, and up to half the clients found on some servers have violated the rules of engagement. On one hand, it must be admitted that actually serving the scofflaws may be in fact just as expensive as detecting the scoff and dropping their packets. On the other hand, in the finest Internet tradition, the most effective way to notify a sender that packets are unwanted is simply to drop them without prejudice.

It is not the intent in the formal NTP specification to require access controls or prescribe the way they must operate. However, as an optional feature the reference implementation provides access controls using an access control list specified in the configuration file. Each entry on the list includes an address and mask and one or more bits for various functions, such as provide time, allow monitoring, allow configuration change, and so forth. A default entry is provided that matches any address not matching another on the list. If the IP address of an incoming packet matches an entry on the list, the associated bits define the service it can receive.


There is another access control function to protect against accidental or malicious clogging attacks. It is called call-gap after a similar function designed to protect telephone networks in cases of national alarm, like an earthquake. As an example, some nefarious implementation attempted to send 256 packets to a USNO time server as fast as possible and without waiting for responses. USNO servers are provisioned by fairly awesome networks, but the nefariot was able to jam network and server queues for each blast, which was repeated at intervals of 1 s.

The call-gap function maintains a list of recent NTP packets with distinct source addresses. As each message arrives, the list is searched for a matching address. If found, that entry goes to the head of the list; if not, an entry is created at the head of the list. In either case, the time of arrival is recorded in the entry. Using these means, the NTP daemon discards packets that exceed a peak rate over one per 2 s and an average rate over one per 5 s. On violation, the daemon also sends a special kiss-o’-death packet to the nefariot. By design, this kills the client association and sends a nasty message to the system log.

Of course, the call-gap and kiss-o’-death packet are much more expensive than either servicing the packet or simply dropping it, but sometimes desperate means are required to provoke the system administrator’s attention. Apparently, a few of them are not watching things since it is not uncommon for a besieged server to drop 20 percent of all arriving packets due to call-gap. Sadly, it is not uncommon to see the same client be repeatedly gapped and for this to continue for a long time. This is not an exaggeration. Some nefariot is still beating on an address once used by one of our time servers that was abandoned several years ago.

Next post:

Previous post: