NTP (Network Time Protocol) is a standard protocol that system clocks use to ensure their time is always accurate. Appliances 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.
BloxOne The Infoblox platform provides an NTP service that you enable on hosts. Hosts can 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 hostsNIOS-X servers. You can deploy the NTP service on supported types of hosts NIOS-X servers within your organization.
The NTP service can be configured uniformly across your organization, with the possibility of locally overriding hosts 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 hosts NIOS-X servers that are running the NTP service. In your BloxOne infrastructureInfoblox Platform, you can add external NTP servers with which other hosts NIOS-X servers synchronize. You can also configure hosts NIOS-X servers that synchronize to external NTP servers to function as NTP servers for other hosts NIOS-X servers in the network.
| Note |
|---|
|
The following diagram illustrates how a host a NIOS-X server can function as the NTP server or NTP client, depending on your NTP configuration:
...
| Excerpt | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|
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.
...
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 host 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 host 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:
...
| Excerpt | ||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||
|
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:
Scenario | Behavior |
|---|---|
No authentication took place on the NTP server and client. | The NTP client synchronizes with the server. |
Authentication took place on the NTP server but not on the NTP client. | The NTP client synchronizes with the server. |
Authentication took place on the NTP server as well as client. | The NTP client synchronizes with the server. |
Authentication did not take place on the NTP server but took place on the client. | The NTP client is out-of-sync with the server. |
Defining NTP Access Control
The NTP access-control list specifies which clients can use a host 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.
...
Use the default ACL to control (1) which clients can use the NIOS appliance server as an NTP server and (2) from which clients the appliance server can accept queries by using ntpq.
| Note |
|---|
NoteCurrently, only the default (all clients) ACL is supported. |
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 hostsNIOS-X servers, do the following:
Configure the global NTP settings to allow
...
NIOS-X servers to adopt the NTP settings. For details, see Configuring Global NTP Settings.
Enable the NTP service on applicable
...
NIOS-X servers after you set up global NTP settings for the NTP service to take effect.
...
Optionally, override global NTP settings at the level of the local
...
NIOS-X server. For details,
...
Monitoring NTP Service
After you have configured the NTP service for a hostNIOS-X server, you can start monitoring its status. For details, see Viewing Service Information.
...