Internet DRAFT - draft-ietf-ntp-ntpv5-requirements
draft-ietf-ntp-ntpv5-requirements
Network Time Protocol J. Gruessing
Internet-Draft Nederlandse Publieke Omroep
Intended status: Informational 18 January 2023
Expires: 22 July 2023
NTPv5 use cases and requirements
draft-ietf-ntp-ntpv5-requirements-01
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").
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 22 July 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gruessing Expires 22 July 2023 [Page 1]
Internet-Draft NTPv5 use cases and requirements January 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised 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. Data Minimisation . . . . . . . . . . . . . . . . . . . . 4
3.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Timescales . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Leap seconds . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Backwards compatibility with NTS and NTPv4 . . . . . . . 5
3.6.1. Dependent Specifications . . . . . . . . . . . . . . 6
3.7. Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
3.8. Security . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Server malfeasance detection . . . . . . . . . . . . . . 6
5. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Delay-based attacks . . . . . . . . . . . . . . . . . . . 7
5.2. Payload manipulation . . . . . . . . . . . . . . . . . . 7
5.3. Denial of Service and Amplification . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 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
Gruessing Expires 22 July 2023 [Page 2]
Internet-Draft NTPv5 use cases and requirements January 2023
future.
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 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 [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 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.
3.1. Resource management
Historically there have been many documented instances of NTP servers
receiving large amounts of unauthorised traffic [ntp-misuse] 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, any 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.
Gruessing Expires 22 July 2023 [Page 3]
Internet-Draft NTPv5 use cases and requirements January 2023
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.
3.2. Data Minimisation
Payload formats SHOULD use the least amount of fields and information
where possible, favouring the use of extensions to transmit optional
data. This is done in part to minimise ongoing use of deprecated
fields, in addition to reducing risks of exposing identifying
information of implementations and deployments.
3.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.
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.
Gruessing Expires 22 July 2023 [Page 4]
Internet-Draft NTPv5 use cases and requirements January 2023
3.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 rollover date sufficiently far into the future that the
protocol's complete obsolescence is 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
[TF.460-6]. 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.
3.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 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.
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.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.
The model for backward compatibility is: servers that support
multiple versions of NTP must 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.
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.
Gruessing Expires 22 July 2023 [Page 5]
Internet-Draft NTPv5 use cases and requirements January 2023
3.6.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.7. 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.
3.8. 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 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.
4. Non-requirements
This section covers topics that are explicitly out of scope.
4.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.
Gruessing Expires 22 July 2023 [Page 6]
Internet-Draft NTPv5 use cases and requirements January 2023
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 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.
5.2. Payload manipulation
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.
5.3. 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 [RFC2827]. The NTPv5 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.
Gruessing Expires 22 July 2023 [Page 7]
Internet-Draft NTPv5 use cases and requirements January 2023
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-07, 26 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ntp-
roughtime-07>.
[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/rfc/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/rfc/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/rfc/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/rfc/rfc8174>.
8.2. Informative References
[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..
Gruessing Expires 22 July 2023 [Page 8]
Internet-Draft NTPv5 use cases and requirements January 2023
[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>.
[TF.460-6] "Standard-frequency and time-signal emissions", n.d.,
<https://www.itu.int/rec/R-REC-TF.460-6-200202-I/en>.
Appendix A. 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.
Author's Address
James Gruessing
Nederlandse Publieke Omroep
Netherlands
Email: james.ietf@gmail.com
Gruessing Expires 22 July 2023 [Page 9]
