idnits 2.17.1 draft-gruessing-ntp-ntpv5-requirements-04.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]), 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 (13 November 2021) is 895 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ntp-roughtime-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol J. Gruessing 3 Internet-Draft Nederlandse Publieke Omroep 4 Intended status: Informational 13 November 2021 5 Expires: 17 May 2022 7 NTPv5 use cases and requirements 8 draft-gruessing-ntp-ntpv5-requirements-04 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 supersede 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/draft-gruessing-ntp- 25 ntpv5-requirements (https://github.com/fiestajetsam/draft-gruessing- 26 ntp-ntpv5-requirements). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 17 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 63 2. Use cases and existing deployments of NTP . . . . . . . . . . 3 64 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Resource management . . . . . . . . . . . . . . . . . . . 3 66 3.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.3. Timescales . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4. Leap seconds . . . . . . . . . . . . . . . . . . . . . . 5 69 3.5. Backwards compatibility to NTS and NTPv4 . . . . . . . . 5 70 3.5.1. Dependent Specifications . . . . . . . . . . . . . . 5 71 3.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 72 3.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Non-requirements . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Server malfeasence detection . . . . . . . . . . . . . . 6 75 5. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1. Delay-based attacks . . . . . . . . . . . . . . . . . . . 6 77 5.2. Payload manipulation . . . . . . . . . . . . . . . . . . 7 78 5.3. Denial of Service and Amplification . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 8.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 NTP version 4 [RFC5905] has seen active use for over a decade, and 90 within this time period the protocol has not only been extended to 91 support new requirements but also fallen victim to vulnerabilities 92 that have made it used for distributed denial of service (DDoS) 93 amplification attacks. 95 1.1. Notational Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Use cases and existing deployments of NTP 105 There are several common scenarios for existing NTPv4 deployments; 106 publicly accessible NTP services such as the NTP Pool [ntppool] are 107 used to offer clock synchronisation for end users and embedded 108 devices, ISP provided servers to synchronise devices such as 109 customer-premises equipment where reduced accuracy may be tolerable. 110 Depending on the network and path these deployments may be affected 111 by variable latency as well as throttling or blocking by providers. 113 Data centres and cloud computing providers also have deployed and 114 offer NTP services both for internal use and for customers, 115 particularly where the network is unable to offer or does not require 116 PTP [IEEE-1588-2008]. As these deployments are less likely to be 117 constrained by network latency or power the potential for higher 118 levels of accuracy and precision within the bounds of the protocol 119 are possible. 121 3. Requirements 123 At a high level, NTPv5 should be a protocol that is capable of 124 operating in both local networks and also over public internet 125 connections where packet loss, delay, and even filtering may occur. 126 It should be able to provide enough information for both basic time 127 information as well as synchronisation. 129 3.1. Resource management 131 Historically there have been many documented instances of NTP servers 132 taking a large increase in unauthorised traffic [ntp-misuse] and the 133 design of NTPv5 must ensure the risk of these can be minimised to the 134 fullest extent. 136 Servers SHOULD have a new identifier that peers use as reference, 137 this SHOULD NOT be a FQDN, an IP address or identifier tied to a 138 public certificate. Servers SHOULD be able to migrate and change 139 their identifiers as stratum topologies or network configuration 140 changes occur. 142 The protocol MUST have the capability for servers to notify clients 143 that the service is unavailable, and clients MUST have clearly 144 defined behaviours honouring this signalling. In addition servers 145 SHOULD be able to communicate to clients that they should reduce 146 their query interval rate when the server is under high bandwidth or 147 has reduced capacity. 149 Clients SHOULD re-establish connections with servers at an interval 150 to prevent attempting to maintain connectivity to a dead host and 151 give network operators the ability to move traffic away from hosts in 152 a timely manner. 154 The protocol SHOULD have provisions for deployments where Network 155 Address Translation occurs, and define behaviours when NAT rebinding 156 occurs. This should also not compromise any DDoS mitigation(s) that 157 the protocol may define. 159 3.2. Algorithms 161 The use of algorithms describing functions such as clock filtering, 162 selection and clustering SHOULD have agility, allowing for 163 implementations to develop and deploy new algorithms independantly. 164 Signalling of algorithm use or preference SHOULD NOT be transmitted 165 by servers. 167 The working group should consider creating a separate informational 168 document to describe an algorithm to assist with implementation, and 169 to consider adopting future documents which describe new algorithms 170 as they are developed. Specifying client algorithms separately from 171 the protocol allows will allow NTPv5 to meet the needs of 172 applications with a variety of network properties and performance 173 requirements. 175 3.3. Timescales 177 The protocol SHOULD adopt a linear, monotonic timescale as the basis 178 for communicating time. The format should meet sufficient scale and 179 precision with resolution either meeting or exceeding NTPv4, and have 180 a rollover date sufficiently far enough into the future that the 181 protocol's complete obsolescence is most likely to occur first. 183 The timescale in addition to any other time sensitive information 184 MUST be sufficient to calculate representations of both UTC and TAI. 185 Through extensions the protocol SHOULD support additional timescale 186 representations outside of the main specification, and all 187 transmissions of time data SHALL indicate the timescale in use. 189 3.4. Leap seconds 191 Tranmission of UTC leap second information MUST be included in the 192 protocol in order for clients to generate a UTC representation but 193 must be transmitted as separate information to the timescale. The 194 specification SHOULD also be capable of transmitting upcoming leap 195 seconds greater than 1 calendar day in advance. 197 Leap second smearing SHOULD NOT be applied to timestamps transmitted 198 by the server, however this should not prevent implementers from 199 applying leap second smearing between the client and any clock it is 200 training. 202 3.5. Backwards compatibility to NTS and NTPv4 204 The support for compatibility with other protocols should not prevent 205 addressing issues that have previous caused issues in deployments or 206 cause ossification of the protocol. 208 Protocol ossification MUST be addressed to prevent existing NTPv4 209 deployments which incorrectly respond to clients posing as NTPv5 from 210 causing issues. Forward prevention of ossification (for a potential 211 NTPv6 protocol in the future) should also be taken into 212 consideration. 214 The model for backward compatibility is servers that support multiple 215 versions NTP and send a response in the same version as the request. 216 This does not preclude servers from acting as a client in one version 217 of NTP and a server in another. 219 3.5.1. Dependent Specifications 221 Many other documents make use of NTP's data formats ([RFC5905] 222 Section 6) for representing time, notably for media and packet 223 timestamp measurements. Any changes to the data formats should 224 consider the potential implementation complexity that may be 225 incurred. 227 3.6. Extensibility 229 The protocol MUST have the capability to be extended, and that 230 implementations MUST ignore unknown extensions. Unknown extensions 231 received by a server from a lower stratum server SHALL not be added 232 to response messages sent by the server receiving these extensions. 234 3.7. Security 236 Data authentication and optional data confidentiality MUST be 237 integrated into the protocol, and downgrade attacks by an in-path 238 attacker must be mitigated. 240 Cryptographic agility must be available, allowing for the protocol to 241 update to the use of more secure cryptographic primitives as they are 242 developed and as attacks and vulnerabilities with incumbent 243 primitives are discovered. Intermediate devices such as hardware 244 capable of performing timestamping of packets SHOULD be able to 245 include information to packets in flight without requiring 246 modification or removal of authentication or confidentiality on the 247 packet. 249 Consideration must be given around how this will be incorporated into 250 any applicable trust model. Downgrading attacks that could lead to 251 an adversary disabling or removing encryption or authentication MUST 252 NOT be possible in the design of the protocol. 254 4. Non-requirements 256 This section covers topics that are explicitly out of scope. 258 4.1. Server malfeasence detection 260 Detection and reporting of server malfeasance should remain out of 261 scope as [I-D.ietf-ntp-roughtime] already provides this capability as 262 a core functionality of the protocol. 264 5. Threat model 266 The assumptions that apply to all of the threats and risks within 267 this section are based on observations of the use cases defined 268 earlier in this document, and focus on external threats outside of 269 the trust boundaries which may be in place within a network. 270 Internal threats and risks such as a trusted operator are out of 271 scope. 273 5.1. Delay-based attacks 275 The risk that an on-path attacker can delay packets between a client 276 and server exists in all time protocols operating on insecure 277 networks and its mitigations are limited within the protocol with a 278 clock which is not yet synchronised. Increased path diversity and 279 protocol support for synchronisation across multiple heterogeneous 280 sources are likely the most effective mitigations. 282 5.2. Payload manipulation 284 Conversely on-path attackers who can manipulate timestamps could also 285 speed up a client's clock, also resulting into drift-related 286 malfunctions and errors such as incorrect expiration of public 287 certificates on the affected hosts. An attacker may also manipulate 288 other data in flight to disrupt service and cause de-synchronisation. 289 In both cases having message authentication with a regular key 290 rotation interval should mitigate; however consideration should be 291 made for hardware based timestamping. 293 5.3. Denial of Service and Amplification 295 NTPv4 has previously suffered from DDoS amplification attacks using a 296 combination of IP address spoofing with a private mode commands used 297 in many NTP implementations, leading to an attacker being able to 298 orders of magnitude of traffic to a victim IP address. Current 299 mitigation uses a combination of disabling the use of private mode 300 commands, in addition to encouraging network operators to implement 301 BCP 38 [RFC2827]. Additional mitigations in future protocol 302 specification should reduce the amplification factor in request/ 303 response payload sizes [drdos-amplification] through the use of 304 padding and consideration of payload data. 306 6. IANA Considerations 308 This document makes no requests of IANA. 310 7. Security Considerations 312 As this document is intended to create discussion and consensus, it 313 introduces no security considerations of its own. 315 8. References 317 8.1. Normative References 319 [I-D.ietf-ntp-roughtime] 320 Malhotra, A., Langley, A., Ladd, W., and M. Dansarie, 321 "Roughtime", Work in Progress, Internet-Draft, draft-ietf- 322 ntp-roughtime-05, 24 May 2021, 323 . 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 332 Defeating Denial of Service Attacks which employ IP Source 333 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 334 May 2000, . 336 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 337 "Network Time Protocol Version 4: Protocol and Algorithms 338 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 8.2. Informative References 347 [drdos-amplification] 348 "Amplification and DRDoS Attack Defense -- A Survey and 349 New Perspectives", n.d., 350 . 352 [IEEE-1588-2008] 353 "IEEE Standard for a Precision Clock Synchronization 354 Protocol for Networked Measurement and Control Systems", 355 n.d.. 357 [ntp-misuse] 358 "NTP server misuse and abuse", n.d., 359 . 362 [ntppool] "pool.ntp.org: the internet cluster of ntp servers", n.d., 363 . 365 Appendix A. Acknowledgements 367 The author would like to thank Doug Arnold and Hal Murray for 368 contributions to this document, and would like to acknowledge Daniel 369 Franke, Watson Ladd, Miroslav Lichvar for their existing documents 370 and ideas. The author would also like to thank Angelo Moriondo, 371 Franz Karl Achard, and Malcom McLean for providing the author with 372 motivation. 374 Author's Address 376 James Gruessing 377 Nederlandse Publieke Omroep 378 Postbus 26444 379 1202 JJ Hilversum 380 Netherlands 382 Email: james.ietf@gmail.com