idnits 2.17.1 draft-ietf-ntp-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 530. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2005) is 6864 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1305 (ref. '1') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1769 (ref. '2') (Obsoleted by RFC 2030, RFC 4330) ** Obsolete normative reference: RFC 2030 (ref. '3') (Obsoleted by RFC 4330) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Time Protocol D. Plonka 3 Internet-Draft University of Wisconsin 4 Expires: January 11, 2006 July 10, 2005 6 Requirements for Network Time Protocol Version 4 7 draft-ietf-ntp-reqs-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 11, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document defines requirements for the Network Time Protocol 41 (NTP) Version 4. NTP provides the mechanisms to synchronize time and 42 coordinate time distribution amongst internet hosts. 44 Table of Contents 46 1. NTP Requirements Open Issues . . . . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 6 50 4.1 Clock Discipline . . . . . . . . . . . . . . . . . . . . . 6 51 4.2 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 4.4 Wander . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 55 5.1 Configuration Requirements . . . . . . . . . . . . . . . . 7 56 5.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 7 57 5.1.2 Automatic, Autonomous Configuration . . . . . . . . . 7 58 5.1.3 Vendor Pre-configuration . . . . . . . . . . . . . . . 7 59 5.1.4 Administrative Domains . . . . . . . . . . . . . . . . 8 60 5.1.5 Key Distribution . . . . . . . . . . . . . . . . . . . 8 61 5.2 System Performance . . . . . . . . . . . . . . . . . . . . 8 62 5.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . 8 63 5.2.2 Client Performance Requirements . . . . . . . . . . . 8 64 5.2.3 Server Performance Requirements . . . . . . . . . . . 8 65 5.3 Security Requirements . . . . . . . . . . . . . . . . . . 8 66 5.4 Internet Protocol Version 6 Requirements . . . . . . . . . 8 67 5.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.5.1 Authentication & Access Control . . . . . . . . . . . 9 69 5.5.2 Client/Peer Rejection . . . . . . . . . . . . . . . . 9 70 5.6 Longevity, Persistence . . . . . . . . . . . . . . . . . . 9 71 5.6.1 Reconfiguration . . . . . . . . . . . . . . . . . . . 9 72 6. Simple Network Time Protocol Requirements . . . . . . . . . . 9 73 7. Operational Requirements . . . . . . . . . . . . . . . . . . . 10 74 7.1 Client Poll Interval . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1 Normative References . . . . . . . . . . . . . . . . . . . 11 80 11.2 Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 82 Intellectual Property and Copyright Statements . . . . . . . . 12 84 This Internet Draft's editor maintains the most current revision at 85 http://net.doit.wisc.edu/~plonka/ntp-reqs/ [5]. You may find an 86 updated document there if draft submission cut-offs have delayed its 87 availability elsewhere. 89 In this revision of this Internet Draft the keyword "FIXME" is used 90 to mark locations where text will likely be added or modified. In 91 subsequent revisions these might be changed to XML comments in the 92 original source file, but for now they indicate the early stage of 93 this draft. 95 1. NTP Requirements Open Issues 97 1. How can we best address SNTP? Currently SNTP Version 4 is 98 defined by its own Informational RFC (RFC 2030). This editor's 99 suggestion is that we either have our new NTP Version 4 documents 100 each contain a SNTP section for the SNTP-pertinent content or to 101 have a new standards-track SNTPv4 protocol document as a 102 companion to the NTPv4 protocol document. The intent is to make 103 our documents as clear as possible to implementors only 104 interested in SNTP, since it is likely to enjoy (or suffer 105 from...) the largest number of distinct, home-grown 106 implementations. In either case, our new NTPv4 RFC(s) would then 107 make RFC 2030 obsolete. 109 2. Should Operation Requirements be included in our NTP Requirements 110 document? One could argue this is BCP, but it also could have a 111 major impact on the robustness of NTP as implemented, especially 112 when utilizing public servers on the Internet. 114 3. The requirements draft editor needs some contributed text and 115 review especially for the Algorithm Requirements section. 117 2. Introduction 119 This document defines requirements for the Network Time Protocol 120 (NTP) Version 4. NTP provides the mechanisms to synchronize time and 121 coordinate time distribution amongst internet hosts. NTP Version 4 122 represents the latest improvements to NTP currently available and in 123 use today. Earlier versions and portions of NTP have been specified 124 by RFCs 1305 [1], 1769 [2], and 2030 [3]. 126 Accurate and syncronized time is a requirement, or distinct 127 advantage, for numerous applications. These applications include 128 distributed databases, stock market operations, document 129 timestamping, aviation traffic control, multimedia program 130 synchronization and teleconferncing, network measurement and control, 131 and many forms of event logging. 133 NTP's stated goals include: 135 Provide the best accuracy possible given network and server 136 conditions. 138 Resist failures including malicious attacks and implementation 139 bugs. 141 Be robust by utilizing Internet diversity and redundancy. 143 Automaticaly organize the subnet topology for best accuracy and 144 reliability. 146 Perform host authentication, independent of non-NTP services. 148 Furthermore, ancillary issues such as access control and non- 149 repudiation are considered goals as well. 151 The following requirements are prescribed or suggested by NTP 152 applications, are direct consequences of NTP's goals, or are expected 153 for interoperability and end-user experience with the versions of NTP 154 that are in widespread use today. 156 In this document, the words "must", "may", and "should" appear in 157 lowercase since this is not a formal specification of the protocol. 158 However, the use of these words here suggests that corresponding 159 portions of the NTPv4 protocol specifications use these keywords in 160 uppercase with the meanings defined by RFC 2119 [6]. 162 3. Terminology 164 The following terms are used in this document: 166 host - an internet host that runs an implementation of NTP. 168 client - an NTP host that is the recipent of a disseminated time 169 value. 171 server - an NTP host that is the source of a disseminated time 172 value. 174 time - the value by which events are ordered in a given frame of 175 reference. For NTP, the frame of reference is an epoch, and the 176 time value is expressed in whole and fractional seconds since that 177 epoch. 179 oscillator - a generator capable of a precise frequency (relative 180 to the given frame of reference) to a specified tolerance. 182 clock - an oscillator together with a counter which records the 183 (fractional) number of cycles since being initialized with a given 184 value at a given time. 186 timescale - The NTP timescale is based on the UTC timescale, such 187 that at the hour zero on 1 January 1972 (the beginning of the UTC 188 era) the NTP clock was set to 2,272,060,800 (the number of seconds 189 since hour zero on 1 January 1900). 191 epoch - the value of the counter at any given time. These are not 192 continuous and depend on the precision of the counter. 194 calendar - a mapping from epoch in some frame of reference to the 195 times and dates used in everyday life. 197 stability - a term used to classify the performance for clock 198 oscillators, the systematic variation of frequency with time, 199 synonymous with aging, drift, trends, etc. 201 jitter - a term used to classify the performance for clock 202 oscillators, the short-term variations in frequency with 203 components greater than 10 Hz. 205 wander - a term used to classify the performance for clock 206 oscillators, the long-term variations in frequency with components 207 less than 10 Hz. 209 stratum - the hierarchical layer at which an NTP host exists. The 210 host(s) at the lowest layer (stratum 1) get their time value from 211 a primary (non-NTP) time source and disseminate the time to hosts 212 of the same or the next higher stratum. 214 subnet - the subset of network hosts that participate in a given 215 NTP arrangement of servers and clients. Typically this arrangment 216 is a hierarchical tree structure in which servers of the lowest 217 strata are at the root and NTP servers of increasing strata branch 218 toward the leaves of the tree, that are a set of NTP clients. 220 primary server - an NTP server host at stratum 1 that synchronizes 221 to a non-NTP, typically national, time standard, such as by radio, 222 satellite, or modem. 224 secondary server/client - an NTP host at stratum 2 or more that 225 synchronizes to primary server(s) via a hierarchical subnet. 227 NTP modes - one of the modes in which an NTP host operates: 229 client/server mode - a unicast mode of operation in which an 230 NTP server host disseminates a time value to an NTP client 231 host. This mode has also been referred to as "master/slave". 233 symmetric mode - a mode of operation in which NTP hosts are 234 equal peers, or servers of the same stratum. 236 multicast mode - a mode of operation in which NTP clients 237 discover their NTP server(s) by receiving multicast 238 advertisements from the available servers. 240 broadcast mode - a mode of intra-LAN operation in which NTP 241 clients receive unsolicited broadcasts of the time value, 242 typically from a single NTP server. 244 4. Algorithm Requirements 246 FIXME: consider common variable definitions whis should be compile 247 time or runtime configurable?: such as MAXSTRAT, MAXSKEW, MAXDISP, 248 MINCLOCK, MAXCLOCK 250 FIXME: We need some help here from someone that knows the NTP 251 reference implementation's (ntpd) code. Which of the compile-time 252 definitions (macros) are required to have the values defined in the 253 implementation, as opposed to being configurable within a required 254 range? We should also define the range required to be supported. 256 4.1 Clock Discipline 258 NTP implementations should include, at least, a clock discipline 259 algorithm that utilizes a traditional linear phase-lock loop (PLL). 260 Furthermore, NTP implementations may include a loop filter and 261 variable frequency oscillator (VFO) that functions as a nonlinear, 262 hybrid phase/frequency-lock (P/F) feedback loop to minimize jitter 263 and wander and decrease time to converge as compared with a linear 264 system only. 266 When available, NTP implementations should use host system-provided 267 time adjustment routines so that clock readings are monotonically 268 increasing such that no two successive clock readings could be the 269 same. 271 4.2 Accuracy 273 Current NTP implementations and deployments generally have accuracies 274 of a few milliseconds in Local-Area Networks, and up to a few tens of 275 milliseconds in global Wide-Area Networks. Given the best of 276 implementation environments, worst-case error cannot exceed one-half 277 the roundtrip delay measured by the client. 279 4.3 Jitter 281 FIXME 283 4.4 Wander 285 FIXME 287 5. Protocol Requirements 289 NTP server implementations must include support for unicast mode of 290 client/server operation and symmetric mode so that a robust 291 hierarchical subnet of NTP hosts can be constructed since this is 292 NTP's basis for reliability. 294 NTP server implementations may provide a multicast mode to serve 295 multiple IP subnets in a network. It may also provide a broadcast 296 mode in which unsolicited time values are disseminated to hosts on 297 its LAN. 299 5.1 Configuration Requirements 301 Implementations must support the configuration of NTP servers using 302 the Domain Name System. Multiple servers, e.g. up to six, should be 303 able to be configured, since diverse network paths to multiple 304 servers is the basis of NTP's reliability. 306 5.1.1 Manual Configuration 308 FIXME 310 5.1.2 Automatic, Autonomous Configuration 312 FIXME: discuss autonomous configuration using multicast (for 313 diversity and redundancy) with cryptographically secure source 314 discovery. 316 Autonomously configured clients must periodically refresh their list 317 of suitable servers. 319 5.1.3 Vendor Pre-configuration 321 FIXME: RFC 4085 [4] defines some best current practice for SNTP 322 operation. 324 5.1.4 Administrative Domains 326 FIXME 328 5.1.5 Key Distribution 330 FIXME 332 5.2 System Performance 334 FIXME 336 5.2.1 Scalability 338 FIXME: how many servers/peers can be configured? How many strata? 340 5.2.2 Client Performance Requirements 342 FIXME 344 5.2.3 Server Performance Requirements 346 FIXME 348 5.3 Security Requirements 350 Implementations must support the MD5-based symmetric key cryptography 351 with preshared keys. This scheme is defined in RFC 1305 [1]. 353 Implementations must support public key cryptography as defined by 354 the so-called "Autokey" protocol, which is used to verify server 355 identity. If employed, the implemetation must regenerate keys in a 356 timely manner to resist compromise. FIXME: add details 358 5.4 Internet Protocol Version 6 Requirements 360 NTPv4 Requirements defined in this document apply without regard to 361 whether the implementation runs atop IPv4 or IPv6, or both. So, an 362 implementation that supports IPv4 must support all of its NTP modes 363 and cryptographic features available using IPv6 whenever IPv6 is 364 available on the underlying platform. 366 5.5 Robustness 368 FIXME 370 5.5.1 Authentication & Access Control 372 NTP has authentication requirements to protect the resulting system 373 from faulty implementations, improper operation, and malicious 374 attacks. These are important in a distrubuted protocol so that 375 damage does not propograte throughout the NTP subnet. 377 NTP implementations must attempt to limit access to trusted peers. 378 Trivially, this is first done by sanity checking NTP packet content 379 to ignore duplicates and to timestamp packets as a one-time pad. 381 However, NTP implementations should also take measures to prevent 382 unauthorized message-stream modification by using a crypto-checksum 383 computed by the sender and checked by the receiver. 385 5.5.2 Client/Peer Rejection 387 NTP server implementations should include the ability to return a so- 388 called "Kiss-o'-Death" (KoD) packet to a configured or discovered set 389 of unwanted NTP cleints. NTP clients, upon receiving the KoD packet, 390 should cease communications with the given NTP server host that sent 391 the packet, and instead rely on their other configured servers. 393 5.6 Longevity, Persistence 395 FIXME 397 5.6.1 Reconfiguration 399 FIXME: mention re-resolving DNS names here? 401 6. Simple Network Time Protocol Requirements 403 The Simple network Time Protocol (SNTP) is a slight variation of NTP 404 in which the clients simply receive periodic time values to update 405 their local clocks. Today, SNTP is the most common use of the NTP 406 infrastructure. Also, SNTP is a small subset of the overall NTP 407 functionality, so it has many unique client implementations. This 408 plurality and ubiquity of SNTP clients warrants special attention as 409 we define requirements for implementations. 411 SNTP Version 4 is defined by RFC 2030 [3] and was improved upon in a 412 more recent draft by Mills, et al. (FIXME: temporarily named "rfc- 413 xxxx"). RFC 4085 [4] defines some best current practice for SNTP 414 operation. 416 An SNTP client should respect the KoD access-control mechanism. 418 7. Operational Requirements 420 FIXME: Do operational requirements belong here or in a seperate 421 document? E.g. stratum 1 servers should be synchronized to a non-NTP 422 time standard, stratum 2 servers must synchronized to primary servers 423 in the NTP hierarchy. 425 7.1 Client Poll Interval 427 An SNTP client must not use a poll interval less than one minute. 429 An SNTP client should increase the poll interval using exponential 430 backoff if ever the server does not respond and also as its required 431 clock performance permits. 433 An SNTP client should randomize its initial inter-query timeout. 435 8. Security Considerations 437 A reliable network time service, such as NTP means to be, requires 438 provisions to prevent accidental or malicious attacks on its servers 439 and clients. Furthermore, reliability requires that NTP clients can 440 verify the authenticity of NTP messages it receives. 442 NTP implementations, whose requirements are described above, address 443 security threats in a number of ways: 445 The hosts in an NTP subnet should be able to be configurated to 446 cryptographically authentication servers using shared secret keys. 447 This is appropriate for hand-configured, engineered subnet 448 hierarchies amongst a relatively small set of trusted NTP hosts. 450 A specially crafted, NTP-specific public-key cryptography method 451 should be employed to simplify the authentication of servers by 452 hosts which are part of a potential large, possibly automatically 453 configured, NTP subnet. 455 The potentially large number and redundancy of NTP hosts and paths 456 amongst them, within an NTP subnet, mitigates some security 457 threats to the overall system. NTP takes advantage of this scale 458 by employing its algorithms to reject poorly performing, possibly 459 compromised, NTP servers to create an overal robust, reliable time 460 synchronization and dissemination system. 462 9. IANA Considerations 464 This document creates no new requirements on IANA namespaces. 466 10. Acknowledgements 468 Most of the NTP information used as background for this document was 469 drawn from David L. Mills' NTP documents, linked from [7] and [8]. 471 11. References 473 11.1 Normative References 475 [1] Mills, D., "Network Time Protocol (Version 3) Specification, 476 Implementation", RFC 1305, March 1992. 478 [2] Mills, D., "Simple Network Time Protocol (SNTP)", RFC 1769, 479 March 1995. 481 [3] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for 482 IPv4, IPv6 and OSI", RFC 2030, October 1996. 484 [4] Plonka, D., "Embedding Globally-Routable Internet Addresses 485 Considered Harmful", BCP 105, RFC 4085, June 2005. 487 11.2 Informative References 489 [5] "Requirements for Network Time Protocol Version 4 Project", 490 . 492 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 493 Levels", BCP 14, RFC 2119, March 1997. 495 [7] "The Network Time Protocol Project", . 497 [8] "The Network Time Synchronization Project", 498 . 500 Author's Address 502 David Plonka 503 University of Wisconsin - Madison 505 Email: plonka@doit.wisc.edu 506 URI: http://net.doit.wisc.edu/~plonka/ 508 Intellectual Property Statement 510 The IETF takes no position regarding the validity or scope of any 511 Intellectual Property Rights or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; nor does it represent that it has 515 made any independent effort to identify any such rights. Information 516 on the procedures with respect to rights in RFC documents can be 517 found in BCP 78 and BCP 79. 519 Copies of IPR disclosures made to the IETF Secretariat and any 520 assurances of licenses to be made available, or the result of an 521 attempt made to obtain a general license or permission for the use of 522 such proprietary rights by implementers or users of this 523 specification can be obtained from the IETF on-line IPR repository at 524 http://www.ietf.org/ipr. 526 The IETF invites any interested party to bring to its attention any 527 copyrights, patents or patent applications, or other proprietary 528 rights that may cover technology that may be required to implement 529 this standard. Please address the information to the IETF at 530 ietf-ipr@ietf.org. 532 Disclaimer of Validity 534 This document and the information contained herein are provided on an 535 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 536 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 537 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 538 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 539 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 540 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 542 Copyright Statement 544 Copyright (C) The Internet Society (2005). This document is subject 545 to the rights, licenses and restrictions contained in BCP 78, and 546 except as set forth therein, the authors retain all their rights. 548 Acknowledgment 550 Funding for the RFC Editor function is currently provided by the 551 Internet Society.