]> Nederlandse Publieke Omroep

Netherlands james.ietf@gmail.com

Internet Network Time Protocol Internet-Draft This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supersede version 4 of the NTP protocol presently referred to as NTP version 5 ("NTPv5"). Note to Readers RFC Editor: please remove this section before publication Source code and issues for this draft can be found at https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements.

Introduction NTP version 4 has seen active use for over a decade, and within this time period the protocol has not only been extended to support new requirements but has also fallen victim to vulnerabilities that have been used for distributed denial of service (DDoS) amplification attacks. In order to advance the protocol and address these known issues alongside add capabilities for future usage this document defines the current known and applicable use cases in existing NTPv4 deployments and defines requirements for the future.

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 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 or NTP specific terminology and concepts within .

Use cases and existing deployments of NTP There are several common scenarios for existing NTPv4 deployments: publicly accessible NTP services such as the NTP Pool are used to offer clock synchronisation for end users and embedded devices, ISP-provided servers are used to synchronise devices such as customer-premises equipment where reduced accuracy may be tolerable. Depending on the network and path these deployments may be affected by variable latency as well as throttling or blocking by providers. Data centres and cloud computing providers also have deployed and offer NTP services both for internal use and for customers, particularly where the network is unable to offer or does not require PTP , and where they may already be familiar with NTP. As these deployments are less likely to be constrained by network latency or power the potential for higher levels of accuracy and precision within the bounds of the protocol are possible, particular through the use of modifications such as the use of bespoke algorithms.

Threat Analysis and Modeling A considerable motivation towards a new version of the protocol is the inclusion of security primitives such as authentication and encryption to bring the protocol in-line with current best practices for protocol design. There are numerous potential threats to a deployment or network handling traffic time synchronisation protocols that section 3 describes, which can be summarised into three basic groups: Denial of Service (DoS), degradation of accuracy, and false time, all of which in various forms apply to NTP. However, not all threats apply specifically to NTP directly, most notable attacks on time sources (§3.2.10) and L2/L3 DoS Attacks (§3.2.7) as both are outside the scope of the protocol, and the protocol itself cannot provide much in the way of mitigations.

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 many 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 and encouraging network operators to implement BCP 38 . The NTPv5 protocol specification should reduce the amplification factor in request/response payload sizes through the use of padding and consideration of payload data, in addition to restricting command and diagnostic modes which could be exploited.

Accuracy Degradation The risk that an on-path attacker can 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.

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. Message authentication with regular key rotation should mitigate both of these cases; however consideration should also be made for hardware-based timestamping.

Requirements At a high level, NTPv5 should be a protocol that is capable of operating in local networks and over public internet connections where packet loss, delay, and filtering may occur. It should be able to provide enough information for both basic time information and synchronisation.

Resource management Historically there have been many documented instances of NTP servers receiving large amounts of unauthorised traffic and the design of NTPv5 must ensure the risk of these can be minimised. The protocol's loop avoidance mechanisms SHOULD NOT use identifiers tied 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 attempting to maintain connectivity to a dead host and give network 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, and other modes such as symmetric and broadcast MAY be supported and SHOULD NOT be required by implementors to implement. Considerations should be made in these modes to avoid implementations and deployments from vulnerabilities and attacks.

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, favouring the use of extensions to transmit optional data.

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. 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.

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 rollover 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 more easily support both versions of the protocol. The timescale, in addition to any other time-sensitive information, MUST be sufficient to calculate representations of both UTC and TAI . Through extensions the protocol SHOULD support additional timescale representations outside of the main specification, and all transmissions of time data SHALL indicate the timescale in use.

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 1 calendar day in advance if that information is known by the server. If the server learns of a leap second less than 1 calendar day before a leap second event, it will start transmitting the information immediately. Smearing of leap seconds SHOULD be supported in the protocol, and the protocol MUST support servers transmitting both 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.

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. 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.

Dependent Specifications Many other documents make use of NTP's data formats ( Section 6) for representing time, notably for media and packet timestamp measurements. Any changes to the data formats should consider the potential implementation complexity that may be incurred.

Extensibility The protocol MUST have the capability to be extended; implementations MUST ignore unknown extensions. Unknown extensions received by a server from a lower stratum server SHALL not be added to response messages sent by the server receiving these extensions.

Security Data authentication and optional data confidentiality MUST be integrated into the protocol, and downgrade attacks by an in-path attacker must be mitigated. The protocol SHOULD support different mechanisms to support different use cases. Cryptographic agility 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 hardware capable of performing timestamping of packets SHOULD be able to add information to packets in flight without requiring modification or removal of authentication or confidentiality on the packet. 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.

Non-requirements This section covers topics that are explicitly out of scope.

Server malfeasance detection Detection and reporting of server malfeasance should remain out of scope as already provides this capability as a core functionality of the protocol.

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 ) already provide mechanisms to do so. This does not prevent however, further extentions enabling this.

IANA Considerations This document makes no requests of IANA.

Security Considerations As this document is intended to create discussion and consensus, it introduces no security considerations of its own.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Boston University Google Sealance, Inc. This document specifies Roughtime - a protocol that aims to achieve rough time synchronization while detecting servers that provide inaccurate time and providing cryptographic proof of their malfeasance. Informative References This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems. n.d. n.d. n.d. n.d. n.d.

Acknowledgements The author would like to thank Doug Arnold, Hal Murray, Paul Gear, and David Venhoek for contributions to this document, and would like to acknowledge Daniel Franke, Watson Ladd, Miroslav Lichvar for their existing documents and ideas. The author would also like to thank Angelo Moriondo, Franz Karl Achard, and Malcom McLean for providing the author with motivation.