Association Management

Association Management

This release of the NTP Version 4 (NTPv4) daemon for Unix incorporates new features and refinements to the NTP Version 3 (NTPv3) algorithms. However, it continues the tradition of retaining backwards compatibility with older versions. The NTPv4 version has been under development for quite a while and isn't finished yet. In fact, quite a number of NTPv4 features have already been implemented in the current NTPv3, including a number of new operating modes for automatic server discovery and improved accuracy in occasionally-connected networks. Following is an extended abstract describing the new features..

An ephemeral association of some mode is mobilized when a message arrives from another client or server. For instance, a symmetric-passive association is mobilized upon arrival of a message from a symmetric- active peer. A client association is mobilized upon arrival of a broadcast message from a multicast server or a server message from a manycast server. Ephemeral associations are demobilized when either (a) the server becomes unreachable or (b) an error occurs on initial contact before the association is mobilized.

The one exception to (a) and (b) above is when autokey is in use and the initial authentication check fails due to unknown key identifier or autokey mismatch. This exception is necessary because the Unix kernel does not bind the local address until the first packet is received. The result in broadcast mode is a rather painful initial exchange, where authentication fails until after the first round of messages. The result in multicast mode is in general fatal, especially if multiple interfaces are in use. As promiscuous modes such as multicast and manycast require authentication for reliable and safe operation, autokey is in general useless with these modes until and if the input/output machinery is overhauled.

Following is a summary of the protocol operations for each mode.

Peer Modes (Active and Passive)

Client/Server Modes Broadcast/Multicast Modes Manycast Mode

Burst Mode

Burst mode can be configured when the network attachment requires an initial calling or training procedure. Each poll initiates a burst of eight request messages at intervals randomized over the range 3-5 s. The reply messages update the clock filter, which then selects the best (most accurate) among them. When the last reply in the burst is sent, the next reply updates the client variables and system clock in the usual manner, as if only a single request/reply cycle had occurred. This mode does produce additional network overhead and can cause trouble if used indiscriminately. It should only be used where the poll interval is expected to settle at the upper limit, usually 1024 s.

Revised Error Checking

It is very important to avoid spurious mobilizations from possibly broken or rogue servers; in particular, to avoid denial-of-service attacks. In order to resist such attacks, arriving messages that might mobilize ephemeral associations are carefully screened using a series of eleven sanity checks.
  1. Duplicate packet. This message is a duplicate of one previously received.

  3. Bogus packet. This message did not result from a message previously sent, or messages have been received out of order.

  5. Unsynchronized. The server has not yet stored the previous timestamps.

  7. Invalid delay or dispersion. Either the delay or dispersion or both computed from the message timestamps are above the normal range.

  9. Authentication failed. The sent MAC does not match the received MAC, either due to the wrong key material or damaged message.

  11. Server unsynchronized. The server indicates unsynchronized in the leap bits included in the packet.

  13. Server stratum check. The server is operating at a stratum above the normal range.

  15. Delay/dispersion check. The related server packet data values are above the normal range.

  17. Autokey failed. The hash of the current session key does not match the most recent key identifiers used. (The hash is repeated four times, in order to recover from lost packets whenever possible.)

  19. Access denied. The sender has been blocked by the access control list.

  21. Key not found. The key identifier does not match any identifier in the key list or the key has expired or been revoked.
Failure to pass tests 5-11 is sufficient evidence to discard the packet without forming an association. However, failure to pass tests 1-4 is not necessarily grounds to reject the packet, since subsequent packets may be acceptable. In this case, the association is mobilized, but only the packet timestamps are stored. For the moment, and until the cryptographic signature algorithm is available, test 9 is temporarily disabled.

David L. Mills (