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.
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.
For more details about the Network Time Protocol, go to the Network Time Foundation website at http://www.ntp.org.
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 required for Common Criteria compliance. For more information on the Common Criteria certification, see Public Sector Certifications.
In Junos operating system (Junos OS) Release 11.2 or later, NTP supports IPv4 VPN routing and forwarding (VRF) requests. 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. In Junos OS Release 11.4 and later, NTP also supports IPv6 VRF requests. Starting in Junos OS Release 18.2R1, there must be no space in the password for configuring the Network Time Protocol (NTP) authentication-key.
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.
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 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
In the NTS-KE protocol phase, the NTS-KE protocol manages the initial authentication, NTS parameter negotiation, and key establishment over TLS in the following order:
- The client performs a TLS handshake with the NTS-KE server and successfully verify the certificates.
-
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.
-
The client and the server successfully establish the key material for communication.
-
The server also sends a supply of initial cookies to the client to use in next phase.
-
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:
-
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 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 recognisable data prevents an adversary from determining that two packets sent over different network addresses came from the same client.
-
-
When the server receives an NTS-secured request from the client, the server decrypts the cookie with a master key.
-
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.
-
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.
-
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.
-
The server finalizes the response packet and sends the packet to the client.
-
The client receives the response packet.
-
The client checks the Unique Identifier field and verifies that the Unique Identifier matches with an outstanding request.
-
The client successfully performs the integrity check of the packet using the key and the AEAD algorithm.
-
The client decrypts the cookies and adds them to its pool and processes the time information received from server.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.