Advanced NTP Topics

Time servers are organized into levels, or strata. Stratum-1 servers are directly connected to an external time source. The stratum-1 server relies on the external source of time to provide the correct time, and synchronizes its system clock to that external time source. The external time source can be a device such as a radio receiver. Figure 7-2 “Stratum-1 Time Servers” shows the relationship between the GPS receiver time source and the stratum-1 server associated with it.

Figure 7-2 Stratum-1 Time Servers

Stratum-2 time servers use stratum-1 servers as their time source. Likewise, stratum-3 servers use stratum-2 servers as their time sources. The maximum stratum level a server can have is 15.

An NTP time server can assume different roles in its relationships with other time servers in the synchronization subnet. A time server can assume one or more of the following roles:

	NOTE: Broadcasting is not recommended (especially when used with local clock impersonators). Broadcasting is an older concept that is no longer used.

Figure 7-3 “Example of Relationships Between Time Servers” illustrates relationships between time servers in a synchronization subnet.

Figure 7-3 Example of Relationships Between Time Servers

The roles of a time server are its relationships to other servers in the synchronization subnet. In the configuration file, a role is defined with one of four statements (peer, server, broadcast, and broadcastclient):

peer host|IP_address specifies that the named host is to provide time that the local host may synchronize to, and the local host is willing to provide time to which the named host may be synchronized.

server host|IP_address specifies that the named host is to provide time that the local host might synchronize to, but the local host does not provide time to which the named host may be synchronized. (The local host is a client of the named host.) In addition, server statements are used to configure external clocks (radio clocks or local system clocks) for stratum-1 servers. Refer to “Configuring External Clocks” for more information.

broadcast host|broadcast_address specifies that the xntpd daemon in the local host transmits broadcast NTP messages to a named address, usually the broadcast address on your local network. (The local host is a broadcaster.)

With the peer, server, or broadcast statement, you can also specify one or more of the following options:

key number specifies that the NTP packets sent to the named host are encrypted using the key that is associated with number. The authentication feature of xntpd must be enabled. See “Configuring Authentication”.

version 1 must be specified if xntpd will be requesting time from a host that is running ntpd, a daemon that is based on version 1 of the NTP protocol. version 2 must be specified if xntpd will be requesting time from a host that is running an xntpd implementation that is based on version 2 of the NTP protocol. If either of these options is not specified, xntpd sends out version 3 NTP packets when polling the host; if the host is a version 1 or 2 implementation, the packets will be discarded.

prefer specifies that the named host should be the primary source for synchronization when it is one of several valid sources. This option is most useful for a time server on a high-speed LAN that is equipped with an external time source, such as a radio clock. As mentioned in XXX"Guidelines for Configuration" on page 215, synchronization may be provided by outside sources. However, the local time server should be the preferred synchronization source.

The other role that you can define in the configuration file is that of a broadcast client. The statement broadcastclient yes indicates that the local host should listen for and attempt to synchronize to broadcast NTP packets. The optional statement broadcastdelay seconds specifies the default round trip delay to the broadcaster.

	NOTE: Every node in an NTP hierarchy must have either a server statement or a broadcastclient yes statement in its configuration file. Every node must have an upper-level server. A stratum-1 server must also have a server statement in its configuration file, which specifies a radio clock or internal system clock as a time source.

Note that if the local host is to assume the role of a server in providing time to clients, there is no configuration of this role on the local system. Instead, the configuration file on the client system would contain a server statement with the name or IP address of the host.

Also note that if authentication is enabled on the local host, the roles you configure are subject to the authentication process. For example, the local host can be configured as a peer or a client of a stratum-1 server, but if the remote server does not meet the criteria for an authenticated synchronization source, it will never be used as a time source by the local host. See “Configuring Authentication”.

	NOTE: xntpd is an HP implementation of version 3.2 of a publicly-available NTP daemon. HP does not guarantee that xntpd is fully compatible with version 1 or version 2 implementations of the daemon.

You can configure xntpd to support an external clock. Clocks are normally configured with server statements in the configuration file. You can place the clock address can be used anywhere else in the configuration file.

Clocks are referenced by an address of the format 127.127.t.u, where t specifies the clock type, and u is a unit number, which is dependent on the clock type for interpretation (this allows multiple instances of the same clock type on the same host).

xntpd supports two kinds of clocks:

See the xntpd man page for more information on configuring external clocks.

Figure 7-3 “Example of Relationships Between Time Servers”, shown earlier in this chapter, depicts an example of servers in a synchronization subnet and their relationships to each other. Figure 7-4 “Example Configurations” shows the peer, server, and broadcast statements that are configured for each of the servers. The system that will assume the server role is configured on its client systems. For example, if Penelope is to be a client of Bonita, you configure the name or address of Bonita on Penelope. You do not need to configure Penelope as a client on Bonita.

Figure 7-4 Example Configurations

xntpd computes the error in the frequency of the clock in the local host. It usually takes xntpd a day or so after it is started to compute a good estimate of the frequency error. The current value of the frequency error may be stored in a driftfile. The driftfile allows a restarted xntpd to reinitialize itself to the estimate stored in the driftfile, saving about a day's worth of time in recomputing a good frequency estimate. You specify the path and name of the driftfile.

	NOTE: xntpd should be operated on a continuous basis. If it is necessary to stop xntpd, the interval when it is not running should be kept to a minimum.

To specify the driftfile, define the keyword driftfile, followed by the name of the file in which the frequency error value is to be stored. The recommended location for the driftfile is /etc/ntp.drift. The following is an example of a driftfile statement:

driftfile /etc/ntp.drift

Authentication is a mechanism that helps protect against unauthorized access to time servers. Authentication is enabled on a system-by-system basis. Once enabled on a system, authentication applies to all NTP relationships configured on the system. When authentication is enabled on a host, only those time servers that send messages encrypted with a configured key are considered as candidates to which the host would be synchronized.

In authenticated mode, each NTP packet transmitted by a host has appended to it a key number and an encrypted checksum of the packet contents. The key number is specified in the peer, server, or broadcast statement for the remote host. You specify either the Data Encryption Standard (DES) or the Message Digest (MD5) algorithm to be used for the encryption of NTP packets.

Upon receipt of an encrypted NTP packet, the receiving host recomputes the checksum and compares it with the one included in the packet. Both the sending and receiving systems must use the same encryption key, defined by the key number.

When authentication is enabled on a host, the following time servers will not be considered by the host for synchronization:

An authentication key file is specified on the host. The key file contains a list of keys and their corresponding key numbers. Each key-key number combination is further defined by a key format, which determines the encryption method being used. See the xntpd man page for more information about the content of the authentication key file. A sample key file is provided in /usr/newconfig/etc/ntp.keys. The recommended location for the key file is /etc/ntp.keys. The key file should be secured to allow only the system administrator to have read and write access (mode 600).

While the key file can contain many keys, you can declare a subset of these keys as trusted keys. Trusted keys are used to determine if a time server is "trusted" as a potential synchronization candidate. Only time servers that use a specified trusted key for encryption, and whose authenticity is verified by successful decryption, are considered synchronization candidates.

Figure 7-5 “Authentication Example” illustrates how authentication works.

Figure 7-5 Authentication Example

In the example in Figure 7-5 “Authentication Example”, authentication is enabled for both Penelope and Golden. An NTP time request from Penelope to Golden will include authentication fields—the key ID 10, and a checksum encrypted with the key corresponding to the key ID 10, "tickle." When Golden receives this request, it recomputes the checksum using the packet's key ID field (10) to look up the key for ID 10 in its key file ("tickle") and compares it to the authentication field in the request.

Golden will send back time information with the key ID 10 and a checksum encrypted using "tickle."

In addition, Penelope will only accept time synchronizations that have used the key ID 10 and the corresponding encryption key "tickle."

To enable authentication on the local host, include the following statement in the /etc/ntp.conf configuration file:

authenticate yes

If the above statement is not specified, no authentication is used. When authentication is enabled, the following keywords and parameters may also be specified:

authdelay seconds indicates the amount of time (in seconds) needed to encrypt an NTP authentication field on the local host. The seconds value is used to correct transmit timestamps for authenticated outgoing packets. The value depends upon the CPU speed of the local host.

	CAUTION: The startup script automatically calculates the proper value for authdelay for the local system and writes it into the configuration file /etc/ntp.conf. Do not modify this value.

keys filename specifies the file that contains the encryption keys used by xntpd. See the xntpd man page for the format of the file.

trustedkey key# [key#2]... specifies the encryption key ID(s) that are trusted as synchronization sources.

xntpd provides a mechanism for restricting access to the local daemon from certain source addresses. In the /etc/ntp.conf file, you can define a restriction list that contains the addresses or addresses-and-masks of sources that may send NTP packets to the local host. For each address or address-mask specified in the restriction list, you can define zero or more flags to restrict time service or queries to the local host.

The source address of each incoming NTP packet is then compared to the restriction list. If a source address matches an entry in the restriction list, the restriction defined by the corresponding flag is applied to the incoming packet. If an address-mask is specified in the restriction list, the source address of each incoming NTP packet is ANDed with the mask, and then compared with the associated address for a match.

The restriction list should not be considered an alternative to authentication. It is most useful for keeping unwanted or broken remote time servers from affecting your local host. An entry in the restriction list has the following format:

restrict address [mask mask] [ntpport] [flag] [flag2]...

The keyword ntpport causes the restriction list entry to be matched only if the source port in the packet is the NTP UDP port 123.

Table 7-6 “Restrict Option Flags” shows the flags that can be specified for xntpd:

A restriction list entry with no flags set leaves matching hosts unrestricted. A source address of an incoming packet may match several entries in the restriction list. The entry that matches the source address most specifically is the entry that is applied. For example, consider the following restriction list entries:

restrict 193.100.0.0 mask 255.255.0.0 ignore
restrict 193.100.10.8

The first entry causes packets from source addresses on net 193.100 to be ignored. However, packets from host 193.100.10.8 are unrestricted, as specified by the second entry. The two restriction list entries effectively cause all packets from net 193.100 to be ignored, with the exception of packets from host 193.100.10.8.

The following are examples of restriction list entries for a local host with the address 193.100.100.7. These entries assume that ntpq requests to the local host can be made only from the local host or the host with address 193.8.10.1, while the local host only synchronizes to a time source on net 193.100.

#default entry - matches *all* source addresses
restrict default notrust nomodify
 
#trust for time, but do not allow ntpq requests
restrict 193.100.0.0 mask 255.255.0.0 nomodify noquery
 
#ignore time requests, but allow ntpq requests
restrict 193.8.10.1 noserve
 
#local host address is unrestricted
restrict 193.100.100.7

Use ntpq to verify the following:

After xntpd starts, run the ntpq program with the -p option:

/usr/sbin/ntpq -p

The -p option prints a list of NTP hosts known to the server, along with a summary of their states. After a while, a display like the following appears:

Table 7-7 ntpq Output Showing Known NTP Hosts

remote refid st t when poll reach delay offset disp=====================================================================*GPS_HP(1) GPS 0 l 48 64 377 0.00 0.516 4.19hpps.cup.hp cupertino 3 u 467 1024 377 7.20 -12.430 15.67+server2 WWVB 1 u 173 256 377 279.95 20.56 16.40 +node1 node3 2 u 131 256 373 9.89 16.28 23.25