draft-ietf-ntp-reqs-00.txt   draft-ietf-ntp-reqs-01.txt 
Network Time Protocol D. Plonka Network Time Protocol D. Plonka
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Expires: January 11, 2006 July 10, 2005 Expires: April 27, 2006 October 24, 2005
Requirements for Network Time Protocol Version 4 Requirements for Network Time Protocol Version 4
draft-ietf-ntp-reqs-00 draft-ietf-ntp-reqs-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines requirements for the Network Time Protocol This document defines requirements for the Network Time Protocol
(NTP) Version 4. NTP provides the mechanisms to synchronize time and (NTP) Version 4. NTP provides the mechanisms to synchronize time and
coordinate time distribution amongst internet hosts. coordinate time distribution amongst internet hosts.
Table of Contents Editorial Notes
1. NTP Requirements Open Issues . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 6
4.1 Clock Discipline . . . . . . . . . . . . . . . . . . . . . 6
4.2 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Wander . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
5.1 Configuration Requirements . . . . . . . . . . . . . . . . 7
5.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 7
5.1.2 Automatic, Autonomous Configuration . . . . . . . . . 7
5.1.3 Vendor Pre-configuration . . . . . . . . . . . . . . . 7
5.1.4 Administrative Domains . . . . . . . . . . . . . . . . 8
5.1.5 Key Distribution . . . . . . . . . . . . . . . . . . . 8
5.2 System Performance . . . . . . . . . . . . . . . . . . . . 8
5.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . 8
5.2.2 Client Performance Requirements . . . . . . . . . . . 8
5.2.3 Server Performance Requirements . . . . . . . . . . . 8
5.3 Security Requirements . . . . . . . . . . . . . . . . . . 8
5.4 Internet Protocol Version 6 Requirements . . . . . . . . . 8
5.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 8
5.5.1 Authentication & Access Control . . . . . . . . . . . 9
5.5.2 Client/Peer Rejection . . . . . . . . . . . . . . . . 9
5.6 Longevity, Persistence . . . . . . . . . . . . . . . . . . 9
5.6.1 Reconfiguration . . . . . . . . . . . . . . . . . . . 9
6. Simple Network Time Protocol Requirements . . . . . . . . . . 9
7. Operational Requirements . . . . . . . . . . . . . . . . . . . 10
7.1 Client Poll Interval . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1 Normative References . . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
This Internet Draft's editor maintains the most current revision at This Internet Draft's editor maintains the most current revision at
http://net.doit.wisc.edu/~plonka/ntp-reqs/ [5]. You may find an http://net.doit.wisc.edu/~plonka/ntp-reqs/ [5]. You may find an
updated document there if draft submission cut-offs have delayed its updated document there if draft submission cut-offs have delayed its
availability elsewhere. availability elsewhere.
In this revision of this Internet Draft the keyword "FIXME" is used In this this Internet Draft the keyword "FIXME" is used to mark
to mark locations where text will likely be added or modified. In locations where text will likely be added or modified. In subsequent
subsequent revisions these might be changed to XML comments in the revisions these might be changed to XML comments in the original
original source file, but for now they indicate the early stage of source file, but for now they indicate the early stage of this draft.
this draft.
1. NTP Requirements Open Issues NTP Requirements Open Issues
1. How can we best address SNTP? Currently SNTP Version 4 is 1. Is the leap seconds issue sufficiently addressed in the new Leap
defined by its own Informational RFC (RFC 2030). This editor's Seconds sub-section? Is it an issue that the (non-standard)
suggestion is that we either have our new NTP Version 4 documents AutoKey protocol was used to distribute the leapseconds table?
each contain a SNTP section for the SNTP-pertinent content or to
have a new standards-track SNTPv4 protocol document as a
companion to the NTPv4 protocol document. The intent is to make
our documents as clear as possible to implementors only
interested in SNTP, since it is likely to enjoy (or suffer
from...) the largest number of distinct, home-grown
implementations. In either case, our new NTPv4 RFC(s) would then
make RFC 2030 obsolete.
2. Should Operation Requirements be included in our NTP Requirements 2. Amongst the NTP WG documents, where will the official terminology
document? One could argue this is BCP, but it also could have a (definitions) be? Presumably there's more content to take from
major impact on the robustness of NTP as implemented, especially the NTP community's documents.
when utilizing public servers on the Internet.
3. The requirements draft editor needs some contributed text and 3. What's "iburst" and how does it affect the polling interval
review especially for the Algorithm Requirements section. requirements?
2. Introduction Revision History
The following is the recent revision history of this document.
$Log: draft-ietf-ntp-reqs.xml,v $
Revision 1.6 2005/10/24 04:56:11 plonka
Moved the open issues and revison history to an editorial
notes preface to fix section numbers.
Mentioned SNTP clients when defining client in the
terminology section.
Did the following edits as suggested by David Mills on the
mailing list:
* in the definition of broadcast in the terminology
section, mentioned that NTP's broadcast mode utilizes
multicast in IPv6.
* In the algorithm requirements section, removed mention of
various macros such as MAXSTRAT, MAXSKEW, etc.
Introduced MAXPOLL, since that has clear requirements.
* reorganized and added text to the algorithm requirements
section, including introducing the various algorithm
sub-sections.
* clarified that SNTP clients are divorced from a number of
algorithm requirements that "full" NTP hosts must use.
* Changed the accuracy section to note that NTP is best
effort, but added some text about service expectations.
* added to the definitions of jitter and wander in the
terminology section.
* with regard to configuring multiple servers, changed the
text to say that 4 should be configurable.
* mentioned that implementations should signal pending
leap-seconds to the OS.
* added some text regarding reconfiguration when NTP
server(s) are unreachable.
As suggested by Danny Mayer on the mailing list, removed the
reference to "master/slave" mode.
Added an item about leap seconds based on David Mill's input
on the mailing list.
Revision 1.5 2005/10/21 20:46:22 plonka
Resolved the SNTP open issue by devoting a section of this draft to
SNTP.
Resolved the Operational Requirements open issue by temporily
devoting a section of this draft to Operational Requirements to
subsequently be moved to a BCP draft.
Added the Management Information Requirements section. This was
based on discussion noted in the minutes from the WG meeting at
IETF63.
Revision 1.4 2005/10/21 19:37:54 plonka
fixed a typo: s/recipent/recipient/
removed reference to the AutoKey protocol and mentioned that
implementations must use an IETF standard method to verify server
identity, and should use a corresponding standard key distribution
protocol. This is based on discussion noted in the minutes from the
WG meeting at IETF63.
added the Revision History
upped the revision number in prep for next submission of this draft
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 7
3.1 Poll Algorithm . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Clock Discipline Algorithm . . . . . . . . . . . . . . . . 8
3.3 Clock Filter Algorithm . . . . . . . . . . . . . . . . . . 9
3.4 Clock Selection Algorithm . . . . . . . . . . . . . . . . 9
3.5 Clustering Algorithm . . . . . . . . . . . . . . . . . . . 9
3.6 Combining Algorithm . . . . . . . . . . . . . . . . . . . 9
3.7 Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7.1 Leap Seconds . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 9
4.1 Configuration Requirements . . . . . . . . . . . . . . . . 10
4.1.1 Manual Configuration . . . . . . . . . . . . . . . . . 10
4.1.2 Automatic, Autonomous Configuration . . . . . . . . . 10
4.1.3 Vendor Pre-configuration . . . . . . . . . . . . . . . 10
4.1.4 Administrative Domains . . . . . . . . . . . . . . . . 10
4.1.5 Key Distribution . . . . . . . . . . . . . . . . . . . 10
4.2 System Performance . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Client Performance Requirements . . . . . . . . . . . 11
4.2.3 Server Performance Requirements . . . . . . . . . . . 11
4.3 Security Requirements . . . . . . . . . . . . . . . . . . 11
4.4 Internet Protocol Version 6 Requirements . . . . . . . . . 11
4.5 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1 Authentication & Access Control . . . . . . . . . . . 11
4.5.2 Client/Peer Rejection . . . . . . . . . . . . . . . . 12
4.6 Longevity, Persistence . . . . . . . . . . . . . . . . . . 12
4.6.1 Reconfiguration . . . . . . . . . . . . . . . . . . . 12
5. Simple Network Time Protocol Requirements . . . . . . . . . . 12
5.1 SNTP Client Poll Interval . . . . . . . . . . . . . . . . 12
6. Management Information Requirements . . . . . . . . . . . . . 13
7. Operational Requirements . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1 Normative References . . . . . . . . . . . . . . . . . . . 14
11.2 Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction
This document defines requirements for the Network Time Protocol This document defines requirements for the Network Time Protocol
(NTP) Version 4. NTP provides the mechanisms to synchronize time and (NTP) Version 4. NTP provides the mechanisms to synchronize time and
coordinate time distribution amongst internet hosts. NTP Version 4 coordinate time distribution amongst internet hosts. NTP Version 4
represents the latest improvements to NTP currently available and in represents the latest improvements to NTP currently available and in
use today. Earlier versions and portions of NTP have been specified use today. Earlier versions and portions of NTP have been specified
by RFCs 1305 [1], 1769 [2], and 2030 [3]. by RFCs 1305 [1], 1769 [2], and 2030 [3].
Accurate and syncronized time is a requirement, or distinct Accurate and syncronized time is a requirement, or distinct
advantage, for numerous applications. These applications include advantage, for numerous applications. These applications include
skipping to change at page 4, line 35 skipping to change at page 5, line 50
applications, are direct consequences of NTP's goals, or are expected applications, are direct consequences of NTP's goals, or are expected
for interoperability and end-user experience with the versions of NTP for interoperability and end-user experience with the versions of NTP
that are in widespread use today. that are in widespread use today.
In this document, the words "must", "may", and "should" appear in In this document, the words "must", "may", and "should" appear in
lowercase since this is not a formal specification of the protocol. lowercase since this is not a formal specification of the protocol.
However, the use of these words here suggests that corresponding However, the use of these words here suggests that corresponding
portions of the NTPv4 protocol specifications use these keywords in portions of the NTPv4 protocol specifications use these keywords in
uppercase with the meanings defined by RFC 2119 [6]. uppercase with the meanings defined by RFC 2119 [6].
3. Terminology 2. Terminology
The following terms are used in this document: The following terms are used in this document:
host - an internet host that runs an implementation of NTP. host - an internet host that runs an implementation of NTP.
client - an NTP host that is the recipent of a disseminated time client - an NTP host that is the recipient of a disseminated time
value. value. A subset of clients are Simple Network Time Protocol
(SNTP) clients.
server - an NTP host that is the source of a disseminated time server - an NTP host that is the source of a disseminated time
value. value.
time - the value by which events are ordered in a given frame of time - the value by which events are ordered in a given frame of
reference. For NTP, the frame of reference is an epoch, and the reference. For NTP, the frame of reference is an epoch, and the
time value is expressed in whole and fractional seconds since that time value is expressed in whole and fractional seconds since that
epoch. epoch.
oscillator - a generator capable of a precise frequency (relative oscillator - a generator capable of a precise frequency (relative
skipping to change at page 5, line 29 skipping to change at page 6, line 43
calendar - a mapping from epoch in some frame of reference to the calendar - a mapping from epoch in some frame of reference to the
times and dates used in everyday life. times and dates used in everyday life.
stability - a term used to classify the performance for clock stability - a term used to classify the performance for clock
oscillators, the systematic variation of frequency with time, oscillators, the systematic variation of frequency with time,
synonymous with aging, drift, trends, etc. synonymous with aging, drift, trends, etc.
jitter - a term used to classify the performance for clock jitter - a term used to classify the performance for clock
oscillators, the short-term variations in frequency with oscillators, the short-term variations in frequency with
components greater than 10 Hz. components greater than 10 Hz. As defined in NTP, jitter is the
exponential average of the RMS differences between samples in a
sliding window of time measurements.
wander - a term used to classify the performance for clock wander - a term used to classify the performance for clock
oscillators, the long-term variations in frequency with components oscillators, the long-term variations in frequency with components
less than 10 Hz. less than 10 Hz. As defined in NTP, wander is the exponential
average of the RMS differences between samples in a sliding window
of frequency measurements.
stratum - the hierarchical layer at which an NTP host exists. The stratum - the hierarchical layer at which an NTP host exists. The
host(s) at the lowest layer (stratum 1) get their time value from host(s) at the lowest layer (stratum 1) get their time value from
a primary (non-NTP) time source and disseminate the time to hosts a primary (non-NTP) time source and disseminate the time to hosts
of the same or the next higher stratum. of the same or the next higher stratum.
subnet - the subset of network hosts that participate in a given subnet - the subset of network hosts that participate in a given
NTP arrangement of servers and clients. Typically this arrangment NTP arrangement of servers and clients. Typically this arrangment
is a hierarchical tree structure in which servers of the lowest is a hierarchical tree structure in which servers of the lowest
strata are at the root and NTP servers of increasing strata branch strata are at the root and NTP servers of increasing strata branch
skipping to change at page 6, line 9 skipping to change at page 7, line 27
to a non-NTP, typically national, time standard, such as by radio, to a non-NTP, typically national, time standard, such as by radio,
satellite, or modem. satellite, or modem.
secondary server/client - an NTP host at stratum 2 or more that secondary server/client - an NTP host at stratum 2 or more that
synchronizes to primary server(s) via a hierarchical subnet. synchronizes to primary server(s) via a hierarchical subnet.
NTP modes - one of the modes in which an NTP host operates: NTP modes - one of the modes in which an NTP host operates:
client/server mode - a unicast mode of operation in which an client/server mode - a unicast mode of operation in which an
NTP server host disseminates a time value to an NTP client NTP server host disseminates a time value to an NTP client
host. This mode has also been referred to as "master/slave". host.
symmetric mode - a mode of operation in which NTP hosts are symmetric mode - a mode of operation in which NTP hosts are
equal peers, or servers of the same stratum. equal peers, or servers of the same stratum.
multicast mode - a mode of operation in which NTP clients multicast mode - a mode of operation in which NTP clients
discover their NTP server(s) by receiving multicast discover their NTP server(s) by receiving multicast
advertisements from the available servers. advertisements from the available servers.
broadcast mode - a mode of intra-LAN operation in which NTP broadcast mode - a mode of intra-LAN operation in which NTP
clients receive unsolicited broadcasts of the time value, clients receive unsolicited broadcasts of the time value,
typically from a single NTP server. typically from a single NTP server. The details of the
broadcast paradigm differ based upon the Internet address
4. Algorithm Requirements family. For IPv4, the broadcast mechanism is used. For IPv6,
its multicast mechanism is used instead, even though this is
still referred to as NTP's broadcast mode.
FIXME: consider common variable definitions whis should be compile 3. Algorithm Requirements
time or runtime configurable?: such as MAXSTRAT, MAXSKEW, MAXDISP,
MINCLOCK, MAXCLOCK
FIXME: We need some help here from someone that knows the NTP FIXME: We need some help here from someone that knows the NTP
reference implementation's (ntpd) code. Which of the compile-time reference implementation's (ntpd) code. Which of the compile-time
definitions (macros) are required to have the values defined in the definitions (macros) are required to have the values defined in the
implementation, as opposed to being configurable within a required implementation, as opposed to being configurable within a required
range? We should also define the range required to be supported. range? We should also define the range required to be supported.
MINPOLL is one example.
4.1 Clock Discipline NTP hosts that are not merely SNTP clients are required to run the
NTP algorithms. When using only one source, these include clock
filter and clock discipline algorithms. When multiple sources are
used, additional selection and clustering algorithms are required and
a combining algorithm should be used. Since SNTP clients do not
operate in symmetric modes, their requirements are somewhat relaxed.
Any SNTP client that does not meet these NTP algorithm requirements
cannot function as an NTP server.
3.1 Poll Algorithm
The NTP poll adjust algorithm is designed to protect the network. As
such it is required of all NTP hosts, including SNTP clients. It
backs off the poll rate both when the system clock converges within
tolerance and when the source becomes unreachable.
An NTP client should randomize its initial inter-query timeout, and
other intervals over a narrow range.
FIXME: add details
3.2 Clock Discipline Algorithm
Note that SNTP clients are not required to discipline their system
clock. The following clock discipline requirements apply to all
other NTP hosts.
If timestamps are determined directly by an attached reference clock,
say by a shared register array with oscillator phase locked to a GPS
receiver, then a clock discipline algorithm is not required.
Otherwise, such as when an implementation determines timestamps from
an ordinary (uncompensated) quartz oscillator performing a time of
day function, the implementation must discipline the clock in both
time and frequency. This generally requires a second-order phase-
lock loop (PLL).
NTP implementations should include, at least, a clock discipline
algorithm that utilizes a traditional linear phase-lock loop (PLL).
Furthermore, NTP implementations may include a loop filter and Furthermore, NTP implementations may include a loop filter and
variable frequency oscillator (VFO) that functions as a nonlinear, variable frequency oscillator (VFO) that functions as a nonlinear,
hybrid phase/frequency-lock (P/F) feedback loop to minimize jitter hybrid phase/frequency-lock (P/F) feedback loop to minimize jitter
and wander and decrease time to converge as compared with a linear and wander and decrease time to converge as compared with a linear
system only. system only.
When available, NTP implementations should use host system-provided When available, NTP implementations should use host system-provided
time adjustment routines so that clock readings are monotonically time adjustment routines so that clock readings are monotonically
increasing such that no two successive clock readings could be the increasing such that no two successive clock readings could be the
same. same.
4.2 Accuracy 3.3 Clock Filter Algorithm
Current NTP implementations and deployments generally have accuracies The clock filter algorithm is required of all NTP servers. FIXME
of a few milliseconds in Local-Area Networks, and up to a few tens of
milliseconds in global Wide-Area Networks. Given the best of
implementation environments, worst-case error cannot exceed one-half
the roundtrip delay measured by the client.
4.3 Jitter 3.4 Clock Selection Algorithm
FIXME The clock selection algorithm applies to NTP hosts utilizing more
than one source. FIXME
4.4 Wander 3.5 Clustering Algorithm
FIXME The clustering algorithm applies to NTP hosts utilizing more than one
source. FIXME
5. Protocol Requirements 3.6 Combining Algorithm
The combining algorithm is recommended of NTP hosts utilizing more
than one source. FIXME
3.7 Accuracy
While NTP service is best effort with no guarantees, current NTP
implementations and deployments generally have accuracies of a few
milliseconds in Local-Area Networks, and up to a few tens of
milliseconds in global Wide-Area Networks. As such, this sets the
service expectation.
The absolute error relative to the time on the server (which could be
in error itself) is not greater than half the roundtrip delay plus
dispersion plus. It is correct to say the worst case error is
bounded by the synchronization distance to the primary source. While
these observations do not lead to strict requirements, it does,
again, indicate the service expectation.
3.7.1 Leap Seconds
Implementations should signal the operating system of a pending leap
second event on, but not before, the day of the leap second event.
Ordinarily, this takes the form of an operating system function call.
4. Protocol Requirements
NTP server implementations must include support for unicast mode of NTP server implementations must include support for unicast mode of
client/server operation and symmetric mode so that a robust client/server operation and symmetric mode so that a robust
hierarchical subnet of NTP hosts can be constructed since this is hierarchical subnet of NTP hosts can be constructed since this is
NTP's basis for reliability. NTP's basis for reliability.
Note that an SNTP client cannot operate in symmetric mode.
NTP server implementations may provide a multicast mode to serve NTP server implementations may provide a multicast mode to serve
multiple IP subnets in a network. It may also provide a broadcast multiple IP subnets in a network. It may also provide a broadcast
mode in which unsolicited time values are disseminated to hosts on mode in which unsolicited time values are disseminated to hosts on
its LAN. its LAN.
5.1 Configuration Requirements 4.1 Configuration Requirements
Implementations must support the configuration of NTP servers using Implementations must support the configuration of NTP servers using
the Domain Name System. Multiple servers, e.g. up to six, should be the Domain Name System. Multiple servers, e.g. four, should be able
able to be configured, since diverse network paths to multiple to be configured, since diverse network paths to multiple servers is
servers is the basis of NTP's reliability. the basis of NTP's reliability.
5.1.1 Manual Configuration 4.1.1 Manual Configuration
FIXME Implementations should be able to configure the minimum poll
interval.
5.1.2 Automatic, Autonomous Configuration FIXME: what else?
4.1.2 Automatic, Autonomous Configuration
FIXME: discuss autonomous configuration using multicast (for FIXME: discuss autonomous configuration using multicast (for
diversity and redundancy) with cryptographically secure source diversity and redundancy) with cryptographically secure source
discovery. discovery.
Autonomously configured clients must periodically refresh their list Autonomously configured clients must periodically refresh their list
of suitable servers. of suitable servers.
5.1.3 Vendor Pre-configuration 4.1.3 Vendor Pre-configuration
FIXME: RFC 4085 [4] defines some best current practice for SNTP FIXME: RFC 4085 [4] defines some best current practice for SNTP
operation. operation.
5.1.4 Administrative Domains 4.1.4 Administrative Domains
FIXME FIXME
5.1.5 Key Distribution 4.1.5 Key Distribution
FIXME FIXME
5.2 System Performance 4.2 System Performance
FIXME FIXME
5.2.1 Scalability 4.2.1 Scalability
FIXME: how many servers/peers can be configured? How many strata? FIXME: how many servers/peers can be configured? How many strata?
5.2.2 Client Performance Requirements 4.2.2 Client Performance Requirements
FIXME FIXME
5.2.3 Server Performance Requirements 4.2.3 Server Performance Requirements
FIXME FIXME
5.3 Security Requirements 4.3 Security Requirements
Implementations must support the MD5-based symmetric key cryptography Implementations must support the MD5-based symmetric key cryptography
with preshared keys. This scheme is defined in RFC 1305 [1]. with preshared keys. This scheme is defined in RFC 1305 [1].
Implementations must support public key cryptography as defined by Implementations must support the use of an IETF standard public key
the so-called "Autokey" protocol, which is used to verify server cryptography scheme to verify server identity. An accompanying IETF
standard key distribution protocol should be supported.
Implementations may support public key cryptography as defined by the
so-called "Autokey" protocol, which is used to verify server
identity. If employed, the implemetation must regenerate keys in a identity. If employed, the implemetation must regenerate keys in a
timely manner to resist compromise. FIXME: add details timely manner to resist compromise.
5.4 Internet Protocol Version 6 Requirements 4.4 Internet Protocol Version 6 Requirements
NTPv4 Requirements defined in this document apply without regard to NTPv4 Requirements defined in this document apply without regard to
whether the implementation runs atop IPv4 or IPv6, or both. So, an whether the implementation runs atop IPv4 or IPv6, or both. So, an
implementation that supports IPv4 must support all of its NTP modes implementation that supports IPv4 must support all of its NTP modes
and cryptographic features available using IPv6 whenever IPv6 is and cryptographic features available using IPv6 whenever IPv6 is
available on the underlying platform. available on the underlying platform.
5.5 Robustness 4.5 Robustness
FIXME FIXME
5.5.1 Authentication & Access Control 4.5.1 Authentication & Access Control
NTP has authentication requirements to protect the resulting system NTP has authentication requirements to protect the resulting system
from faulty implementations, improper operation, and malicious from faulty implementations, improper operation, and malicious
attacks. These are important in a distrubuted protocol so that attacks. These are important in a distrubuted protocol so that
damage does not propograte throughout the NTP subnet. damage does not propograte throughout the NTP subnet.
NTP implementations must attempt to limit access to trusted peers. NTP implementations must attempt to limit access to trusted peers.
Trivially, this is first done by sanity checking NTP packet content Trivially, this is first done by sanity checking NTP packet content
to ignore duplicates and to timestamp packets as a one-time pad. to ignore duplicates and to timestamp packets as a one-time pad.
However, NTP implementations should also take measures to prevent However, NTP implementations should also take measures to prevent
unauthorized message-stream modification by using a crypto-checksum unauthorized message-stream modification by using a crypto-checksum
computed by the sender and checked by the receiver. computed by the sender and checked by the receiver.
5.5.2 Client/Peer Rejection 4.5.2 Client/Peer Rejection
NTP server implementations should include the ability to return a so- NTP server implementations should include the ability to return a so-
called "Kiss-o'-Death" (KoD) packet to a configured or discovered set called "Kiss-o'-Death" (KoD) packet to a configured or discovered set
of unwanted NTP cleints. NTP clients, upon receiving the KoD packet, of unwanted NTP clients. NTP clients, upon receiving the KoD packet,
should cease communications with the given NTP server host that sent should cease communications with the given NTP server host that sent
the packet, and instead rely on their other configured servers. the packet, and instead rely on their other configured servers.
5.6 Longevity, Persistence 4.6 Longevity, Persistence
FIXME FIXME
5.6.1 Reconfiguration 4.6.1 Reconfiguration
FIXME: mention re-resolving DNS names here? NTP clients must attempt to reconfigure when they discover that their
server is unreachable. This potentially involves, but is not
necessarily limited to: performing a DHCP query to discover an NTP
server, resolve the server DNS names, and restart the security
protocol.
6. Simple Network Time Protocol Requirements 5. Simple Network Time Protocol Requirements
The Simple network Time Protocol (SNTP) is a slight variation of NTP The Simple network Time Protocol (SNTP) is a slight variation of NTP
in which the clients simply receive periodic time values to update in which the clients simply receive periodic time values to update
their local clocks. Today, SNTP is the most common use of the NTP their local clocks. Today, SNTP is the most common use of the NTP
infrastructure. Also, SNTP is a small subset of the overall NTP infrastructure. Also, SNTP is a small subset of the overall NTP
functionality, so it has many unique client implementations. This functionality, so it has many unique client implementations. This
plurality and ubiquity of SNTP clients warrants special attention as plurality and ubiquity of SNTP clients warrants special attention as
we define requirements for implementations. we define requirements for implementations.
SNTP Version 4 is defined by RFC 2030 [3] and was improved upon in a SNTP Version 4 is defined by RFC 2030 [3] and was improved upon in a
more recent draft by Mills, et al. (FIXME: temporarily named "rfc- more recent draft by Mills, et al. (FIXME: temporarily named "rfc-
xxxx"). RFC 4085 [4] defines some best current practice for SNTP xxxx"). RFC 4085 [4] defines some best current practice for SNTP
operation. operation.
An SNTP client should respect the KoD access-control mechanism. An SNTP client may use any means available to set its clock based on
the received NTP packet. That is, an SNTP client is not required to
7. Operational Requirements conform to the same rules that an NTP client must regarding the NTP
algorithms.
FIXME: Do operational requirements belong here or in a seperate An SNTP client should respect the KoD access-control mechanism.
document? E.g. stratum 1 servers should be synchronized to a non-NTP
time standard, stratum 2 servers must synchronized to primary servers
in the NTP hierarchy.
7.1 Client Poll Interval 5.1 SNTP Client Poll Interval
An SNTP client must not use a poll interval less than one minute. An SNTP client must not use a poll interval less than one minute.
An SNTP client should increase the poll interval using exponential An SNTP client should increase the poll interval using exponential
backoff if ever the server does not respond and also as its required backoff if ever the server does not respond and also as its required
clock performance permits. clock performance permits.
An SNTP client should randomize its initial inter-query timeout. An SNTP client should randomize its initial inter-query timeout.
6. Management Information Requirements
Implementations may make management information available to remote
managers. If provided, such implementations must use a IETF standard
protocol. FIXME: If we elaborate on the management information base
itself, consider what is made available using the ntpdc utility.
This is the "special NTP query program" used to query the ntpd
daemon.
7. Operational Requirements
Operational requirements identified during the preparation of this
document may be collected here in anticipation of subsequently moving
them to a BCP draft.
E.g. stratum 1 servers should be synchronized to a non-NTP time
standard, stratum 2 servers must synchronized to primary servers in
the NTP hierarchy.
8. Security Considerations 8. Security Considerations
A reliable network time service, such as NTP means to be, requires A reliable network time service, such as NTP means to be, requires
provisions to prevent accidental or malicious attacks on its servers provisions to prevent accidental or malicious attacks on its servers
and clients. Furthermore, reliability requires that NTP clients can and clients. Furthermore, reliability requires that NTP clients can
verify the authenticity of NTP messages it receives. verify the authenticity of NTP messages it receives.
NTP implementations, whose requirements are described above, address NTP implementations, whose requirements are described above, address
security threats in a number of ways: security threats in a number of ways:
skipping to change at page 11, line 9 skipping to change at page 14, line 14
synchronization and dissemination system. synchronization and dissemination system.
9. IANA Considerations 9. IANA Considerations
This document creates no new requirements on IANA namespaces. This document creates no new requirements on IANA namespaces.
10. Acknowledgements 10. Acknowledgements
Most of the NTP information used as background for this document was Most of the NTP information used as background for this document was
drawn from David L. Mills' NTP documents, linked from [7] and [8]. drawn from David L. Mills' NTP documents, linked from [7] and [8].
Danny Mayer, Brian Haberman, and David Mills provided useful comments
or contributed text for this document.
11. References 11. References
11.1 Normative References 11.1 Normative References
[1] Mills, D., "Network Time Protocol (Version 3) Specification, [1] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[2] Mills, D., "Simple Network Time Protocol (SNTP)", RFC 1769, [2] Mills, D., "Simple Network Time Protocol (SNTP)", RFC 1769,
March 1995. March 1995.
 End of changes. 58 change blocks. 
126 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/