Rate Management and the Kiss-o'-Death

From: Harlan Stenn Date: Sat, 11 Sep 2010 21:53:59 +0000 (-0400) Subject: Documentation updates from Dave Mills X-Git-Tag: NTP_4_2_7P48~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=44920aab70c76ca56c27b682cea91a74a07d76f5;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 4c8bfa77eFjjYTUXEmG2_OjzV7cH8A --- diff --git a/ChangeLog b/ChangeLog index 45f6a88e0..caab5e65d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* Documentation updates from Dave Mills. (4.2.7p47) 2010/09/11 Released by Harlan Stenn * Documentation updates from Dave Mills. * [Bug 1588] finish configure --disable-autokey implementation. diff --git a/html/accopt.html b/html/accopt.html index bcda8d51b..9ce44375b 100644 --- a/html/accopt.html +++ b/html/accopt.html @@ -8,9 +8,10 @@ @@ -18,7 +19,7 @@ gif

from Pogo, Walt Kelly

The skunk watches for intruders and sprays.

Last update: - 09-Sep-2010 23:54 + 11-Sep-2010 16:55 UTC

Introduction

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.

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.

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 ntp-keygen utility program in the NTP software distribution.

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 http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines - required.

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

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 http://www.openssl.org and can be installed using the procedures outlined in the Building and Installing the Distribution page. Once installed, the configure and build process automatically detects the library and links the library routines +required.

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 --enable-autokey 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 ntp-keygen utility program in the NTP software distribution.

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.

Authentication is configured separately for each association using the key or autokey option of the server configuration command, as described in the Server Options page, and the options described on this page. The ntp-keygen 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 www.ntp.org.

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 disable auth command. Authentication is also an access control option using the restric command and the notrust flag.

Symmetric Key Cryptography

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.

Keys and related information are specified in a keys file, usually called ntp.keys, 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 ntpq and ntpdc utility programs. Ordinarily, the ntp.keys file is generated by the ntp-keygen 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 digest option of the crypto command, and a 20-character printable ASCII string or a 40-character hex string as the key itself.

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.

Keys and related information are specified in a keys file, usually called ntp.keys, 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 ntpq and ntpdc utility programs. Ordinarily, the ntp.keys file is generated by the ntp-keygen 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 digest option of the crypto command, and a 20-character printable ASCII string or a 40-character hex string as the key itself.

When ntpd is first started, it reads the key file specified by the keys command and installs the keys in the key cache. However, individual keys must be activated with the trustedkey configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using ntpdc. The requestkey command selects the key ID used as the password for the ntpdc utility, while the controlkey command selects the key ID used as the password for the ntpq utility.

By default, the message digest algorithm is MD5 selected by the key type M 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).

Microsoft Windows Authentication

In addition to the above means, ntpd 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 mssntp flag of the restrict command described on the Access Control Options page. 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.

Public Key Cryptography

See the Autokey Public-Key Authentication page.

diff --git a/html/authopt.html b/html/authopt.html index 5df0becee..226bcf4e5 100644 --- a/html/authopt.html +++ b/html/authopt.html @@ -17,7 +17,7 @@ color: #FF0000; gif

from Alice's Adventures in Wonderland, Lewis Carroll

Our resident cryptographer; now you see him, now you don't.

Last update: - 10-Sep-2010 0:05 + 11-Sep-2010 15:56 UTC

Autokey Public-Key Authentication

Last update: - 06-Sep-2010 18:02 + 11-Sep-2010 19:19 UTC

@@ -22,7 +22,8 @@

Introduction

NTPv4 supports the Autokey security protocol, which is based on public key cryptography. The Autokey Version 2 protocol described on the Autokey Protocol 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 Autokey Identity Schemes 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 Autonomous Authentication page.

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 --enable-autokey 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 ntp-keygen utility program in the NTP software distribution.

The Autokey Version 2 protocol described on the Autokey Protocol 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 Autokey Identity Schemes 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 Autonomous Authentication page.

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.

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.

NTP Secure Groups

diff --git a/html/index.html b/html/index.html index 11f92c9f2..8833ebf10 100644 --- a/html/index.html +++ b/html/index.html @@ -11,7 +11,7 @@ gif

P.T. Bridgeport Bear; from Pogo, Walt Kelly

Pleased to meet you.

Last update: - 06-Sep-2010 20:10 + 11-Sep-2010 21:04 UTC

The Handbook

This distribution is an implementation of RFC-5905 "Network Time Protocol Version 4: Protocol and Algorithms Specification".
+ 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.

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 Network Time Protocol (NTP) Simulator page.

The Handbook

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.

NTP Version 4 Release NotesVersion 4 Release Notes: Lists recent changes and new features in the current distribution.
Association Management: Describes how to configure servers and peers and manage the various options. Includes automatic server discovery schemes.
Automatic Server Discovery Schemes +
Automatic Server Discovery Schemes: Describes automatic ser very discovery using broadcast, multicast, manycast and server pool scheme.
Access Control Support: Describes the access control mechanisms that can be used to limit client access to various time and management functions.

statsdir directory_path

Specify the directory path prefix for statistics file names.

File Set Types

diff --git a/html/rate.html b/html/rate.html index e25a021c6..4e21d87b3 100644 --- a/html/rate.html +++ b/html/rate.html @@ -5,13 +5,21 @@ Rate Management and the Kiss-o'-Death +

Rate Management and the Kiss-o'-Death Packet

from Pogo, Walt Kelly

Our junior managers and the administrators.

Last update: - 09-Sep-2010 20:49 + 11-Sep-2010 16:52 UTC

Guard Time

Guard time is the minimum time between successive packets. By default this is 2 s, but can be changed using the minimum option of the discard command. By design, this is also the interval between packets sent using the burst and iburst options.

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.

In the ntpd 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 minimum option of the discard command.

Average Headway Time

There are two features in ntpd 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 ntpd is 8 s, but this can be changed using the average option of the discard command, but not less than 3 (8 s).

If the iburst or burst 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 minpoll option of the server 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 ntpq rv command.

diff --git a/html/scripts/miscopt.txt b/html/scripts/miscopt.txt index 5408a364b..b2fdeecaf 100644 --- a/html/scripts/miscopt.txt +++ b/html/scripts/miscopt.txt @@ -1,6 +1,5 @@ document.write("

Miscellaneous Commands and Options

broadcastdelay - specify broadcast delay
discard - specify minimum guard time and average headway
driftfile - specify frequency file
enable - enable options
disable - disable options

How NTP Works

Last update: - - 08-Sep-2010 21:25 - + 11-Sep-2010 17:51 UTC

Introduction
NTP Daemon Architecture and Basic Operation
How Statistics are Determined
Clock Discipline Algorithm

Introduction

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. 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 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 Network Time Synchronization Research Project page.

gif

Figure 1. NTP Host Processes and Algorithms

Figure 1. NTP Daemon Processes and Algorithms

NTP Host Architecture and Basic Operation

NTP Daemon Architecture and Basic Operation

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 origin timestamp T₁ upon departure of the client request and the receive timestamp T₂ upon arrival at the server, the transmit timestamp T₃ upon departure of the server reply and the destination timestamp T₄ upon arrival at the client. These timestamps are used to calculate the clock offset and roundtrip delay:

offset = [(T₂ -T₁) + (T₃ - T₄)] / 2
@@ -26,7 +35,7 @@

Those sources that have passed a number of sanity checks are declared selectable. From the selectable population the statistics are used by the select algorithm to determine a number of truechimers according to correctness principles. From the truechimer population a number of survivors are determined on the basis of statistical principles. One of the survivors is declared the system peer 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.

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 iburst option on the Server Options page. For additional details about the clock filter, select, cluster and combine algorithms see the Architecture Briefing on the NTP Project Page.

How Statistics are Determined

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 ms/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.

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.

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.

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.

The quality of time service is determined by a quantity called the synchronization distance. It 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 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.

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.

Clock Discipline Algorithm

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 time constant, 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.

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.

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.

Related Links

Related Links

Introduction

Symmetric Key Cryptography

Microsoft Windows Authentication

Public Key Cryptography

Related Links

Autokey Public-Key Authentication

Table of Contents

Introduction

NTP Secure Groups

Related Links

Table of Contents

The Handbook

The Handbook

Related Links

File Set Types

Rate Management and the Kiss-o'-Death Packet

Related Links

Guard Time

Average Headway Time

How NTP Works

Table of Contents

Introduction

NTP Host Architecture and Basic Operation

NTP Daemon Architecture and Basic Operation

How Statistics are Determined

How Statistics are Determined

Clock Discipline Algorithm

Clock Discipline Algorithm