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

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 01:02:15 -0700

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.

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.

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.

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.

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

---

From: Watson Ladd <[email-masked]>
Date: Tue, 26 Mar 2019 10:41:46 +0100

> poll interval used.  But this is also a case of cost-shifting, and I am

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

> The following simple solution handles both of the first two questions.

Is this current behavior?

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

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

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 02:47:44 -0700

On 3/26/2019 2:41 AM, Watson Ladd wrote:
> 
> 
> On Tue, Mar 26, 2019, 9:02 AM Harlan Stenn <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Are these clients leap-second aware?  If so, that's probably true.

If they are not leap second aware then you're talking about clients that
don't place a high value on accurate time synchronization, so they don't
care.

This is not the client population that will have problems with data
minimization.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 03:04:44 -0700

Sorry, I missed the later questions.

On 3/26/2019 2:41 AM, Watson Ladd wrote:
> ...

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.

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

> 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

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.

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 26 Mar 2019 11:05:02 +0100

Dieter Sibold
[email-masked]

> This is not the client population that will have problems with data

 From my point of view these are arguments against leap-smearing and not 
against the data minimization draft which from my point of view is 
mandatory since it meet modern regulation requirements such as the eu 
gdpr.

- Dieter

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 03:09:23 -0700

Dieter,

On 3/26/2019 3:05 AM, Dieter Sibold wrote:
> mandatory since it meet modern regulation requirements such as the eu gdpr.
> 
> - Dieter

You are expected to run your systems the way you want, to your
specifications.

A GROWING number of public time servers offer leap-smeared time.

This affects a growing number of clients.

I am opposed to using "creative destruction" as a means to force people
to do things the way I think they should be done.  I am a big fan of
providing people with robust mechanisms to provide the tools implement
their local policy choices.

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 26 Mar 2019 11:26:33 +0100

> offered analysis for the costs or benefits of the effects of these

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.

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

> poll interval used.  But this is also a case of cost-shifting, and I am

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.

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

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

> 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

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.

> 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

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.

> following leap-smeared time.  These points address the  two follow-on

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?

> server SHOULD respond with leap-smeared time and a LEAP-SMEAR-REFID as

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.

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

> 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: [email-masked]
Phone: +49 5281 9309-414
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

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 04:04:37 -0700

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

I submit it will be important to the operator of the client, and that
may or may not be the same organization that operates the servers.

What would happen if some of the general pool operators decided to offer
leap smearing?

Compare this to the vendors Foo, and Bar, who have separately arranged
to offer foo.pool.ntp.org and bar.pool.ntp.org.  If Foo decides its
clients should use correct time, they have their pool servers offer
correct time.  If Bar decides its clients should use leap smeared time,
they have their pool servers offer that.

> and the operator decides to so so, or not.

Agreed.  And I'd augment that to say it's Good if we give arbitrary
clients a way to detect this, and if they choose, make decisions based
on what the server tells them.

> where I doubt they can and do change the poll interval at all.

All we can do is make a good-faith offer.  This satisfies our
responsibility *to* the client.  We are not responsible *for* the
client's behavior.  If the client doesn't honor our poll request and
doesn't sync well enough, then if the client doesn't care then ... they
don't care.  If the clients *do* care they have an opportunity to make a
different choice.

> Or just what the operator has decided to enforce?

It depends.  I touched on this above.  And sometimes servers will send
client requests to monitor and track other systems.

One of my goals here is to give the recipient of these responses the
tools and information that will allow them to make choices that are
right for them.

> it should do so by default, but eventually there may be exceptions. See

:)

And what happens if a server operator changes their mind about this at
some point in the future?

> the special "smear REFID". This should be just informational.

Yes.

> peer a monitoring program like ntpq could display the appropriate

This goes to the SUGGESTED-REFID.  Even if it's not used, I currently
believe that if ntpd in 4.4.0 syncs to a leap-smearing source, even if
that source does not use SUGGEST-REFID, there will be code to make sure
that the client's published system peer is a leap-smear REFID, for the
following reasons:

- it shows up in ntpq.
- it allows the 2nd half of the leap smear to be applied as expected.

> smear the leap second then it should really do so in this case.

I considered this case, and this is why I made the decision I wrote above.

If the client is able to handle the leap second then we should give it
the opportunity to do so.  There's a chance the client will iburst, so
it will likely sync after 6 of the 8 iburst polls.  In this case, the
7th poll will contain either LI=0, meaning it doesn't believe that a
leap event is pending, or it will send LI=1.  As soon as it sends either
of these, the server knows how to respond to the client.  And if the
time is close enough or in the leap smear period, the server may well be
telling the client to use a shorter poll interval, so even if the client
went from LI=3 to LI=0 it will continue to use a shorter poll interval
and shift from correct time to smeared time.

I even think I have a way to help this along even better, with an update
to the EXTENDED-INFORMATION extension field.

> flag 0x1 or 0x2 and true UTC instead of smeared time.

If you want your server to ALWAYS send smeared time, then you are right.

If you want your server to offer correct time to clients that know how
to handle the leap second and smeared time to clients that do not state
they know how to handle a leap second, then I probably disagree with you
and I'd appreciate our discussing this more so we can come to an agreement.

> been configured to smear the leap second.

I do see your point and I remember thinking about this a lot, and there
was a reason I wrote what I did.  That reason could be as simple as
"SHOULD" means "you really really should do this, unless you have a Good
Reason not to, in which case you MAY respond with LI=[12] and correct
time." Put another way, I'm leaving an "escape hatch" for the
possibility that there's a special case that hasn't been considered.

> not even accept a response from a server that has an extension field

Agreed, and that's what the I-DO EF is for.  If the client sends this,
the server knows what the client can accept.

It's been my experience that we don't want to send unsolicited EFs in
server responses.

> should append that extension field.

Agreed.

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

I have a list of our ideas, and I'm happy to set up a place for it.

> the client request is protocol v3 or v4.

Certainly not for v3, as EFs didn't exist there.  I'm fine with sending
known-allowed EFs in v4 responses.

> has occurred, which may cause a 0.5 s time step on the client.

Yes.  And in that case there are several options to avoid this problem:

- configure the clients to query servers that will give them the time
they want (there are several ways to do this),
- get motivated to upgrade the client software after the next leap second.

> which should explicitly avoid time steps.

Yes, but if the client is following a regular server they'll step by a
second.  If they follow a leap smear server then they won't step.  And
if they follow a "new style" server that offers smeared time to folks
who only send a leap smear refid in the last half of the correction then
they'll step a half-second correction.

But we're back to the case where we have to ask the question "how
important is it to the client to have accurate time?"

> smearing is 24/0 and thus is finished if the leap second occurs.

Yes, and that's a local policy choice which some folks may well choose
to select.

> Exactly as you've described it above? This will break compatibility with

Out of the box the default configuration will behave the same way
ntp-4.2.8 behaves.  Admins will have the *option* to select something
different.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 04:26:30 -0700

Dieter,

I probably should have answered your points with a longer and better
comment.

I am in no way suggesting that people should use leap smearing.

I am saying that regardless of what sort of time folks want to
distribute, we should give them the tools and configuration options (the
"mechanism") that will allow them to make the choices that support their
goals (the "local policy").

Since the NTP Project has folks who have specifically asked us to
provide a way to offer leap smearing to their client populations, we
want to be sure to let them serve their client populations to their
satisfaction.

ntp-4.4.0 will behave, out of the box, pretty much the way ntp-4.2.8
does.  Each administrator will simply have the *ability* to better
customize how they will answer.

Their choices will likely include:

- only send correct time (to everybody)
- only send leap-smearing time, to all client requests
- send correct time to clients sending LI=1, and smeared
  time to clients sending LI=0

This will all be configurable on a per-IP or per-network basis.

Do you see any problems with this approach?

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 26 Mar 2019 12:25:09 +0100

> value of 0x0, 0x1, or 0x2.

That would mean different implementations would get different
responses from the server, right? Isn't that defeating the point of
leap smearing?

E.g. ntpdate would not see a leap smear at all, but ntpd would. And
ntpd would see it only after it has synchronized, not on start, so
interesting things could happen if it was (re)started during the leap
smear. When the offset of the leap smeared time reaches the step
threshold, it could be stuck in a loop stepping the clock back and
forth, or not?

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 04:41:12 -0700

> responses from the server, right? Isn't that defeating the point of

Each side is responsible for its own behavior and choices.

As I just wrote to Dieter, an ntpd server operator can decide, on a
per-IP or per-network basis, what sort of time to return to clients
during a leap event.

> E.g. ntpdate would not see a leap smear at all, but ntpd would.

I haven't looked at an ntpdate packet in a long time, so while I'm not
sure, I'm happy to believe you.

ntpdate needs to die and go away.  We've told folks for very many years
that it hasn't fulfilled its purposed in even very many more years'
time.  But if people want to use ntpdate, they can always point it at
servers that will give it the time they want.

We will look to see how the sntp client behaves in this case, however.

> And
> smear.

Very possibly.  In that case folks are still perfectly able to make
choices about the servers they connect to.  There really are a wide
variety of choices and options here.

We're not forcing anybody to do anything.

This is all about giving people the level of choices and options they want.

> When the offset of the leap smeared time reaches the step

I'm curious how that would happen.  And even if it did, the problem
would not happen if these clients talked to servers that gave them the
sort of time they wanted during a leap smear event.

And once again I'm reminded to ask: if somebody actually configured
their clients to behave so "loosely" then how much can they really care
about accurate synchronized time?  Yes, that does sound a bit harsh.
But it's not like the case where folks didn't test their leap second
code and live-locked a huge number of kernels that then maxed out the
CPUs and a short while later caused all the HVAC systems to turn on
full.  That cost a bunch of folks real money in electricity alone.

Again, these things won't happen unless somebody specifically asks for them.

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 26 Mar 2019 12:47:45 +0100

Hi everyone,
(sorry for top-posting, Outlook is crap when it comes to quoting correctly)

I believe that the leap smearing approach has been invented in order to avoid that clients (or their OS) which do not implement leap seconds properly, survive a leap second event without time steps. The leap smearing as it has been implemented in most cases does NOT prevent clients which should not use leap smearing for various reasons (e.g. legal requirements) to sync to an leap-smearing NTP server. IMHO we should find a way to avoid that a client expecting correct time is not served with smeared time. This includes the gazillion clients out in the field not knowing about special refids or extension fields. They send an RFC compliant request (well, most of them do) to a server and expect the response to be correct time.

I therefore would want to see that an NTP server per default is only sending smeared time to clients which specifically ask for it. As far as I can see this could only be done using an extension field in the request, as all wiggling with the header fields of an incoming NTP request is always based on an assumption what exactly the NTP clients knows and wants. And this may be true for most clients, but not for all. I have seen a lot of embedded crude NTP implementations in the field and although I am all for some educational punishment in case some software engineer did not read the entire standard before implementing a client which is not compliant or behaves crazy in our opinion (100ms polling interval anyone?), I would like to avoid messing things up with all these implementations out there. 

I can agree to Harlans approach that the configuration should allow corner cases and overriding the standard behavior, but I would like to avoid to break things for all that stuff already deployed. 

Having said that, in case someone chooses to let his NTP server send smeared time but uses standard NTP packets for that (i.e. responses will be accepted by any standards compliant NTP v2, v3 or v4 client), we should definitely clearly mark the fact that this response packet is carrying smeared time using the refid. This way, you can at least see it when you try to debug why your client is slowly drifting away or flipping because someone unintentionally set it up to use two servers providing smeared time and two servers providing correct time. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

On 26.03.19, 12:27 "ntp im Auftrag von Harlan Stenn" <[email-masked] im Auftrag von [email-masked]> wrote:

    Dieter,

    

    

    
    
    H

---

From: [email-masked]
Date: Tue, 26 Mar 2019 12:58:41 +0100

Hello all,

I support Dieter's viewpoint that most of Harlan's original points can be 
read as arguments against leap smearing rather than arguments against data 
minimization (or the way it is handled in the current Data Minimization 
draft).
Honestly, I would go one step further and add that the whole discussion 
point is an argument for the case that the decision to use UTC over TAI in 
the first place was a mistake and should be reconsidered as soon as 
possible (which might not be soon at all).

That digression aside, the decision that was put forward was that of the 
document using either "SHOULD" or "MAY" for certain normative clauses.
First off, I'm a bit unclear about the significance of this decision (as 
in, who would be affected): wouldn't the same implementation be the same 
degree of conformant to a given document if all occurances of SHOULD were 
replaced by MAY and/or vice versa?
That said, it is my belief that given the rather hard-to-measure 
difference as outlined in RFC 2119, SHOULD is better suited than MAY a 
collection of suggestions
- whose advantages include making things conformant to current data 
protection regulations and preventing security goals of a crypto add-on 
from being unobtainable in the first place due to quirks of the underlying 
protectee protocol
- whose main (argued) disadvantage is that it reduces the convenience with 
which a potentially system-disrupting hack can be executed

Best regards,
Kristof

Von:    "Dieter Sibold" <[email-masked]>
An:     "Harlan Stenn" <[email-masked]>
Kopie:  "Watson Ladd" <[email-masked]>, [email-masked]
Datum:  26.03.2019 11:05
Betreff:        Re: [Ntp] Objections to the current language in 
draft-ietf-data-minimization
Gesendet von:   "ntp" <[email-masked]>

Dieter Sibold
[email-masked]

On 26 Mar 2019, at 10:47, Harlan Stenn wrote:

>>     ?SHOULD? recommendations in the document should be changed to 
>> ?MAY?.
>>
>>     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
>>     depending on how they?re asked.
>>
>>     Let?s look a the poll interval first.  If a server knows a 
>> leap second
>>     client ?lies? and doesn?t tell the server its actual poll 
>> interval, the

- Dieter

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 26 Mar 2019 05:12:43 -0700

HI Kristof,

On 3/26/2019 4:58 AM, [email-masked] wrote:
> Hello all,
> 
> I support Dieter's viewpoint that most of Harlan's original points can
> be read as arguments against leap smearing rather than arguments against
> data minimization (or the way it is handled in the current Data
> Minimization draft).
> point is an argument for the case that the decision to use UTC over TAI
> in the first place was a mistake and should be reconsidered as soon as

That's fine, but it's a separate discussion.

Some Very Big Players are insisting on using leap-smeared time, so it's
a fact of life that we must live with.

As written, the data-minimization would make it pretty much impossible
to handle mixed client populations where some clients were leap-second
aware and some were not.

Forcing a decision on this point - in either direction - is effectively
"creative destruction", and will only serve to fracture the current
infrastructure.

I think that's a terrible idea.

The goal in what I'm proposing is, in effect, either "live and let
live", or perhaps "be excellent to each other".

> degree of conformant to a given document if all occurences of SHOULD
> were replaced by MAY and/or vice versa?
> from being unobtainable in the first place due to quirks of the
> underlying protectee protocol
> - whose main (argued) disadvantage is that it reduces the convenience
> with which a potentially system-disrupting hack can be executed

Different groups have different needs/goals.  One size simply does not
fit all situations.

H
--
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> Dieter Sibold
> [email-masked]
> 
>>> “good”, there
>> http://nwtime.org <http://nwtime.org/>- be a Member!
>>

---

From: [email-masked]
Date: Tue, 26 Mar 2019 13:19:51 +0100

"ntp" <[email-masked]> schrieb am 26.03.2019 12:41:12:

> Von: "Harlan Stenn" <[email-masked]>
> An: "Miroslav Lichvar" <[email-masked]>
> Kopie: "[email-masked]" <[email-masked]>
> Datum: 26.03.2019 12:42
> Betreff: Re: [Ntp] Objections to the current language in draft-ietf-
> data-minimization

Only to a degree.
Allowing the server to decide on a per-case basis about what the time 
content of its response will be (and then using a "SHOULD" clause to do 
it) removes determinism, which seems like a bad idea in a request-response 
message scheme.
Accountability for time servers is a hard enough topic (see Roughtime and 
NTS, and please trust me that there is a good amount of additional 
intricate problems with accountability that the documents do not even 
touch upon).
I do not think we want to hand out free passes to servers for behaving in 
possibly unpredictable ways.

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 26 Mar 2019 13:29:33 +0100

> On 3/26/2019 3:26 AM, Martin Burnicki wrote:
[...]
> What would happen if some of the general pool operators decided to offer

I think I've read in the advices for pool servers that they should *not
at all* use smeared time, so by definition no pool servers should
provide smeared time.

I also think the pool maintainers pretty much know that this would be
very dangerous, and will not allow for a mixed pool.

In the past it happened that some pool servers were stratum-2 servers
that synchronized to Google's smearing servers. This is clearly a
misconfiguration (intentionally or not), and I think the pool's
monitoring system should try to detect this and kick them out of the pool.

Of course the problem remains for clients which have just recently
received the IP address of affected servers from the pool's DNS system.

> they have their pool servers offer that.

No, if the pool should support leap smearing then an extra pool should
be set up with a different name. In addition, if this happened at all,
vendors Foo, and Bar would have to agree *how* their servers smear the
time: which interval, which shape, only before the LS or symmetrically, ...

Otherwise this would cause even more confusion than it does now.

[...]
> don't care.  If the clients *do* care they have an opportunity to make a

This is fine since it's optional and compatible with simple client
implementations.

[...]
> client requests to monitor and track other systems.

This is again a completely different scenario since monitoring results
are normally not used to discipline the own system time.

> some point in the future?

Public server shouldn't smear at all, and if the operator of a private
server decides to change this he should know which clients are affected.
It's the same if an operator decides to let his server start smearing
leap seconds.

> - it allows the 2nd half of the leap smear to be applied as expected.

The question is of legacy NTP clients would put the "smear REFID" into
packets sent to the server. If they don't do so then your proposal will
cause problems.

> and shift from correct time to smeared time.

And how do you know from the beginning if a client uses iburst?

What if a simple client always just sends LI 0x03?

> If you want your server to ALWAYS send smeared time, then you are right.

That's the intended behavior when using leap second smearing.

> and I'd appreciate our discussing this more so we can come to an agreement.

My main goals would be to not break compatibility with existing clients,
don't make configuration more complex than absolutely necessary, and
only if possible without side affects provide optional ways to improve
the client's behavior and resulting accuracy.

> It's been my experience that we don't want to send unsolicited EFs in

That's what I meant.

> I have a list of our ideas, and I'm happy to set up a place for it.

That would be appreciated.

> known-allowed EFs in v4 responses.

Which EF discussed here is known-allow for all or non-current NTPv4
implementations?

> they want (there are several ways to do this),

That's the basic idea. If the client just has to use smeared time I
configure a server that provides it, and if I don#t want this I choose a
"normal" server. This doesn't require any tricks.

> - get motivated to upgrade the client software after the next leap second.

I think you know this is often not possible due to various reasons.

> they'll step a half-second correction.

Yes, and the operators of the client machine will be happy if they
configured leap smearing to avoid time steps, and now the time sis
stepped in spite of the smearing.

Sorry Harlan, but this sounds pretty error prone.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 10:32:36 +0100

> I therefore would want to see that an NTP server per default is only sending smeared time to clients which specifically ask for it. As far as I can see this could only be done using an extension fi…

Sorry, I disagree here.

As mentioned before, the original intention of leap smearing was to have
an easy way to let *all* clients of a server process the leap second in
the same way, without time steps, so that the clients always have the
*same* time, even if it's not always the correct time.

With the simple approach invented by Google (AFAIK), which is currently
also implemented in ntpd, you only have to configure the server(s) to
provide smeared time, if you need this. All clients will just follow,
regardless whether the clients are full-featured NTP daemons, or simple
NTP clients. You don't have to do anything at the client side. No need
to update each client's NTP software, modify each client's
configuration, or whatever.

If a server *only* provided smeared time to clients that explicitly ask
for it then it would not be possible to hide a leap second from simple
clients, as originally intended. You would need to care about each
individual client, make sure that it *supports* explicit requesting
smeared time, make sure it has been *configured* to enable this, etc.

So if you want a feature like this then it should at least be possible
to configure the server to always send smeared time to all clients, or
only send smeared time to clients that explicitly ask for it, which
works only if *all* clients that need it support it and have been
configured to use it.

> Having said that, in case someone chooses to let his NTP server send smeared time but uses standard NTP packets for that (i.e. responses will be accepted by any standards compliant NTP v2, v3 or v4…

Yes, that's a question of proper or faulty configuration.

With a configuration where smeared time is only sent on request a
similar problem would arise if you expect your client to smear the leap
second but forget to explicitly enable this.

To determine whether a particular server smears the time across a leap
second, or not, it is pretty late to detect this only when the server
starts already starts smearing and sends the smear REFID.

A cool feature would be to be able to determine in advance if a server
will smear the time in case of a leap second, or not, so you know if you
can configure your client to use it, or not, without having to wait
until the next leap second occurs.

For example, current versions of ntpd show a "leapsmearinterval" value
in the output of "ntpq -p" if leap smearing is enabled on this server.
But of course this information is not available if "ntpq" is not
inhibited by restrictions, so it would be great if there was a different
mechanism to retrieve this information.

On the other hand, most of this discussion only applies to clients that
get the time directly from a smearing server. What about the clients at
the next level, which get the time from a server that is being smeared
by its own upstream server?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 27 Mar 2019 03:59:28 -0700

> very dangerous, and will not allow for a mixed pool.

I'm not suggesting a mixed pool.

But I can certainly see the use by a vendor pool to have that pool offer
whatever time they choose, or have *.smeared.ntp.org as servers that are
known to smear the same way.

Agreed.

> are normally not used to discipline the own system time.

Of course.  But if there are systems that are communicating with each
other using modes 3/4, implementing this proposal will wipe out most all
of the data in the mode 3 query.

It's about information, not actual time synchronization.

> Public server shouldn't smear at all,

Many agree with you, including me.  But that doesn't stop an increasing
number of Very Big Players from doing it anyway.

> and if the operator of a private server decides
> to change this he should know which clients are affected.

I'm not so sure about this.  How can the operator of a private server be
expected to know or care who is contacting it?

> packets sent to the server. If they don't do so then your proposal will

OK, and I am genuinely curious how big a problem it will be.  Especially
since Somebody had to decide what server to connect to.

Remember, in the case you describe it appears to be pretty clear that
highly accurate and well-synchronized time is not very important.  Do
you disagree?  And the problem you are talking about is that after the
leap second event, eventually the client will correct a half-second of
offset.  That might happen immediately (in the case of behavior like
sntp), or it could take ~6 poll intervals.

> And how do you know from the beginning if a client uses iburst?

As a server I have no idea.  But if it's running ntpd or similar, it
will still sync up in about 6 polls, no matter what the poll interval is.

> What if a simple client always just sends LI 0x03?

Then it will get the documented response.

> That's the intended behavior when using leap second smearing.

There's what the server intends, and what the client intends.  They may
or may not be the same...

> the client's behavior and resulting accuracy.

If you know your clients and how they will behave, in what way does this
proposal do worse than what you have now?

I'm pretty certain that with what I've described, you can set up your
system to behave exactly same way with the new code that you have it
behave with the old code.

And if it behaves the same way, where is the problem?

Do you disagree?

> That would be appreciated.

OK, I've started that process going.

> Which EF discussed here is known-allow for all or non-current NTPv4

I-DO is the proposal that makes this easy, at least for folks who use
the chalkboard we set up to track EF proposals.  I addressed this with
part of draft-stenn-ntp-extension-fields, but the WG decided that the
proposal was not worth pursuing.

Yes.

> I think you know this is often not possible due to various reasons.

Of course.  But eventually it works out.

> Sorry Harlan, but this sounds pretty error prone.

Nobody has to use any of it.  And sure, it's possible to configure
things in a way that causes trouble.

But I'm pretty sure that this proposal gives people the server mechanism
(choices) they need to select the policy they want, and the clients
remain perfectly free and capable to select whatever servers they want.

But please show me how what I'm proposing is *worse* that what we have now.

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 27 Mar 2019 12:15:28 +0100

On 27.03.19, 10:34 "ntp im Auftrag von Martin Burnicki" <[email-masked] im Auftrag von [email-masked]> wrote:

>> I believe that the leap smearing approach has been invented in order to avoid that clients (or their OS) which do not implement leap seconds properly, survive a leap second event without time steps. The leap smearing as it has been        
>> implemented in most cases does NOT prevent clients which should not use leap smearing for various reasons (e.g. legal requirements) to sync to an leap-smearing NTP server. IMHO we should find a way to avoid that a client expecting >> correct time is not served with smeared time. This includes the gazillion clients out in the field not knowing about special refids or extension fields. They send an RFC compliant request (well, most of them do) to a server and expect the >> response to be correct time.
>> 
>> I therefore would want to see that an NTP server per default is only sending smeared time to clients which specifically ask for it. As far as I can see this could only be done using an extension field in the request, as all wiggling with the 
>> header fields of an incoming NTP request is always based on an assumption what exactly the NTP clients knows and wants. And this may be true for most clients, but not for all. I have seen a lot of embedded crude NTP 
>> implementations in the field and although I am all for some educational punishment in case some software engineer did not read the entire standard before implementing a client which is not compliant or behaves crazy in our opinion 
>> (100ms polling interval anyone?), I would like to avoid messing things up with all these implementations out there. 

>    *same* time, even if it's not always the correct time.
    
I do not think that our two statements contradict each other, I therefore would say I disagree that we disagree ;-) ..

>    smeared time, make sure it has been *configured* to enable this, etc.

Yes, exactly. My intention was to address the "server can send both correct time and smeared time" situation and I want to avoid that the server is using some kind of interpretation of the header fields in an NTP request to decide whether he sends one or the other. 
    
 >   works only if *all* clients that need it support it and have been
 
I agree that there should be such a configuration option (I.e. basically keeping the support for leap smear in ntpd as it is currently implemented).

>> Having said that, in case someone chooses to let his NTP server send smeared time but uses standard NTP packets for that (i.e. responses will be accepted by any standards compliant NTP v2, v3 or v4 client), we should definitely 
>> clearly mark the fact that this response packet is carrying smeared time using the refid. This way, you can at least see it when you try to debug why your client is slowly drifting away or flipping because someone unintentionally set it up 
>> to use two servers providing smeared time and two servers providing correct time. 

  >  second but forget to explicitly enable this.

Of course, you can always break anything by misconfiguring it. But in your example, you have to break the client configuration. I would like to avoid that a server is updated to the latest version of ntpd and is deliberately set up to be able to send both correct and smeared time, and the client in your example is sending requests with the leap bits in a certain condition that triggers the server to send smeared time (although the client may not want this).

So, my approach is putting the "configuration responsibility" on the server. 

 >  until the next leap second occurs.

Yes, if a client sends this special "please send me smeared time" request, the server could respond with a response (using EF) that indicates that there is currently no active smearing. This way a client could detect whether the server supports sending smeared time. If a server does not know this mechanism, it would probably respond with a regular NTP response packet not containing the "I am supporting this smeared-time-request" EF .. In fact the special NTP response by servers supporting this mechanism could (and should) include also the offset between correct time and the smeared time. Outside of a leap second smearing period this would simply be 0 but the mere fact that the server responds with this EF is telling the client that it supports it. 

>    by its own upstream server?
 
Again, since the information about the leap smear to correct time offset is available to the intermediate server supporting this mechanism, it can provide both smeared and correct time to downstream clients. Maybe the EF could also include information about how the smearing is done, to allow a client / intermediate server to calculate the offset between correct time and smeared time on its own, for example when the connection to the upstream server is lost in the middle of a leap smear event. 

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn:

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 27 Mar 2019 15:12:19 +0100

> I do not think that our two statements contradict each other, I therefore would say I disagree that we disagree ;-) ..

OK, that's much appreciated! ;-)

Eventually I have misunderstood what you wrote.

> Yes, exactly. My intention was to address the "server can send both correct time and smeared time" situation and I want to avoid that the server is using some kind of interpretation of the header f…

OK, that makes sense.

> I agree that there should be such a configuration option (I.e. basically keeping the support for leap smear in ntpd as it is currently implemented).

Good.

> Of course, you can always break anything by misconfiguring it. But in your example, you have to break the client configuration.

Hm, maybe you change the client behavior, but you don't change its
configuration.

> I would like to avoid that a server is updated to the latest version of ntpd and is deliberately set up to be able to send both correct and smeared time, and the client in your example is sending requests with the leap bits in a certain condition that triggers the server to send smeared time (although the client may not want this).

Again, in my opinion the basic rule is that if the server operator
decides to let the clients smear a leap second it configures the server
to send smeared time, and it's not up to the clients to decide if they
want this, or not.

The idea to let a smearing server send true UTC time to clients that
anyway know that a leap second approaches does not originate from me.

As we've seen in the discussion, if we use the LI bits from the client
request to distinguish these cases this may stop working as expected
after the time the leap second has been inserted, if the smear interval
extends beyond this time like in a "symmetric" 12/12 approach. The leap
bits are then cleared in both cases.

> So, my approach is putting the "configuration responsibility" on the server. 

But unless I'm missing something you *also* have to configure each
client to explicitly request smeared time, so the responsibility is not
only on the server.

> Yes, if a client sends this special "please send me smeared time" request, the server could respond with a response (using EF) that indicates that there is currently no active smearing. This way a…

But usually the client does not know when a leap second has been
scheduled, and smearing may begin. So should the client append the "send
smeared time" EF to each client request sent to a server (which sounds
like overkill), or should it only start doing so if it has received the
first leap second warning bit (LI 0x1 or 0x2) from the server?

> Again, since the information about the leap smear to correct time offset is available to the intermediate server supporting this mechanism, it can provide both smeared and correct time to downstrea…

It would probably even be necessary to let a server tell what the
smearing shape looks like. Even if a node receives the current smear
offset from the server at each poll, between 2 polls it had to
extrapolate the smear offset it sends to its own clients.

Martin
-- 
Martin Burnicki

Senior Software Engineer