[ntpwg] ***SPAM*** Re: Comments on NTP draft -06

[David L. Mills]

Guys,

Thanks for Stewart's close study. Thanks for Danny's comments. This is 
going to be a burden for the editors, for which I have much sympathy. If 
this had been in PDF markup, the editors wouldn't need as much sympathy.

Inline:

Dave

Danny Mayer wrote:

> Stewart Bryant wrote:
>
>> 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?
>
>
> In this case the V4 version of the NTP protocol.

It <- NTPv4

>
>> Protocol Version 6 address family. NTPv4 includes fundamental
>>
>> 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?
>>
>
> You have a point here especially as Dave Mills is constantly tweaking
> the algorithms to improve the results. However I think that the point
> trying to be made here is that there is a set of algorithms being used
> and not just one that needs to be used to bring the clock into
> compliance with UTC. I don't think it's the algorithms themselves that's
> set in stone, it the fact that there's a set of them each of which can
> be implemented any way the implementor pleases. I cannot craft better
> language on this, but I'm sure others can.
>
Essay follows.

The reason for these restrictions is that the impulse response of each 
secondary server along the path from the primary servers to the clients 
needs to be carefully controlled to avoid underdamping or overdamping of 
the aggregate impulse response. The more servers along the path the more 
critical this is. If a client has no dependent clients of its own or if 
a server has only a single reference clock, the mitigation algorithms 
are not needed, which is the nexus of the specification.

Notwithstanding the above, if any server or client claims NTPv4 
compliance, then the algorithms must be functionally equivalent to the 
specified algorithms. This is a truth in advertising issue and raises an 
endless number of issues. Case in point:

Symmetricom makes a NTP server with a single GPS clock. By the above 
definition it is properly described as an SNTPv4 server. It doesn't need 
the mitigation algorithms. Now, Symmetricom provides an ACTS clock as 
backup, but only one of the two can be active at any time. By rule it 
remains SNTPv4 compliant. Now, Symmetrcom allows both to operate at the 
same time, which raises the issue how the two are mitigated. To conform 
strictly to the spec, the prescribed algorithms must be implemented to 
claim NTPv4 conformance.

 From an engineering point of view, there are many ways to skin the cat. 
A fully conforming NTPv4 implementation should function identically to 
the reference implementation with respect to source selection, step 
behavior, impulse response, etc. There have been a wide variety of 
situations reported over the years. Customers should expect a new 
product claiming NTPv4 compliance to behave in the same fashion as 
present experience.

However, it would be possible to slice and dice. For example, if a 
product used a selection algorithm other than NTPv4 but functioned "in 
the same way", is it NTPv4 compliant? That's a very hard thing to 
confirm or deny. The NTPv4 selection algorithm embodies a dose of 
computer science theory from which strong claims of accuracy and 
behavior can be proved. Really, all that is needed is to require that 
any competing algorithm obey the same principles. I don't know how to 
roll these principles in the specification and expect implementors to 
have the training and experience to properly implement an equivalent but 
different algorithm.

>> =========
>>
>>
>>
>> As a standard practice, timing network topology should be organized
>> SB> Should or MUST?
>
>
> I think "should" is sufficient here as NTP goes to great lengths to
> discard anything that does not conform to its idea of valid (for some
> meaning of valid). timing loop avoidance and synchronization distance
> minimization just helps the calculations.
>
>> 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
>
>
> I think that Dave Mills really means distance spanning tree from a
> mathematical point of view.

I really mean "shortest distance spanning tree" in a strictly 
mathematical sense. If you find "shortest path spanning tree" more 
soothing, go for it. The key concept is "Bellman Ford".

>
>> 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.
>>
>
> Well this looks like a duplicate of Figure 35 on P54. We should
> eliminate one or the other.

No; the two tables are very different. Read carefully. I leave to the 
editors to adopt whatever figure label is politically correct.

>> ============
>>
>>
>> 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??
>
>
> Those candidates which most recently responded with an NTP packet.
>
>> 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?
>
>
> It is. This is a definition of what the term means rather than how it is
> to be estimated.
>
>> 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.
>
I have made it clear over the years both in my publications and messages 
that the timing issues in wrangling a herd of cheap computer clocks is 
unlike tuning a farm of cesium oscillators and the terms used in each 
field may be differnent. See the statistics definitions on p 9.

>>
>> 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?
>
>
> If you mean instances of servers, then this is just an example. The
> reference implementation lets you have as many as you want but it will
> ignore some if it has too many but even that limit can be changed.
>
>> ==========
>>
>>
>> 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?
>
>
> What's calculated when you boil everything down is the amount that your
> system clock differs from the reference clocks. That number may be
> positive or negative but NTP never calculates time in the future or
> past, just the amount your clock disagrees and the frequency changes
> necessary to bring it into line.


Absolutely. This point is often lost in discourse. What does it mean to 
add 2007 June 28 1902 to 1582 June 28 2007?

>
>> ===========
>>
>>
>> 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?
>
>
> The recipients of NTP packets the server responds with, or in the case
> of broadcast the ones it sends out that are received by clients.
>
>> 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?
>
>
> Yes. This is assigned by IANA. See Section 7.2 (p18) and also Section 15.
>
>> SB> BTW can you run NTP over DCP or perhaps one of the SCTP modes?
>
>
> In theory you can run it over any protocol, but you would would break
> things like autokey which makes use of the IP address of the client and
> server to authenticate. It's really designed for UDP/IP.
>
>> ==========
>>
>> +-----------+------------+-----------------------+
>> | 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?
>

See p 4. These are names of symbols as used in formulae and come from 
the PDF reference and implementation guide. The reader can easily figure 
that out.

>>
>> 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?
>
There is no mention of longword in this doeument, only 32-bit words, 
multiple words and subfields.

>
> 32-bit word, to be specific.
>
>> 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.
>

It's very clear in the figure and in the explantion below.

>>
>>
>>
>> 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 editors might or might not want to change the figure and/or words.

>>
>> 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 :)
>
Don't get me going.

>>
>> 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?
>
>
> Not exactly. It's actually the last day of a specific quarter though I
> don't think it's ever happened yet on any day but the last day of the 
> year.

The document really means the last minute of the day. The reason for 
this is that the leap is actually implemented in the kernel and the 
kernel really doesn't want to figure the last day in the month. The 
expectation is that the impelmentation will figure out which day and set 
the leap bits in the kernel syscall sometime on that day. The editors 
may wish to add words to that effect.

>
>> | 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
>
Read it word for word. The editors might want to explain here more 
details about the influence of stratum in computing the synchronization 
distance and why that is important in the selection process, but I think 
that is not warranted here.

>
> This looks like an implementation-specific detail.
>
>> 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
>
>
> Yep, that's wrong. The precision can be calculated from this but it
> isn't the minimum time.

Not wrong. That's exactly how is is calculated. See p 14.

>
>> ===============
>> +------+----------------------------------------------------------+
>> | 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?
>
>
> If don't think that there is a need for that. It's just advisory about
> what's being used. That could change if this becomes required
> information, eg for tracability.
>
>> SB> Does there need to be an IEEE1588 code?
>
>
> What's that for?

This document says nothing about IEEE 1588, nor is there need to. It 
might be polite in the introduction to mention that.

>
>> =============
>>
>> 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?
>
>
> Meaning what?

Good practice is to strike a timestamp as close to the hardware as 
possible, but a reader familar with the art would know that.

>
>> =============
>>
>> 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?
>>
> NTP headers.

I don't understand how the NTP hash could include the headers at lower 
protocol layers.

>
>> =============
>>
>>
>> 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?
>
>
> Right now it's informational, with the exception of my recommendation to
> make DENY, RSTR, and RATE have the client do something. Is there a need
> for this in the IANA registry?

I remain uncomforable about requiring an NTPv4 complient client to do 
something about kiss codes. Strongly advising is the politically correct 
request. As reported in the PTTI paper about the Wisconsin and NIST 
incidents, clients that abuse the service are not about to do anything 
about complaint reports. Current SNTP hacks like ntpdate and sntp don't 
abuse the rulse, but script in which they are embedded might. More 
likely, a responsible sntp implementation might return an exit code that 
tells a responsible script to back off.

>
>>
>> +------+------------------------------------------------------------+
>> | 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?
>
> words are 32-bits in this document.

This practice originates from the dawn of IP/TCP thirty years ago. I 
follow in that honorable tradition.

>> 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?
>>
>
> I would expect this to be unsigned. However note the UDP limitations
> prevent it getting so big that the sign bit ever becomes an issue.

All lengths are unsigned.

>
>> ==========
>>
>>
>> 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
>
>
> No, the problem is that some servers (especially true of embedded
> systems) don't have the datetime stored in NVR and have no idea when
> they start what time it is. The 32-bit limit on the size of the variable
> used in the call on traditional Unix boxes in which they use to retrieve
> the time from the system clock is what causes this problem.

See the discussion on p 15 and especially on p 29. Note the distinction 
between first and second order differences..

>
>>
>> ============
>>
>> 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?
>
>
> No, see above.
>
>> ==============
>>
>>
>> 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.
>
I yield to the editors to respond to these points.

>>
>> ==============
>>
>> 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.
>
>
> There was a dropped partial sentence that I already noted in my response.
>
> Danny
>
>> 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.
>
As clearly stated in the text, the appendix is not intended as an 
implementation, only a guide to understanding the algorithms. To insure 
consistency the code has been compiled and checked for errors. Some 
details which should be obvious to one skilled in the art have 
intentionally been omitted. I don't think, nor am I prepared to change 
the format or style of presentation. The typo is intentional.

>>
>> =============
>>
>> #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.
>
This is not an extract from the reference implementation. As said above, 
it has been compiled to check for typos, consistency, etc. In 
retrospect, the variable names should have been more closely consistent 
with those used in themain  text, but I'm not going to fix that now.

>>
>> - Stewart
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://support.ntp.org/pipermail/ntpwg/attachments/20070628/9fff86ad/attachment-0001.html