= Automatic Server Discovery Schemes =

[cols="10%,90%",frame="none",grid="none",style="verse"]
|==============================
|image:pic/alice51.gif[]|
{millshome}pictures.html[from 'Alice's Adventures in Wonderland', Lewis Carroll]

Make sure who your friends are.

|==============================

== Related Links ==

include::includes/hand.txt[]

== Table of Contents ==

* link:#assoc[Association Management]
* link:#bcst[Broadcast/Multicast Scheme]
* link:#mcst[Manycast Scheme]
* link:#pool[Server Pool Scheme]

'''''

[[modes]]
== Introduction ==

This page describes the automatic server discovery schemes provided in
NTPv4. There are three automatic server discovery schemes: broadcast,
manycast, and server pool; which are described on this page. The
broadcast scheme utilizes the ubiquitous broadcast or one-to-many
paradigm native to IPv4 and IPv6.  The manycast scheme is similar
to specifying to broadcast, but the servers listen on a specific
address known to the client.  The server pool scheme uses DNS to resolve
addresses of multiple volunteer servers scattered throughout the world.

All three schemes work in much the same way and might be described as
_grab-n'-prune._ Through one means or another they grab a number of
associations either directly or indirectly from the configuration file,
order them from best to worst according to the NTP mitigation
algorithms, and prune the surplus associations.

[[assoc]]
== Association Management ==

All schemes use an iterated process to discover new preemptable client
associations as long as the total number of client associations is less
than the +maxclock+ option of the +tos+ command. The +maxclock+ default
is 10, but it should be changed in typical configuration to some lower
number, usually two greater than the +minclock+ option of the same
command.

All schemes use a stratum filter to select just those servers with
stratum considered useful. This can avoid large numbers of clients
ganging up on a small number of low-stratum servers and avoid servers
below or above specified stratum levels. By default, servers of all
strata are acceptable; however, the +tos+ command can be used to
restrict the acceptable range from the +floor+ option, inclusive, to the
+ceiling+ option, exclusive. Potential servers operating at the same
stratum as the client will be avoided.  Additional filters can be
supplied using the methods described on the
link:authentic.html[Authentication Support] page.

The pruning process uses a set of unreach counters, one for each
association created by the configuration or discovery processes. At each
poll interval, the counter is increased by one. If an acceptable packet
arrives for a persistent (configured) or ephemeral (broadcast)
association, the counter is set to zero. If an acceptable packet arrives
for a preemptable (manycast, pool) association and survives the
selection and clustering algorithms, the counter is set to zero. If the
the counter reaches an arbitrary threshold of 10, the association
becomes a candidate for pruning.

The pruning algorithm is very simple. If an ephemeral or preemptable
association becomes a candidate for pruning, it is immediately
demobilized. If a persistent association becomes a candidate for
pruning, it is not demobilized, but its poll interval is set at the
maximum. The pruning algorithm design avoids needless discovery/prune
cycles for associations that wander in and out of the survivor list, but
otherwise have similar characteristics.

Following is a summary of each scheme. Note that reference to option
applies to the commands described on the link:confopt.html[Configuration
Options] page. See that page for applicability and defaults.

[[bcst]]
== Broadcast/Multicast Scheme ==

The broadcast/multicast scheme is deprecated in NTPsec due to
irreparable security flaws. Client-side support has been removed.
Server-side support for broadcast only remains present but may be
removed in a future version, and its use is strongly discouraged.

A broadcast server generates messages continuously at intervals by
default 64 s and time-to-live by default 127. These defaults can be
overridden by the +minpoll+ and +ttl+ options, respectively. Not all
kernels support the +ttl+ option. A broadcast client responds to the
first message received by waiting a randomized interval to avoid
implosion at the server. It then polls the server in client/server mode
using the +iburst+ option in order to quickly authenticate the server,
calibrate the propagation delay and set the client clock. This normally
results in a volley of six client/server exchanges at 2-s intervals
during which both the synchronization and cryptographic protocols run
concurrently.

If for some reason the broadcast server does not
respond to these messages, the client will cease transmission and
continue in listen-only mode with a default propagation delay. The
volley can be avoided by using the +broadcastdelay+ command with nonzero
argument.

Following the volley, the server continues in listen-only mode and sends
no further messages for this association.

A server is configured in broadcast mode using the +broadcast+ command
and specifying the broadcast address of a local interface. If two or
more local interfaces are installed with different broadcast addresses,
a +broadcast+ command is needed for each address. This provides a way to
limit exposure in a firewall, for example.

NTPsec permits the use of symmetric authentication with broadcast mode
the same way as any other mode; however, it is not effective at
providing security because the sessionless, one-way nature of the
protocol makes detection of replayed or delayed packets
impossible. Regardless of whether authentication is employed,
broadcast mode must be used only on physically-secure networks where
all systems on the subnet are fully trusted.

[[mcst]]
== Manycast Scheme ==

Note: This mode of operation is deprecated, because manycast
associations cannot be effectively secured.  Accordingly, manycast
client support has been removed from NTPsec; manycast server mode is
retained for backwards compatibility but may be removed in a future
release.

Manycast is an automatic server discovery and configuration paradigm.
It is intended as a means for a client to troll the nearby network
neighborhood (not necessarily on the same link, where broadcast
would work), to find cooperating servers, validate them using
cryptographic means and evaluate their time values with respect to
other servers that might be lurking in the vicinity. It uses the
grab-n'-drop paradigm with the additional feature that active means
are used to grab additional servers should the number of associations
fall below the +maxclock+ option of the +tos+ command. The intended
result is that each manycast client mobilizes client associations with
some number of the "best" of the nearby manycast servers, yet
automatically reconfigures to sustain this number of servers should
one or another fail.

The manycast paradigm is not the anycast paradigm described in RFC 1546,
which is designed to find a single server from a clique of servers
providing the same service. The manycast paradigm is designed to find a
plurality of redundant servers satisfying defined optimality criteria.

Manycasting can be used with symmetric-key cryptography.

A manycast server is configured using the +manycastserver+ command,
which listens on the specified address for manycast client
messages.  If a manycast server is in scope of the current TTL and is
itself synchronized to a valid source and operating at a stratum level
equal to or lower than the manycast client, it replies with an ordinary
unicast server message.

[[pool]]
== Server Pool Scheme ==

The idea of targeting servers on a random basis to distribute and
balance the load is not a new one; however, the
http://www.pool.ntp.org/en/use.html[NTP Pool Project] puts
this on steroids. At present, several thousand operators around the
globe have volunteered their servers for public access. In general,
NTP is a lightweight service and servers used for other purposes don't
mind an additional small load. The trick is to randomize over the
population and minimize the load on any one server while retaining the
advantages of multiple servers using the NTP mitigation algorithms.

To support this service, custom DNS software is used by pool.ntp.org
and its subdomains to discover a random selection of participating
(in-country) servers in response to a DNS query. The client receiving
this list mobilizes some or all of them, similar to the manycast
discovery scheme, and prunes the excess. Cryptographic authentication
is not required.

The pool scheme is configured using one or more +pool+ commands with DNS
names indicating the pool from which to draw. The +pool+ command can be
used more than once; duplicate servers are detected and discarded. In
principle, it is possible to use a configuration file containing a
single line +pool   pool.ntp.org+. The NTP Pool Project offers
instructions on using the pool with the +server+ command, which is
suboptimal but works with older versions of +ntpd+ predating the +pool+
command.  Use of the +server+ command does a one-time DNS lookup, and
uses the IP address returned thereafter.  If the server becomes unavailable,
the DNS will not be re-resolved.  The +pool+ command will
use multiple servers that the DNS resolves to, refreshing as required.

'''''

include::includes/footer.txt[]
