Network Time Protocol J. Gruessing Internet-Draft Nederlandse Publieke Omroep Intended status: Informational 13 November 2021 Expires: 17 May 2022 NTPv5 use cases and requirements draft-gruessing-ntp-ntpv5-requirements-04 Abstract 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 [RFC5905] presently referred to as NTP version 5 ("NTPv5"). This document is non-exhaustive and does not in its current version represent working group consensus. 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 (https://github.com/fiestajetsam/draft-gruessing- ntp-ntpv5-requirements). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 May 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Gruessing Expires 17 May 2022 [Page 1] Internet-Draft NTPv5 use cases and requirements November 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Use cases and existing deployments of NTP . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Resource management . . . . . . . . . . . . . . . . . . . 3 3.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Timescales . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Leap seconds . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Backwards compatibility to NTS and NTPv4 . . . . . . . . 5 3.5.1. Dependent Specifications . . . . . . . . . . . . . . 5 3.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Server malfeasence detection . . . . . . . . . . . . . . 6 5. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Delay-based attacks . . . . . . . . . . . . . . . . . . . 6 5.2. Payload manipulation . . . . . . . . . . . . . . . . . . 7 5.3. Denial of Service and Amplification . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction NTP version 4 [RFC5905] 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 also fallen victim to vulnerabilities that have made it used for distributed denial of service (DDoS) amplification attacks. Gruessing Expires 17 May 2022 [Page 2] Internet-Draft NTPv5 use cases and requirements November 2021 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. 2. 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 [ntppool] are used to offer clock synchronisation for end users and embedded devices, ISP provided servers 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 [IEEE-1588-2008]. 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. 3. Requirements At a high level, NTPv5 should be a protocol that is capable of operating in both local networks and also over public internet connections where packet loss, delay, and even filtering may occur. It should be able to provide enough information for both basic time information as well as synchronisation. 3.1. Resource management Historically there have been many documented instances of NTP servers taking a large increase in unauthorised traffic [ntp-misuse] and the design of NTPv5 must ensure the risk of these can be minimised to the fullest extent. Servers SHOULD have a new identifier that peers use as reference, this SHOULD NOT be a FQDN, an IP address or identifier tied to a public certificate. Servers SHOULD be able to migrate and change their identifiers as stratum topologies or network configuration changes occur. Gruessing Expires 17 May 2022 [Page 3] Internet-Draft NTPv5 use cases and requirements November 2021 The protocol MUST have the capability for servers to notify clients that the service is unavailable, and clients MUST have clearly defined behaviours honouring this signalling. In addition servers SHOULD be able to communicate to clients that they should reduce their query interval rate when the server is under high bandwidth or has reduced capacity. Clients SHOULD re-establish connections with servers at an interval 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. 3.2. 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 independantly. 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 to consider adopting future documents which describe new algorithms as they are developed. Specifying client algorithms separately from the protocol allows will allow NTPv5 to meet the needs of applications with a variety of network properties and performance requirements. 3.3. Timescales The protocol SHOULD adopt a linear, monotonic timescale as the basis for communicating time. The format should meet sufficient scale and precision with resolution either meeting or exceeding NTPv4, and have a rollover date sufficiently far enough into the future that the protocol's complete obsolescence is most likely to occur first. 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. Gruessing Expires 17 May 2022 [Page 4] Internet-Draft NTPv5 use cases and requirements November 2021 3.4. Leap seconds Tranmission 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 SHOULD also be capable of transmitting upcoming leap seconds greater than 1 calendar day in advance. Leap second smearing SHOULD NOT be applied to timestamps transmitted by the server, however this should not prevent implementers from applying leap second smearing between the client and any clock it is training. 3.5. Backwards compatibility to NTS and NTPv4 The support for compatibility with other protocols should not prevent addressing issues that have previous caused issues in deployments or cause ossification of the protocol. Protocol ossification MUST be addressed to prevent existing NTPv4 deployments which incorrectly respond 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. The model for backward compatibility is servers that support multiple versions NTP and send a response in the same version as the request. This does not preclude servers from acting as a client in one version of NTP and a server in another. 3.5.1. Dependent Specifications Many other documents make use of NTP's data formats ([RFC5905] 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. 3.6. Extensibility The protocol MUST have the capability to be extended, and that 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. Gruessing Expires 17 May 2022 [Page 5] Internet-Draft NTPv5 use cases and requirements November 2021 3.7. Security Data authentication and optional data confidentiality MUST be integrated into the protocol, and downgrade attacks by an in-path attacker must be mitigated. Cryptographic agility must be available, allowing for the protocol to update to the use of more secure cryptographic primitives 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 include information to packets in flight without requiring modification or removal of authentication or confidentiality on the packet. Consideration must be given around 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. 4. Non-requirements This section covers topics that are explicitly out of scope. 4.1. Server malfeasence 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. Threat model The assumptions that apply to all of the threats and risks within this section are based on observations of the use cases defined earlier in this document, and focus on external threats outside of the trust boundaries which may be in place within a network. Internal threats and risks such as a trusted operator are out of scope. 5.1. Delay-based attacks 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 are limited within the protocol with 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. Gruessing Expires 17 May 2022 [Page 6] Internet-Draft NTPv5 use cases and requirements November 2021 5.2. Payload manipulation Conversely on-path attackers who can manipulate timestamps could also speed up a client's clock, also resulting into drift-related malfunctions and errors such as incorrect expiration of public certificates on the affected hosts. An attacker may also manipulate other data in flight to disrupt service and cause de-synchronisation. In both cases having message authentication with a regular key rotation interval should mitigate; however consideration should be made for hardware based timestamping. 5.3. Denial of Service and Amplification NTPv4 has previously suffered from DDoS amplification attacks using a combination of IP address spoofing with a private mode commands used in many NTP implementations, leading to an attacker being able to orders of magnitude of traffic to a victim IP address. Current mitigation uses a combination of disabling the use of private mode commands, in addition to encouraging network operators to implement BCP 38 [RFC2827]. Additional mitigations in future protocol specification should reduce the amplification factor in request/ response payload sizes [drdos-amplification] through the use of padding and consideration of payload data. 6. IANA Considerations This document makes no requests of IANA. 7. Security Considerations As this document is intended to create discussion and consensus, it introduces no security considerations of its own. 8. References 8.1. Normative References [I-D.ietf-ntp-roughtime] Malhotra, A., Langley, A., Ladd, W., and M. Dansarie, "Roughtime", Work in Progress, Internet-Draft, draft-ietf- ntp-roughtime-05, 24 May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Gruessing Expires 17 May 2022 [Page 7] Internet-Draft NTPv5 use cases and requirements November 2021 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [drdos-amplification] "Amplification and DRDoS Attack Defense -- A Survey and New Perspectives", n.d., . [IEEE-1588-2008] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", n.d.. [ntp-misuse] "NTP server misuse and abuse", n.d., . [ntppool] "pool.ntp.org: the internet cluster of ntp servers", n.d., . Appendix A. Acknowledgements The author would like to thank Doug Arnold and Hal Murray 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. Author's Address James Gruessing Nederlandse Publieke Omroep Postbus 26444 Gruessing Expires 17 May 2022 [Page 8] Internet-Draft NTPv5 use cases and requirements November 2021 1202 JJ Hilversum Netherlands Email: james.ietf@gmail.com Gruessing Expires 17 May 2022 [Page 9]