+* Documentation updates from Dave Mills.
(4.2.7p47) 2010/09/11 Released by Harlan Stenn <stenn@ntp.org>
* Documentation updates from Dave Mills.
* [Bug 1588] finish configure --disable-autokey implementation.
<style type="text/css">
<!--
<style1 {
- color: #FF0000;
+color: #FF0000;
font-weight: bold;
}
+-->
</style>
</head>
<body>
<img src="pic/pogo6.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>The skunk watches for intruders and sprays.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->09-Sep-2010 23:54<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 16:55<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<p>Unless noted otherwise, further information about these ccommands is on the <a href="accopt.html">Access Control Support</a> page.</p>
<dl>
<dt id="discard"><tt>discard [ average <i>avg</i> ][ minimum <i>min</i> ] [ monitor <i>prob</i> ]</tt></dt>
- <dd>Set the parameters of the rate control facility which protects the server from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets that violate these limits are discarded. If, in addition, the <tt>kod</tt> flag is present, a kiss-o'-death packet is returned. See the <a href="rate.html">Rate Management</a> page for further information.
- The options are:
+ <dd>Set the parameters of the rate control facility which protects the server from client abuse. If the <tt>limited</tt> flag is present in the ACL, packets that violate these limits are discarded. If, in addition, the <tt>kod</tt> flag is present, a kiss-o'-death packet is returned. See the <a href="rate.html">Rate Management</a> page for further information. The options are:
<dl>
<dt><tt>average <i>avg</i></tt></dt>
<dd>Specify the minimum average interpacket spacing (minimum average headway
time) in log<sub>2</sub> s with default 3.</dd>
<dt><tt>minimum <i>min</i></tt></dt>
- <dd>Specify the minimum interpacket spacing (guard time) in seconds with default 1.</dd>
+ <dd>Specify the minimum interpacket spacing (guard time) in seconds with default 2.</dd>
<dt><tt>monitor</tt></dt>
<dd>Specify the probability of being recorded for packets that overflow the MRU list size limit set by <tt>mru maxmem</tt> or <tt>mru maxdepth</tt>. This is a performance optimization for servers with aggregate arrivals of 1000 packets per second or more.</dd>
</dl>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->09-Sep-2010 16:39<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 19:15<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<ul>
<li class="inline"><a href="#auth">Introduction</a></li>
<li class="inline"><a href="#symm">Symmetric Key Cryptography</a></li>
+ <li class="inline"><a href="#windows">Microsoft Windows Authentication</a></li>
<li class="inline"><a href="#pub">Public Key Cryptography</a></li>
</ul>
<hr>
<h4 id="auth">Introduction</h4>
<p>This page describes the various cryptographic authentication provisions in NTPv4. Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server.</p>
-<p> The NTPv3 specification RFC-1305 defines a scheme properly described as symmetric key cryptography. It uses the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same key and key identifier as the server. If the OpenSSL cryptographic library is installed, support is available for all message digest algorithms included in the library. Note however, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms is available.</p>
-<p>NTPv4 includes the symmetric key scheme and iin addition a new scheme based on public key cryptography and called Autokey. Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
-<p>While the algorithms for MD5 symmetric key cryptography are included in the NTPv4 software distribution, modern algorithms for symmetric key and public key cryptograpny requires the OpenSSL software library to be installed before building the NTP distribution. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines
- required.</p>
+<p> The NTPv3 specification RFC-1305 defines a scheme properly described as symmetric key cryptography. It uses the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same key and key identifier as the server. The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported..</p>
+<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1. However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines
+required.</p>
+<p>In addition to the symmetric key algorithms, this distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built. Public key cryptography is generally more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page, and the options described on this page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
+<p>By default, authentication is required only for those packets that might require significant resources, such as broadcast, symmetric active or manycast server packets, as these represent a potential clogging vulnerability. In the current climate of targeted broadcast or "letterbomb" attacks, defeating this requirement would be decidedly dangerous. However, it can be defeated using the <tt>disable auth</tt> command. Authentication is also an access control option using the <tt>restric</tt> command and the <tt>notrust</tt> flag.</p>
<h4 id="symm">Symmetric Key Cryptography</h4>
-<p>The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key, key ID and key type to authenticate NTP packets. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key. Note that for historic reasons the message digest algorithm is not consistent with RFC-1828. The digest is computed directly from the concatenation of the key string followed by the packet contents with the exception of the MAC itself.</p>
-<p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor. The program generates pseudo-random keys, one key for each line. Each line consists of three fields, the key identifier as a decimal number from 1 to 65534 inclusive, a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command, and a 20-character printable ASCII string or a 40-character hex string as the key itself.</p>
+<p>The original RFC-1305 specification allows any one of possibly 65,534 keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key, key ID and key type to authenticate NTP packets. If an NTP packet includes a message authentication code (MAC), consisting of a key ID and message digest, it is accepted only if the key ID matches a trusted key and the message digest is verified with this key. The digest is computed directly from the concatenation of the key string followed by the packet contents with the exception of the MAC itself.</p>
+<p>Keys and related information are specified in a keys file, usually called <tt>ntp.keys</tt>, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor. The program generates pseudo-random keys, one key for each line. Each line consists of three fields, the key identifier as a decimal number from 1 to 65,534 inclusive, a key type chosen from the keywords of the <tt>digest</tt> option of the <tt>crypto</tt> command, and a 20-character printable ASCII string or a 40-character hex string as the key itself.</p>
<p>When <tt>ntpd</tt> is first started, it reads the key file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
-<p>By default, the message digest algorithm is MD5 selected by the key type <tt>M</tt> in the keys file. However, if the OpenSSL library is installed, any message digest algorithm supported by that library can be used. The key type is selected as the algorithm name given in the OpenSSL documentation. The key type is associated with the key and can be different for different keys. The server and client must share the same key, key ID and key type and both must be trusted. Note that if conformance to FIPS 140-2 is required, the message digest algorithm must conform to the Secure Hash Standard (SHS), which requires an algorithm from the Secure Hash Algorithm (SHA) family, and the digital signature encryption algorithm, if used, must conform to the Digital Signature Standard (DSS), which requires the Digital Signature Algorithm (DSA).</p>
+<h4 id="windows">Microsoft Windows Authentication</h4>
<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="authopt.html">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
<h4 id="pub">Public Key Cryptography</h4>
<p>See the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
<img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
<p>Our resident cryptographer; now you see him, now you don't.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->10-Sep-2010 0:05<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 15:56<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
lowest 120 key IDs which start with the digit 1. The spaces
surrounding the ellipsis are required when specifying a range.</dd>
</dl>
-</dl>
<hr>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
<body>
<h3>Autokey Public-Key Authentication</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->06-Sep-2010 18:02<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 19:19<!-- #EndDate -->
UTC</p>
<hr>
<h4>Table of Contents</h4>
</ul>
<hr>
<h4 id="pub">Introduction</h4>
-<p>NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
+<p>This distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built. Public key cryptography is generally more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
+<p> The Autokey Version 2 protocol described on the <a href="http://www.eecis.udel.edu/%7emills/proto.html">Autokey Protocol</a> page verifies packet integrity using MD5 message digests and verifies the source using digital signatures and any of several digest/signature schemes. Optional identity schemes described on the <a href="http://www.eecis.udel.edu/~mills/ident.html">Autokey Identity Schemes</a> page are based on cryptographic challenge/response exchanges. These schemes provide strong security against replay with or without message modification, spoofing, masquerade and most forms of clogging attacks. These schemes are described along with an executive summary, current status, briefing slides and reading list on the <a href="http://www.eecis.udel.edu/~mills/autokey.html">Autonomous Authentication</a> page.</p>
<p>Autokey authenticates individual packets using cookies bound to the IP source and destination addresses. The cookies must have the same addresses at both the server and client. For this reason operation with network address translation schemes is not possible. This reflects the intended robust security model where government and corporate NTP servers are operated outside firewall perimeters.</p>
<p>There are three timeouts associated with the Autokey scheme. The key list timeout, which defaults to about 1.1 h, specifies the interval between generating new key lists. The revoke timeout, which defaults to about 36 h, specifies the interval between generating new private values. The restart timeout, with default about 5 d, specifies the interval between protocol restarts to refresh public values. In general, the behavior when these timeouts expire is not affected by the issues discussed on this page.</p>
<h4 id="group">NTP Secure Groups</h4>
<img src="pic/barnstable.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html"><i>P.T. Bridgeport Bear</i>; from <i>Pogo</i>, Walt Kelly</a>
<p>Pleased to meet you.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->06-Sep-2010 20:10<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 21:04<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<h4>Table of Contents</h4>
<ul>
<li class="inline"><a href="#intro">Introduction</a></li>
- <li class="inline"><a href="#conf">The Handbook</a></li>
+ <li class="inline"><a href="#hand">The Handbook</a></li>
<li class="inline"><a href="#build">Building and Installing NTP</a></li>
-<li class="inline"><a href="#prob">Resolving Problems</a></li>
+
<li class="inline"><a href="#prob">Resolving Problems</a></li>
<li class="inline"><a href="#info">Further Information</a></li>
</ul>
<hr>
<dl>
<dd>It is very important that readers understand that the NTP document collection began 25 years ago and remains today a work in progress. It has evolved as new features were invented and old features retired. It has been widely copied, cached and morphed to other formats, including man pages, with varying loss of fidelity. However, these HTML pages are the ONLY authoritative and definitive reference. Readers should always use the collection that comes with the distribution they use. A copy of the online collection at <a href="http://www.ntp.org">www.ntp.org</a> is normally included in the most recent snapshot, but might not agree with an earlier snapshot or release version.</dd>
</dl>
-<p>The Network Time Protocol (NTP) is widely used to synchronize a computer
- to Internet time servers or other sources, such as a radio or satellite
- receiver or telephone modem service. It can also be used as a server
- for dependent clients. It provides accuracies typically less than
- a millisecond on LANs and up to a few milliseconds on WANs. Typical
- NTP configurations utilize multiple redundant servers and diverse
- network paths in order to achieve high accuracy and reliability.
- Authentication is provided using symmetric key cryptography and
- the MD5 message digest algorithm included in the distribution. If
- the OpenSSL cryptographic library is installed, the SHA or SHA1 message
- digest algorithms can be used. If the OpenSSL library is installed,
- additional options based on public key cryptography are available.</p>
-<p>NTP time synchronization services are widely available in the public Internet.
- The public NTP subnet in late 2010 includes several thousand servers
- in most countries and on every continent of the globe, including Antarctica.
- These servers support a total population estimated at over 25 million computers
- in the global Internet. The NTP subnet operates with a hierarchy of levels,
- where each level is assigned a number called the stratum. Stratum 1 (primary)
- servers at the lowest level are directly synchronized to national time services.
- Stratum 2 (secondary) servers at the next higher level are synchronize to stratum
- 1 servers and so on. Normally, NTP clients and servers with a relatively small
- number of clients do not synchronize to public primary servers. There
- are several hundred public secondary servers operating at higher strata and
- are the preferred choice.</p>
-<p>This distribution includes a simulation framework in which substantially
- all the runtime NTP operations and most features can be tested and
- evaluated. This has been very useful in exploring in vitro response
- to unusual circumstances or over time periods impractical in vivo. Details
- are on the <a href="ntpdsim.html">Network
-Time Protocol (NTP) Simulator</a> page.</p>
-<h4 id="info2">The Handbook</h4>
+<p>This distribution is an implementation of RFC-5905 "Network Time Protocol Version 4: Protocol and Algorithms Specification".<br>
+ NTP is widely used to synchronize a computer to Internet time servers or other sources, such as a radio or satellite receiver or telephone modem service. It can also be used as a serverfor dependent clients. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.</p>
+<p>This distribution includes a simulation framework in which substantially all the runtime NTP operations and most features can be tested and evaluated. This has been very useful in exploring in vitro response to unusual circumstances or over time periods impractical in vivo. Details are on the <a href="ntpdsim.html">Network Time Protocol (NTP) Simulator</a> page.</p>
+<h4 id="hand">The Handbook</h4>
<p>A good deal of tutorial and directive information is availabl on the handbook pages. These should be read in conjunction with the command and opetion information available on the pages listed on the sitemap page.</p>
<dl>
<dt><a href="release.html">NTP Version 4 Release NotesVersion 4 Release Notes</a></dt>
<dd>Lists recent changes and new features in the current distribution.</dd>
<dt><a href="assoc.html">Association Management</a></dt>
<dd>Describes how to configure servers and peers and manage the various options. Includes automatic server discovery schemes.</dd>
- <dt><a href="discover.html">Automatic Server Discovery Schemes</a>
+ <dt><a href="discover.html">Automatic Server Discovery Schemes</a></dt>
<dd>Describes automatic ser very discovery using broadcast, multicast, manycast and server pool scheme.</dd>
<dt><a href="access.html">Access Control Support</a></dt>
<dd>Describes the access control mechanisms that can be used to limit client access to various time and management functions.</dd>
<img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"></a> from <i>Pogo</i>, Walt Kelly</a>
<p>Pig was hired to watch the logs.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->10-Sep-2010 0:29<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 16:32<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
These options are intended for remote configutation commands.</dd>
</dl>
</dd>
- <dt><tt>statsdir <i>directory_path</i></tt></dt>
+ <dt id="statsdir"><tt>statsdir <i>directory_path</i></tt></dt>
<dd>Specify the directory path prefix for statistics file names.</dd>
</dl>
<h4 id="types">File Set Types</h4>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Rate Management and the Kiss-o'-Death</title>
<link href="scripts/style.css" type="text/css" rel="stylesheet">
+<style type="text/css">
+<!--
+<style1 {
+color: #FF0000;
+ font-weight: bold;
+}
+-->
+</style>
</head>
<body>
<h3>Rate Management and the Kiss-o'-Death Packet</h3>
<img src="pic/boom4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
<p>Our junior managers and the administrators.</p>
<p>Last update:
- <!-- #BeginDate format:En2m -->09-Sep-2010 20:49<!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 16:52<!-- #EndDate -->
UTC</p>
<br clear="left">
<h4>Related Links</h4>
<h4 id="guard">Guard Time</h4>
<p>Guard time is the minimum time between successive packets. By default this is 2 s, but can be changed using the <tt>minimum</tt> option of the <tt>discard</tt> command. By design, this is also the interval between packets sent using the <tt>burst</tt> and <tt>iburst</tt> options.</p>
<p>A review of past client abuse incidence shows the most frequent scenario is a broken client that attempts to send a number of packets at rates of one per second or more. On one occasion due to a defective client design, over 750,000 clients fell into this mode. There have been occasions where this abuse has persisted for days at a time. These scenarios are the most damaging, as they can threaten not only the victim server but the network infrastructure as well.</p>
-<p>In the <tt>ntpd</tt> design the minimum headway between the last packet received and the current packet is called the guard time. If the headway is less than the guard time, the packet is discarded. The guard time defaults to 2 s, but this can be changed using the <tt>minimum</tt> option of the <a href="acccopt.html#discard"><tt>discard</tt></a> command.</p>
+<p>In the <tt>ntpd</tt> design the minimum headway between the last packet received and the current packet is called the guard time. If the headway is less than the guard time, the packet is discarded. The guard time defaults to 2 s, but this can be changed using the <tt>minimum</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command.</p>
<h4 id="mah">Average Headway Time</h4>
<p>There are two features in <tt>ntpd</tt> to manage the interval between one packet and the next. These features make use of a set of counters: a client output counter for each association and a server input counter for each distinct client address. Each counter increments by a value called the headway when a packet is processed and decrements by one each second. The default minimum average headway in <tt>ntpd</tt> is 8 s, but this can be changed using the <tt>average</tt> option of the <a href="accopt.html#discard"><tt>discard</tt></a> command, but not less than 3 (8 s).</p>
<p>If the <tt>iburst</tt> or <tt>burst</tt> options are present, the poll algorithm sends a burst of packets instead of a single packet at each poll opportunity. The NTPv4 specification requires that bursts contain no more than eight packets; so, starting from an output counter value of zero, the maximum counter value or output ceiling can be no more than eight times the minimum poll interval set by the <tt>minpoll</tt> option of the <a href="confopt.html#server"><tt>server</tt></a> command. However, if the burst starts with a counter value other than zero, there is a potential to exceed the ceiling. The poll algorithm avoids this by computing an additional headway time so that the next packet sent will not exceed the ceiling. Additional headway time can result from Autokey protocol operations. Designs such as this are often called leaky buckets. The current headway is displayed as the headway peer variable by the <tt>ntpq</tt> <a href="ntpq.html#pe"><tt>rv</tt></a> command.</p>
document.write("<p>Miscellaneous Commands and Options</p><ul>\
<li class='inline'><a href='miscopt.html#broadcastdelay'>broadcastdelay - specify broadcast delay</a></li>\
-<li class='inline'><a href='miscopt.html#discard'>discard - specify minimum guard time and average headway</a></li>\
<li class='inline'><a href='miscopt.html#driftfile'>driftfile - specify frequency file</a></li>\
<li class='inline'><a href='miscopt.html#enable'>enable - enable options</a></li>\
<li class='inline'><a href='miscopt.html#enable'>disable - disable options</a></li>\
<body>
<h3>How NTP Works</h3>
<p>Last update:
- <!-- #BeginDate format:En2m -->
- 08-Sep-2010 21:25
- <!-- #EndDate -->
+ <!-- #BeginDate format:En2m -->11-Sep-2010 17:51<!-- #EndDate -->
UTC</p>
+<h4>Table of Contents</h4>
+<ul>
+ <li class="inline"><a href="#intro">Introduction</a></li>
+ <li class="inline"><a href="#ntp">NTP Daemon Architecture and Basic Operation</a></li>
+ <li class="inline"><a href="#stats">How Statistics are Determined</a></li>
+ <li class="inline"><a href="#clock">Clock Discipline Algorithm</a></li>
+</ul>
<hr>
+<h4 id="intro">Introduction</h4>
+<p>NTP time synchronization services are widely available in the public Internet. The public NTP subnet in late 2010 includes several thousand servers in most countries and on every continent of the globe, including Antarctica, and sometimes in space and on the sea floor. These servers support a total population estimated at over 25 million computers in the global Internet.</p>
+<p> The NTP subnet operates with a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services. Stratum 2 (secondary) servers at the next higher level are synchronize to stratum 1 servers and so on. Normally, NTP clients and servers with a relatively small number of clients do not synchronize to public primary servers. There are several hundred public secondary servers operating at higher strata and are the preferred choice.</p>
+<p>This page preetns an overview of the NTP daemon included in this distribution. We refer to this as the reference implementation only because it was the one used to test and validate the NTPv4 specificatioin RFC-5905. It is best read in conjunction with the briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">Network Time Synchronization Research Project</a> page.</p>
<div align="center">
<p><img src="pic/fig_3_1.gif" alt="gif"></p>
- <p>Figure 1. NTP Host Processes and Algorithms</p>
+ <p>Figure 1. NTP Daemon Processes and Algorithms</p>
</div>
-<h4>NTP Host Architecture and Basic Operation</h4>
+<h4 id="ntp">NTP Daemon Architecture and Basic Operation</h4>
<p>The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of downstatum servers and as a server for upstratum clients. It includes a pair of peer/poll processes for each reference clock or remote server used as a synchronization source. The poll process sends NTP packets at intervals ranging from 8 s to 36 h. The peer process receives NTP packets and runs the on-wire protocol that collects four timestamps: the <em>origin timestamp</em> <em>T</em><sub>1</sub> upon departure of the client request and the <em>receive timestamp</em> <em>T</em><sub>2</sub> upon arrival at the server, the <em>transmit timestamp</em> <em>T</em><sub>3</sub> upon departure of the server reply and the <em>destination timestamp</em> <em>T</em><sub>4</sub> upon arrival at the client. These timestamps are used to calculate the clock offset and roundtrip delay:</p>
<div align="center">
<p>offset = [(<em>T</em><sub>2</sub> -<em>T</em><sub>1</sub>) + (<em>T</em><sub>3</sub> - <em>T</em><sub>4</sub>)] / 2<br>
</div>
<p>Those sources that have passed a number of sanity checks are declared <em>selectable</em>. From the selectable population the statistics are used by the select algorithm to determine a number of <em>truechimers</em> according to correctness principles. From the truechimer population a number of <em>survivors</em> are determined on the basis of statistical principles. One of the survivors is declared the <em>system peer</em> and the system statistics inherited from it. The combine algorithm computes a weighted average of the peer offset and jitter to produce the final values used by the clock discipline algorithm to adjust the system clock time and frequency.</p>
<p> When started, the program requires several measurements sufficient data fro these a algorithms to work properly before setting the clock. As the default poll interval is 64 s, it can take several minutes to set the clock. The time can be reduced using the <tt>iburst</tt> option on the <a href="confopt.html">Server Options</a> page. For additional details about the clock filter, select, cluster and combine algorithms see the Architecture Briefing on the NTP Project Page.</p>
-<h4>How Statistics are Determined</h4>
+<h4 id="stats">How Statistics are Determined</h4>
<p>Each source is characterized by the offset and delay measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm of the peer process. Each time an NTP packet is received from a source, the dispersion is initialized by the sum of the precisions of the server and client. The offset, delay and dispersion values are inserted as the youngest stage of an 8-stage shift register, thus discarding the oldest stage. Subsequently, the dispersion in each stage is increased at a fixed rate of 15 <font face="symbol">m</font>s/s, representing the worst case error due to skew between the server and client clocks. The clock filter algorithm in each peer process selects the stage with the lowest delay, which generally represents the most accurate values, and the associated offset and delay values become the peer variables of the same name. The peer dispersion continues to grow at the same rate as the register dispersion. The peer dispersion is determined as a weighted average of the dispersion samples in the shift register. Finally, the peer jitter is determined as the root-mean-square (RMS) average of all the offset samples in the shift register relative to the selected sample. </p>
<p> The clock filter algorithm continues to process packets in this way until the source is no longer reachable. In this case the algorithm inserts dummy samples with "infinite" dispersion are inserted in the shift register, thus displacing old samples.</p>
<p>The composition of the survivor population and the system peer selection is redetermined as each update from each server is received. The system variables are copied from the peer variables of the same name and the system stratum set one greater than the system peer stratum. Like peer dispersion, the system dispersion increases at the same rate so, even if all sources have become unreachable, the daemon appears to upstratum clients at ever increasing dispersion.</p>
<p>Of interest in this discussion is how an NTP client determines if a server is reachable and suitable as a source of synchronization. Reachability is determined by an 8-bit shift register, which is shifted left by one bit as each poll message is sent, with zero replacing the vacated rightmost bit. Each time an update is received the rightmost bit is set. The source is considered reachable if any bit is set in the register; otherwise, it is considered unreachable. The peer dispersion is used as a filter to determine whether a source is usable or not. If the server is unreachable or the dispersion exceeds the select threshold threshold (1.5 s by default), it is not selectable to synchronize the system clock.</p>
<p>The quality of time service is determined by a quantity called the <em>synchronization distance.</em> It is computed as one-half the <em>root delay</em> to the primary source of time; i.e., the primary reference clock, plus the <em>root dispersion</em>. The root root delay and root dispersion are included in the NTP packet header. The client adds the current system peer delay and dispersion to the corresponding root values and saves them in its own system variables which are passed on to dependent clients. Like peer dispersion, the root dispersion increases at the same rate.</p>
<p>Although it might seem counterintuitive, a cardinal rule in the selection processes is, once a sample has been selected by the clock filter algorithm, that sample and any older samples are no longer selectable. This applies also to the select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. This means that not every sample can be used to update the peer variables and up to seven samples can be ignored between selected samples. This fact has been carefully considered in the discipline algorithm design with due consideration of the feedback loop delay and minimum sampling rate. In engineering terms, even if only one sample in eight survives, the resulting sample rate is twice the Nyquist rate at any time constant and poll interval.</p>
-<h4>Clock Discipline Algorithm</h4>
+<h4 id="clock">Clock Discipline Algorithm</h4>
<p>At the heart of the NTP host is the clock discipline algorithm, which is best described as a hybrid phase/frequency-lock feedback loop. In the NTP reference implementation, it is an intricately crafted algorithm that automatically adapts for optimum performance while minimizing network overhead. Its response is determined by the <em>time constant</em>, which results in a "stiffness" depending on the jitter of the available sources and the stability of the system clock oscillator. The time constant is also used as the poll interval by the poll processes. However, in NTP symmetric mode, each peer manages its own poll interval and the two might not be the same. In such cases either peer uses the minimum of its own poll interval and that of the other peer, which is included in the NTP packet header.</p>
<p>It is important to understand how the dynamics of the discipline are affected by the poll interval. At an interval of 64 s and a step change of 100 ms, the time response crosses zero in about 50 minutes and overshoots about 7 ms, as per design. However, the step correction causes a temporary frequency change of about 5 PPM, which is slowly corrected within a few hours. The result is that the overshoot slowly subsides over the that interval. This is an intrinsic feature of a discipline loop that can minimize both time and frequency offset.</p>
<p>Since the discipline loop is linear, the response with different step sizes and poll intervals has the characteristic, but scaled differently in amplitude and time. The response scales exactly with step amplitude, so that the response to a 10-ms step has the same characteristic, but with amplitude one-tenth that with the 100-ms step. The response scales exactly with poll interval, so at a poll interval of 8 s the time response is the same as at 64 s, but at a time scale one-eighth that at 64 s.</p>
projects / thirdparty / ntp.git / commitdiff
