<HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]"> <TITLE>Release Notes </TITLE> </HEAD> <BODY> <H3> Association Management</H3> <HR> <H4> Association Modes</H4> 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.. <P>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. <P>The one exception to (a) and (b) above is when <TT><A HREF="authopt.htm">autokey</A></TT> 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. <P>Following is a summary of the protocol operations for each mode. <P>Peer Modes (Active and Passive) <UL>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.</UL> Client/Server Modes <UL>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.</UL> Broadcast/Multicast Modes <UL>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.</UL> Manycast Mode <UL>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.</UL> <H4> Burst Mode</H4> 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 to values above 1024 s. <H4> Revised Error Checking</H4> 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. <OL> <LI> Duplicate packet. This message is a duplicate of one previously received.</LI> <BR> <LI> Bogus packet. This message did not result from a message previously sent, or messages have been received out of order.</LI> <BR> <LI> Unsynchronized. The server has not yet stored the previous timestamps.</LI> <BR> <LI> Invalid delay or dispersion. Either the delay or dispersion or both computed from the message timestamps are above the normal range.</LI> <BR> <LI> Authentication failed. The sent MAC does not match the received MAC, either due to the wrong key material or damaged message.</LI> <BR> <LI> Server unsynchronized. The server indicates unsynchronized in the leap bits included in the packet.</LI> <BR> <LI> Server stratum check. The server is operating at a stratum above the normal range.</LI> <BR> <LI> Delay/dispersion check. The related server packet data values are above the normal range.</LI> <BR> <LI> 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.)</LI> <BR> <LI> Access denied. The sender has been blocked by the access control list.</LI> <BR> <LI> Key not found. The key identifier does not match any identifier in the key list or the key has expired or been revoked.</LI> </OL> 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. <BR> <HR> <ADDRESS> David L. Mills (mills@udel.edu)</ADDRESS> <BR> </BODY> </HTML>