[ntpwg] ***SPAM*** FW: Comments on NTP draft -06
Odonoghue, Karen F CIV NSWCDD, W13
karen.odonoghue at navy.mil
Wed Jun 27 03:52:28 UTC 2007
This message from Stewart seems to have been bounced by
the ntp mailing list as spam.
Karen
-----Original Message-----
From: Stewart Bryant [mailto:stbryant at cisco.com]
Sent: Tuesday, June 26, 2007 8:48
To: Odonoghue, Karen F CIV NSWCDD, W13
Cc: NTP Working Group
Subject: Comments on NTP draft -06
Abstract
The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
described in RFC 1305, as well as previous versions of the protocol.
It includes a modified protocol header to accommodate the Internet
SB> What does "It" refer to?
Protocol Version 6 address family. NTPv4 includes fundamental
==========
The NTP subnet model includes a number of widely accessible primary
time servers synchronized by wire or radio to national standards.
The purpose of the NTP protocol is to convey timekeeping information
from these primary servers to secondary time servers and clients via
both private networks and the public Internet. Crafted algorithms
SB> What is a crafted algorithm?
mitigate errors that may result from network disruptions, server
failures and possible hostile actions. Servers and clients are
configured such that values flow towards clients from the primary
servers at the root via branching secondary servers.
=========
2. Modes of Operation
An NTP implementation operates as a primary server, secondary server
or client. A primary server is synchronized directly to a reference
clock, such as a GPS receiver or telephone modem service. A client
synchronizes to one or more upstream servers, but does not provide
synchronization to dependent clients. A secondary server has one or
more upstream servers and one or more downstream servers or clients.
All servers and clients who are fully NTPv4 compliance MUST implement
the entire suite of algorithms described in this document.
SB> Why do we insist on this, surely someone producing an improved
SB> algorithm should be able to use it and still claim conformance?
=========
As a standard practice, timing network topology should be organized
SB> Should or MUST?
to avoid timing loops and minimize the synchronization distance. In
NTP the subnet topology is determined using a variant of the Bellman-
Ford distributed routing algorithm, which computes the shortest-
distance spanning tree rooted on the primary servers. As a result of
SB> check the term spanning - shortest path tree might be better
SB> Do you mean server (singular) or servers (plural). If the latter
there
SB> may be a collection of SPTs rooted at each server
this design, the algorithm automatically reorganizes the subnet, so
as to produce the most accurate and reliable time, even when there
are failures in the timing network.
============
+-----------------------------------+
| Packet Variable <-- Variable |
+-----------------------------------+
| x.leap <-- s.leap |
| x.version <-- r.version |
| x.mode <-- 4 |
| x.stratum <-- s.stratum |
| x.poll <-- r.poll |
| x.precision <-- s.precision |
| x.rootdelay <-- s.rootdelay |
| x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid |
| x.reftime <-- s.reftime |
| x.org <-- r.xmt |
| x.rec <-- r.dst |
| x.xmt <-- clock |
| x.keyid <-- r.keyid |
| x.digest <-- md5 digest |
+-----------------------------------+
Figure 2: fast_xmit Packet Header
SB> This is not a header definition in an IETF sense. In any case this
SB> seems rather detailed this early in the spec given that no
definition
SB> of these fields is yet given.
============
The ephemeral associations compete among themselves. As new
ephemeral associations are mobilized, the client runs the mitigation
algorithms described in Section 10 and Section 11.2 for the best
candidates out of the population, the remaining ephemeral
associations are timed out and demobilized. In this way the
population includes only the best and freshest candidates to
SB> Freshest??
discipline the system clock. The reference implementation includes
intricate means to do this, but these are beyond the scope of this
document.
==========
The delay (delta) represents the round trip delay
between the client and server. The dispersion (epsilon) represents
the maximum error inherent in the measurement. It increases at a
SB> Shouldn't the term "maximum error" have some form of statistical
context?
rate equal to the maximum disciplined system clock frequency
tolerance (PHI), typically 15 PPM. The jitter (psi) is defined as
the root-mean-square (RMS) average of the most recent offset
differences, represents the nominal error in estimating the offset.
SB> In timing terms jitter has significance in representing the high
SB> frequency error term (as opposed to wander it's low frequency
counterpart
SB> Do we need to make it clear that we are using a different
definition.
While the theta, delta, epsilon, and psi statistics represent
measurements of the system clock relative to the each server clock
SB> typo "to the each"
=========
.....................................................................
. Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline.
. . . . Process .
.+--------+. +-----------+. +------------+ . .
.| |->| |. | | . .
.|Server 1| |Peer/Poll 1|->| | . .
.| |<-| |. | | . .
.+--------+. +-----------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+--------+. +-----------+. | | +-----------+. .
.| |->| |. | Selection |->| |. +------+ .
.|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | .
.| |<-| |. | Cluster | | Algorithm |. |Filter| .
.+--------+. +-----------+. | Algorithms |->| |. +------+ .
. . ^ . | | +-----------+. | .
. . | . | | . | .
.+--------+. +-----------+. | | . | .
.| |->| |. | | . | .
.|Server 3| |Peer/Poll 3|->| | . | .
.| |<-| |. | | . | .
.+--------+. +-----------+. +------------+ . | .
....................^.........................................|......
| . V .
| . +-----+ .
+--------------------------------------| VFO | .
. +-----+ .
. Clock .
. Adjust .
. Process .
............
Figure 3: Implementation Model
SB> Are three instances the norm, the max or just an example?
==========
The only arithmetic operation permitted on dates and timestamps is
twos-complement subtraction, yielding a 127-bit or 63-bit signed
SB> Why not addition to yield a time in the future?
===========
s = era * 2^(32) + timestamp.
Converting between NTP and system time can be a little messy, but
SB> but or and?
beyond the scope of this document. Note that the number of days in
===========
7. Data Structures
The NTP protocol state machines described in following sections are
SB>typo in the following
defined using state variables and code fragments defined in
Appendix A. State variables are separated into classes according to
their function in packet headers, peer and poll processes, the system
process and the clock discipline process. Packet variables represent
the NTP header values in transmitted and received packets. Peer and
poll variables represent the contents of the association for each
server separately. System variables represent the state of the
server as seen by its dependent clients. Clock discipline variables
SB> what is a dependent client?
represent the internal workings of the clock discipline algorithm.
Additional parameters and variable classes are defined in Appendix A.
==========
+-----------+-------+----------------------------------+
| Name | Value | Description |
+-----------+-------+----------------------------------+
| PORT | 123 | NTP port number |
SB> UDP port number assigned to NTP?
SB> BTW can you run NTP over DCP or perhaps one of the SCTP modes?
==========
+-----------+------------+-----------------------+
| Name | Formula | Description |
+-----------+------------+-----------------------+
| leap | leap | leap indicator (LI) |
| version | version | version number (VN) |
| mode | mode | mode |
| stratum | stratum | stratum |
| poll | poll | poll exponent |
| precision | rho | precision exponent |
| rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID |
| reftime | reftime | reference timestamp |
| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp |
| keyid | keyid | key ID |
| digest | digest | message digest |
+-----------+------------+-----------------------+
SB> do you mean formula or symbol - applies many places - but we meet it
SB> here without explanation?
Figure 8: Packet Header Variables
The NTP packet header follows the UDP and IP headers and the physical
header specific to the underlying transport network. Some fields use
multiple words and others are packed in smaller fields within a word.
SB> I don't remember seeing a definition of word yet? In any case
SB> don't we mean longword?
The NTP packet header shown in Figure 9 has 12 words followed by
optional extension fields and finally an optional message
authentication code (MAC) consisting of the key identifier field and
message digest field.
SB> It should be clearer (in the fig) which of the (long)words below
are each component mentioned by name above.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reference Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Extension Field 1 (variable) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Extension Field 2 (variable) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Digest (128) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Packet Header Format
===========
The extension fields are used to add optional capabilities, for
example, the Autokey security protocol [3]. The extension field
format is presented in order that the packet can be parsed without
knowledge of the extension field functions. The MAC is used by both
Burbank, et al. Expires November 25, 2007 [Page 20]
Internet-Draft NTPv4 Specification May 2007
Autokey and the symmetric key authentication scheme described in
Appendix A.
A list of the packet header variables is shown in Figure 8 and
described in detail below. Except for a minor variation when using
the IPv6 address family, these fields are backwards compatible with
NTPv3. The packet header fields apply to both transmitted packets (x
prefix) and received packets (r prefix). In Figure 9 the size of
some multiple-word fields is shown in bits if not the default 32
bits.
SB> Why not say bits in the fig and remove the text above which is
SB> mildly confusing
The header extends from the beginning of the packet to the end
of the Transmit Timestamp field.
SB> This would certainly be clearer with notations in the fig above
SB> or a set of smaller figures and a larger structure diagram
SB> or a better representation method such as pdf :)
The fields and associated packet variables (in parentheses) are
interpreted as follows:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the last minute of the current
month with values defined in Figure 10.
+-------+-------------------------------------------------+
| Value | Meaning |
+-------+-------------------------------------------------+
| 0 | no warning |
| 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds |
SB> surely last minute of the last day of the month has X seconds?
| 3 | alarm condition (the clock is not synchronized) |
+-------+-------------------------------------------------+
===========
It is customary to map the stratum value 0 in received packets to
MAXSTRAT (16) in the peer variable p.stratum and to map p.stratum
values of MAXSTRAT or greater to 0 in transmitted packets. This
allows reference clocks, which normally appear at stratum 0, to be
conveniently mitigated using the same algorithms used for external
sources.
SB> I do not understand the above para
Poll: 8-bit signed integer representing the maximum interval between
successive messages, in log2 seconds. Suggested default limits for
minimum and maximum poll intervals are 6 and 10, respectively.
Precision: 8-bit signed integer representing the precision of the
system clock, in log2 seconds. For instance a value of -18
corresponds to a precision of about one microsecond. The precision
can be determined when the service first starts up as the minimum
time of several iterations to read the system clock.
SB> I do not understand the last sentence
===============
+------+----------------------------------------------------------+
| ID | Clock Source |
+------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System |
| GAL | Galileo Positioning System |
| PPS | Generic pulse-per-second |
| IRIG | Inter-Range Instrumentation Group |
| WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
| DCF | LF Radio DCF77 Mainflingen, DE 77.5 kHz |
| HBG | LF Radio HBG Prangins, HB 75 kHz |
| MSF | LF Radio MSF Anthorn, UK 60 kHz (Rugby until April 2007) |
| JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz |
| LORC | MF Radio LORAN C 100 kHz |
| TDF | MF Radio Allouis, FR 162 kHz |
| CHU | HF Radio CHU Ottawa, Ontario |
| WWV | HF Radio WWV Ft. Collins, CO |
| WWVH | HF Radio WWVH Kauai, HI |
| NIST | NIST telephone modem |
| ACTS | NIST telephone modem |
| USNO | USNO telephone modem |
| PTB | European telephone modem |
+------+----------------------------------------------------------+
Figure 13: Reference Identifiers
SB> Is this going to be an IANA registry?
SB> Does there need to be an IEEE1588 code?
=============
Origin Timestamp (org): Time at the client when the request departed
for the server, in NTP timestamp format.
SB>Is there a reference interface point for this?
=============
The MAC consists of the Key Identifier followed by the Message
Digest. The message digest, or cryptosum, is calculated as in [8]
over all header and optional extension fields, but not the MAC
itself.
SB> All headers, or all NTP headers?
=============
A list of
the currently-defined kiss codes is given in Figure 14. Other than
displaying the kiss code, KoD packets have no protocol significance
and are discarded after inspection.
SB> Is this going to be an IANA registry?
+------+------------------------------------------------------------+
| Code | Meaning |
+------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed |
| AUTO | Autokey sequence failed |
| BCST | The association belongs to a broadcast server |
| CRYP | Cryptographic authentication or identification failed |
| DENY | Access denied by remote server |
| DROP | Lost peer in symmetric mode |
| RSTR | Access denied due to local policy |
| INIT | The association has not yet synchronized for the first |
| | time |
| MCST | The association belongs to a dynamically discovered server |
| NKEY | No key found. Either the key was never installed or is |
| | not trusted |
| RATE | Rate exceeded. The server has temporarily denied access |
| | because the client exceeded the rate threshold |
| RMOT | Alteration of association from a remote host running |
| | ntpdc. |
| STEP | A step change in system time has occurred, but the |
| | association has not yet resynchronized |
+------+------------------------------------------------------------+
Figure 14: Kiss Codes
===========
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Signature .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Extension Field Format
All extension fields are zero-padded to a word (4 octets) boundary.
SB> Is it normal to describe words as 32 bits?
The Field Type field is specific to the defined function and is not
elaborated here. While the minimum field length containing required
fields is 4 words (16 octets), a maximum field length remains to be
established.
The Length field is a 16-bit integer which indicates the length of
SB> Integer or unsigned integer?
==========
Note that the quantities within parentheses are computed from 64-bit
unsigned timestamps and result in signed values with 63 significant
bits plus sign. These values can represent dates from 68 years in
the past to 68 years in the future. However, the offset and delay
are computed as sums and differences of these values, which contain
62 significant bits and two sign bits, so can represent unambiguous
values from 34 years in the past to 34 years in the future. In other
words, the time of the client must be set within 34 years of the
server before the service is started. This is a fundamental
limitation with 64-bit integer arithmetic.
SB> I am not sure why a client needs to be configured with a time
SB> to within 34 years. Surely if you make the assumption that the
SB> packet takes less than 34 years to arrive you can bootstrap
SB> without needing configuration - or at least you can relax the time
SB> from 34 years to 136 years
============
In implementations where floating double arithmetic is available, the
first-order differences can be converted to floating double and the
second-order sums and differences computed in that arithmetic. Since
the second-order terms are typically very small relative to the
timestamp magnitudes, there is no loss in significance, yet the
unambiguous range is restored from 34 years to 68 years.
SB> Surely there is a protocol action that can resolve the ambiguity
SB> without needing floating double?
==============
Note that the on-wire protocol as described resists replay of a
server response packet. However, it does not resist replay of the
client request packet, which would result in a server reply packet
with new values of T2 and T3 and result in incorrect offset and
delay. This vulnerability can be avoided by setting the xmt state
variable to zero after computing the offset and delay.
SB> Need to check that the security section has a back ref to here.
==============
14. Security Considerations
NTPv4 provides an optional authentication field that utilizes the MD5
algorithm. MD5, as the case for SHA-1, is derived from MD4, which
has long been known to be weak. In 2004, techniques for efficiently
finding collisions in MD5 were announced. A summary of the
apropriateness of MD5 can be found in [10].
In the case of NTP as specified herein, NTP broadcast clients are
vulnerable to disruption by misbehaving or hostile SNTP or NTP
broadcast servers elsewhere in the Internet. Access controls and/or
cryptographic authentication means should be provided for additional
security in such cases.
SB> This should be reviewed by the security directorate before the
SB> draft goes any further. Based on previous experience I doubt that
SB> the analysis will be considered sufficient. Note that the main
SB> text calls up at least one threat that is not called up here.
===============
15. IANA Considerations
UDP/TCP Port 123 was previously assigned by IANA for this protocol.
The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
the IPv6 multicast address ending :101 for NTP. This document
introduces NTP extension fields allowing for the development of
future extensions to the protocol, where a particular extension is to
be identified by the Field Type sub-field within the extension field.
IANA is requested to establish and maintain a registry for Extension
Field Types associated with this protocol, populating this registry
with no initial entries. As future needs arise, new Extension Field
Types may be defined. Following the policies outlined in [11], new
consensus.
SB> English problem in last sentence.
SB> There are a bunch of other values that are assigned in this protocol
SB> surely these need registries to ensure that the standard develops
SB> in a controlled way. This is an essential difference between
SB> definition by standard and definition by reference implementation.
============
Appendix A. Code Skeleton
SB> You need to specify the normative/informative status of this
appendix
SB> vis a vis the main body of the specification.
SB> Shouldn't this have a reference to ANSI C so that we have a
SB> definition of all the types - alternatively they all
SB> need to be defined here for consistency.
=============
#include <math.h> /* avoids complaints about sqrt() */
#include <sys/time.h> /* for gettimeofday() and friends */
#include <stdlib.h> /* for malloc() and friends */
SB> Don't you need a pointer to a definitive instance of the above
SB> header files?
/*
* Data types
*
* This program assumes the int data type is 32 bitsand the long data
SB> typo bitsand
==============
/*
* Timestamp conversion macroni
*/
SB> typo macroni?
============
/*
* Global constants. Some of these might be converted to variables
* which can be tinkered by configuration or computed on-fly. For
* instance, the reference implementation computes PRECISION on-fly and
* provides performance tuning for the defines marked with % below.
*/
SB> We really need to distinguish quite firmly between
SB> invariants, implementation parameters and initial values
SB> This comment applies to all of the #defines in the
SB> following sections
#define VERSION 4 /* version number */
#define MINDISP .01 /* % minimum dispersion (s) */
#define MAXDISP 16 /* maximum dispersion (s) */
#define MAXDIST 1 /* % distance threshold (s) */
#define NOSYNC 0x3 /* leap unsync */
#define MAXSTRAT 16 /* maximum stratum (infinity metric) */
#define MINPOLL 6 /* % minimum poll interval (64 s)*/
#define MAXPOLL 17 /* % maximum poll interval (36.4 h) */
#define MINCLOCK 3 /* minimum manycast survivors */
#define MAXCLOCK 10 /* maximum manycast candidates */
#define TTLMAX 8 /* max ttl manycast */
#define BEACON 15 /* max interval between beacons */
#define PHI 15e-6 /* % frequency tolerance (15 PPM) */
#define NSTAGE 8 /* clock register stages */
#define NMAX 50 /* maximum number of peers */
#define NSANE 1 /* % minimum intersection survivors */
#define NMIN 3 /* % minimum cluster survivors */
===============
SB> Suppose you ought to point out that this is the UNIX epoch - NTP
SB> epoch difference
#define JAN_1970 2208988800UL /* 1970 - 1900 in seconds */
================
SB> Is there any formal process to check that there were no edit issues
SB> in the code - which is I assume an extract from the reference
implementation
SB> That is true here, but will apply again when it goes though the
SB> edit process.
- Stewart
More information about the ntpwg
mailing list