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

[Martin Burnicki <[e-mail]>]

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

I basically agree with Harlan. Even though these details are not
*required* in client/server mode, they can help to optimize the client's
behavior and performance.

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

The question is whether it is important what the client wants.

Leap second smearing is a hack to hide a leap second from the client(s),
and the operator decides to so so, or 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.

Agreed. What should the server do if the client doesn't accept a
proposed poll interval? There are lots of simple, dump clients out there
where I doubt they can and do change the poll interval at all.

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

Is it important what the client wants?
Or just what the operator has decided to enforce?

> - Should the server respond with correct, or leap-smeared time?

IMO, if the server has been configured to provide leap-smeared time then
it should do so by default, but eventually there may be exceptions. See
below.

> This leads to the follow-on questions:
> 
> - How can the client know if it's getting correct, or leap-smeared time?

If the server supports this (e.g. current ntpd does), the client can
*optionally* check the refid received from the server and see that it's
the special "smear REFID". This should be just informational.

> - How can one tell if a client is following a leap-smearing server?

Again, if the client detects the "smear REFID" received from its system
peer a monitoring program like ntpq could display the appropriate
information.

> The following simple solution handles both of the first two questions.
> 
> 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.

This sounds reasonable at the first glance. If the client has already
received a the leap second announcement from a different source then it
is anyway aware of the leap second and will handle it normally. In this
case it doesn't make much sense to spoof this client and send him a
smeared time to hide the leap second.

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

No, here I disagree. If the client sends leap bits 0x3 this means it is
currently not synchronized, and the server may be the only time source
the client has. If the server operator has decided to let the server
smear the leap second then it should really do so in this case.

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

No. If the server has been configured to smear the time and hide the
leap second then it should do so by default, which also means *not* to
send a leap second warning to a client unless the client clearly
indicates in its request that it anyway knows about the upcoming leap
second. Only in this case the server should send the leap second warning
flag 0x1 or 0x2 and true UTC instead of smeared time.

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

No. IMO, if the client sends leap bits 0x0 or 0x3 then the server MUST
NOT respond with correct time and an LI value of 0x1 or 0x2 if it has
been configured to smear the leap second.

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

This is a good idea, but older clients or other client implementations
may not recognize the LEAP-SMEAR-REFID as a special case, and they may
not even accept a response from a server that has an extension field
they don't expect.

So eventually extension field handling should be mandatory for v5 of the
NTP protocol, and only if a v5 client request is received the server
should append that extension field.

BTW, is there a common place to collect suggestions for v5 of the NTP
protocol?

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

Of course, the server should continue to send smeared time and the
LEAP-SMEAR-REFID as long as smearing is still in progress, but as I've
mentioned before, it should not append an extension field by default if
the client request is protocol v3 or v4.

However, if the server *only* responds with leap-smeared time if it
receives the LEAP-SMEAR-REFID from the client then I'd expect that this
*breaks compatibility* with many simple client implementations that are
out in the wild. If such clients won't send this special REFID then they
would get non-smeared time back from the server after the leap second
has occurred, which may cause a 0.5 s time step on the client.

I don't think this consistent with the original idea of leap smearing,
which should explicitly avoid time steps.

On the other hand, this problem wouldn't even arise if the leap second
smearing is 24/0 and thus is finished if the leap second occurs.

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

This is correct. If a client has increased its poll interval in
continuous operation because the frequency correction is stable then
it's a good idea to let the server suggest a shorter poll interval
before the leap smearing starts and ends.

This should be really helpful to minimize the client's time offset error
caused by the frequency change at the beginning and end of the smear
interval.

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

Exactly as you've described it above? This will break compatibility with
non-ntpd-4.4.x clients.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy