NTPv5 use cases and requirements
draft-gruessing-ntp-ntpv5-requirements-03

Network Time Protocol                                       J. Gruessing
Internet-Draft                                           10 October 2021
Intended status: Informational                                          
Expires: 13 April 2022

                    NTPv5 use cases and requirements
               draft-gruessing-ntp-ntpv5-requirements-03

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/I-D/tree/main/draft-gruessing-ntp-
   ntpv5-requirements (https://github.com/fiestajetsam/I-D/tree/main/
   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 13 April 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Gruessing                 Expires 13 April 2022                 [Page 1]
Internet-Draft      NTPv5 use cases and requirements        October 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
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.1.  Threat model  . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.1.  Delay-based attacks . . . . . . . . . . . . . . . . .   6
       5.1.2.  Payload manipulation  . . . . . . . . . . . . . . . .   6
       5.1.3.  Denial of Service and Amplification . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   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 13 April 2022                 [Page 2]
Internet-Draft      NTPv5 use cases and requirements        October 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.

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.

   The specification MUST have support for servers to notify clients
   that the service is unavailable, and clients MUST have clearly
   defined behaviours honouring this signalling.  In addition to this

Gruessing                 Expires 13 April 2022                 [Page 3]
Internet-Draft      NTPv5 use cases and requirements        October 2021

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

   Algorithms describing functions such as clock filtering, selection
   and clustering SHOULD be omitted from the protocol specification; the
   specification should instead only provide what is necessary to
   describe protocol semantics and normative behaviours.

   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.  It also allows for innovation in implementations
   without sacrificing basic interoperability.

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
   specification should continue to use the existing NTP epoch unless
   requirements on precision, resolution, or backwards compatibility
   cannot be met.

   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 13 April 2022                 [Page 4]
Internet-Draft      NTPv5 use cases and requirements        October 2021

3.4.  Leap seconds

   Support for UTC leap second information MUST be included in the
   protocol specification 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 part of the wire specification,
   however this should not prevent implementers from applying leap
   second smearing between the client and any clock it is training but
   MUST NOT be applied to downstream clients.

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 13 April 2022                 [Page 5]
Internet-Draft      NTPv5 use cases and requirements        October 2021

4.  IANA Considerations

   Considerations should be made about the future of the existing IANA
   registry for NTPv4 parameters.  If NTPv5 becomes incompatible with
   these parameters a new registry SHOULD be created.

5.  Security Considerations

   Encryption and authentication MUST be provided by the protocol
   specification as a default and MUST be resistant to downgrade
   attacks.  The encryption used must have agility, allowing for the
   protocol to update as more secure cryptography becomes known and
   vulnerabilities are discovered.

   The specification MAY consider leaving room for middleboxes which may
   deliberately modify packets in flight for legitimate purposes.
   Thought 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.

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

5.1.  Threat model

   TODO: Describe the assumptions which support this model, separating
   those which can be generic to any deployment, and those that are more
   industry or deployment specific.

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

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

Gruessing                 Expires 13 April 2022                 [Page 6]
Internet-Draft      NTPv5 use cases and requirements        October 2021

   rotation interval should mitigate; however consideration should be
   made for hardware based timestamping.

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

6.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,
              <https://www.ietf.org/archive/id/draft-ietf-ntp-roughtime-
              05.txt>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc2827>.

   [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,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

Gruessing                 Expires 13 April 2022                 [Page 7]
Internet-Draft      NTPv5 use cases and requirements        October 2021

   [drdos-amplification]
              "Amplification and DRDoS Attack Defense -- A Survey and
              New Perspectives", n.d.,
              <https://arxiv.org/abs/1505.07892>.

   [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.,
              <https://en.wikipedia.org/wiki/
              NTP_server_misuse_and_abuse>.

   [ntppool]  "pool.ntp.org: the internet cluster of ntp servers", n.d.,
              <https://www.ntppool.org>.

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

   Email: james.ietf@gmail.com

Gruessing                 Expires 13 April 2022                 [Page 8]