Association Management

Association Modes

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)

In these modes, two client/server peers agree to back each other up, should the synchronization source for either peer fail. One or both peers is configured in symmetric-active mode using the peer command. Alternatively, one - the active peer - is configured in this mode and the other, the passive peer, operates in symmetric-passive mode and requires no prior configuration. Both association scenarios operate in NTPv4 as in NTPv3; however, several bugs in the handling of keys and recovery of resources when an active peer fails, have been corrected in NTPv4. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv3 autokey scheme. Client/Server Modes

In these modes, a client sends a request to the server and expects a reply at some future time. The client is configured in client mode using the server (sic) command; the server requires no prior configuration. The original NTPv3 authentication scheme is applicable in this mode, as well as the new NTPv3 autokey scheme. Broadcast/Multicast Modes

In these modes, the server generates messages at intervals specified by the minpoll subcommand. When using IP multicast addresses, the scope of the multicast tree is specified by the ttl subcommand in hops. When using a local interface broadcast address, the scope is limited to the attached subnet. The client responds to the first message received by waiting an interval randomized over the minpoll interval, in order to avoid implosions. Then, it polls the server in burst mode, in order to accumulate data to reliably set the host clock. This normally results in eight client/server cycles over a 32-s interval. When the next multicast message is received, the client computes the offset between the system clock just set and the apparent time of the multicast message in order to correct the apparent time in future multicast messages. Manycast Mode

In this mode, a configured client broadcasts a request message as in client mode to a designated multicast group address. All servers configured as manycast clients and in ttl range respond with a server reply message. Each reply mobilizes a persistent client/server association as in client mode. Then, the NTP intersection and clustering algorithms act to discard all but the best of these associations, which then continue as in client/server mode.

Poll Interval Management

A major goal in the system design is to minimize network overhead without significant impairment in accuracy. Since each system clock update requires an exchange of messages with each of possibly several servers, the interval between these messages, the poll interval, must be carefully and automatically managed over a prescribed range in response to prevailing wander of the system clock oscillator and network jitter. The limits to this range are set by the minpoll and maxpoll variables described on the Configuration Options page. The default values (usually 64 s and 1024 s) should be changed only in very special circumstances and thorough understanding of the consequences.

Ordinarily, the daemon manages the poll interval automatically so that, most of the time the interval hovers near the maximum. However, under conditions of extreme network jitter or when the servers are intermittently unreachable, the poll interval may be reduced, in the extreme to the minimum. However, after some period when a server remains unreachable, the poll interval is increased in steps to the maximum. This protects the network against spurious traffic while continuing to probe for server reachability.

Burst mode can be configured when the network attachment requires an initial calling or training procedure and in cases where the first message sent after a considerable interval is lost or the network has moderate to high loss rate. 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 to values at or above 1024 s.

Each poll initiates a burst of either two or eight request messages. If the server is unreachable, 2 messages are sent; if reachable, 8 messages are sent. If no valid reply is received, the client waits for 16 s before sending the next request. This is to allow time to complete a dial-out modem or ISDN call. If a valid reply is received, the client waits for 2 s before sending the next request. Reply messages update the clock filter, but do not update the system clock until 2 s after the last request is sent.

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.

Duplicate packet. This message is a duplicate of one previously received.
Bogus packet. This message did not result from a message previously sent, or messages have been received out of order.
Unsynchronized. The server has not yet stored the previous timestamps.
Invalid delay or dispersion. Either the delay or dispersion or both computed from the message timestamps are above the normal range.
Authentication failed. The sent MAC does not match the received MAC, either due to the wrong key material or damaged message.
Server unsynchronized. The server indicates unsynchronized in the leap warning bits included in the packet.
Server stratum check. The server is operating at a stratum above the normal range.
Delay/dispersion check. The related server packet data values are above the normal range.
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.)
Access denied. The sender has been blocked by the access control list.
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 (mills@udel.edu)