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

[Watson Ladd <[e-mail]>]

On Tue, Mar 26, 2019, 9:02 AM Harlan Stenn <[e-mail]> wrote:

> In my opinion, draft-ietf-ntp-data-minimization-04, like its -03
> predecessor, exclusively focuses on ways to expose as little information
> as possible and completely ignores and discounts the costs or problems
> that can and in some cases will occur if its recommendations are followed.
>
> If my claims are accepted, section 1. Introduction of
> draft-ietf-ntp-data-minimization should be appropriately rewritten to
> remove its incorrect, or at least misleading, claims, and many of the
> “SHOULD” recommendations in the document should be changed to “MAY”.
>
> In particular, draft-ietf-ntp-data-minimization blindly and explicitly
> recommends setting LI, the poll interval, and the REFID to 0, with no
> offered analysis for the costs or benefits of the effects of these
> recommendations.
>
> In this email I’ll use a leap second event to illustrate these points.
>
> Regardless of whether or not you believe leap smearing is “good”, there
> are time servers out there that only offer correct time, some that only
> offer leap-smeared time, and some that offer one or the other -
> depending on how they’re asked.
>
> For better or worse, a noticeable group of time server operators now
> offer leap-smeared time in response to NTP mode 3 (client) requests.
> Sometimes this is what the clients want, sometimes it is not.
> Regardless, there is clear value and benefit in being able to see if:
>
> a server is offering correct, or leap-smeared time
> a client is following a correct, or a leap-smearing server
>
> Let’s look a the poll interval first.  If a server knows a leap second
> event is coming, it is in a position to look at the poll interval from
> the client and send back a recommended poll interval that will make sure
> the client properly handles leap second handling.  Yes, even if the
> client “lies” and doesn’t tell the server its actual poll interval, the
> server can respond conservatively, and be responsible to the client.
> This behavior may well cause an unnecessary increase in the server load.
>  It is also possible that the server may choose to remember the IP and
> port of the incoming request to independently try and verify the actual
> poll interval used.  But this is also a case of cost-shifting, and I am
> opposed to it.
>

Alternatively clients can ensure that they pull at least once every 24
hours so they will know when a second happens.


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


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


> 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. And what is this a reference implementation of if the
standard has not been updated to include these behaviors?


> --
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
>