idnits 2.17.1 draft-gruessing-ntp-ntpv5-requirements-01.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: To provide the protocol MUST have the capability to be extended. The specification should specify 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 (December 29, 2020) is 1186 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 282 == Outdated reference: A later version (-09) exists of draft-ietf-ntp-roughtime-03 Summary: 1 error (**), 0 flaws (~~), 3 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 December 29, 2020 4 Intended status: Informational 5 Expires: July 2, 2021 7 NTPv5 use cases and requirements 8 draft-gruessing-ntp-ntpv5-requirements-01 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 July 2, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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. IP affinity . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.3. Timescales . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4. Leap seconds . . . . . . . . . . . . . . . . . . . . . . 4 69 3.4.1. Leap second smearing . . . . . . . . . . . . . . . . 4 70 3.5. Backwards compatibility to NTS and NTPv4 . . . . . . . . 4 71 3.6. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . 6 78 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 NTP version 4 [RFC5905] has seen active use for over a decade, and 84 within this time period the protocol has not only been extended to 85 support new requirements but also fallen victim to vulnerabilities 86 that have made it used for distributed denial of service (DDoS) 87 amplification attacks. 89 1.1. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 2. Use cases and existing deployments of NTP 99 There are several common scenarios for exxisting NTPv4 deployments; 100 publicly accessible NTP services such as the NTP Pool [ntppool] are 101 used to offer clock synchronisation for end users and embedded 102 devices, ISP provided servers to synchronise devices such as 103 customer-premesis equipment where reduced accuracy may be tollerable. 104 Depending on the network and path these deployments may be affected 105 by variable latency as well as throttling or blocking by providers. 107 Data centres and cloud computing providers also have deployed and 108 offer NTP services both for internal use and for customers, 109 particularly where the network is unable to offer or does not require 110 PTP [IEEE-1588-2008]. As these deployments are less likely to be 111 constrained by network latency or power the potential for higher 112 levels of accuracy and precision within the bounds of the protocol 113 are possible. 115 3. Requirements 117 At a high level, NTPv5 should be a protocol that is capable of 118 operating in both local networks and also over public internet 119 connections where packet loss, delay, and even filtering may occur. 121 Timestamp resolution SHOULD either match or exceed NTPv4, and be 122 extensible to represent any specified timescale. 124 The protocol SHOULD NOT transmit time zone information and should 125 focus on providing clock synchronisation as TZDIST [RFC7808] already 126 provides this ability. 128 3.1. IP affinity 130 Servers SHOULD have a new identifier that peers use as reference, 131 this SHOULD NOT be a FQDN, an IP address, or identifier tied to a 132 certificate. Servers SHOULD be able to migrate and change their 133 identifiers as stratum topologies or network configuration changes 134 occur. 136 Clients SHOULD re-establish connections with servers at an interval 137 to prevent attempting to maintain connectivity to dead host and give 138 network operators the ability to move traffic away from IP addresses 139 in a timely manner. This functionality should also compliment having 140 a "Kiss of Death" or similar message from servers. 142 3.2. Algorithms 144 Algorithms describing functions such as clock filtering, selection 145 and clustering SHOULD be omitted from the specification; the 146 specification should instead only provide only what is necessary to 147 describe protocol semantics and normative behaviours. 149 The working group should consider creating a separate informational 150 document to describe an algorithm to assist with implementation, and 151 to consider adopting future documents which describe new algorithms 152 as they are developed. Specifying client algorithms separately from 153 the protocol allows will allow NTPv5 to meet the needs of 154 applications with a variety of network properties and performance 155 requirements. It also allows for innovation in implementations 156 without sacrificing basic interoperability. 158 3.3. Timescales 160 Support SHOULD be available for other timescales in addition to UTC - 161 this should include, but not limited to the use of TAI or Modified 162 Julian Date as defined in [I-D.ietf-ntp-roughtime], however UTC SHALL 163 be the default timescale and MUST be supported by all 164 implementations. Consideration should be made to include listing the 165 supported timescales either as part of specific IANA parameter 166 registry, or as part of the extension registry. 168 3.4. Leap seconds 170 The specification or the protocol SHOULD be explicit about when a 171 leap second is being applied, and the protocol should allow for 172 transmiting an upcoming leap second ahead of the day it is to be 173 applicable. Nevertheless, due to network delays and the polling 174 interval, applications with NTP clients will need to manage the leap 175 second event at their local clock. 177 3.4.1. Leap second smearing 179 Server responses SHOULD include not only an indicator as to wether 180 the server supports smearing, but also if the current time being 181 transmitted is smeared. The protocol may also transmit the start/end 182 or duration of the smearing ahead of time. It MUST be possible for 183 clients to determine the unsmeared time of the timescale. 185 3.5. Backwards compatibility to NTS and NTPv4 187 The support for compatibility with other protocols SHOULD NOT prevent 188 addressing issues that have previous caused issues in deployments or 189 cause ossification of the protocol. Protocol ossification MUST be 190 addressed to prevent existing NTPv4 deployments which incorrectly 191 respond to clients posing as NTPv5 from causing issues. Forward 192 prevention of ossification (for a potential NTPv6 protocol in the 193 future) SHOULD also be taken into consideration. 195 The model for backward compatibility is servers that support mutliple 196 versions NTP and send a response in the same version as the request. 197 This does not preclude high stratum servers from acting as a client 198 in one version of NTP and a server in another. 200 3.6. Extensibility 202 To provide the protocol MUST have the capability to be extended. The 203 specification should specify that implementations MUST ignore unknown 204 extensions. Unknown extensions received by a server from a lower 205 stratum server SHALL not be added to response messages sent by the 206 server receiving these extensions. 208 4. IANA Considerations 210 Considerations should be made about the future of the existing IANA 211 registry for NTPv4 parameters. If NTPv5 becomes incompatible with 212 these parameters a new registry SHOULD be created. 214 5. Security Considerations 216 Encryption and authentication MUST be provided by the protocol 217 specification as a default and MUST be resistent to downgrade 218 attacks. The encryption used must have agility, allowing for the 219 protocol to update as more secure cryptography becomes known and 220 vulnerabilities are discovered. 222 The specification MAY consider leaving room for middleboxes which may 223 deliberately modify packets in flight for legitimate purposes. 224 Thought must be given around how this will be incorporated into any 225 applicable trust model. Downgrading attacks that could lead to an 226 adversary disabling or removing encryption or authentication MUST NOT 227 be possible in the design of the protocol. 229 Detection and reporting of server malfeasence SHOULD remain out of 230 scope of this specification as [I-D.ietf-ntp-roughtime] already 231 provides this capability as a core functionality of the protocol. 233 --back 235 6. Acknowledgements 237 The author would like to thank Doug Arnold for contributions to this 238 document, and would like to acknowledge Daniel Franke, Watson Ladd, 239 Miroslav Lichvar for their existing documents and ideas. The author 240 would also like to thank Angelo Moriondo, Franz Karl Achard, and 241 Malcom McLean for providing the author with motivation. 243 7. References 245 7.1. Normative References 247 [I-D.ietf-ntp-roughtime] 248 Malhotra, A., Langley, A., and W. Ladd, "Roughtime", 249 draft-ietf-ntp-roughtime-03 (work in progress), August 250 2020. 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, 254 DOI 10.17487/RFC2119, March 1997, 255 . 257 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 258 "Network Time Protocol Version 4: Protocol and Algorithms 259 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 260 . 262 [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution 263 Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, 264 . 266 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 267 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 268 May 2017, . 270 7.2. Informative References 272 [IEEE-1588-2008] 273 "IEEE Standard for a Precision Clock Synchronization 274 Protocol for Networked Measurement and Control Systems", 275 n.d.. 277 [ntppool] "pool.ntp.org: the internet cluster of ntp servers", n.d., 278 . 280 7.3. URIs 282 [1] https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing- 283 ntp-ntpv5-requirements 285 Author's Address 287 James Gruessing 289 Email: james.ietf@gmail.com