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.