idnits 2.17.1 draft-gruessing-ntp-ntpv5-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5905], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: 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. -- The document date (May 22, 2021) is 1070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 279 == Unused Reference: 'RFC7808' is defined on line 254, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-ntp-roughtime-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol J. Gruessing 3 Internet-Draft May 22, 2021 4 Intended status: Informational 5 Expires: November 23, 2021 7 NTPv5 use cases and requirements 8 draft-gruessing-ntp-ntpv5-requirements-02 10 Abstract 12 This document describes the use cases, requirements, and 13 considerations that should be factored in the design of a successor 14 protocol to supercede version 4 of the NTP protocol [RFC5905] 15 presently referred to as NTP version 5 ("NTPv5"). This document is 16 non-exhaustive and does not in its current version represent working 17 group consensus. 19 Note to Readers 21 _RFC Editor: please remove this section before publication_ 23 Source code and issues for this draft can be found at 24 https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing-ntp- 25 ntpv5-requirements [1]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 23, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 63 2. Use cases and existing deployments of NTP . . . . . . . . . . 3 64 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Resource mamangement . . . . . . . . . . . . . . . . . . 3 66 3.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.3. Timescales . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4. Leap seconds . . . . . . . . . . . . . . . . . . . . . . 4 69 3.5. Backwards compatibility to NTS and NTPv4 . . . . . . . . 4 70 3.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 6.2. Informative References . . . . . . . . . . . . . . . . . 6 76 6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 NTP version 4 [RFC5905] has seen active use for over a decade, and 83 within this time period the protocol has not only been extended to 84 support new requirements but also fallen victim to vulnerabilities 85 that have made it used for distributed denial of service (DDoS) 86 amplification attacks. 88 1.1. Notational Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 2. Use cases and existing deployments of NTP 98 There are several common scenarios for exxisting NTPv4 deployments; 99 publicly accessible NTP services such as the NTP Pool [ntppool] are 100 used to offer clock synchronisation for end users and embedded 101 devices, ISP provided servers to synchronise devices such as 102 customer-premesis equipment where reduced accuracy may be tollerable. 103 Depending on the network and path these deployments may be affected 104 by variable latency as well as throttling or blocking by providers. 106 Data centres and cloud computing providers also have deployed and 107 offer NTP services both for internal use and for customers, 108 particularly where the network is unable to offer or does not require 109 PTP [IEEE-1588-2008]. As these deployments are less likely to be 110 constrained by network latency or power the potential for higher 111 levels of accuracy and precision within the bounds of the protocol 112 are possible. 114 3. Requirements 116 At a high level, NTPv5 should be a protocol that is capable of 117 operating in both local networks and also over public internet 118 connections where packet loss, delay, and even filtering may occur. 120 3.1. Resource mamangement 122 Historically there have been many documented instances of NTP servers 123 taking a large increase in unauthorised traffic [ntp-misuse] and the 124 design of NTPv5 must ensure the risk of these can be minimised to the 125 fullest extent. 127 Servers SHOULD have a new identifier that peers use as reference, 128 this SHOULD NOT be a FQDN, an IP address or identifier tied to a 129 public certificate. Servers SHOULD be able to migrate and change 130 their identifiers as stratum topologies or network configuration 131 changes occur. 133 The specification MUST have support for servers to notify clients 134 that the service is unavailable, and clients MUST have clearly 135 defined behaviours honouring this signalling. In addition to this 136 servers SHOULD be able to communicate to clients that they should 137 reduce their query interval rate when the server is under high 138 bandwidth or has reduced capacity. 140 Clients SHOULD re-establish connections with servers at an interval 141 to prevent attempting to maintain connectivity to a dead host and 142 give network operators the ability to move traffic away from hosts in 143 a timely manner. 145 3.2. Algorithms 147 Algorithms describing functions such as clock filtering, selection 148 and clustering SHOULD be omitted from the protocol specification; the 149 specification should instead only provide what is necessary to 150 describe protocol semantics and normative behaviours. 152 The working group should consider creating a separate informational 153 document to describe an algorithm to assist with implementation, and 154 to consider adopting future documents which describe new algorithms 155 as they are developed. Specifying client algorithms separately from 156 the protocol allows will allow NTPv5 to meet the needs of 157 applications with a variety of network properties and performance 158 requirements. It also allows for innovation in implementations 159 without sacrificing basic interoperability. 161 3.3. Timescales 163 The protocol SHOULD adopt a linear, monotonic timescale as the basis 164 for communicating time. The format should meet sufficient scale and 165 precision with resolution either meeting or exceeding NTPv4, and have 166 a rollover date sufficiently far enough into the future that the 167 protocol's complete obsolescence is most likely to occur first. The 168 timescale in addition to any other time sensitive information must be 169 sufficient to calculate representations of both UTC and TAI. Through 170 extensions the protocol SHOULD support additional timescale 171 representations outside of the main specification, and all 172 transmissions of time data SHALL indicate the timescale in use. 174 3.4. Leap seconds 176 Support for UTC leap second information MUST be included in the 177 protocol specification in order for clients to generate a UTC 178 representation but must be transmitted as separate information to the 179 timescale. The specification SHOULD also be capable of transmitting 180 upcoming leap seconds greater than 1 calendar day in advance. 182 Leap second smearing SHOULD NOT be part of the wire specification, 183 however this should not prevent implementors from applying leap 184 second smearing between the client and any clock it is training but 185 MUST NOT be applied to downstream clients. 187 3.5. Backwards compatibility to NTS and NTPv4 189 The support for compatibility with other protocols should not prevent 190 addressing issues that have previous caused issues in deployments or 191 cause ossification of the protocol. 193 Protocol ossification MUST be addressed to prevent existing NTPv4 194 deployments which incorrectly respond to clients posing as NTPv5 from 195 causing issues. Forward prevention of ossification (for a potential 196 NTPv6 protocol in the future) should also be taken into 197 consideration. 199 The model for backward compatibility is servers that support mutliple 200 versions NTP and send a response in the same version as the request. 201 This does not preclude servers from acting as a client in one version 202 of NTP and a server in another. 204 3.6. Extensibility 206 The protocol MUST have the capability to be extended, and that 207 implementations MUST ignore unknown extensions. Unknown extensions 208 received by a server from a lower stratum server SHALL not be added 209 to response messages sent by the server receiving these extensions. 211 4. IANA Considerations 213 Considerations should be made about the future of the existing IANA 214 registry for NTPv4 parameters. If NTPv5 becomes incompatible with 215 these parameters a new registry SHOULD be created. 217 5. Security Considerations 219 Encryption and authentication MUST be provided by the protocol 220 specification as a default and MUST be resistent to downgrade 221 attacks. The encryption used must have agility, allowing for the 222 protocol to update as more secure cryptography becomes known and 223 vulnerabilities are discovered. 225 The specification MAY consider leaving room for middleboxes which may 226 deliberately modify packets in flight for legitimate purposes. 227 Thought must be given around how this will be incorporated into any 228 applicable trust model. Downgrading attacks that could lead to an 229 adversary disabling or removing encryption or authentication MUST NOT 230 be possible in the design of the protocol. 232 Detection and reporting of server malfeasence SHOULD remain out of 233 scope of this specification as [I-D.ietf-ntp-roughtime] already 234 provides this capability as a core functionality of the protocol. 236 6. References 237 6.1. Normative References 239 [I-D.ietf-ntp-roughtime] 240 Malhotra, A., Langley, A., Ladd, W., and M. Dansarie, 241 "Roughtime", draft-ietf-ntp-roughtime-04 (work in 242 progress), February 2021. 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 250 "Network Time Protocol Version 4: Protocol and Algorithms 251 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 252 . 254 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 255 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 256 . 258 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 259 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 260 May 2017, . 262 6.2. Informative References 264 [IEEE-1588-2008] 265 "IEEE Standard for a Precision Clock Synchronization 266 Protocol for Networked Measurement and Control Systems", 267 n.d.. 269 [ntp-misuse] 270 "NTP server misuse and abuse", n.d., 271 . 274 [ntppool] "pool.ntp.org: the internet cluster of ntp servers", n.d., 275 . 277 6.3. URIs 279 [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- 280 ntp-ntpv5-requirements 282 Appendix A. Acknowledgements 284 The author would like to thank Doug Arnold and Hal Murray for 285 contributions to this document, and would like to acknowledge Daniel 286 Franke, Watson Ladd, Miroslav Lichvar for their existing documents 287 and ideas. The author would also like to thank Angelo Moriondo, 288 Franz Karl Achard, and Malcom McLean for providing the author with 289 motivation. 291 Author's Address 293 James Gruessing 295 Email: james.ietf@gmail.com