Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Network Time Protocol

SUMMARY Network Time Protocol (NTP) is a protocol used to synchronize time on all the devices in a network.

NTP Overview

Network Time Protocol (NTP) is a widely used protocol used to synchronize the clocks of routers and other hardware devices on the Internet. Primary NTP servers are synchronized to a reference clock directly traceable to Coordinated Universal Time (UTC). Reference clocks include GPS receivers and telephone modem services, NTP accuracy expectations depend on the environment application requirements. However, NTP can generally maintain time to within tens of milliseconds over the public internet.

NTP is defined in the RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification

Devices running Junos OS can be configured to act as an NTP client, a secondary NTP server, or a primary NTP server. These variations are as follows:

  • Primary NTP Server—Primary NTP servers are synchronized to a reference clock that is directly traceable to UTC. These servers then re-distribute this time data downstream to other Secondary NTP servers or NTP clients.

  • Secondary NTP Server—Secondary NTP servers are synchronized to a primary or secondary NTP server. These servers then re-distribute this data downstream to other Secondary NTP servers or NTP clients.

  • NTP Client—NTP clients are synchronized to a primary or secondary NTP server. Clients do not re-distribute this time data to other devices.

Note:

The NTP subnet includes a number of widely accessible public primary time servers that can be used as a network’s primary NTP server. Juniper Networks strongly recommends that you authenticate any primary servers you use.

Each device on your network can be configured to run in one or more of the following NTP modes:

  • Broadcast Mode—One or more devices is set up to transmit time information to a specified broadcast or multicast address. Other devices listen for time sync packets on these addresses. This mode is less accurate than the client/server mode.

  • Client/Server Mode—Devices are organized hierarchically across the network in client/server relationships.

  • Symmetric Active (peer) Mode—Two or more devices are configured as NTP server peers to provide redundancy.

By default, if an NTP client time drifts so that the difference in time from the NTP server exceeds 128 milliseconds, the NTP client is automatically stepped back into synchronization. The NTP client will still synchronize with the server even if the offset between the NTP client and server exceeds the 1000-second threshold. You can manually request that a device synchronize with an NTP server by using the set date ntp operational command on the router. On devices running Junos OS that have dual Routing Engines, the backup Routing Engine synchronizes directly with the primary Routing Engine.

All Juniper platforms that run Junos OS support the leap second adjustment. By default, if the NTP server is aware of the leap second calculations, then the Junos device will automatically add the 1 second delay. PTP (Precision Time Protocol) is used to detect and propagate leap second synchronization changes throughout all nodes in a network. NTP is also required for Common Criteria compliance. For more information on the Common Criteria certification, see Public Sector Certifications.

For more details about the Network Time Protocol, go to the Network Time Foundation website at http://www.ntp.org.

NTP supports IPv4 VPN and IPv6 routing and forwarding (VRF) requests on Junos OS. VRF request is also supported on Junos OS Evolved Release 20.2R1 onwards. This enables an NTP server running on a provider edge (PE) router to respond to NTP requests from a customer edge (CE) router. As a result, a PE router can process any NTP request packet coming from different routing instances.

Network Time Security (NTS) Support for NTP

NTS Overview

NTS provides cryptographic security for network time synchronization and supports client-server mode of NTP. NTS uses Transport Layer Security (TLS) protocol and Authenticated Encryption with Associated Data (AEAD) to obtain network time in an authenticated manner to the users. NTS also provides support for encryption of NTP extension fields.

The most important security processes are dependent on accurate time. Network time synchronization from a malicious source leads to serious consequences. Enabling NTS ensures accurate network time synchronization on your device.

Starting Junos OS Evolved release version 24.2R1, supports RFC 8915 compliance for Network Time Security (NTS) using Network Time Protocol (NTP) on ACX-Series, QFX-Series and PTX-Series devices. NTS provides cryptographic security for network time synchronization and supports the client/server mode of NTP.

This RFC 8915 compliance feature supports:

- Configuration of local-certificate for server and certificate verification options for client.

- Verification of x.509 certificates to establish a TLS channel between client and server.

- TLS NTS-KE protocol support.

- Support for NTS secured client-server NTP communication at server and client.

Benefits of NTS

  • Provides strong cryptographic protection against wide range of security attacks such as packet manipulation, spoofing, DDOS amplification attacks, and replay attacks
  • Ensures accurate network time synchronization from a reliable source
  • Provides scalability: Servers can serve several clients without manually pre-configuring any client-specific configuration. Because of the usage of cookies the server does not need to locally store the client specific data such as keys and AEAD algorithm
  • Prevents tracking of mobile devices

Network Time Synchronization with NTS

NTS consists of two protocols, the NTS Key Establishment protocol (NTS-KE) and the NTP time synchronization using NTS extension fields. Figure 1 shows the interactions in NTS.

NTS-KE Protocol

The NTS Key Establishment protocol (NTS-KE) uses TLS protocol to manage the initial authentication of the server, NTS parameter negotiation, and key establishment over TLS in the following order:

  1. The client performs a TLS handshake with the NTS-KE server and successfully verify the certificates.

  2. The client performs the NTS parameters negotiation with the server over the TLS-protected channel. The cryptographic algorithms negotiated are AEAD methods, which protects the NTP packets in the second phase.

  3. The client and the server successfully establish the key material for communication.

  4. The server also sends a supply of initial cookies to the client to use in next phase.

  5. The TLS channel closes and NTP proceeds to the next phase where actual exchange of time data happens.

NTS supports only the TLS version 1.3. The older TLS versions get rejected during the NTS-KE protocol phase.

NTP Time Synchronization Using NTS Extension Fields

This phase manages the encryption and authentication during NTP time synchronization through the extension fields in the NTP packets in the following order:

  1. The client queries the NTP server about time with NTS extension fields. These extension fields include cookies and an authentication tag computed using negotiated AEAD algorithm and key material extracted from the NTS-KE handshake.

    An NTS-secured NTP client request contains the following NTS extension fields:

    • Unique Identifier Extension Field: Contains randomly generated data and provides the means for replay protection at the NTS level.

    • NTS Cookie Extension Field: Contains the information about the key material, which establishes during NTS-KE phase, and the negotiated cryptographic algorithm. A cookie is only used once in a request to prevent tracking.

    • NTS Cookie Placeholder Extension Field: (Optional) Communicates to the server that the client wants to receive additional cookies in the response packet.

    • NTS Authenticator and Encrypted Extension Fields: Generated using AEAD Algorithm and key established during NTS-KE. This field provides the integrity protection for the NTP header and all the previous extension fields.

    Constant refreshing of cookies protects a device from tracking when it changes network addresses. For example a mobile device moving across different networks. The lack of any recognizable data prevents an adversary from determining that two packets sent over different network addresses came from the same client.

  2. When the server receives an NTS-secured request from the client, the server decrypts the cookie with a master key.

  3. The server extracts the negotiated AEAD algorithm and the keys that are available in the cookie. Using this key, the server checks the integrity of the NTP packet to ensure no manipulations to the packet.

  4. The server generates one or more new cookies and creates the NTP response packet. The server generates at least one new cookie and one additional cookie for each Cookie Placeholder Extension Field that the client added in the request packet.

    The response packet contains two NTS extension fields:

    • The Unique Identifier Extension Field, which has the same contents from the Unique Identifier field in request packet.
    • The NTS Authenticator and Encrypted Extension Field, which secures the NTP header and the previous extension fields using the extracted keys.

  5. The server also encrypts the cookies and includes them in the NTS Authenticator and Encrypted Extension Fields. This procedure also protects the client from tracking because an attacker cannot extract the cookies from a response message.

  6. The server finalizes the response packet and sends the packet to the client.

  7. The client receives the response packet.

  8. The client checks the Unique Identifier field and verifies that the Unique Identifier matches with an outstanding request.

  9. The client successfully performs the integrity check of the packet using the key and the AEAD algorithm.

  10. The client decrypts the cookies and adds them to its pool and processes the time information received from server.

NTP Time Servers

The IETF defined the Network Time Protocol (NTP) to synchronize the clocks of computer systems connected to each other over a network. Most large networks have an NTP server that ensures that time on all devices is synchronized, regardless of the device location. If you use one or more NTP servers on your network, ensure you include the NTS server addresses in your Junos OS configuration.

When configuring the NTP, you can specify which system on the network is the authoritative time source, or time server, and how time is synchronized between systems on the network. To do this, you configure the router, switch, or security device to operate in one of the following modes:

  • Client mode—In this mode, the local router or switch can be synchronized with the remote system, but the remote system can never be synchronized with the local router or switch.

  • Symmetric active mode—In this mode, the local router or switch and the remote system can synchronize with each other. You use this mode in a network in which either the local router or switch or the remote system might be a better source of time.

    Symmetric active mode can be initiated by either the local or the remote system. Only one system needs to be configured to do so. This means that the local system can synchronize with any system that offers symmetric active mode without any configuration whatsoever. However, we strongly encourage you to configure authentication to ensure that the local system synchronizes only with known time servers.

  • Broadcast mode—In this mode, the local router or switch sends periodic broadcast messages to a client population at the specified broadcast or multicast address. Normally, you include this statement only when the local router or switch is operating as a transmitter.

  • Server mode—In this mode, the local router or switch operates as an NTP server.

    In NTP server mode, the Junos OS supports authentication as follows:

    • If the NTP request from the client comes with an authentication key (such as a key ID and message digest sent with the packet), the request is processed and answered based on the authentication key match.

    • If the NTP request from the client comes without any authentication key, the request is processed and answered without authentication.

Configure NTP Time Server and Time Services

When you use NTP, configure the router or switch to operate in one of the following modes:

  • Client mode

  • Symmetric active mode

  • Broadcast mode

  • Server mode

The following topics describe how to configure these modes of operation:

Configure the Router or Switch to Operate in Client Mode

To configure the local router or switch to operate in client mode, include the server statement and other optional statements at the [edit system ntp] hierarchy level:

Specify the address of the system acting as the time server. You must specify an address, not a hostname.

To include an authentication key in all messages sent to the time server, include the key option. The key corresponds to the key number you specify in the authentication-key statement, as described in .

By default, the router or switch sends NTP version 4 packets to the time server. To set the NTP version level to 1, 2, or 3, include the version option.

If you configure more than one time server, you can mark one server preferred by including the prefer option.

The following example shows how to configure the router or switch to operate in client mode:

Configure the Router or Switch to Operate in Symmetric Active Mode

To configure the local router or switch to operate in symmetric active mode, include the peer statement at the [edit system ntp] hierarchy level:

Specify the address of the remote system. You must specify an address, not a hostname.

To include an authentication key in all messages sent to the remote system, include the key option. The key corresponds to the key number you specify in the authentication-key statement.

By default, the router or switch sends NTP version 4 packets to the remote system. To set the NTP version level to 1, 2 or 3, include the version option.

If you configure more than one remote system, you can mark one system preferred by including the prefer option:

Configure the Router or Switch to Operate in Broadcast Mode

To configure the local router or switch to operate in broadcast mode, include the broadcast statement at the [edit system ntp] hierarchy level:

Specify the broadcast address on one of the local networks or a multicast address assigned to NTP. You must specify an address, not a hostname. If the multicast address is used, it must be 224.0.1.1. Multicast protocols PIM and IGMP should be enabled on the NTP client facing interfaces in order to facilitate the device to transmit NTP packets over multicast address 224.0.1.1. Run the following commands to do so:

Note:

NTP over multicast is not supported within the routing instance on the device.

To include an authentication key in all messages sent to the remote system, include the key option. The key corresponds to the key number you specify in the authentication-key statement.

By default, the router or switch sends NTP version 4 packets to the remote system. To set the NTP version level to 1, 2, or 3, include the version option.

Configure the Router or Switch to Operate in Server Mode

In server mode, the router or switch acts as an NTP server for clients when the clients are configured appropriately. The only prerequisite for “ server mode” is that the router or switch must be receiving time from another NTP peer or server. No other configuration is necessary on the router or switch.

When configuring the NTP service in the management VRF (mgmt_junos), you must configure at least one IP address on a physical or logical interface within the default routing instance and ensure that this interface is up in order for the NTP service to work with the mgmt_junos VRF.

To configure the local router or switch to operate as an NTP server, include the following statements at the [edit system ntp] hierarchy level:

Specify the address of the system acting as the time server. You must specify an address, not a hostname.

To include an authentication key in all messages sent to the time server, include the key option. The key corresponds to the key number you specify in the authentication-key statement.

By default, the router or switch sends NTP version 4 packets to the time server. To set the NTP version level to 1,or 2, or 3, include the version option.

If you configure more than one time server, you can mark one server preferred by including the prefer option.

The following example shows how to configure the router or switch to operate in server mode:

Starting Junos OS Evolved release version 24.2R1, the following options are added to configure the NTS feature:

See Also

Example: Configure NTP as a Single Time Source for Router and Switch Clock Synchronization

Debugging and troubleshooting are much easier when the timestamps in the log files of all the routers or switches are synchronized, because events that span the network can be correlated with synchronous entries in multiple logs. We strongly recommend using the Network Time Protocol (NTP) to synchronize the system clocks of routers, switches, and other network equipment.

By default, NTP operates in an entirely unauthenticated manner. If a malicious attempt to influence the accuracy of a router or switch’s clock succeeds, it could have negative effects on system logging, make troubleshooting and intrusion detection more difficult, and impede other management functions.

The following sample configuration synchronizes all the routers or switches in the network to a single time source. We recommend using authentication to make sure that the NTP peer is trusted. The boot-server statement identifies the server from which the initial time of day and date is obtained when the router boots. The server statement identifies the NTP server used for periodic time synchronization. The source-address statement enables you to specify one source address per family for each routing instance, The authentication-key statement specifies that an HMAC-Message Digest 5 (MD5) scheme should be used to hash the key value for authentication, which prevents the router or switch from synchronizing with an attacker’s host posing as the time server.

Synchronize and Coordinate Time Distribution Using NTP

Using NTP to synchronize and coordinate time distribution in a large network involves these tasks:

Configure NTP

  • To configure NTP on the switch, include the ntp statement at the [edit system] hierarchy level:

Configure NTP Boot Server

When you boot the switch, it issues an ntpdate request, which polls a network server to determine the local date and time. You need to configure a server that the switch uses to determine the time when the switch boots. Otherwise, NTP will not be able to synchronize to a time server if the server’s time appears to be very far off of the local switch’s time.

  • To configure the NTP boot server, include the boot-server statement at the [edit system ntp] hierarchy level:

Note:

The boot-server option is deprecated starting in Junos OS Release 20.4R1.

  • Junos OS Release 15.1 onwards, to configure the NTP boot server, include the set ntp server statement at the [edit system ntp] hierarchy level:

Specify either the IP address or the hostname of the network server.

Specify a Source Address for an NTP Server

For IP version 4 (IPv4), you can specify that if the NTP server configured at the [edit system ntp] hierarchy level is contacted on one of the loopback interface addresses, the reply always uses a specific source address. This is useful for controlling which source address NTP will use to access your network when it is either responding to an NTP client request from your network or when it itself is sending NTP requests to your network.

To configure the specific source address that the reply will always use, and the source address that requests initiated by NTP server will use, include the source-address statement at the [edit system ntp] hierarchy level. The source-address is a valid IP address configured on one of the router or switch interfaces.

For example:

Starting in Junos OS Release 13.3, and Junos OS Evolved Release 20.2R1 you can configure the source address using the routing-instance statement at the [edit system ntp source-address source-address] hierarchy level:

As a result, while sending NTP message through any interface in the ntp-source-test routing instance, the source address 12.12.12.12 is used.

Note:

The routing-instance statement is optional and if not configured, the primary address of the interface will be used.

Specify one source address per family for each routing instance,

For example:

When configuring the NTP service in the management VRF (mgmt_junos), you must configure at least one IP address on a physical or logical interface within the default routing instance and ensure that this interface is up in order for the NTP service to work with the mgmt_junos VRF.

Note:

If a firewall filter is applied on the loopback interface, ensure that the source-address specified for the NTP server at the [edit system ntp] hierarchy level is explicitly included as one of the match criteria in the firewall filter. This enables the Junos OS to accept traffic on the loopback interface from the specified source address.

The following example shows a firewall filter with the source address 10.1.4.3 specified in the from statement included at the [edit firewall filter firewall-filter-name] hierarchy:

If no source-address statement is configured for the NTP server, include the primary address of the loopback interface in the firewall filter.

NTP Configuration

The Network Time Protocol (NTP) provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse network. Debugging and troubleshooting are much easier when the timestamps in the log files of all the routers or switches are synchronized, because events that span the network can be correlated with synchronous entries in multiple logs. We recommend using the Network Time Protocol (NTP) to synchronize the system clocks of routers, switches, and other network equipment.

To configure NTP:

  1. Configure Junos OS to retrieve the time when it first boots up.

    Use the boot-server statement with the IP address of your NTP server. If DNS is configured, you can use a domain name instead of an IP address.

    For example, set an IP address of 172.16.1.1 for your NTP server.

    For example, set a domain name. In this example, the domain name is provided by pool.ntp.org.

  2. Specify the source address that the reply will always use, and the source address that requests initiated by NTP server will use, include the source-address statement at the [edit system ntp] hierarchy level.
    For example:
  3. Specify one source address per family for each routing instance.
    For example, the following statement is configured:
  4. (Optional) Configure one or more reference NTP servers to keep the device synchronized with periodic updates.

    It is a good practice to do this, as the Junos OS device can remain up for a long time, and therefore the clock can drift.

    For example, set an IP address of 172.16.1.1 for your NTP server.

    For example, set a domain name provided by pool.ntp.org.

  5. (Optional) Set the local time zone to match the device’s location.

    Universal Coordinated Time (UTC) is the default. Many administrators prefer to keep all their devices configured to use the UTC time zone. This approach has the benefit of allowing you to easily compare the time stamps of logs and other events across a network of devices in many different time zones.

    On the other hand, setting the time zone allows Junos OS to present the time in the correct local format.

    For example:

  6. Verify the configuration.

    Check the system uptime. This command provides the current time, when the device was last booted, when the protocols started, and when the device was last configured.

    Check the NTP server status and associations of the clocking sources used by your device.

    To configure NTP on the router or switch, include the ntp statement at the [edit system] hierarchy level:

Example: Configure NTP

The Network Time Protocol (NTP) provides the mechanism to synchronize time and coordinate time distribution in a large, diverse network. NTP uses a returnable-time design in which a distributed subnet of time servers operating in a self-organizing, hierarchical primary-secondary configuration synchronizes local clocks within the subnet and to national time standards by means of wire or radio. The servers also can redistribute reference time using local routing algorithms and time daemons.

This example shows how to configure NTP:

Requirements

This example uses the following software and hardware components:

  • Junos OS Release 11.1 or later

  • A switch connected to a network on which an NTP boot server and NTP server reside

Overview

Debugging and troubleshooting are much easier when the timestamps in the log files of all switches are synchronized, because events that span a network can be correlated with synchronous entries in multiple logs. We recommend using the Network Time Protocol (NTP) to synchronize the system clocks of your switch and other network equipment.

In this example, an administrator wants to synchronize the time in a switch to a single time source. We recommend using authentication to make sure that the NTP peer is trusted. The boot-server statement identifies the server from which the initial time of day and date are obtained when the switch boots. The server statement identifies the NTP server used for periodic time synchronization. The authentication-key statement specifies that an HMAC-Message Digest 5 (MD5) scheme is used to hash the key value for authentication, which prevents the switch from synchronizing with an attacker’s host that is posing as the time server.

Configuration

To configure NTP:

Procedure

CLI Quick Configuration

To quickly configure NTP, copy the following commands and paste them into the switch’s terminal window:

Step-by-Step Procedure

To configure NTP :

  1. Specify the boot server:

  2. Specify the NTP server:

  3. Specify one source address per family for each routing-instance:

  4. Specify the key number, authentication type (MD5), and key for authentication:

Results

Check the results:

Verification

To confirm that the configuration is correct, perform these tasks:

Checking the Time

Purpose

Check the time that has been set on the switch.

Action

Enter the show system uptime operational mode command to display the time.

Meaning

The output shows that the current date and time are June 12, 2009 and 12:49:03 PDT. The switch booted 4 weeks, 6 hours, and 24 minutes ago, and its protocols were started approximately 3 minutes before it booted. The switch was last configured by user admin1 on May 27, 2009, and there is currently one user logged in to the switch.

The output also shows that the load average is 0.05 seconds for the last minute, 0.06 seconds for the last 5 minutes, and 0.01 seconds for the last 15 minutes.

Displaying the NTP Peers

Purpose

Verify that the time has been obtained from an NTP server.

Action

Enter the show ntp associations operational mode command to display the NTP server from switch obtained its time.

Meaning

The asterisk (*) in front of the NTP server name, or peer, indicates that the time is synchronized and obtained from this server. The delay, offset, and jitter are displayed in milliseconds.

Displaying the NTP Status

Purpose

View the configuration of the NTP server and the status of the system.

Action

Enter the show ntp status operational mode command to view the status of the NTP.

Meaning

The output shows status information about the switch and the NTP.

NTP Authentication Keys

Time synchronization can be authenticated to ensure that the switch obtains its time services only from known sources. By default, network time synchronization is unauthenticated. The switch will synchronize to whatever system appears to have the most accurate time. We strongly encourage you to configure authentication of network time services.

To authenticate other time servers, include the trusted-key statement at the [edit system ntp] hierarchy level. The trusted keys refer to the configured key that is trusted and used by NTP for secure clock synchronization. Any configured key not referenced in the trusted-key is not qualified and is rejected by NTP. Only time servers that transmit network time packets containing one of the specified key numbers are eligible to be synchronized. Additionally, the key needs to match the value configured for that key number. Other systems can synchronize to the local switch without being authenticated.

Each key can be any 32-bit unsigned integer except 0. Include the key option in the peer, server, or broadcast statements to transmit the specified authentication key when transmitting packets. The key is necessary if the remote system has authentication enabled so that it can synchronize to the local system.

To define the authentication keys, include the authentication-key statement at the [edit system ntp] hierarchy level:

number is the key number, type is the authentication type (only Message Digest 5 [MD5], SHA1, and SHA256 are supported), and password is the password for this key. The key number, type, and password must match on all systems using that particular key for authentication. There must be no space in the password for configuring the Network Time Protocol (NTP) authentication-key.

Note:

EX4300, EX4600, and related non-MP devices such as QFX5100 (EX and QFX models that run BSD6) support only MD5 authentication for NTP and do not support SHA-1 and SHA-256 authentication types.

Configure Devices to Listen to Broadcast Messages Using NTP

When you are using NTP, you can configure the local router or switch to listen for broadcast messages on the local network to discover other servers on the same subnet by including the broadcast-client statement at the [edit system ntp] hierarchy level:

When the router or switch detects a broadcast message for the first time, it measures the nominal network delay using a brief client-server exchange with the remote server. It then enters broadcast client mode, in which it listens for, and synchronizes to, succeeding broadcast messages.

To avoid accidental or malicious disruption in this mode, both the local and remote systems must use authentication and the same trusted key and key identifier.

Configure Devices to Listen to Multicast Messages Using NTP

When you are using NTP, you can configure the local router or switch to listen for multicast messages on the local network to discover other servers on the same subnet by including the multicast-client statement at the [edit system ntp] hierarchy level:

When the router or switch receives a multicast message for the first time, it measures the nominal network delay using a brief client-server exchange with the remote server. It then enters multicast client mode, in which it listens for, and synchronizes to, succeeding multicast messages.

You can specify one or more IP addresses. (You must specify an address, not a hostname.) If you do, the router or switch joins those multicast groups. If you do not specify any addresses, the software uses 224.0.1.1.

To avoid accidental or malicious disruption in this mode, both the local and remote systems must use authentication and the same trusted key and key identifier.