Re: [Ntp] Objections to the current language in draft-ietf-data-minimization

[Harlan Stenn <[e-mail]>]

Sorry, I missed the later questions.

On 3/26/2019 2:41 AM, Watson Ladd wrote:
> 
> ...
>
>     Now let’s move to the approaching leap second event.  In this case, I’ll
>     be assuming the behavior of what I call 12/12 leap smearing, where a
>     half-second of correction is applied beginning at UTC noon on the day of
>     the leap second (ie, for 12 hours’ time), and the final half-second of
>     correction is applied starting at midnight UTC after the leap second was
>     applied until UTC noon on the day after the leap second (ie, for the
>     remaining 12 hours’ time).
>     To save folks from having to look it up, NTP communicates knowledge
>     about pending leap events via the first two bits of the NTP packet,
>     known as the LI, or Leap Indicator bits:
> 
>      0x0    Normal time
>      0x1    Last minute of the last DOM has 61 seconds
>      0x2    Last minute of the last DOM has 59 seconds
>      0x3    Not synchronized
> 
>     NTP instances sending mode 3 (client request) queries expect to receive
>     a mode 4 (server) response.  This response may be the correct time, and
>     it may be leap-smeared time.  The key questions are:
> 
>     - Does the client want leap-smeared time?
>     - Should the server respond with correct, or leap-smeared time?
> 
>     This leads to the follow-on questions:
> 
>     - How can the client know if it's getting correct, or leap-smeared time?
>     - How can one tell if a client is following a leap-smearing server?
> 
>     The following simple solution handles both of the first two questions.
> 
> 
> Is this current behavior? 

A) I'm not sure, but I don't see that it matters.  Implementing this
proposal as-written would make this solution impossible.

B) Regardless of A), the Reference Implementation will be doing this
soon, as folks need time to deploy and test it before the next leap
second event.

>     If the client sends its request with LI values of 0x1 or 0x2, it is
>     telling the server that it believes a leap event is pending.  In this
>     case the server SHOULD respond with correct time with an LI value of
>     0x0, 0x1, or 0x2; not leap-smeared time.  If the client sends a packet
>     with LI=0x3, the server SHOULD also respond with correct time with an LI
>     value of 0x0, 0x1, or 0x2.
> 
>     If the client sends its request with an LI value of 0x0 before leap
>     smearing starts, the server SHOULD respond with correct time with an LI
>     value of 0x0, 0x1, or 0x2.  If the client sends its request with an LI
>     value of 0x0 *during* a leap smear correction, the server SHOULD respond
>     with leap-smeared time and an LI value of 0x0, and MAY respond with
>     correct time and an LI value of 0x1 or 0x2.
> 
>     Furthermore, responses containing leap-smeared time SHOULD include a
>     REFID that identifies the "system peer" as a leap-smeared source.  See
>     draft-stenn-ntp-leap-smear-refid for more information.  This response
>     also SHOULD include a SUGGESTED-REFID extension field, as described by
>     draft-stenn-ntp-suggest-refid, to make it obvious that the system is
>     following leap-smeared time.  These points address the  two follow-on
>     questions.
> 
>     The LEAP-SMEAR-REFID and SUGGESTED-REFID extensions have another key
>     role during the application of a leap smear - that of making sure the
>     system behaves properly during the last half of the 12/12 leap smear
>     correction.
> 
>     Once the leap second has applied, the LI value for correct time reverts
>     to 0x0.  When a leap smearing client asks for time during the second
>     phase of this correction, it will be sending its requests with LI=0x0,
>     as *all* time requests from a leap-smearing client will contain LI=0x0
>     when a leap event is not pending.  But in this case, how does the server
>     know it should continue sending leap-smeared time, as opposed to correct
>     time?  The answer is that the client requests include the client's
>     REFID, which in this case SHOULD be a LEAP-SMEAR-REFID.
> 
> 
> A future spec of this behavior can override the draft or future rfc. Why
> is that not an option?

Why delay?

Past experience shows that it takes YEARS for progress to be made in the
committee, even for simple things.  Leap second events currently happen
roughly about once every year and a half or so.

Some of us plan to have solid experience under our belts by the time
that happens.

>     When a server receives a mode 3 (client) request containing a
>     LEAP-SMEAR-REFID during the second phase of a leap-smear correction, the
>     server SHOULD respond with leap-smeared time and a LEAP-SMEAR-REFID as
>     the SUGGESTED-REFID.
> 
>     When the leap-smear correction has ended, normal query/responses will
>     again be in effect.
> 
>     Finally, servers should know when a leap event is about to occur.  Other
>     systems may not have this information.  It’s polite, cooperative, and
>     informative if the client sends its poll interval to the server.  A
>     server that knows a leap second event is coming SHOULD reply with a
>     suggested poll interval that will, even in the face of dropped UDP
>     packets, allow the client that pays attention to the suggested poll
>     interval from the server to re-query often enough to quickly track these
>     events and stay well-synchronized.
> 
>     In short, if you care about data minimization more than you care about
>     having accurate synchronized time, minimize away.
> 
>     If you are primarily interested in having accurate synchronized time,
>     playing nice with others, getting the time you want and be able to see
>     what's going on during a leap second event:
> 
>     - be honest with your LI bits
>     - be honest when reporting your poll interval
>     - pay attention if a server asks you to adjust your poll interval
>     - consciously choose the REFID in your messages
> 
>     The upcoming (full) Reference Implementation release of ntp-4.4.0 from
>     the NTP Project will have these behaviors in it.
> 
> 
> Apparently not.

Perhaps you know something I don't.  As the NTP Project Lead I have a
pretty good idea of what's going to be in what release.

> And what is this a reference implementation of if the
> standard has not been updated to include these behaviors?

It's what the current/next revision of NTP is expected to be.

You may disagree with the history of how the NTP Standard has
progressed, and that's OK.

In EVERY CASE, the NTP codebase was fully written, engineered, tested,
and deployed before the first draft of each revision of the Standard was
attempted.

The first alpha release of ntp-4 came out in September of 1997.  The
first production release of ntp-4 came out in February of 2002.  The
first DRAFT of the NTPv4 spec was published in July of 2005, and RFC5905
wasn't published until June of 2010.  That's about 13 years after the
code was released.

If you want to wait to run software until after the Standard has been
passed, and if you don't want to take advantage of improvements that are
not yet standardized, that's certainly your choice.

We're continuing to evolve the codebase into the best possible way to
securely and efficiently communicate synchronized time.  We plan to
continue to do this.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!