NTPv5 Use Cases and Requirements

1.1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Use of time specific terminology used in this document may further be specified in [RFC7384] or NTP specific terminology and concepts within [RFC5905].¶

3.1. Denial of Service and Amplification

NTPv4 has previously suffered from DDoS amplification attacks using a combination of IP address spoofing and private mode commands used in some NTP implementations, leading to an attacker being able to direct very large volumes of traffic to a victim IP address. Current mitigations are disabling private mode commands susceptible to attacks and encouraging network operators to implement BCP 38 [RFC2827] as well as source address validation where possible.¶

The NTPv5 protocol specification should be designed with current best practices for UDP based protocols in mind [RFC8085]. It should reduce the potential amplification factors in request/response payload sizes [drdos-amplification] through the use of padding of payload data, in addition to restricting command and diagnostic modes which could be exploited.¶

3.2. Accuracy Degradation

The risk that an on-path attacker can systemically delay packets between a client and server exists in all time protocols operating on insecure networks and its mitigations within the protocol are limited for a clock which is not yet synchronised. Increased path diversity and protocol support for synchronisation across multiple heterogeneous sources are likely the most effective mitigations.¶

3.3. False Time

Conversely, on-path attackers who can manipulate timestamps could also speed up a client's clock resulting in drift-related malfunctions and errors such as premature expiration of certificates on affected hosts. An attacker may also manipulate other data in flight to disrupt service and cause de-synchronisation. Additionally attacks via replaying previously transmitted packets can also delay or confuse receiving clocks, impacting ongoing synchronisation.¶

Message authentication with regular key rotation should mitigate all of these cases; however deployments should consider finding an appropriate compromise between the frequency of rotation to balance the window of attack and the rate of re-keying.¶

4.1. Resource Management

Historically there have been many documented instances of NTP servers receiving ongoing large volumes of unauthorised traffic [ntp-misuse] and the design of NTPv5 must ensure the risk of these can be minimised through the use of signalling unwanted traffic (e.g Kiss of Death) or easily identifiable packet formats which make rate-limiting, filtering, or blocking by firewalls possible.¶

The protocol's loop avoidance mechanisms SHOULD be able to use identifiers that change over time. Identifiers MUST NOT relate to network topology, in particular such mechanism should not rely on any FQDN, IP address or identifier tied to a public certificate used or owned by the server. Servers SHOULD be able to migrate and change any identifier used as stratum topologies or network configuration changes occur.¶

An additional identifier mechanism MAY be considered for the purposes of client allow/deny lists, logging and monitoring. Such a mechanism when included, SHOULD be independent of any loop avoidance mechanism, and authenticity requirements SHOULD be considered.¶

The protocol MUST have the capability for servers to notify clients that the service is unavailable and clients MUST have clearly defined behaviours for honouring this signalling. In addition servers SHOULD be able to communicate to clients that they should reduce their query rate when the server is under high load or has reduced capacity.¶

Clients SHOULD periodically re-establish connections with servers to prevent maintaining prolonged connectivity to unavailable hosts and give operators the ability to move traffic away from hosts in a timely manner.¶

The protocol SHOULD have provisions for deployments where Network Address Translation occurs and define behaviours when NAT rebinding occurs. This should also not compromise any DDoS mitigation(s) that the protocol may define.¶

Client and server protocol modes MUST be supported. Other modes such as symmetric and broadcast MAY be supported by the protocol but SHOULD NOT be required by implementers to implement. Considerations should be made in these modes to avoid implementation vulnerabilities and to protect deployments from attacks.¶

4.2. Data Minimisation

To minimise ongoing use of deprecated fields and exposing identifying information of implementations and deployments, payload formats SHOULD use the least amount of fields and information where possible, realising that data minimisation and resource management can be at odds with one another. The use of extensions should be preferred when transmitting optional data.¶

4.3. Algorithms

The use of algorithms describing functions such as clock filtering, selection, and clustering SHOULD have agility, allowing for implementations to develop and deploy new algorithms independently. Signalling of algorithm use or preference SHOULD NOT be transmitted by servers, however essential properties of the algorithm (e.g. precision) SHOULD be obvious.¶

The working group should consider creating a separate informational document to describe an algorithm to assist with implementation, and consider adopting future documents which describe new algorithms as they are developed. Specifying client algorithms separately from the protocol will allow NTPv5 to meet the needs of applications with a variety of network properties and performance requirements.¶

4.4. Timescales

The protocol should adopt a linear, monotonic timescale as the basis for communicating time. The format should provide sufficient scale, precision, and resolution to meet or exceed NTPv4's capabilities, and have a roll-over date sufficiently far into the future that the protocol's complete obsolescence is likely to occur first. Ideally it should be similar or identical to the existing epoch and data model that NTPv4 defines to allow for implementations to better support both versions of the protocol, simplifying implementation.¶

The timescale, in addition to any other time-sensitive information, MUST be sufficient to calculate representations of both UTC and TAI [TF.460-6], noting that UTC itself as the current timescale used in NTPv4 is neither linear nor monotonic unlike TAI. Through extensions the protocol SHOULD support additional timescale representations outside of the main specification, and all transmissions of time data MUST indicate the timescale in use.¶

4.5. Leap seconds

Transmission of UTC leap second information MUST be included in the protocol in order for clients to generate a UTC representation, but must be transmitted as separate information to the timescale. The specification MUST require that servers transmit upcoming leap seconds greater than 24 hours in linear timescale in advance if that information is known by the server. If the server learns of a leap second less than 24 hours before an upcoming leap second event, it MUST start transmitting the information immediately.¶

Smearing [google-smear] of leap seconds SHOULD be supported in the protocol, and the protocol MUST support servers transmitting information if they are configured to smear leap seconds and if they are actively doing so. Behaviours for both client and server in handling leap seconds MUST be part of the specification; in particular how clients handle multiple servers where some may use leap seconds and others smearing, that servers should not apply both leap seconds and smearing, as well as details around smearing timescales. Supported smearing algorithms MUST be defined or referenced.¶

4.6. Backwards Compatibility with NTS and NTPv4

The desire for compatibility with older protocols should not prevent addressing deployment issues or cause ossification of the protocol caused by middleboxes [RFC9065].¶

Servers that support multiple versions of NTP MUST send a response in the same version as the request as the model of backwards compatibility. This does not preclude servers from acting as a client in one version of NTP and a server in another.¶

Protocol ossification MUST be addressed to prevent existing NTPv4 deployments which respond incorrectly to clients posing as NTPv5 from causing issues. Forward prevention of ossification (for a potential NTPv6 protocol in the future) should also be taken into consideration.¶

4.7. Extensibility

The protocol MUST have the capability to be extended; implementations MUST ignore unknown extensions. Unknown extensions received from a lower stratum server SHALL NOT be re-transmitted towards higher stratum servers.¶

4.8. Security

Data authentication and integrity MUST be supported by the protocol, with optional support for data confidentiality. Downgrade attacks by an in-path attacker must be mitigated. The protocol MUST define at least one common mechanism to ensure interoperability, but should also include support for different mechanisms to support different deployment use cases. Extensions and additional modes SHOULD also incorporate authentication and integrity on data which could be manipulated by an attacker, on-path or off-path.¶

Upgrading cryptographic algorithms must be supported, allowing for more secure cryptographic primitives to be incorporated as they are developed and as attacks and vulnerabilities with incumbent primitives are discovered.¶

Intermediate devices such as networking equipment capable of modifying NTP packets, for example to adjust timestamps MUST be able to do so without compromising authentication or confidentiality. Extension fields with separate authentication may be used to facilitate this.¶

Consideration must be given to how this will be incorporated into any applicable trust model. Downgrading attacks that could lead to an adversary disabling or removing encryption or authentication MUST NOT be possible in the design of the protocol.¶

5.1. Server Malfeasance Detection

Detection and reporting of server malfeasance should remain out of scope as [I-D.ietf-ntp-roughtime] already provides this capability as a core functionality of the protocol.¶

5.2. Additional Time Information and Metadata

Previous versions of NTP do not transmit additional time information such as time zone data or historical leap seconds, and NTPv5 should not explicitly add support for it by default as existing protocols (e.g. TZDIST [RFC7808]) already provide mechanisms to do so. This does not prevent however, further extensions enabling this.¶

5.3. Remote Monitoring Support

Largely due to previous DDoS amplification attacks, mode 6 messages which have historically provided the ability for monitoring of servers SHOULD NOT be supported in the core of the protocol. However, it may be provided as a separate extension specification. It is likely that even with a new version of the protocol middleboxes may continue to block this mode in default configurations into the future.¶