NTP (Network Time Protocol) is a standard protocol that system clocks use to ensure their time is always accurate. Servers that use NTP try to synchronize their time as close as possible to UTC (Coordinated Universal Time), the standard timescale used worldwide. For communications between clients and servers, NTP uses UDP (User Datagram Protocol) on port 123.

NTP is based on a hierarchy where reference clocks are at the top. Each level in the hierarchy is a stratum: stratum-0 servers provide the reference clocks that synchronize their time to UTC by using receivers, satellite systems, and other technology; stratum-1 servers synchronize their clocks to those of the reference clocks and serve time to clients; stratum-2 servers synchronize their clocks to those of stratum-1 servers; and so forth. The stratum number indicates the number of levels between the NTP server and the reference clock. A higher stratum number could indicate that there is more variance between the NTP server and the reference clock.

The Infoblox platform provides an NTP service that you enable on NIOS-X servers. NIOS-X servers can use the deployed service as a local provider for the NTP service. Using the deployed NTP service not only reduces the number of clients communicating directly with an external NTP service but also ensures that a common source of time is used for all NIOS-X servers. You can deploy the NTP service on supported types of NIOS-X servers within your organization.

The NTP service can be configured uniformly across your organization, with the possibility of locally overriding NIOS-X servers that have the NTP service deployed. The NTP service supports configurations that include authentication, specific attributes, and access-control lists. 

Global NTP settings are inherited by NIOS-X servers that are running the NTP service. In your Infoblox Platform, you can add external NTP servers with which other NIOS-X servers synchronize. You can also configure NIOS-X servers that synchronize to external NTP servers to function as NTP servers for other NIOS-X servers in the network.

The following diagram illustrates how a NIOS-X server can function as the NTP server or NTP client, depending on your NTP configuration:

Open

Authenticating NTP

To prevent intruders from interfering with the time services on your network, authenticate communications between the NTP service and a public NTP server and between the NTP service and external NTP clients.

NTP uses symmetric key cryptography: the server and client use the same algorithm and key to calculate and verify a message’s MAC (message authentication code). The MAC is the digital thumbprint of a message, and the receiver uses the MAC to verify the authenticity of the message. 

Currently, the NTP authentication mechanism supports only MD5: a message-digest algorithm and a cryptographic protocol used for authenticating messages. MD5 is based on a hash function that verifies that the key you sent matches the key received by the client.

As shown in the following illustration, the NTP client administrator must first obtain the secret key information from the administrator of the NTP server. The server and client must have the same key ID and data. Therefore, when you configure the NIOS-X server as an NTP client and want to use authentication, you must obtain the key information from the administrator of the external NTP server and enter the information when configuring authentication. When you configure a NIOS-X server as an NTP server, you must create a key and send the key information to clients in a secure manner.

A key consists of the following:

• Key Number: A positive integer that identifies the key.

• Key Type: The key format and the algorithm used to calculate the MAC of a message:

  • M: The key is an ASCII string that is 1 to 31 characters in length and uses MD5.

  • N: The key is a 64-bit hexadecimal number in the NTP format. The bits in each octet have been rotated one bit right, to have the parity bit in the high-order bit of the octet. You must specify leading zeros, and odd parity must be maintained.

• Key String: The key data used to calculate the MAC. The format depends on the Key Type you select.

The following illustration describes how the NTP client administrator obtains a trusted key from the NTP server administrator:

Open

When the NTP client sends a request for time services to the NTP server, it creates the MAC by using the agreed-upon algorithm to compress the request’s message, encrypts the compressed message (which is also called a message digest) with the secret key, and then appends the MAC to the message. When the NTP server receives the message from the client, it performs the same procedure on the message: it compresses the message it received, encrypts it with the secret key, generates the MAC, and then compares the MAC it created against the MAC it received. If the MACs match, the server processes and responds to the message. If the MACs do not match, the receiver drops the message.

The following table lists the behavior of the NTP client and server in various scenarios:

Defining NTP Access Control

The NTP access-control list specifies which clients can use a NIOS-X server as an NTP server. If you do not configure access control, then the NTP service will allow access to all clients. You can configure access control at the level of the global NTP service and override this configuration at the level of the local NTP service.

To accept queries from clients, the NTP service uses ntpq: the standard utility program used to query NTP servers about their statuses and operational parameters. By default, the NTP service does not accept ntpq queries from any client. For the NTP service to accept queries from a certain client, you have to specify this.

Use the default ACL to control (1) which clients can use the NIOS server as an NTP server and (2) from which clients the server can accept queries by using ntpq.

Enabling Kiss-o'-Death for NTP

Usually, when an NTP server denies service to an NTP client that has exceeded the rate limit, it typically drops the packets without notifying the client. In this case, the client is unaware of the situation and continues to transmit packets. To request that the client either slow down or stop transmitting, enable the NTP service (when it is acting as an NTP server) to transmit a KoD packet, which contains the following:

• the stratum field that is set to zero, which implies that the sent packet is invalid

• the ASCII string that contains the rate in the reference identifier field, which indicates the status of the transmitted packet and access control

When the client receives the KoD packet, it might reduce the transmission rate or stop transmission completely.

You can enable KoD at the global NTP level and override it at the local level. If you do not enable the rate limit before enabling KoD, then KoD will remain disabled.

For more information about KoD, refer to RFC 5905 (Network Time Protocol Version 4: Protocol and Algorithms Specification).

Configuring Global and Local NTP Service

To configure the NTP service for NIOS-X servers, do the following:

1. Configure the global NTP settings to allow NIOS-X servers to adopt the NTP settings. For details, see Configuring Global NTP Settings. 

2. Enable the NTP service on applicable NIOS-X servers after you set up global NTP settings for the NTP service to take effect.

3. Optionally, override global NTP settings at the level of the local NIOS-X server. For details, see Overriding Global NTP Settings.
   
   

Monitoring NTP Service

After you have configured the NTP service for a NIOS-X server, you can start monitoring its status. For details, see Viewing Service Information.