diff options
Diffstat (limited to 'contrib/ntp/html/assoc.htm')
| -rw-r--r-- | contrib/ntp/html/assoc.htm | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/contrib/ntp/html/assoc.htm b/contrib/ntp/html/assoc.htm new file mode 100644 index 0000000..69cb7bc --- /dev/null +++ b/contrib/ntp/html/assoc.htm @@ -0,0 +1,170 @@ +<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> |
