Subject: [ntpwg] Issues with the NTP draft -06

From: mayer at gis.net (Danny Mayer)
Date: Fri, 22 Jun 2007 12:29:14 -0400

I finally managed to get through the draft and I have the following
feedback which I will divide into two parts: substantive and nits.
Overall I find the document to be in pretty good shape though I have
mostly ignored the Appendix A code skeleton.

Substantive:
1) P9 Section 3.2 Second Paragraph
There is no description or indication of what the maximum value of TTL
is or should be or how to decide on what it should be. Similarly there
is no indication of what the minimum number of associations is or how to
decide what it should be.

2) P22: Poll:
Should we allow polling of less than 1 second? We surely don't want to
encourage this.

3) P23:
   Above stratum 1 (secondary servers and clients) this is the reference
   identifier of the server and is intended to detect timing loops.  If
   using the IPv4 address family, the identifier is the four-octet IPv4
   address.  If using the IPv6 address family, it is the first four
   octets of the MD5 hash of the IPv6 address.  Note that, when using
   the IPv6 address family on an NTPv4 server with a NTPv3 client, the
   Reference Identifier field appears to be a random value and a timing
   loop might not be detected.

The problem here is that the refid is to be used to detect timing loops
but it can be any value that can do the job and should be unique for
each server and not interface address. Thus a server should have one and
only one refid irrespective of whether it is using IPv4 or IPv6
addresses. Tying it to an IP address is not really a good idea. Tying it
to a MAC address might be a better idea.

4) P24. Section 7.4 last sentence:
   Other than
   displaying the kiss code, KoD packets have no protocol significance
   and are discarded after inspection.

I'd like to see recipients of KISS codes take actions dependent on the
receipt of some of the codes. Practical experience has shown that the
operators of public servers need to be able to assert more control over
the clients that contact their servers. I'd like to therefore change
this sentence to read as follows:

   Recipients of kiss codes MUST inspect them and in the following cases
   take these actions:
   a) For kiss codes: DENY, RSTR the client MUST demobilize any
      associations to that server and stop sending packets to that
      server;
   b) For kiss code: RATE the client MUST immediately reduce its polling
      interval to that server and continue to reduce it each time it
      receives a RATE kiss code.
   c) Other than the above conditions, KoD packets have no protocol
      significance and are discarded after inspection.

5) P26: Extension Field Format
Shouldn't the Extension Field format be left to the implementation of
the extension field protocol with the exception of the first part which
consists of the field type and the length of the extension field and
it's overall alignment? I'm not clear why association ID, timestamp,
filestamp, etc. would be defined in this document.

Nits:
1) P.5:
   The on-wire protocol described
   in Section 8 is based on a returnable-time design which depends only
   on measured clock offsets, but does not require reliable message
   delivery.
Please add the following:
   Reliable message delivery such as TCP can actually make the delivered
   NTP packet less reliable since retries would increase the delay value
   and other errors.

2) P5:
   All servers and clients who are fully NTPv4 compliance MUST implement
Change to:
   All servers and clients who are fully NTPv4 compliant MUST implement

3) P6:
   of a symmetric active packet with matching no association.  That
Change to:
   of a symmetric active packet with no matching association.  That

4) p7:
   and sends the reply packet as described in Figure 2 of Section 9.2.
Change to:
   and sends the reply packet as described in Figure 2.

5) p9:
Remove the last sentence in the last paragraph in section 3.2
   The reference implementation includes
   intricate means to do this, but these are beyond the scope of this
   document.

This is not relevant here and is implementation dependent.

6) p9-10:
   Under definitions should noise be defined? It is used in the
   reference implementation but not in the document. Dave did send out
   a definition in a recent email message.

7) P22 Figure 12:
   should be change the last entry and make it look like this:
   16     unsynchronized
   17-255 reserved

8) P24: Add the following before Key Identifier in section 7.3:
   Extension Field n: See Section 7.5 for a description of the format of
   this field.

9) P26 and P56 Section 15: IANA allocations of addresses 224.0.1.1 and
:101 needs references to documents.

10) P32 top of page:
   The common names and formula names are interchangeable; formula names
   are intended for equations where space is important.

I have no idea what the reference to "space" means here. Can anyone explain?

11) P37: Figure 24
   4 access denied | The access controls have black
Change to:
   4 access denied | The access controls have blacklisted the source
                     address.

12) P56: Section 15
    Following the policies outlined in [11], new consensus.
Change to:
    Following the policies outlined in [11], new values are to be
    defined by IETF Consensus.

Danny

---

From: brad at shub-internet.org (Brad Knowles)
Date: Sat, 23 Jun 2007 02:29:20 -0500

>  to a MAC address might be a better idea.

You've got a MAC address per interface, so if you want to avoid doing 
anything on a per-interface basis, then using the MAC address is just 
as bad as an IP address.  Moreover, with many high availability 
services, you can "steal" IP and MAC addresses from one machine to 
another, and you really don't want to base anything for NTP on 
something that could be moved from one machine to another on a 
moments notice.

You need to choose something else that is relatively guaranteed to be 
unique on a per-server basis, is guaranteed to stay on that server 
and not move anywhere else, and is guaranteed to be unique regardless 
of how many interfaces, IP addresses, MAC addresses, etc... that may 
be on the server.  For Suns, this might be hostid, but for other 
platforms I suspect you're going to need something else.

Note that this unique id could change between reboots of the server, 
or stop-and-restart operations of the NTP daemon, etc....

So, one potential solution would be for the NTP daemon to take all 
known MAC addresses, IP addresses, and other suitable information 
that is available at the time of the start of the NTP program and 
combine that with a suitably large pseudo-random number, and then 
generate an MD-5 or SHA-1 or SHA-2 hash of that number, extract the 
leftmost or rightmost four octets, and have that calculated value 
become the "refid".

I'm not saying that this is the only solution, or even that it is 
necessarily the best solution.  But it does seem to be a pretty good 
solution, and assuming you choose a "good enough" hash function, it 
should be sufficiently unique for the purpose of loop detection.

>  receipt of some of the codes.

Excellent idea.

-- 
Brad Knowles <brad at shub-internet.org>, Consultant & Author
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Slides from Invited Talks: <http://tinyurl.com/tj6q4>

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

---

From: tglassey at earthlink.net (TS Glassey)
Date: Sat, 23 Jun 2007 08:52:32 -0700

----- Original Message ----- 
From: "Brad Knowles" <brad at shub-internet.org>
To: <mayer at gis.net>; "NTP Working Group" <ntpwg at lists.ntp.isc.org>
Sent: Saturday, June 23, 2007 12:29 AM
Subject: Re: [ntpwg] Issues with the NTP draft -06

> something that could be moved from one machine to another on a

OK - lets jump up to 200000 feet and quantify this model - and the 
requirement... So then you are looking for a way to anchor the trust and 
integrity model for the NTP Server to a physical source or site.

> be on the server.

> For Suns, this might be hostid, but for other

A system specific PKI Token is the way to go. And NTP can lead the way into 
this 'brave new world' of 'computing images with integrated integrity' - 
i.e. the identity that is unique and mechancially verifiable.

> or stop-and-restart operations of the NTP daemon, etc....

Not if the ID is registered in the DNS services as part of the 'Well Known 
Service'

> leftmost or rightmost four octets, and have that calculated value

Yes, this has been proposed before as well. But it doesnt tie the NTP Server 
to the legal jurisdiction its operated in and that is the key from a 
commercial use standpoint from the NTP Audit Model...

> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/ntpwg

---

From: mills at udel.edu (David L. Mills)
Date: Sat, 23 Jun 2007 20:00:15 +0000

Guys,

The refid issue has always been a tug between backward compatibility and 
word size. The method chosen is not perfect, but is a good compromise.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070623/8b9633dc/attachment.html

---

From: mayer at gis.net (Danny Mayer)
Date: Sat, 23 Jun 2007 23:44:18 -0400

> integrity model for the NTP Server to a physical source or site.

No, the goal is to prevent timing loops. The value needs only to be
reasonably unique. This is not an authentication scheme. Autokey is used
for authentication.

Danny

---

From: tglassey at earthlink.net (TS Glassey)
Date: Sat, 23 Jun 2007 21:55:57 -0700

The same quality of integrity is required in the prevention of timing loops 
so that the logs of actions documented therein are believable.

T.

---

From: brad at shub-internet.org (Brad Knowles)
Date: Sun, 24 Jun 2007 00:06:20 -0500

>  so that the logs of actions documented therein are believable.

The whole "Guaranteed Bet The Entire Budget Of The Entire World For 
The Entire History of Humanity Super Hyper Duper Nuclear Crypto 
Authenticated Audited Can't Be Broken In The Entire Lifespan of the 
Entire Universe No Matter How Many Advances There Are In Quantum 
Mathematics" type of solution is not one that we are trying to 
address at the moment.

At the moment, we're just trying to address the issue of a somewhat 
better way of selecting a refid that will help reduce the probability 
of a timing loop, based on what we know of current limitations on how 
the refid is generated from a single IP address and how current 
networking technology tends to cause single IP addresses to migrate 
from one machine to another or one site to another, or where a single 
machine might have more than a single IP address.

We'll solve that other problem at some other time.

All IMO, of course.

-- 
Brad Knowles <brad at shub-internet.org>

---

From: heiko.gerstung at meinberg.de (Heiko Gerstung)
Date: Mon, 25 Jun 2007 08:21:07 +0200

>>  to a MAC address might be a better idea.
I think that the stratum level does a much better job in avoiding timing 
loops, we probably should abandon the idea that the refid is anything 
more than an informational value. Is the refid really checked in the 
code? If it is (probably in the peer handling stuff) then I would 
suspect that it only covers direct connections to the next upstream 
server and does not perform a full loop check (server A -> server B-> 
server C -> server A).
> something that could be moved from one machine to another on a 
I would say that the refid is no security related data object. I agree 
that the MAC address and IP can change, but I do not see any bad 
implications here, at least not for the operational status.

> should be sufficiently unique for the purpose of loop detection.
Using a public host key of the server would work as well. But I do not 
see that this helps in preventing loops, the only benefit I could see is 
if a server would carry all those unique IDs of all servers between the 
stratum 0 source and itself around and pass that list on to its 
downstream servers/clients. That would enable us to provide a "time 
trail" or a solution to the "traceable" time" stuff.

Regards,
Heiko

> Excellent idea

---

From: brian.utterback at sun.com (Brian Utterback)
Date: Mon, 25 Jun 2007 08:06:06 -0400

One of the key pieces you need to remember is that the while the refid
should be unique, unless the data you want to use for the server's
refid is already in the data somewhere that arrives from the server,
the refid must be derivable from the client.

To answer Heiko's comment about the stratum level, the problem with
stratum level is the propagation delay when the level changes. However,
the reason having only two levels of loop detection works is that the
stratum level generally works for larger loops.

I have always wondered if there might not be a way to get better
loop detection if you treated the refid as a sort of shift register.
Each server would choose a random one byte number at shift that number
on the the refid it passes to the client. Then the client would look
at each byte of the refid from all of its servers. If the higher order
byte matches the clients random byte, avoid it if you can. If the
top two bytes match the lowest byte of the client's server's refid and
the the client's own byte, reject it. Reject if more bytes match.
-- 
blu

If global warming is about climate change, isn't
trying to prevent it actually anti-climatic?
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom

---

From: kostecke at ntp.org (Steve Kostecke)
Date: Mon, 25 Jun 2007 08:37:35 -0400

Heiko Gerstung said:

>see that this helps in preventing loops, the only benefit I could see
>is if a server would carry all those unique IDs of all servers between
>the stratum 0 source and itself around and pass that list on to its

Autokey, when properly configured, provides exactly this capability.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project http://support.ntp.org/
Public Key at http://support.ntp.org/Users/SteveKostecke

---

From: mayer at gis.net (Danny Mayer)
Date: Mon, 25 Jun 2007 08:38:56 -0400

> implications here, at least not for the operational status.

I agree. I just want to get away from the idea that we SHOULD use IPv4
addresses (or IPv6 addresses MD5-summed). Just because the reference
implementation uses that doesn't mean that everyone else should do so.
The value can be anything as long as it's relatively unique.

Danny

---

From: brian at innovationslab.net (Brian Haberman)
Date: Mon, 25 Jun 2007 08:50:54 -0400

> The value can be anything as long as it's relatively unique.

Given that the task at hand is documenting what NTPv4 is today, what
implementations *do not* use the IPv4 address or the hashed IPv6 address
as the refid?  I don't see the benefit of trying to retrofit this type
of change into the protocol spec trying to be advanced.

Regards,
Brian

---

From: heiko.gerstung at meinberg.de (Heiko Gerstung)
Date: Mon, 25 Jun 2007 15:32:15 +0200

> Autokey, when properly configured, provides exactly this capability.
Sounds great, Is there any tool or utility out there that can show me 
the exact trace for an instance of ntpd?

Best Regards,
Heiko

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Mon, 25 Jun 2007 09:40:11 -0400

> the exact trace for an instance of ntpd?

Did you look at ntptrace or are you asking about Autokey?

Danny

---

From: heiko.gerstung at meinberg.de (Heiko Gerstung)
Date: Mon, 25 Jun 2007 15:52:41 +0200

> Did you look at ntptrace or are you asking about Autokey?

I indeed was talking about the Autokey trace. The "problem" with 
ntptrace is that it queries each involved server directly which is not 
what I thought of. Hold on  a second - are we getting off topic a little 
bit? :-)

In regards to the draft I would not change the wording at this stage, 
simply because it has no direct impact on the functionality of the 
protocol and the draft documents what is currently done in 100% of the 
implementation base.

Regards,
 Heiko

---

From: heiko.gerstung at meinberg.de (Heiko Gerstung)
Date: Mon, 25 Jun 2007 15:55:32 +0200

> stratum level generally works for larger loops.
Well, is the propagation delay of the refid better? As far as I can tell 
the stratum level and the refid are changing at exactly the same time or 
do I miss something?
> the the client's own byte, reject it. Reject if more bytes match.
I think that the stratum level offers the same functionality with a 
simpler approach. Add 1 to the stratum level of your upstream server and 
never synchronize with a server that has the same or higher stratum 
level. What a ruleset :-)

Cheers,
Heiko

---

From: mayer at gis.net (Danny Mayer)
Date: Mon, 25 Jun 2007 09:57:23 -0400

> of change into the protocol spec trying to be advanced.

Not quite. The task is to document what an implementor needs to do, not
what the reference implementation does. I have no idea what other
implementations do.

Danny

---

From: kostecke at ntp.org (Steve Kostecke)
Date: Mon, 25 Jun 2007 10:00:05 -0400

Heiko Gerstung said:

>Steve Kostecke schrieb:
>
>> Heiko Gerstung said:
>>
>>> Using a public host key of the server would work as well. But I do
>>> not see that this helps in preventing loops, the only benefit I
>>> could see is if a server would carry all those unique IDs of all
>>> servers between the stratum 0 source and itself around and pass that
>>> list on to its downstream servers/clients. That would enable us to
>>> provide a "time trail" or a solution to the "traceable" time" stuff.
>>

If you're looking for something that will pretty-print the certificate
trail, or shrink-wrap it in a GUI, the answer is no. However all of the
raw data is available.

A snapshot of the certificates held by ntpd are displayed in the 'ntpq
-crv' output (ntpq -c"rv 0 cert" displays just the certificates).

The cryptostats log file provides a log of certificate receipt, etc.

>To: Steve Kostecke <kostecke at ntp.org>
>Cc: ntpwg at lists.ntp.isc.org

Please send your replies TO: the list and refrain from CC:ing me.

---

From: heiko.gerstung at meinberg.de (Heiko Gerstung)
Date: Mon, 25 Jun 2007 16:29:05 +0200

> -crv' output (ntpq -c"rv 0 cert" displays just the certificates).
That would mean that I could see a bunch of certificates from all the 
servers in the autokey hierarchy. Is there a chance or a collection of 
data that shows me how exactly the hierarchy looks like (i.e. which 
server is getting the time from whom)?

> The cryptostats log file provides a log of certificate receipt, etc.
Log files are great for finding out what has happened when but I do 
think they are useful for determining the current status of something.

> Please send your replies TO: the list and refrain from CC:ing me
Done. Sorry, my mail client seems to better like it the other way around.

Regards,
Heiko

---

From: brian at innovationslab.net (Brian Haberman)
Date: Mon, 25 Jun 2007 10:58:56 -0400

> what the reference implementation does. I have no idea what other

One of Heiko's notes stated that 100% of the implementations handle the
refid the way it is defined in the spec.  Sounds like a consensus to me.

Regards,
Brian

---

From: kostecke at ntp.org (Steve Kostecke)
Date: Mon, 25 Jun 2007 11:03:01 -0400

Heiko Gerstung said:

>Steve Kostecke schrieb:
>
>> Heiko Gerstung said:
>>
>>> Sounds great, Is there any tool or utility out there that can show
>>> me the exact trace for an instance of ntpd?
>>
>> A snapshot of the certificates held by ntpd are displayed in
>> the 'ntpq -crv' output (ntpq -c"rv 0 cert" displays just the
>> certificates).
>
>servers in the autokey hierarchy.

Yes.  You'll see something like this:

cert="lan_server root_server 0x6", expire=200806241435,
cert="root_server root_server 0x7", expire=200805112155,
cert="client lan_server 0x6", expire=200806241442,
cert="client lan_refclock_server 0x6", expire=200806241442,
cert="lan_server lan_server 0x7", expire=200806182029,
cert="lan_refclock_server lan_refclock_server 0x7", expire=200805102346,
cert="client client 0x2", expire=200805311052

>Is there a chance or a collection of data that shows me how exactly the
>hierarchy looks like (i.e. which server is getting the time from whom)?

That's the job of the non-existant pretty-printing utility. The
collection of certs above shows two certificate trails:

Trail #1: client -> lan_server -> root_server

cert="client client 0x2"		# self-signed client
cert="client lan_server 0x6"		# client signed by lan_server
cert="lan_server lan_server 0x7"	# self-signed lan-server
cert="lan_server root_server 0x6"	# lan_server signed by root_server
cert="root_server root_server 0x7"	# self-signed root_server

Trail #2: client -> lan_server_with_refclock

cert="client client 0x2"
cert="client lan_server_with_refclock 0x6"
cert="lan_server_with_refclock lan_server_with_refclock 0x7"

---

From: mills at udel.edu (David L. Mills)
Date: Mon, 25 Jun 2007 17:16:50 +0000

Heiko,

Yes, the loop test is rigorously implemented and it really does work. 
Note that the Bellman Ford metric is already biased in order to avoid 
loops in the first place, but loops can still form in manycast and 
multiple broadcast configurations. If you look very carefully, you will 
note that not only does the test avoid loops, but it avoids cases where 
your neighbor is synchronized to the same server as you.

I say again, the scheme is not perfect, but it --is backward compatible 
with previous versions--.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.isc.org/pipermail/ntpwg/attachments/20070625/021b0895/attachment-0001.html

---

From: mills at udel.edu (David L. Mills)
Date: Mon, 25 Jun 2007 17:38:27 +0000

Brian,

The stratum is a red herring. It is the result of a comparison between 
synchronization distances, not the primal cause. As in all good Bellman 
Ford implementations, the distance is biased so as to minimize dither 
and resulting stratum flaps. While yours and other schemes might even be 
more reliable, I say for the umpteenth time the issue of backwards 
compatibility trumps all.

Dave

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Tue, 26 Jun 2007 13:47:43 +0100

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

---

From: mayer at ntp.isc.org (Danny Mayer)
Date: Thu, 28 Jun 2007 10:11:49 -0400

> SB> What does "It" refer to?

In this case the V4 version of the NTP protocol.

> 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.

>    As a standard practice, timing network topology should be organized

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.

> 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.

>    are failures in the timing network.

Well this looks like a duplicate of Figure 35 on P54. We should
eliminate one or the other.

Those candidates which most recently responded with an NTP packet.

>    intricate means to do this, but these are beyond the scope of this

It is. This is a definition of what the term means rather than how it is
to be estimated.

>    measurements of the system clock relative to the each server clock

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.

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.

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.

>    Additional parameters and variable classes are defined in Appendix A.

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.

32-bit word, to be specific.

>    are each component mentioned by name above.

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.

>            | 3     | alarm condition (the clock is not synchronized) |

This looks like an implementation-specific detail.

> 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.

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?

Meaning what?

NTP headers.

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?

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

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.

No, see above.

There was a dropped partial sentence that I already noted in my response.

Danny

---

From: sla at ucolick.org (Steve Allen)
Date: Thu, 28 Jun 2007 09:12:16 -0700

> don't think it's ever happened yet on any day but the last day of the year.

No, not the quarter.  The text is right to use "month".  ITU-R TF.460
allows for a leap second on the last day of *any* month.  That's
another point in favor of including a reference to the official
document.

Perhaps the original point was that when the LI is 0 then the last
minute of the month should default to 60 seconds?

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

---

From: seaman at noao.edu (Rob Seaman)
Date: Thu, 28 Jun 2007 09:52:57 -0700

To expand on Steve's comments, note:

1) Leap seconds have indeed also been issued at the end of June (but  
not 2007).

2) Just announced, there will be NO leap second at the end of  
December 2007.

3) Current IERS policy limits the introduction of leap seconds to the  
end of June and December, but the UTC standard (good for many  
centuries yet) has always been the end of any month.

See:  http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

Rob Seaman
NOAO
-----

On Jun 28, 2007, at 9:12 AM, Steve Allen wrote:

>>>            +------- 
>>> +-------------------------------------------------+
>>>            | Value |  
>>> Meaning                                         |
>>>            +------- 
>>> +-------------------------------------------------+
>>>            | 0     | no  
>>> warning                                      |

---

From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 28 Jun 2007 13:30:13 -0600 (MDT)

In message: <20070628161216.GA16642 at ucolick.org>
            Steve Allen <sla at ucolick.org> writes:
: On Thu 2007-06-28T10:11:49 -0400, Danny Mayer hath writ:
: > >    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.

"Day" is right here, at least from historical ntp implementation point
of view.  These implementations turn on the 'today is leap second day'
in the kernel, which implements its local policy for doing that when
they see these bits set.

: No, not the quarter.  The text is right to use "month".  ITU-R TF.460
: allows for a leap second on the last day of *any* month.  That's
: another point in favor of including a reference to the official
: document.

Current ntp implementations limit this to the quarterly, and filters
them when it isn't leap day.

: Perhaps the original point was that when the LI is 0 then the last
: minute of the month should default to 60 seconds?

I think that's good, or a separate value to distinguish 

Warner

---

From: sla at ucolick.org (Steve Allen)
Date: Thu, 28 Jun 2007 13:09:42 -0700

> them when it isn't leap day.

Not a problem.  There are roughly 300 years yet to elapse before this
detail will need further attention.

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 28 Jun 2007 20:39:00 +0000

Warner,

There have been some recent changes, but your description is 
substantially correct. See the leap second section in the ntp-dev 
documentation for the ntpd program.

Specifically, the current code can use the lNIST eapseconds file even 
without the crypto code. The NIST leapseconds file is refreshed about 
once every six months, even if nothing has changed. If the file is 
present and a leap has been announced at a specific NTP second in 
future, the daemon computes the number of seconds remaining until the 
leap. If the number of seconds is less than a month, the system leap 
bits are set. If leass than a day, the kernel is armed for the leap.

If kernel code is not available or disabled, the leap is implemented as 
an ugly step. If the Unix system clock code is as recommended in the 
nanokernel distribution, the kernel clock will appear to be set 
backward, but stand still or slowly advance during the leap second.

If the leapseonds table is not present and a plurality of server leap 
bits are set, the number of NTP seconds until the end of the month is 
computed from calendar calculations and it operates as above.

A small number of issues remain, such as what to do about expired 
leapsecond files, what to do if the leapsecond information is downloaded 
from a crypto server, etc. The paint ain't quite dry yet.

Dave

---

From: imp at bsdimp.com (M. Warner Losh)
Date: Thu, 28 Jun 2007 14:51:54 -0600 (MDT)

In message: <46841C64.5090504 at udel.edu>
            "David L. Mills" <mills at udel.edu> writes:
: A small number of issues remain, such as what to do about expired 
: leapsecond files, what to do if the leapsecond information is downloaded 
: from a crypto server, etc. The paint ain't quite dry yet.

Funny you should mention the 'what to do if the leapsecond information
is expired' cased.  I'm looking into a bug in that area.  Last
summer's leap second tables have expired today, leading to some
unexpected bugs in the code that I maintain...  We have a need to know
leap information in our application, so we use the NIST format to
store the data...

I noticed that the NIST leapsecond.list file was updated in early May
to expire in june 2008, several weeks before bulletin C34 came out
making it official that there's no leap second this December.  I can
only assume that the folks at NIST have an inside track on information
about future leaps :-)

Thanks for the update on the code.  I've read the leap second part of
the udel ntpd code far too many times over the past 8 years, but I've
managed to escape that chore for about two years now...

Warner

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Thu, 28 Jun 2007 23:00:19 +0100

> minute of the month should default to 60 seconds?

That too.

My point was that the text in the table should align with the main text, 
which as a I recall said last second of the month.

- Stewart

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Thu, 28 Jun 2007 22:54:00 +0100

As I pointed out in my review comments there are a number of tables of 
assigned values that are not called up as needing IANA registries.

The response was that they were only advisory and therefore did not need 
to be registered.

I can see how a standard set by reference implementation can get away 
with this approach, but I do not think that it is satisfactory in a 
standard set by an SDO.

Once NTP is published as an RFC there needs to be a formal mechanism 
whereby values can be added to informational tables in such a way that 
clashes do not occur. Allocation of additional values needs to be done 
in such a way that they do not damage the protocol and access is fair 
and impartial. IETF mechanism for doing that is by requesting a registry 
entry from IANA using the permission level documented in the RFC that 
created it.

Stewart

---

From: mills at udel.edu (David L. Mills)
Date: Thu, 28 Jun 2007 20:18:43 +0000

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

> In this case the V4 version of the NTP protocol.

It <- NTPv4

> 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.

> 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".

> 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.

>> 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.

> 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?

> server to authenticate. It's really designed for UDP/IP.

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.

>> SB> don't we mean longword?
There is no mention of longword in this doeument, only 32-bit words, 
multiple words and subfields.

>> are each component mentioned by name above.

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

The editors might or might not want to change the figure and/or words.

>> SB> or a better representation method such as pdf :)
Don't get me going.

> don't think it's ever happened yet on any day but the last day of the 

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) |
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.

> Yep, that's wrong. The precision can be calculated from this but it

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

>> SB> Does there need to be an IEEE1588 code?

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

>> SB>Is there a reference interface point for this?

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

>> SB> All headers, or all NTP headers?

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

> 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.

> 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.

> prevent it getting so big that the sign bit ever becomes an issue.

All lengths are unsigned.

> 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..

>> SB> without needing floating double?
I yield to the editors to respond to these points.

>> SB> definition by standard and definition by reference implementation.
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.

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.

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