From: Harlan Stenn Date: Tue, 10 May 2011 19:46:36 +0000 (-0400) Subject: Documentation updates from Dave Mills X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4be3f4242633cfae3bd3a22b01c06e3194b38b7e;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 4dc9961cQqY3tpI58C1cNtTJQNPdNQ --- diff --git a/ChangeLog b/ChangeLog index a02c763474..fee7a001cf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -17,6 +17,7 @@ each no_sys_peer event. This prevents a particular form of clock- hopping, such as using LOCAL briefly at startup before remote peers are selectable. This fixes the issue reported in [Bug 988]. +* Documentation updates from Dave Mills. (4.2.7p163) 2011/05/08 Released by Harlan Stenn * [Bug 1911] missing curly brace in libntp/ntp_rfc2553.c (4.2.7p162) 2011/05/03 Released by Harlan Stenn diff --git a/html/autokey.html b/html/autokey.html index b6157f93b4..93a9817e33 100644 --- a/html/autokey.html +++ b/html/autokey.html @@ -16,16 +16,19 @@

Autokey Public-Key Authentication

Last update: - 15-Jan-2011 21:26 + 11-Feb-2011 10:36 UTC

Table of Contents

Introduction

@@ -37,7 +40,7 @@

Autokey is designed to authenticate servers to clients, not the other way around as in SSH. An Autokey server can support an authentication scheme such as the Trusted Certificate (TC) scheme described in RFC 5905, while a client is free to choose between the various options. It is important to understand that these provisions are optional and that selection of which option is at the discretion of the client. If the client does not require authentication, it is free to ignore it, even if some other client of the same server elects to participate in either symmetric key or public key cryptography.

Autokey uses industry standard X.509 public certificates, which can be produced by commercial services, utility programs in the OpenSSL software library, and the ntp-keygen utility program in the NTP software distribution. A certificate includes the subject name of the client, the issuer name of the server, the public key of the client and the time period over which the the public and private keys are valid. All Autokey hosts have a self-signed certificate with the Autokey name as both the subject and issuer. During the protocol, additional certificates are produced with the Autokey host name as subject and the host that signs the certificate as issuer.

There are two timeouts associated with the Autokey scheme. The key list timeout is set by the automax command, which specifies the interval between generating new key lists by the client or server. The default timeout of about 1.1 hr is appropriate for the majority of configurations and ordinarily should not be changed. The revoke timeout is set by the revoke command, which specifies the interval between generating new server private values. It is intended to reduce the vulnerability to cryptanalysis; however, new values require the server to encrypt each client cookie separately. The default timeout of about 36 hr is appropriate for most servers, but might be too short for national time servers.

-

Autokey Subnets

+

Autokey Subnets

An Autokey subnet consists of a collection of hosts configured as an acyclic, directed tree with roots one or more trusted hosts (THs) operating at the lowest stratum of the subnet. Note that the requirement that the NTP subnet be acyclic means that, if two hosts are configured with each other in symmetric modes, each must be a TH. The THs are synchronized directly or indirectly to national time services via trusted means, such as radio, satellite or telephone modem, or one or more trusted agents (TAs) of a parent subnet. NTP subnets can be nested, with the THs of a child subnet configured for one or more TAs of a parent subnet. The TAs can serve one or more child subnets, each with its own security policy and set of THs.

A certificate trail is a sequence of certificates, each signed by a host one step closer to the THs and terminating at the self-signed certificate of a TH. The requirement that the subnet be acyclic means certificate trails can never loop. NTP servers operate as certificate authorities (CAs) to sign certificates provided by their clients. The CAs include the TAs of the parent subnet and those subnet servers with dependent clients.

In order for the signature to succeed, the client certificate valid period must begin within the valid period of the server certificate. If the server period begins later than the client period, the client certificate has expired; if the client period begins later than the server period, the server certificate has expired.

@@ -50,75 +53,56 @@

Figure 1 shows an example configuration with three NTP subnets, Alice, Helen and Carol. Alice and Helen are parent groups for Carol with TA C belonging to Alice and TA S belonging to Helen. Hosts A and B are THs of Alice, host R is the TH of Helen and host X is the TH of Carol. Assume that all associations are client/server, child subnet TH X has two mobilized associations, one to Alice TA host C and the other to Carol TA host S. While not shown in the figure, Alice hosts A and B could configure symmetric mode associations between them for redundancy and backup.

Note that host D certificate trail is D→C→A or D→C→B, depending on the particular order the trails are built. Host Y certificate trail is only Y→X, since X is a TH. Host X has two certificate trails X→C→A or X→C→B, and X→S→R.

-

Subnet Group Names

-

In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using subnet group names. An Autokey host name is specified by the -s option of the ntp-keygen program using the syntax host@group, where host is the host name and group is the optional subnet group name. If host is omitted, the host name defaults to the string returned by the Unix gethostname() routine. Thus, for host beauregard.udel.edu the option -s @red specifies the Autokey host name beauegard.udel.edu@red.

+

Subnet Group Names

+

In some configurations where more than one subnet shares an Ethernet or when multiple subnets exist in a manycast or pool configuration, it is useful to isolate one subnet from another. In Autokey this can be done using group names. An Autokey host name is specified by the -s host@group option of the ntp-keygen program, where host is the host name and group is the group name. If host is omitted, the name defaults to the string returned by the Unix gethostname() routine, ordinarily the DNS name of the host. Thus, for host beauregard.udel.edu the option -s @red specifies the Autokey host name beauegard.udel.edu@red.

A subnet host with a given group name will discard ASSOC packets from all subnets with a different group name. This effectively disables the Autokey protocol without additional packet overhead. For instance, one or more manycast or pool servers will not respond to ASSOC packets from subnets with difference group names. Groups sharing an Ethernet will be filtered in the same way.

-

However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the ident option of the crypto command and/or the ident option of the server command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the -s option of the ntp-keygen program.

-

NTP Secure Groups

+

However, as shown in Figure 1, there are configurations where a TH of one group needs to listen to a TA of a different group. This is accomplished using the ident group option of the crypto command and/or the ident group option of the server command. The former case applies to all hosts sharing a common broadcast, manycast or symmetric passive modes, while the latter case applies to each individual client/server or symmetric active mode association. In either case the host listens to the specified group name in addition to the group name specified in the -s option of the ntp-keygen program.

+

Secure Groups

NTP security groups are an extension of the NTP subnets described in the previous section. They include in addition to certificate trails one or another identity schemes described on the Autokey Identity Schemes page. NTP secure groups are used to define cryptographic compartments and security hierarchies. The identity scheme insures that the server is authentic and not victim of masquerade by an intruder acting as a middleman.

An NTP secure group is an NTP subnet configured as an acyclic tree rooted on the THs. The THs are at the lowest stratum of the secure group. They run an identity exchange with the TAs of parent subnets All group hosts construct an unbroken certificate trail from each host, possibly via intermediate hosts, and ending at a TH of that group. The TH verifies authenticity with the TA of the parent subnet using an identity exchange.

gif

Figure 2. Identify Scheme

-

The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, the identity exchange involves a challenge-response protocol where a client generates a nonce and sends to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.

+

The identity exchange is run between a TA acting as a server and a TH acting as a client. As shown in Figure 2, the identity exchange involves a challenge-response protocol where a client generates a nonce and sends it to the server. The server performs a mathematical operation involving a second nonce and the secret group key, and sends the result along with a hash to the client. The client performs a another mathematical operation and verifies the result with the hash.

Since each exchange involves two nonces, even after repeated observations of many exchanges, an intruder cannot learn the secret group key. It is this quality that allows the secret group key to persist long after the longest period of certificate validity. In the Schnorr (Identify Friend or Foe - IFF) scheme, the secret group key is not divulged to the clients, so they cannot conspire to prove identity to other hosts.

As described on the Autokey Identity Schemes page, there are five identity schemes, three of which - IFF, GQ and MV - require identity files specific to each scheme. There are two types of files for each scheme, an encrypted server keys file and a nonencrypted client keys file, also called the parameters file, which usually contains a subset of the keys file.

Figure 2 shows how keys and parameters are distributed to servers and clients. A TA constructs the encrypted keys file and the nonencrypted parameters file. Hosts with no dependent clients can retrieve client parameter files from an - archive or web page. The ntp-keygen program can export parameter files using the -e option. By convention, the file name is the name of the secure group and must match the ident command option and the ident option of the server command.

-

When more than one TH Is involved in the secure group, it is convenient for the TAs and THs to use the same files. To do this, one of the parent TAs includes the -i group option on the ntp-keygen command line, where group is the name of the child secure group. The ntp-keygen program can export server keys files - using the -q option and chosen remote password. The files are installed - on the TAs and then renamed using the name given as the first line in the file, but without - the filestamp. The secure group name must match the ident group option of the crypto command for all TAs.

+ archive or web page. The ntp-keygen program can export parameter files using the -e option. By convention, the file name is the name of the secure group and must match the ident option of the crypto command or the ident option of the server command.

+

When more than one TH Is involved in the secure group, it is convenient for the TAs and THs to use the same encrypted key files. To do this, one of the parent TAs includes the -i group option on the ntp-keygen command line, where group is the name of the child secure group. The ntp-keygen program can export server keys files using the -q option and a chosen remote password. The files are installed on the TAs and then renamed using the name given as the first line in the file, but without the filestamp. The secure group name must match the ident option for all TAs.

In the latest Autokey version, the host name and group name are independent of each other and the host option of the crypto command is deprecated. When compatibility with older versions is required, specify the same name for both the -s and -i options.

In special circumstances the Autokey message digest algorithm can be changed using the digest option of the crypto command. The digest algorithm is separate and distinct from the symmetric key message digest algorithm. If compliance with FIPS 140-2 is required, -the algorithm must be ether SHA or SHA1. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.

+ the algorithm must be ether SHA or SHA1. The Autokey message digest algorithm must be the same for all participants in the NTP subnet.

Example

-

Returning to the example of Figure 1, Alice, Helen and Carol run TC, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child group TH X. Both have the same encrypted keys file and X the common parameters file.

-

Configuration - Authentication Schemes

-

Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple. For each server, e.g. time.nist.gov, as root:

+

Returning to the example of Figure 1, Alice, Helen and Carol run run the Trusted Certificate (TC) scheme, internally, as the environment is secure and without threat from external attack, in particular a middleman masquerade. However, TH X of Carol is vulnerable to masquerade on the links between X and C and between X and S. Therefore, both parent subnet TAs C and S run an identity exchange with child subnet TH X. Both have the same encrypted keys file and X the common parameters file.

+

Configuration - Authentication Schemes

+

Autokey has an intimidating number of options, most of which are not necessary in typical scenarios. However, the Trusted Certificate (TC) scheme is recommended for national NTP time services, such as those operated by NIST and USNO. Configuration for TC is very simple.

+

Referring to Figure 1, for each TH, A, B, R and X, as root:

# cd /usr/local/etc
# ntp-keygen -T

-

This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. Include in the ntp.conf configuration file something like

-

# disable kernel
- # server 127.127.18.1 minpoll 12 maxpoll 17 # ACTS modem
- # phone atdt913035547785 atddt913034944774
+

and for the other hosts the same commands without the -T option. This generates an RSA private/public host key file and a self-signed certificate file for the RSA digital signature algorithm with the MD5 message digest algorithm. For the THs a trusted certificate is generated; for the others a nontreusted certificate is generated. Include in the ntp.conf configuration file for all hosts other than the primary servers, A, B and R, something like

+

# server host autokey
# crypto
# driftfile /etc/ntp.drift

-

Note the first three lines are specific to the ACTS driver and NIST modem telephone numbers. The second number will be tried if the first times out. Alternatively, any other reference clock can be used, or even another time server.

-

For each client, e.g. grundoon.udel.edu, as root:

-

# cd /usr/local/etc
- # ntp-keygen

-

(There is no -T option). Include in the ntp.conf configuration file something like

-

# server time.nist.gov iburst autokey
- # crypto
- # driftfile /etc/ntp.drift

-

It is possible to configure clients of server grundoon.udel.edu in the same way with the server line pointing to grundoon.udel.edu. Dependent clients authenticate to time.nistg.gov through grundoon.udel.edu.

-

In the above configuration examples, the default Autokey host name is the string returned by the Unix gethostname() library routine. However, this name has nothing to do with the DNS name of the host. The Autokey host name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys files. The Autokey host name can be changed using the -s option of the ntp-keygen program. The default password can be changed using the -p option of the ntp-keygen program and the pw option of the crypto command.

-

Configuration - Identity Schemes

-

The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. A parent subnet TA generates IFF identity files using an ntp-keygen program command with options specified in this section, while the child secure group TH uses the same program command with no options. Both the TA and TH use the crypto command with no options. In addition, the TH specifies options for the server and ident commands as described in this section.

-

It's best to start with a functioning TC configuration and add commands as necessary. For example, the TA generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the command

-

ntp-keygen -I.

-

Note the TA is not necessarily a trusted host, so may not need the -T option. The nonencrypted client parameters can be exported using the command

+

where host is the selected server name as shown in the figure. Servers A, B and R are configured for local reference clocks or trusted remoter servers as required.

+

In the above configuration examples, the default host name is the string returned by the Unix gethostname() routine, ordinarily the DNS name of the host. This name is used as the subject and issuer names on the certificate, as well as the default password for the encrypted keys file. The host name can be changed using the -s option of the ntp-keygen program. The default password can be changed using the -p option of the ntp-keygen program and the pw option of the crypto configuration command.

+

Group names can be added to this configuration by including the -s host@group option with the ntp-keygen program. For the purpose of illustration, the host string is empty, signifying the default host name. For example, @yellow can be used for the Alice group, @orange for the Helen group and @blue for the Carol group. In addition, for TH X the ident yellow option should be added to the server command for the Alice group and the ident orange option should be added to the server command for the Helen group.

+

Configuration - Identity Schemes

+

The example in this section uses the IFF identity scheme, but others, including GQ and MV, can be used as well. It's best to start with a functioning TC configuration and add commands as necessary. We start with the subnets of Figure 1 configured as in the previous section. Recall that the parent subnet TA for Alice is C and for Helen is S. Each of the TAs generates an encrypted server keys file and nonencrypted client parameters file for the IFF identity scheme using the -I option of the ntp-keygen program. Note the TAs are not necessarily trusted hosts, so may not need the -T option.

+

The nonencrypted client parameters can be exported using the command

ntp-keygen -e >file,

-

where the -e option redirects the client parameters to file via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command

+

where the -e option redirects the client parameters to file via the standard output stream for a mail application or stored locally for later distribution to one or more THs. In a similar fashion the encrypted keys file can be exported using the command

ntp-keygen -q passw2 >file,

-

where passwd2 is the read password for another TH. While the file name used for the client parameters file is arbitrary, it is common practice to use the subnet group name as described above, such as red. On the other hand, the file name used for the keys file must follow the conventions described on the ntp-keygen page. The encrypted server keys file is exported to other TAs that may serve the secure group, while the nonencrypted client parameters file can be distributed to all THs by nonsecure means.

-

To complete the configuration, the TH includes the client parameters file name as the ident option of the the server command for the TA association

+

where passwd2 is the read password for another TA. We won't need this file here.

+

While the file names used for the exported files are arbitrary, it is common practice to use the name given as the first line in the file with the filestamp suppressed. Thus, the nonencryted parameters file from each TA is copied to X with this name.

+

To complete the configuration, the TH includes the client parameters file name in the ident option of the the server command for the TA association

server 1.2.3.4 ident group,

-

where group is the chosen group name, in this case red. In addition, if operating as a broadcast/multicast client or a symmetric passive peer, the TH includes an ident command

-

ident group,

-

where group is the chosen group name, in this case red.

-

Identity Schemes and Cryptotypes

-

All configurations include a public/private host key pair and matching certificate. Absent an identity scheme, this is a Trusted Certificate (TC) scheme. There are three optional identity schemes, IFF, GQ and MV described on the Identity Schemes page. With these schemes all servers in the group have encrypted server identity keys, while clients have nonencrypted client identity parameters. The client parameters can be obtained from a trusted agent (TA), usually one of the THs of the lower stratum group. Further information on identity schemes is on the Autokey Identity Schemes page.

-

A specific combination of authentication and identity schemes is called a cryptotype, which applies to clients and servers separately. A group can be - configured using more than one cryptotype combination, although not all combinations - are interoperable. Note however that some cryptotype combinations may successfully - intemperate with each other, but may not represent good security practice. The - server and client cryptotypes are defined by the the following codes.

+

where group is the file name given above.

+

Identity Schemes and Cryptotypes

+

A specific combination of authentication and identity schemes is called a cryptotype, which applies to clients and servers separately. A group can be configured using more than one cryptotype combination, although not all combinations are interoperable. Note however that some cryptotype combinations may successfully intemperate with each other, but may not represent good security practice. The server and client cryptotypes are defined by the the following codes.

NONE
A client or server is type NONE if authentication is not available or not configured. Packets exchanged between client and server have no MAC.
@@ -221,7 +205,7 @@ the algorithm must be ether SHA or SHA1. The Autokey message d
115 protocol error
The protocol state machine has wedged due to unexpected restart.
-

Files

+

Files

See the ntp-keygen page. Note that provisions to load leap second values from the NIST files have been removed. These provisions are now available whether or not the OpenSSL library is available. However, the functions that can download these values from servers remains available.

diff --git a/html/drivers/driver6.html b/html/drivers/driver6.html index 31ccce38ce..9d93157d70 100644 --- a/html/drivers/driver6.html +++ b/html/drivers/driver6.html @@ -10,7 +10,7 @@

IRIG Audio Decoder

Author: David L. Mills (mills@udel.edu)
lart upsdate: - 03-Sep-2010 20:24 + 08-Mar-2011 2:24 UTC

Synopsis

@@ -53,7 +53,6 @@ The timecode format used for debugging and data recording includes data helpful
x40
Codec error (overrun). The machine is not fast enough to keep up with the codec.
x80
- ^
Device status error (Spectracom).

Fudge Factors

diff --git a/html/miscopt.html b/html/miscopt.html index 4686b2a60d..695f1f8bf2 100644 --- a/html/miscopt.html +++ b/html/miscopt.html @@ -10,7 +10,7 @@ giffrom Pogo, Walt Kelly

We have three, now looking for more.

Last update: - 11-Jan-2011 5:29 + 12-Feb-2011 6:22 UTC


Related Links

@@ -95,7 +95,7 @@
setvar variable [default]
This command adds an additional system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form name = value is followed by the default keyword, the variable will be listed as part of the default system variables (ntpq rv command). These additional variables serve informational purposes only. They are not related to the protocol other that they can be listed. The known protocol variables will always override any variables defined via the setvar mechanism. There are three special variables that contain the names of all variable of the same group. The sys_var_list holds the names of all system variables. The peer_var_list holds the names of all peer variables and the clock_var_list holds the names of the reference clock variables.
tinker [allan allan | dispersion dispersion | freq freq | huffpuff huffpuff | panic panic | step step | stepout stepout]
-
This command alters certain system variables used by the clock discipline algorithm. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. Thptie oons are as follows:
+
This command alters certain system variables used by the clock discipline algorithm. The default values of these variables have been carefully optimized for a wide range of network speeds and reliability expectations. Very rarely is it necessary to change the default values; but, some folks can't resist twisting the knobs. Options are are as follows:
allan allan
diff --git a/html/release.html b/html/release.html index d2e03af7f8..d78b0032f7 100644 --- a/html/release.html +++ b/html/release.html @@ -11,7 +11,7 @@ giffrom Alice's Adventures in Wonderland, Lewis Carroll

The rabbit toots to make sure you read this.

Last update: - 18-sep-10 3:29 + 25-feb-11 20:01 UTC


Related Links

@@ -26,23 +26,25 @@

NTP has been under development for almost 30 years, but the paint ain't dry even now. This release of the NTP Version 4 (NTPv4) distribution for Unix, VMS and Windows incorporates new features and refinements, but retaining backwards compatibility with older versions, including NTPv3 and NTPv2, but not NTPv1. Support for NTPv1 has been discontinued because of certain security vulnerabilities.

New Features

    -
  • The behavior of the daemon at startup has been considerably improved. The time to measure the frequency and correct an initial offset error when started fro the first time is now no more than ten minutes. Upon restart, it takes no more than five minutes to reduce the initial offset to less than one millisecond without adversely affecting the frequency. This avoids a subsequent frequency correction which could take up to several hours.
    • +
  • The behavior of the daemon at startup has been considerably improved. The time to measure the frequency and correct an initial offset error when started for the first time is now no more than ten minutes. Upon restart, it takes no more than five minutes to reduce the initial offset to less than one millisecond without adversely affecting the frequency. This avoids a subsequent frequency correction which could take up to several hours.
  • A new feature called interleaved mode can be used in NTP symmetric and broadcast modes. It is designed to improve accuracy - by minimizing errors due to queueing and transmission delays. It is described on the NTP + by minimizing errors due to queuing and transmission delays. It is described on the NTP Interleaved Modes page.
  • The huff-n'-puff filter is designed to avoid large errors with DSL circuits and highly asymmetrical traffic, as when downloading large files. Details are on the The Huff-n'-Puff Filter page.
    • -
  • A new feature called orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It provides relable backup in isolated networks or in pr when Internet sources have become unavaillable. See the Orphan Mode page for further information.
    • -
  • This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. There is support for the optional Kiss-o'- Death (KoD) packet intended to slow down an abusive client. See the Rate Management and the Kiss-o'-Death Packet page for further information.
    • +
  • A new feature called orphan mode provides an automatic, subnet-wide synchronization feature with multiple sources. It provides reliable backup in isolated networks or in pr when Internet sources have become unavailable. See the Orphan Mode page for further information.
    • +
  • This release includes comprehensive packet rate management tools to help reduce the level of spurious network traffic and protect the busiest servers from overload. There is support for the optional Kiss-o'-Death (KoD) packet intended to slow down an abusive client. See the Rate Management and the Kiss-o'-Death Packet page for further information.
  • There are two new burst mode features available where special conditions apply. One of these is enabled by the iburst keyword in the server configuration command. It is intended for cases where it is important to set the clock quickly when an association is first mobilized. The other is enabled by the burst keyword in the server configuration command. It is intended for cases where the network attachment requires an initial calling or training procedure. See the Association Management page for further information.
    • -
  • The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest routine have been removed from the base distribution. All 128- and 160- bit message digests routines are now supported for both symmetric key and public key cryptosystems. See the Authetication Support pagefor further information and the Authentication Options page for a list of supported digest algorithms.
    • -
  • This release includes support for Autokey public-key cryptography for authenticating public servers to clients, as described in RFC 5906. This support requires the --enabld-autokey option when building the distribution. Additional information about Autokey is on the Autokey Publid Key Authentication page and links from there.
    • +
  • The OpenSSL cryptographic library has replaced the library formerly available from RSA Laboratories. All cryptographic routines except a version of the MD5 message digest algorithm have been removed from the base distribution. All 128-bit and 160-bit message digests algorithms are now supported for both symmetric key and public key cryptosystems. See the Authentication Support page for further information and the Authentication Options page for a list of supported digest algorithms.
    • +
  • This release includes support for Autokey public-key cryptography for authenticating public servers to clients, as described in RFC 5906. This support requires the --enabld-autokey option when building the distribution. The deployment of Autokey subnets is now considerably simpler than in earlier versions. A subnet naming scheme is now available to filter manycast and pool configurations. Additional information about Autokey is on the Autokey Public Key Authentication page and links from there.
  • The NTP descrete even simulator has been substantially upgraded, now including scenarios with multiple servers and time-sensitive scripts. This allows the NTP algorithms to be tested in an embedded environment with systematic and pseudo-random network delay and oscillator wander distributions. This has been used to verify correct operation under conditions of extreme error and misconfiguration. See the ntpdsim - Network Time Protocol (NTP) simulator page. A technical description and performance analysis is given in the white papers at the NTP Project Page.
  • NTPv4 includes three new server discovery schemes, which in most applications can avoid per-host configuration altogether. Two of these are based on IP multicast technology, while the remaining one is based on crafted DNS lookups. See the Automatic NTP Configuration Schemes page for further information.
  • The status display and event report monitoring functions have been considerably expanded, including new statistics files and event reporting to files and the system log. See the Event Messages and Status Words page for further information.
  • Several new options have been added for the ntpd command line. For the inveterate knob twiddlers several of the more important performance variables can be changed to fit actual or perceived special conditions. In particular, the tinker and tos commands can be used to adjust thresholds, throw switches and change limits.
  • The ntpd daemon can be operated in a one-time mode similar to ntpdate, which program is headed for retirement. See the ntpd - Network Time Protocol (NTP) daemon page for the new features.
    • +
  • A number of white papers have been added to the library on the NTP Reseatch Project Page, including:
+

Changes and Upgrades Since the NTPv3 Version (xntp3-5)

  • If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is detected, support for the IPv6 address family is supported in addition to the default support for the IPv4 address family. In contexts where a host name is expected, a -4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a -6 qualifier forces DNS resolution to the IPv6 namespace.
    • diff --git a/html/warp.html b/html/warp.html index 240c6caf22..089d310f97 100644 --- a/html/warp.html +++ b/html/warp.html @@ -9,7 +9,7 @@

    How NTP Works

    Last update: - 14-Oct-2010 16:45 + 22-Feb-2011 17:55 UTC

    Related Links

    @@ -21,9 +21,9 @@

Introduction and Overview

-

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.

-

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 via satellite, radio and telephone modem. 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.

-

This page presents an overview of the NTP daemon included in this distribution. We refer to this daemon as the reference implementation only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the Network Time Synchronization Research Project page.

+

NTP time synchronization services are widely available in the public Internet. The public NTP subnet in early 2011 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.

+

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 via satellite, radio or telephone modem. 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.

+

This page presents an overview of the NTP daemon included in this software distribution. We refer to this daemon as the reference implementation only because it was used to test and validate the NTPv4 specification RFC-5905. It is best read in conjunction with the briefings on the Network Time Synchronization Research Project page.

gif

Figure 1. NTP Daemon Processes and Algorithms

@@ -34,7 +34,7 @@

offset = [(T2 - T1) + (T3 - T4)] / 2
delay = (T4 - T1) - (T3 - T2).

-

The algorithm described on the Clock Filter Algorithm page selects the offset and delay samples most likely to produce accurate time. Those peers that have passed the peer sanity tests of the flash status word are declared selectable. From the selectable population the statistics are used by the algorithm described on the Clock Select Algorithm page to determine a number of truechimers according to correctness principles. From the truechimer population the algorithm described on the Clock Cluster Algorithm page determines a number of survivors on the basis of statistical clustering principles. The algorithms described on the Mitigation Rules and the prefer Keyword page combine the survivor offsets, designate one of them as the system peer and produces the final offset used by the algorithm described on the Clock Discipline Algorithm page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the loopstats option of the filegen command. For additional details about these algorithms, see the Architecture Briefing on the Network Time Synchronization Research Project page.

+

The algorithm described on the Clock Filter Algorithm page selects the offset and delay samples most likely to produce accurate results. Those servers that have passed the sanity tests are declared selectable. From the selectable population the statistics are used by the algorithm described on the Clock Select Algorithm page to determine a number of truechimers according to correctness principles. From the truechimer population the algorithm described on the Clock Cluster Algorithm page determines a number of survivors on the basis of statistical clustering principles. The algorithms described on the Mitigation Rules and the prefer Keyword page combine the survivor offsets, designate one of them as the system peer and produces the final offset used by the algorithm described on the Clock Discipline Algorithm page to adjust the system clock time and frequency. The clock offset and frequency, are recorded by the loopstats option of the filegen command. For additional details about these algorithms, see the Architecture Briefing on the Network Time Synchronization Research Project page.

Statistics Budget

Each source is characterized by the offset and delay samples measured by the on-wire protocol and the dispersion and jitter calculated by the clock filter algorithm. In a window of eight samples, this algorithm selects the offset sample with the lowest delay, which generally represents the most accurate data. The selected samples become the peer offset and peer delay. The peer dispersion is determined as a weighted average of the dispersion samples in the window. It continues to grow at the same rate as the sample dispersion, 15 ms/s. Finally, the peer jitter is determined as the root-mean-square (RMS) average of the offset samples in the window relative to the selected offset sample. The peer offset, peer delay, peer dispersion and peer jitter are recorded by the peerstats option of the filegen command. Peer variables are displayed by the rv command of the ntpq program.

The clock filter algorithm continues to process packets in this way until the source is no longer reachable. Reachability is determined by an eight-bit shift register, which is shifted left by one bit as each poll packet is sent, with 0 replacing the vacated rightmost bit. Each time an update is received, the rightmost bit is set to 1. The source is considered reachable if any bit is set to 1 in the register; otherwise, it is considered unreachable.

@@ -44,10 +44,11 @@

Quality of Service

The mitigation algorithms deliver several important statistics, including system offset and system jitter. These statistics are determined by the mitigation algorithms's from the survivor statistics produced by the clock cluster algorithm. System offset is best interpreted as the maximum likelihood estimate of the system clock offset, while system jitter is best interpreted as the expected error of this estimate. These statistics are reported by the loopstats option of the filegen command.

Of interest in this discussion is how the daemon determines the quality of service from a particular reference clock or remote server. This is determined from two statistics, expected error and maximum error. Expected error, or system jitter, is determined from various jitter components; it represents the nominal error in determining the mean clock offset.

-

Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called synchronization distance. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the ntp_gettimeofday() kernel system call. See the Kernel Model for Precision Timekeeping page for further information.

+

Maximum error is determined from delay and dispersion contributions and represents the worst-case error due to all causes. In order to simplify discussion, certain minor contributions to the maximum error statistic are ignored. Elsewhere in the documentation the maximum error is called synchronization distance. If the precision time kernel support is available, both the estimated error and maximum error are reported to user programs via the ntp_gettime() kernel system call. See the Kernel Model for Precision Timekeeping page for further information.

The maximum error is computed as one-half the root delay to the primary source of time; i.e., the primary reference clock, plus the root dispersion. The root variables are included in the NTP packet header received from each server. When calculating maximum error, the root delay is the sum of the root delay in the packet and the peer delay, while the root dispersion is the sum of the root dispersion in the packet and the peer dispersion.

A source is considered selectable only if its maximum error is less than the select threshold, by default 1.5 s, but can be changed according to client preference using the maxdist option of the tos command. A common consequences is when an upstream server loses all sources and its maximum error apparent to dependent clients begins to increase. The clients are not aware of this condition and continues to accept synchronization as long as the maximum error is less than the select threshold.

-

Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock 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 for 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.

+

Although it might seem counter-intuitive, a cardinal rule in the selection process is, once a sample has been selected by the clock filter algorithm, older samples are no longer selectable. This applies also to the clock select algorithm. Once the peer variables for a source have been selected, older variables of the same or other sources are no longer selectable. The reason for these rules is to limit the time delay in the the clock discipline algorithm. This is necessary to preserve the optimum impulse response and thus the risetime and overshoot.

+

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 for 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.

diff --git a/html/xleave.html b/html/xleave.html index ef2bc2266d..ab78a85f89 100644 --- a/html/xleave.html +++ b/html/xleave.html @@ -11,7 +11,7 @@ giffrom Pogo, Walt Kelly

You need a little magic.

Last update: - 04-Sep-2010 19:44 + 24-Apr-2011 2:32 UTC


@@ -22,7 +22,7 @@ It is activated by the xleave option with the peer or broadcast configuration commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode.

As demonstrated in the white paper Analysis and Simulation of the NTP On-Wire Protocols, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper Interleaved - Synchronization Protocols for LANs and Space Data Links.

+ Synchronization Protocols for LANs and Space Data Links. Additional discussion is on the Interleaved Modes Issues page.

gif