freebsd-dev/contrib/ntp/html/assoc.htm
1999-12-09 13:01:21 +00:00

171 lines
7.5 KiB
HTML

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