171 lines
7.5 KiB
HTML
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>
|
|
<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>
|