Subject: [Ntp] Fwd: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

From: James <[email-masked]>
Date: Sun, 10 Oct 2021 20:01:53 +0200

Despite saying I was going to hold off making a new version, I've made
some changes to prevent expiration ahead of IETF 112, including an
initial threat model and other minor changes.
The working group's feedback as always would be appreciated.

- J

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, 10 Oct 2021 at 10:02
Subject: New Version Notification for
draft-gruessing-ntp-ntpv5-requirements-03.txt
To: James Gruessing <[email-masked]>

A new version of I-D, draft-gruessing-ntp-ntpv5-requirements-03.txt
has been successfully submitted by James Gruessing and posted to the
IETF repository.

Name:           draft-gruessing-ntp-ntpv5-requirements
Revision:       03
Title:          NTPv5 use cases and requirements
Document date:  2021-10-10
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-03.txt
Status:
https://datatracker.ietf.org/doc/draft-gruessing-ntp-ntpv5-requirements/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements
Diff:
https://www.ietf.org/rfcdiff?url2=draft-gruessing-ntp-ntpv5-requirements-03

Abstract:
   This document describes the use cases, requirements, and
   considerations that should be factored in the design of a successor
   protocol to supersede version 4 of the NTP protocol [RFC5905]
   presently referred to as NTP version 5 ("NTPv5").  This document is
   non-exhaustive and does not in its current version represent working
   group consensus.

The IETF Secretariat

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 11 Oct 2021 09:18:42 +0200

Hi!

I wonder: Should "gruessing" be "guessing" actually?

Regards,
Ulrich

>>> James <[email-masked]> schrieb am 10.10.2021 um 20:01 in Nachricht
<CAO+dDx=[email-masked]>:
> ‑ J
> ‑‑‑‑‑‑‑‑‑‑ Forwarded message ‑‑‑‑‑‑‑‑‑
> From: <internet‑[email-masked]>
> draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
> A new version of I‑D, draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
> Name:           draft‑gruessing‑ntp‑ntpv5‑requirements
> Revision:       03
> Document date:  2021‑10‑10
https://www.ietf.org/archive/id/draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

> Status:
> https://datatracker.ietf.org/doc/draft‑gruessing‑ntp‑ntpv5‑requirements/ 
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft‑gruessing‑ntp‑ntpv5‑requirements

> Diff:
> https://www.ietf.org/rfcdiff?url2=draft‑gruessing‑ntp‑ntpv5‑requirements‑03

>    non‑exhaustive and does not in its current version represent working
>    group consensus.
> 
> 
> 
> 
> The IETF Secretariat
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Doug Arnold <[email-masked]>
Date: Thu, 14 Oct 2021 22:45:18 +0000

Thanks James,

I think that this is pretty close to what is needed for ntpv5.  I like the separation of protocol and algorithms, and the use of monotonic timescale for timestamp fields (at least by default), and the insistence on security.

I have two comments:
1. Why do you think that encryption should be the default mode? People often consider timing information to be critical but not secret.  Also it is likely to affect accuracy in implementations by adding a variable delay to encrypt.

2. I think that it is better to allow leap smearing and make it a visible part of the protocol than to pretend it is not going to happen.  On this topic I think that Miroslav’s proposal was more realistic.  Data center network architects tell me they definitely plan to continue to do leap smearing.

Doug

From: ntp <[email-masked]> on behalf of James <[email-masked]>
Date: Sunday, October 10, 2021 at 2:02 PM
To: NTP WG <[email-masked]>
Subject: [Ntp] Fwd: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
Despite saying I was going to hold off making a new version, I've made
some changes to prevent expiration ahead of IETF 112, including an
initial threat model and other minor changes.
The working group's feedback as always would be appreciated.

- J

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, 10 Oct 2021 at 10:02
Subject: New Version Notification for

Abstract:

The IETF Secretariat

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 15 Oct 2021 08:09:52 +0200

>>> Doug Arnold <doug.arnold=[email-masked]> schrieb am
15.10.2021 um 00:45 in Nachricht
<[email-masked]>

> Thanks James,
> 
> I think that this is pretty close to what is needed for ntpv5.  I like the 
> separation of protocol and algorithms, and the use of monotonic timescale
for 
> timestamp fields (at least by default), and the insistence on security.
> 
> I have two comments:
> 1. Why do you think that encryption should be the default mode? People often

> consider timing information to be critical but not secret.  Also it is
likely 
> to affect accuracy in implementations by adding a variable delay to
encrypt.

When NTP is all about dirstibuting the correct time, encryption really seems
useless there.
However if someone wants to track (passively) how far off a server's time is,
encryption might make sense.

> 
> 2. I think that it is better to allow leap smearing and make it a visible 
> part of the protocol than to pretend it is not going to happen.  On this 
> topic I think that Miroslav’s proposal was more realistic.  Data center 
> network architects tell me they definitely plan to continue to do leap 
> smearing.

I'd strongly support some remote monitoring capability (preferrably being more
efficient than SNMP).
Authentication for any modification should be required, and optionally
encryption for any data exchange.

Regards,
Ulrich

---

From: James <[email-masked]>
Date: Fri, 15 Oct 2021 11:27:20 +0200

Doug,
Thanks for the feedback, responses inline.

> On 15 Oct 2021, at 00:45, Doug Arnold <[email-masked]> wrote:
> 
> Thanks James,
>  

We’ve had a few discussions on list on the subject in the past, and the draft says:

> Encryption and authentication MUST be provided by the protocol specification as a default and MUST be resistant to downgrade attacks...

To put this another way, I think the specification must provide confidentiality as well as authentication, and that if either is applied they cannot be removed from a connection (aka a security downgrade) which makes authentication the minimum and doesn’t necessarily mandate confidentiality.

This section in particular could probably use some editing and clarification to better explain this [1] as we’ll likely need consensus calls made.

> 2. I think that it is better to allow leap smearing and make it a visible part of the protocol than to pretend it is not going to happen.  On this topic I think that Miroslav’s proposal was more re…

In other use cases such as publicly accessible NTP, leap smearing has effectively fragmented the pools of services a given host can use as mixing smeared and non-smeared services is not a good idea, in addition to the start/end and cadence of smearing being inconsistent between providers [2]. I think that having a “linear, monotonic timescale” and leap smearing together are contradictory and so having smearing in the wire format would requiring changing that. My proposal doesn’t prevent smearing of a clock being synchronised, it’s about removing the smear from the wire.

- J

1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4
2: https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/

---

From: Doug Arnold <[email-masked]>
Date: Fri, 15 Oct 2021 15:53:44 +0000

Hello James,

I agree that leap smearing is a clumsy and dangerous way to avoid the complication of correctly handling leap seconds in distributed database software.  And if it was up to me all IT equipment would use TAI for all timing except what is displayed to humans.  But it is not up to me.  The people who are making the call tell me that they believe that leap seconds is less bad than either moving everything from UTC to TAI, or writing and debugging database software that manages leap seconds properly.

So given that state of affairs.  What do we do?

Doug

From: James <[email-masked]>
Date: Friday, October 15, 2021 at 5:27 AM
To: Doug Arnold <[email-masked]>
Cc: NTP WG <[email-masked]>
Subject: Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt
Doug,
Thanks for the feedback, responses inline.

On 15 Oct 2021, at 00:45, Doug Arnold <[email-masked]<mailto:[email-masked]>> wrote:

Thanks James,

I have two comments:

- J

---

From: Danny Mayer <[email-masked]>
Date: Fri, 15 Oct 2021 12:06:01 -0400

On 10/15/21 5:27 AM, James wrote:
>> On 15 Oct 2021, at 00:45, Doug Arnold <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Thanks James,
>> I think that this is pretty close to what is needed for ntpv5.  I 
>> like the separation of protocol and algorithms, and the use of 
>> monotonic timescale for timestamp fields (at least by default), and 
>> the insistence on security.
>> I have two comments:
>> 1. Why do you think that encryption should be the default mode? 
>> People often consider timing information to be critical but not 
>> secret.  Also it is likely to affect accuracy in implementations by 
>> adding a variable delay to encrypt.
>
> > Encryption and authentication MUST be provided by the protocol 
> specification as a default and MUST be resistant to downgrade attacks...
>
> To put this another way, I think the specification must provide 
> confidentiality as well as authentication, and that if either is 
> applied they cannot be removed from a connection (aka a security 
> downgrade) which makes authentication the minimum and doesn’t 
> necessarily mandate confidentiality.
>
> This section in particular could probably use some editing and 
> clarification to better explain this [1] as we’ll likely need 
> consensus calls made.
Encryption needs to be off the table. It's not just a bad idea, it 
provides no benefits. Time is not a confidential matter. If you have 
some use cases for encryption, please state them.
>
>> 2. I think that it is better to allow leap smearing and make it a 
>> visible part of the protocol than to pretend it is not going to 
>> happen.  On this topic I think that Miroslav’s proposal was more 
>> realistic.  Data center network architects tell me they definitely 
>> plan to continue to do leap smearing.
>
> In other use cases such as publicly accessible NTP, leap smearing has 
> effectively fragmented the pools of services a given host can use as 
> mixing smeared and non-smeared services is not a good idea, in 
> addition to the start/end and cadence of smearing being inconsistent 
> between providers [2]. I think that having a “linear, monotonic 
> timescale” and leap smearing together are contradictory and so having 
> smearing in the wire format would requiring changing that. My proposal 
> doesn’t prevent smearing of a clock being synchronised, it’s about 
> removing the smear from the wire.
>
Leap seconds needs work. I have an idea to add a leap second info piece 
to the base packet that will not only tell you if a leap second is in 
progress, but also when the last one occurred and the number of leap 
seconds added since TAI but also if one is coming up when it will occur 
and the new number of leap seconds instead. In addition, if leap 
smearing is in progress then the type of smearing (by ID maintained by 
IANA). This allows a client to filter out leap smearing or type of leap 
smearing it doesn't want.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Oct 2021 17:03:29 +0000

➢ Encryption needs to be off the table. It's not just a bad idea, it provides no benefits. Time is not a confidential matter. If you have some use cases for encryption, please state them.

I am not so sure it provides no benefits.  We used to think that DNS was a public repository and that there were no privacy concerns, and it turns out we were wrong.  Sure, time itself is not confidential -- anyone can buy a watch :) -- but the story around the meta-data for time services is not as clear.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 15 Oct 2021 13:29:19 -0400

> I am not so sure it provides no benefits.  We used to think that DNS was a public repository and that there were no privacy concerns, and it turns out we were wrong.  Sure, time itself is not confi…
The reason to do encryption is to make the contents confidential so 
noone else can know what the contents are. There's nothing in the NTP 
packet that needs to be hidden from prying eyes. The DNS issue is again 
not a matter of confidentiality. As a former DNS Developer I can tell 
you that the issue resolved with DNSSEC was to prevent spoofing. The DNS 
packet is NOT encrypted, it just has content to prevent spoofing. The 
Kaminsky attack shows an example of that.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Oct 2021 17:36:17 +0000

My point on DNS wasn't about DNSSEC, but it was about the current DNS privacy protocols (DoH, etc).

As I said, I am not confident that there is nothing in the DNS protocol messages, or meta-data, that doesn't warrant privacy. I consider myself a security person, and blanket assertions as "this protection isn't necessary" make me feel uneasy, given our history of getting things wrong.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Oct 2021 17:37:37 +0000

Sigh.  "I am not confident that tehre is nothing in the *NTP* protocol messages ... "

On 10/15/21, 1:36 PM, "Salz, Rich" <rsalz=[email-masked]> wrote:

---

From: James <[email-masked]>
Date: Fri, 15 Oct 2021 20:05:19 +0200

Danny,
It turns out DNS does need confidentiality in addition to authentication, because:

* DNSSEC is not universal, and due to broken implementations and operators who don’t bother implementing it fully not everything is covered by it
* It turns out there is a significant market for DNS query data as it allows for passive tracking of individual users and systems. Some of this is good (e.g. intrusion detection in corporate networks), but a lot of it is bad (such as ISPs violating customer’s expectations of privacy by reselling their data)
* AXFR/IXFR related traffic, which if observed in flight could expose inner details of multi-horizon or “hidden master” deployment patterns, or in insecure deployments cause hijacking of zones or records. RFC 9103 addresses some of these risks by using DNS over TLS.

DNS information may be public, but one can’t know the data unless they know what they are looking for. The TLDR Project[1] was a good example of this, and it uncovered details on the DPRK’s public DNS[2] which was previously not fully known. DNSSEC allowing for enumeration of zones was never seen as a neutral or good feature, it is seen as a security issue, which is where NSEC3 came about.

Back to the topic of NTP, I could elaborate further on the threat model in my draft to cover scenarios where confidentiality may be a useful mitigation. However, as has been mentioned by Rich and others in the past the overall trend for internet-facing protocols (which I assume NTPv5 would be) is to provide confidentiality even if optional, in part because of all the details RFC 7624 describes, amongst other guidance we’ve received from the IESG and other reviews for protocols of recent times.

Perhaps you can elaborate why you think confidentiality in NTP is a bad idea?

- J

1: https://github.com/mandatoryprogrammer/TLDR <https://github.com/mandatoryprogrammer/TLDR>
2: https://github.com/mandatoryprogrammer/NorthKoreaDNSLeak <https://github.com/mandatoryprogrammer/NorthKoreaDNSLeak>

> On 15 Oct 2021, at 19:29, Danny Mayer <[email-masked]> wrote:
> 
> 
> The reason to do encryption is to make the contents confidential so noone else can know what the contents are. There's nothing in the NTP packet that needs to be hidden from prying eyes. The DNS issue is again not a matter of confidentiality. As a former DNS Developer I can tell you that the issue resolved with DNSSEC was to prevent spoofing. The DNS packet is NOT encrypted, it just has content to prevent spoofing. The Kaminsky attack shows an example of that.
> 
> Danny
> 
>

---

From: James <[email-masked]>
Date: Fri, 15 Oct 2021 20:39:26 +0200

The problem you’re expressing here does not appear to be at odds with my proposal. All that changes is that instead of the server smearing the time it transmits, the NTP client can optionally smear the clock it is synchronising instead. A server that supports both v4 and v5 must not smear v5 timestamps, but it can smear v4.

The alternative approaches are as I see it:
1. Continue the status quo, where we have no way to signal smearing, no consistent smearing cadence, and clients avoiding mixing smeared/non-smeared servers. Nothing improves.
2. Introduce some means to communicate the existence of smearing, and either standardising the smearing cadence or have some way of signalling it. Clients may be able to mix same-cadence smearing servers but cannot mix between smearing and non-smearing. This only legitimises the status quo bodge and makes it explicit.

The people who are making the call are absolutely welcome to come participate in this discussion and provide further information. It would be great to understand more details about their use cases.

- J

> On 15 Oct 2021, at 17:53, Doug Arnold <[email-masked]> wrote:
> 
> Hello James,
>  
> On 15 Oct 2021, at 00:45, Doug Arnold <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Thanks James,
>  
> 1: https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4 <https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/4>
> 2: https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/ <https://mailarchive.ietf.org/arch/msg/ntp/hJTpPJ1L5bzBPhLtiQzL3bk75LM/>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 15 Oct 2021 18:59:01 +0000

> 2. Introduce some means to communicate the existence of smearing, and either standardising the smearing cadence or have some way of signalling it. Clients may be able to mix same-cadence smearing s…

I am not a time expert. If those are the only two choices – and we need to see if others step forward – then my view is that #2 is clearly better.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 15 Oct 2021 15:32:17 -0400

On 10/15/21 2:05 PM, James wrote:
> * DNSSEC is not universal, and due to broken implementations and 
> operators who don’t bother implementing it fully not everything is 
> covered by it
> * It turns out there is a significant market for DNS query data as it 
> allows for passive tracking of individual users and systems. Some of 
> this is good (e.g. intrusion detection in corporate networks), but a 
> lot of it is bad (such as ISPs violating customer’s expectations of 
> privacy by reselling their data)
Yes, but that has to do with (mainly) browser requests for IP addresses 
and to keep that information from ISP's and others. It's not really a 
DNS issue per se.
> * AXFR/IXFR related traffic, which if observed in flight could expose 
> inner details of multi-horizon or “hidden master” deployment patterns, 
> or in insecure deployments cause hijacking of zones or records. RFC 
> 9103 addresses some of these risks by using DNS over TLS.
AXFR/IXFR doesn't use DOH and can definitely be encrypted or use TLS 
encapsulation.
>
> DNS information may be public, but one can’t know the data unless they 
> know what they are looking for. The TLDR Project[1] was a good example 
> of this, and it uncovered details on the DPRK’s public DNS[2] which 
> was previously not fully known. DNSSEC allowing for enumeration of 
> zones was never seen as a neutral or good feature, it is seen as a 
> security issue, which is where NSEC3 came about.
There's also a NSEC5 proposal though that went nowhere.
>
> Back to the topic of NTP, I could elaborate further on the threat 
> model in my draft to cover scenarios where confidentiality may be a 
> useful mitigation. However, as has been mentioned by Rich and others 
> in the past the overall trend for internet-facing protocols (which I 
> assume NTPv5 would be) is to provide confidentiality even if optional, 
> in part because of all the details RFC 7624 describes, amongst other 
> guidance we’ve received from the IESG and other reviews for protocols 
> of recent times.
>
I want to know why confidentiality is a good idea. The complication of 
encrypting an NTP packet adds to the uncertainty of the departure of the 
packet, prevents hardware timestamping and a myriad of other measurement 
issues. The timestamps are not confidential and are only of momentary 
value. What are you trying to hide? When concentrating on the packet 
please identify what parts of the packet should not be exposed since the 
timestamps surely cannot be. If I'm wrong please tell me why I'm wrong 
and provide example use cases to support your theory. I see nothing in 
RFC7624 to indicate an area of concern where NTP is involved.

Danny

---

From: Hal Murray <[email-masked]>
Date: Fri, 15 Oct 2021 12:50:17 -0700

[email-masked] said:
> issues.

Does encrypting complicate that more than authenticating?

-- 
These are my opinions.  I hate spam.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 18 Oct 2021 07:49:14 +0200

>>> Doug Arnold <doug.arnold=[email-masked]> schrieb am
15.10.2021 um 17:53 in Nachricht
<[email-masked]>

> Hello James,
> 
> I agree that leap smearing is a clumsy and dangerous way to avoid the 
> complication of correctly handling leap seconds in distributed database 
> software.  And if it was up to me all IT equipment would use TAI for all 
> timing except what is displayed to humans.  But it is not up to me.  The 
> people who are making the call tell me that they believe that leap seconds
is 
> less bad than either moving everything from UTC to TAI, or writing and 
> debugging database software that manages leap seconds properly.
> 

Hi!

I guess the standard C library needs new functions to get the correct time
first ;-)
time_t has a problem.

Amazingly gettimeofday can use struct timezone, while clock_gettime() can't.
So adding the TAI offset to struct timezone would not help much.

Regards,
Ulrich

> To: Doug Arnold <doug.arnold@meinberg‑usa.com>
> Subject: Re: [Ntp] New Version Notification for 
> On 15 Oct 2021, at 00:45, Doug Arnold 
> <doug.arnold@meinberg‑usa.com<mailto:doug.arnold@meinberg‑usa.com>> wrote:
> 
> Thanks James,
> 
for 

likely 
encrypt.
>> Encryption and authentication MUST be provided by the protocol
specification 
> as a default and MUST be resistant to downgrade attacks...
> 
> confidentiality as well as authentication, and that if either is applied
they 
> cannot be removed from a connection (aka a security downgrade) which makes 
> authentication the minimum and doesn’t necessarily mandate confidentiality.
> 
> This section in particular could probably use some editing and clarification

> to better explain this [1] as we’ll likely need consensus calls made.
> 
> 
> effectively fragmented the pools of services a given host can use as mixing

> smeared and non‑smeared services is not a good idea, in addition to the 
> start/end and cadence of smearing being inconsistent between providers [2].
I 
> think that having a “linear, monotonic timescale” and leap smearing together

> are contradictory and so having smearing in the wire format would requiring

> changing that. My proposal doesn’t prevent smearing of a clock being 
> synchronised, it’s about removing the smear from the wire.
> 
> ‑ J
> 
> 1: 
>
https://github.com/fiestajetsam/draft‑gruessing‑ntp‑ntpv5‑requirements/issues/

> 4

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 18 Oct 2021 07:55:12 +0200

>>> Danny Mayer <[email-masked]> schrieb am 15.10.2021 um 19:29 in
Nachricht <[email-masked]>:

>> ➢ Encryption needs to be off the table. It's not just a bad idea, it 
> provides no benefits. Time is not a confidential matter. If you have some
use 
> cases for encryption, please state them.
>>
>> I am not so sure it provides no benefits.  We used to think that DNS was a

> public repository and that there were no privacy concerns, and it turns out

> we were wrong.  Sure, time itself is not confidential -- anyone can buy a 
> watch :) -- but the story around the meta-data for time services is not as 
> clear.
>>

Maybe you missed DNSCrypt, DNS-over-Quic (DoQ) and DNS-over-HTTPS
(DoH).

---

From: Danny Mayer <[email-masked]>
Date: Mon, 18 Oct 2021 10:10:13 -0400

> So adding the TAI offset to struct timezone would not help much.

The TAI-UTC decision was made over two decades ago. We just have to live 
with the consequences.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 18 Oct 2021 10:16:52 -0400

> Maybe you missed DNSCrypt, DNS-over-Quic (DoQ) and DNS-over-HTTPS
No I didn't. These efforts were about protecting users from ISP's, 
Government agencies, etc. knowing what was being requested. There's 
nothing secret about a timestamp. You really need to concentrate on the 
content of the packet and decide which parts, if any, need to be 
concealed from prying eyes. I have seen nothing so far that requires 
concealment. Please offer actual use cases of what needs to be concealed 
and why.

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 18 Oct 2021 16:33:33 +0200

> To put this another way, I think the specification must provide confidentiality as well as authentication, and that if either is applied they cannot be removed from a connection (aka a security dow…

I still don't understand this part. What do "as a default" and
"authentication the minimum" exactly mean? What information needs to
be encrypted? Everything? The first octet cannot be encrypted to allow
detection of NTPv5 packets on the port 123.

For NTPv5 to be successful in replacing NTPv4, I think it needs to
support no authentication, symmetric keys and NTS.

> In other use cases such as publicly accessible NTP, leap smearing has effectively fragmented the pools of services a given host can use as mixing smeared and non-smeared services is not a good idea…

They can be supported both as different timescales, server responding
in the one that the client has requested.

If you don't allow leap smearing in NTPv5 at all, I suspect people
will either stick to NTPv4, missing the important improvements in
NTPv5, or ignore the specification and use a leap-smeared version of
NTPv5 anyway.

Same for UTC vs TAI.

It seems we need to agree on some very high level goals for NTPv5. Is
it supposed to replace most NTPv4 use cases? Is it supposed to be
implementable on current operating systems?

-- 
Miroslav Lichvar

---

From: Warner Losh <[email-masked]>
Date: Mon, 18 Oct 2021 08:54:05 -0600

On Mon, Oct 18, 2021 at 8:10 AM Danny Mayer <[email-masked]> wrote:

> > <
> [email-masked]
> >
> >
> >> Hello James,
> >>
> > time_t has a problem

Yes. The fundamental problem is that POSIX says there's no such thing
as leap seconds in time_t. They don't exist, they don't have a unique
encoding. And any way you represent them (there's at least 3 I know
of) is ambiguous. This is the reason why smearing is a thing.

> > So adding the TAI offset to struct timezone would not help much.

Look at the 'right' timezones.

But clock_gettime passes in the 'clock' that you want. You can ask for
TAI time, but you still have the ambiguity.

> The TAI-UTC decision was made over two decades ago. We just have to live

Sadly, POSIX standardized TAI-UTC == 0. Or rather, put leapseconds
outside of the standard as something that's not worth considering since
it makes time code more complicated. Hence no unique time_t encoding for
UTC leap seconds. Or really, any encoding at all for leap seconds (which is
why I know of several ways to do it). There's language that can be taken to
mean a specific encoding, but there's contradictory language that says the
other language shouldn't be construed to dictate an encoding :(.

Oh the hundreds of hours I've wasted coping with this issue back
when I was building timing systems for a living.

Warner

---

From: James <[email-masked]>
Date: Mon, 18 Oct 2021 18:47:13 +0200

> On 18 Oct 2021, at 16:33, Miroslav Lichvar <[email-masked]> wrote:
> 

Authentication does not imply confidentiality. Where confidentiality is employed I think it’s a reasonable assumption that the entire payload would not be confidential (but all could be authenticated) and that version detection and other information that is needed in clear can do so.

> support no authentication, symmetric keys and NTS.

As I said to you last year, no authentication is fine but the protocol MUST prevent downgrade of it - to be explicit, an untrusted adversary removing it. I’m unsure given the simplistic nature of NTPv4 that this is feasible without just mandating it all the time, but I’m happy to consider other approaches that lead to the requirement being met.

> NTPv5, or ignore the specification and use a leap-smeared version of

I’m not sure “we have to do it like x or people will ignore the specification” is an appropriate position to take. Our choices are:

* Smear in the server, and be at odds with attempting to be a linear, monotonic timescale and have an accuracy penalty to all clients and limit how they can source time. If this is what NTPv5 does it should signal both the presence of potential smearing as well as when smearing is happening, and we have to answer my previous comments regarding smearing cadence.
* Have the client handle smearing the clock it synchronises, which removes all the negatives of server smearing at the cost of doing this computation. This means a mixture of clients who want UTC or TAI can use the same server, and each client can do its own business regarding cadence.

> implementable on current operating systems?

I absolutely agree with this, and in part that’s what my document is trying to cover but we’ve all been too busy arguing about the other points. To answer your questions I would say “yes” to both (and I cover use cases in my document) but we should also be explicit about what use cases are not in scope. I’m happy to take suggestions for prose from you or anyone on list.

- J

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Oct 2021 16:50:52 +0000

> support no authentication, symmetric keys and NTS.

NTPv4 and NTS are not going to go away in the next few years.  I see no reason why NTPv5 has to support them, other than coexist.  It's more like IPv4 and IPv6 than it is like TLS 1.0/1.1 and TLS 1.2/1.3 in my view.

---

From: Hal Murray <[email-masked]>
Date: Mon, 18 Oct 2021 14:13:01 -0700

[email-masked] said:
> There's nothing secret about a timestamp.

Agreded.

But the rest of the packet could provide tracking information unless everybody 
uses data minimization.

We could change the format of the request so that there is nothing to 
minimize.  (That would need padding so the length matches the response so NTP 
can't be used for amplification.)

If we are using something like data minimization because the request and 
response packet formats are similar, then we all have to use the same data 
minimization rather than have each client implementation invent their own set 
of constants.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Oct 2021 09:16:48 +0200

On Mon, Oct 18, 2021 at 06:47:13PM +0200, James wrote:
> As I said to you last year, no authentication is fine but the protocol MUST prevent downgrade of it - to be explicit, an untrusted adversary removing it.

The format of the message itself should make it impossible for the
authentication to be removed? I think there always needs to be an
authenticator field, which can be removed or zeroed out by the
attacker. If the implementation does not check the field correctly, it
will accept an unauthenticated message. I think that's an
implementation issue, not a protocol issue.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Oct 2021 09:35:07 +0200

> NTPv4 and NTS are not going to go away in the next few years.  I see no reason why NTPv5 has to support them, other than coexist.  It's more like IPv4 and IPv6 than it is like TLS 1.0/1.1 and TLS 1…

I think it's the latter. NTPv4 has a number of issues that were
identified and need to be fixed. That's the reason why I wrote my
draft. But now it seems there are people trying to turn NTP into
something else, with different ideas how an ideal protocol for time
synchronization should look like, but making it less practical, not
covering the common NTPv4 use cases.

Would it make sense to put this effort on a separate path and call it
NTPv6 or something else?

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 10:01:45 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 18.10.2021 um 16:33 in
Nachricht <YW2FvUiaHC/hbxkG@localhost>:

...
> Same for UTC vs TAI.

I thing the TAI offset (whole seconds) should be part of every NTPv5 timing packet. So we can keep the old timestamp format while providing TAI.
Maybe NTPv6 will demand that TAI should be the new time base. Still we would need the offset to provide UTC and similar.

...

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 10:05:36 +0200

>>> Warner Losh <[email-masked]> schrieb am 18.10.2021 um 16:54 in Nachricht
> TAI time, but you still have the ambiguity.

In my version of Linux (rather "new" regarding "industry standards") such a flag does not exist.

...

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 10:15:32 +0200

>>> James <[email-masked]> schrieb am 18.10.2021 um 18:47 in Nachricht
<[email-masked]>:

...
> * Smear in the server, and be at odds with attempting to be a linear, 
> monotonic timescale and have an accuracy penalty to all clients and limit how 
> they can source time. If this is what NTPv5 does it should signal both the 
> presence of potential smearing as well as when smearing is happening, and we 
> have to answer my previous comments regarding smearing cadence.
...

I think the point is: If a server smears the leapsecond, it should also keep the "non-smeared time" and send that out when being asked for the time.
Basically that would mean that there is no leap smearing in the NTP protocol; only local.

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Oct 2021 10:17:46 +0200

> I thing the TAI offset (whole seconds) should be part of every NTPv5 timing packet. So we can keep the old timestamp format while providing TAI.

That's the Timescale Offset field in my draft. If the selected
timescale is UTC or TAI, it contains the TAI-UTC offset, or 0x8000 if
unknown. The expectation is that client will request the timescale
which it is using for timestamping of NTP packets.

> Maybe NTPv6 will demand that TAI should be the new time base. Still we would need the offset to provide UTC and similar.

If all computer clocks were keeping time in TAI, or at least could
convert all their timestamps to TAI, that would make sense. But I
think it's more likely that UTC will stop leaping before TAI is
adopted everywhere.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 11:29:30 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 19.10.2021 um 09:16 in
Nachricht <YW5w4OPTrVLVQPdA@localhost>:
>> As I said to you last year, no authentication is fine but the protocol MUST

> prevent downgrade of it ‑ to be explicit, an untrusted adversary removing
it.
> implementation issue, not a protocol issue.

So it seems the authentication being requested has to be authentic ;-)
Unfortunately as the key to use is the key to "sign" the message (classic
symmetric keys), you cannot request key 0 (for unauthenticated) signed with key
0, because everybody can create such a "signature".
At the moment the server configuration determines the authentication to be
accepted, not the on-wire protocol.

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 11:31:35 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 19.10.2021 um 09:35 in
Nachricht <YW51K0w2UeOjY3g0@localhost>:
>> NTPv4 and NTS are not going to go away in the next few years.  I see no 
> reason why NTPv5 has to support them, other than coexist.  It's more like 
> IPv4 and IPv6 than it is like TLS 1.0/1.1 and TLS 1.2/1.3 in my view.
> 

I think we are still in the discussion phase, not in the implementation
phase.
Let's make a "good version", not a "quick version".

> ‑‑

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Oct 2021 11:43:25 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 19.10.2021 um 10:17 in
Nachricht <YW5/KqAZdI+EmlTn@localhost>:
>> I thing the TAI offset (whole seconds) should be part of every NTPv5 timing

> packet. So we can keep the old timestamp format while providing TAI.
> 
> timescale is UTC or TAI, it contains the TAI‑UTC offset, or 0x8000 if

Would it be allowable for a stratum-1 server to provide an "unknown TAI
offset" while still claiming to be "v5"?
It could be a challenge for systems like DCF-77 that do do provide a TAI
offset.
So maybe a special "refclock" (similar to the "PPS") would be needed to
provide the TAI offset from UTC only.
We have the leapseconds file, but updating it is still a manual task.

> 
>> Maybe NTPv6 will demand that TAI should be the new time base. Still we
would 
> need the offset to provide UTC and similar.
> 

It depends how future OS time APIs will look like.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Oct 2021 11:54:00 +0200

> offset" while still claiming to be "v5"?

Yes, of course. Most systems don't care about TAI.

> It could be a challenge for systems like DCF-77 that do do provide a TAI

Right. There are also isolated networks where computers are
synchronized to one another, but only loosely synchronized to UTC
(e.g. manual correction few times per year).

> It depends how future OS time APIs will look like.

Right.

One of the requirements for NTPv5 should be that it can be properly
implemented on current versions of all major systems, i.e. TAI cannot
be the only supported timescale.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 19 Oct 2021 03:59:14 -0700

[email-masked] said:
> implemented on current versions of all major systems, i.e. TAI cannot be the
> only supported timescale. 

Depends on what you mean by "supported".

I think we should split things into two parts.

The time used in time-transfer should be TAI to keep things clean.  No leap.  
No smear.

We need something else to cover conversion from TAI to leaping UTC and/or 
smearing UTC.  That info doesn't change very often.  I'd like to see it in a 
separate packet or maybe even a separate RFC.

The client does the conversion.  That means the client has to know if it is 
leaping or smearing.  But it needs that anyway if it is going to ask for leap 
or smear.

We could put all the authentication in a 3rd RFC.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Oct 2021 13:27:32 +0200

> The time used in time-transfer should be TAI to keep things clean.  No leap.  

I'm sure that would look great on paper, but how exactly do you
implement it? You cannot convert POSIX time_t to TAI just from the
timestamp alone. When you receive a timestamp from the kernel (e.g. in
the SO_TIMESTAMP control message), you don't know if it was captured
before or after the leap.

The other important issue is that the TAI-UTC offset is not always
known.

NTP is a simple protocol for exchanging timestamps. It shouldn't
enforce what kind of timestamps are exchanged.

It would be nice if all ideas proposed for NTPv5 had to be provided
with a proof-of-concept implementation. We would have it ready in no
time.

-- 
Miroslav Lichvar

---

From: Warner Losh <[email-masked]>
Date: Tue, 19 Oct 2021 08:18:13 -0600

On Tue, Oct 19, 2021 at 2:05 AM Ulrich Windl <
[email-masked]> wrote:

> >> >>>> Doug Arnold <doug.arnold=[email-masked]>
> schrieb
> >> am

clock_gettime(CLOCK_TAI, &ts);

CLOCK_TAI isn't standardized by POSIX, but it definitely exists in Linux
and has for 15 or 20 years.

Whether or not the system has the requisite information to give it to you
is another matter, but the clock is well defined and absolutely exists.
See Documentation/core-api/timekeeping.rst for its definition.

Warner

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Oct 2021 16:06:52 +0100

Ulrich Windl <[email-masked]> wrote:
>
> I thing the TAI offset (whole seconds) should be part of every NTPv5
> timing packet. So we can keep the old timestamp format while providing
> TAI. Maybe NTPv6 will demand that TAI should be the new time base. Still
> we would need the offset to provide UTC and similar.

The packet will also need some kind of leap indicator, because if a client
only has the current timestamp and offset, and is not aware it is in the
middle of a positive leap second, the client cannot know whether it is
2016-12-31 23:59:60 or 2017-01-01 00:00:00. (This is true whether the
timestamp is trad NTP or counts TAI seconds.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
The Minch: South or southeast 3 to 5 veering southwest 6 to gale 8,
then becoming cyclonic later. Slight or moderate becoming moderate or
rough, occasionally very rough in southwest. Rain then showers,
perhaps thundery. Moderate or good, occasionally poor.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 19 Oct 2021 11:17:41 -0400

> Maybe NTPv6 will demand that TAI should be the new time base. Still we would need the offset to provide UTC and similar.
My proposal for an additional field includes the total number of 
leapseconds added to TAI. You can then use this number to calculate the 
TAI time from the UTC timestamps sent. A zero value for the count would 
indicate the server doesn't know.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 19 Oct 2021 11:22:12 -0400

> which it is using for timestamping of NTP packets.
It's better that the offset be zero rather than 0x800 to indicate that 
it doesn't know. That way there will be no mistake.
> think it's more likely that UTC will stop leaping before TAI is
That would have been great more than 20 years ago, but whoever decided 
to do it this way had their own reasons, probably lost in the mists of 
time! :)

Danny

---

From: Warner Losh <[email-masked]>
Date: Tue, 19 Oct 2021 09:26:28 -0600

On Tue, Oct 19, 2021 at 9:18 AM Danny Mayer <[email-masked]> wrote:

> timing packet. So we can keep the old timestamp format while providing TAI.
> would need the offset to provide UTC and similar.
> >

Is that field signed or unsigned?  How large is it?

Personally, I'd make it a signed 16 bits and have 0x8000 indicating unknown.
We believe today it will always be a positive number that only ever
increases.
However, recent rotation data says that weird short term things can happen
even if we know the long term trend is always increasing and it would be a
cheap way to hedge bets.

But even an 8 bit unsigned field with 0 meaning unknown is a huge
improvement.

Be sure to have this field be well defined near leap seconds though. IIRC,
the number should increment at the start of the leap second in UTC time,
but I've not thought that through completely and since all simple things
with leapseconds are harder than you think, best to be clear so everyone
knows and any 'simple' mistakes are caught in review :) Having it only
be approximate near the leap second would be a really really bad
idea... Better to say '0' 30s either side of a leap second than to have
it be broadcast incorrectly for a few seconds after...

Warner

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Oct 2021 17:00:22 +0100

> But even an 8 bit unsigned field with 0 meaning unknown is a huge

8 bits for DTAI will only last about 100 years.

https://www.ucolick.org/~sla/leapsecs/dutc.html

> the number should increment at the start of the leap second in UTC time,

The leap second tables published by the IERS and NIST, and Bulletin C,
state that the new value of DTAI is valid from 0h UTC after the leap
second.

If you are on a POSIX system it's better to bump DTAI just before the leap
second, because that keeps the date correct. (However if you simply
evaluate the time_t formula in POSIX, that puts a positive leap second
just after midnight instead of just before.)

There is no way to represent the time during a positive leap second with
just a timestamp and DTAI: you also need a leap-in-progress flag.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  https://dotat.at/
Southeast Biscay: Variable 2 to 4 becoming southwesterly 4 to 6.
Slight or moderate becoming moderate or rough. Rain later. Good,
occasionally moderate later.

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 20 Oct 2021 09:08:44 +0200

>>> Warner Losh <[email-masked]> schrieb am 19.10.2021 um 16:18 in Nachricht

Hi!

OK, I see that I have
/usr/include/bits/time.h:#   define CLOCK_TAI                   11
/usr/include/linux/time.h:#define CLOCK_TAI                     11

but it's not documented in "man clock_gettime", so I did not know about it.

In the kernel I found these helper functions:
/**
 * ktime_get_clocktai - Returns the TAI time of day in ktime_t format
 */
static inline ktime_t ktime_get_clocktai(void)
{
        return ktime_get_with_offset(TK_OFFS_TAI);
}

__timekeeping_set_tai_offset(struct timekeeper *tk, s32 tai_offset)

However I couldn't find out who ever sets tha toffset and how...

> See Documentation/core-api/timekeeping.rst for its definition.

That file does not exist in my version 8-(

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 20 Oct 2021 09:14:53 +0200

> it be broadcast incorrectly for a few seconds after...

TAI-based servers can report the offset correctly at all times, so
clients can reliably reconstruct TAI reliably from the UTC timestamp
and the offset, but if they synchronize the clock in TAI and have an
option to request timestamps in TAI, they should probably do that
instead.

I agree it's important to define where exactly the leap is expected.
For easier implementation and compatibility with NTPv4, it might make
sense to specify the "nanokernel" leap used in current systems.

UTC-based servers will need to indicate "unknown" offset around the
leap to avoid jumps in the reconstructed TAI.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 20 Oct 2021 09:22:02 +0200

>>> Warner Losh <[email-masked]> schrieb am 19.10.2021 um 17:26 in Nachricht
> it be broadcast incorrectly for a few seconds after...

Spontaneous idea: Why not have a triple (ToLS, c_offs, n_offs) where "ToLS" is the "Time of Leapsecond", "c_offs" is the current TAI offset, while "n_offs" is the next offset.
So the offset would indicate the type of leap event, and ToLS would indicate when that would happen (in TAI time). That would also allow a proper leap announcement.

Regards,
Ulrich

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 20 Oct 2021 19:46:28 +0200

> NTPv5, or ignore the specification and use a leap-smeared version of

Many National Metrology Instituts (NMI) are using NTP to disseminate the legal time, which always is based on UTC. I suppose NMIs will appreciate if NTPv5 servers will have the option to disseminate UTC.

---

From: [email-masked]
Date: Thu, 21 Oct 2021 09:43:07 +0200

> downgrade) which makes authentication the minimum and doesn?t 

This is an interesting point.
Talking confidentiality can quickly get one to talk about masking the 
subject of conversation - and with synchronization, there is a very clear 
divide, where you can either 1) have good synchronization performance, 
because messages and timestamping are treated with urgency, OR 2) have the 
conversation not be recognizable as a synchronization exchange.
I suspect NTP/any sync protocol will always have to be treated a little 
bit differently where aspects of confidentiality are concerned.
With NTP in particular, yeah, there is even current practice that 
explicitly demands that packets be recognizable as NTP packets.

> clarification to better explain this [1] as we?ll likely need 
> consensus calls made.
> >>
> >>> 2. I think that it is better to allow leap smearing and make it 
> a visible part of the protocol than to pretend it is not going to 
> happen.  On this topic I think that Miroslav?s proposal was more 
> >> In other use cases such as publicly accessible NTP, leap smearing
> has effectively fragmented the pools of services a given host can 
> use as mixing smeared and non-smeared services is not a good idea, 
> in addition to the start/end and cadence of smearing being 
> inconsistent between providers [2]. I think that having a ?linear, 
> monotonic timescale? and leap smearing together are contradictory 
> and so having smearing in the wire format would requiring changing 
> that. My proposal doesn?t prevent smearing of a clock being 
> synchronised, it?s about removing the smear from the wire.
> >
> Many National Metrology Instituts (NMI) are using NTP to disseminate
> the legal time, which always is based on UTC. I suppose NMIs will 
> appreciate if NTPv5 servers will have the option to disseminate UTC.

Currently being employed in PTB's actual time dissemination working group, 
I can 100% attest to this.
All of my colleagues and superiors that I've ever talked to about this 
were shocked and appalled to learn that the WG was considering anything 
other than UTC as the basis for dissemination.

In that vein, I'm also supposed to communicate that the whole issue might 
become moot "soon", since leap seconds might just be removed as a thing 
that happens in UTC.
I'm just not sure how that relates to the timeframe for a possible NTPv5 
RFC release...

---

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 02:20:00 -0700

[email-masked] said:
>> The time used in time-transfer should be TAI to keep things clean.
>> No leap. No smear.

> I'm sure that would look great on paper, but how exactly do you implement it?
> You cannot convert POSIX time_t to TAI just from the timestamp alone. When
> you receive a timestamp from the kernel (e.g. in the SO_TIMESTAMP control
> message), you don't know if it was captured before or after the leap.

Good point.  What does the current code do?

I don't have a simple/clean answer.

A short term hack would be to drop all packets where a time stamp is ambigious.

A long term solution would be for the kernel to keep time in TAI and the 
library to translate all the old APIs to UTC.

A medium term fix for SO_TIMESTAMP and friends would add the TAI-UTC offset to 
the time stamp or a leap-in-progress flag.  That's a few lines of code in the 
kernel.

> The other important issue is that the TAI-UTC offset is not always known.

Yes.  I think requiring the client to know the TAI offset is reasonable.  They 
can get it from a leap-seconds type file or from a simple UDP exchange.  It's 
the same as knowing about the next leap second.

We could put it in every packet, but that seems ugly to me.  It makes things 
slightly simpler for the simple/dumb client (1 packet vs 2) at the cost of 
complicating the packet on the wire.

Maybe we should have a separate packet format for simple clients.  How dumb 
are current dumb clients?  Would they be happy with only a single time stamp 
from the server?  Do they even care about fractions of a second?

> NTP is a simple protocol for exchanging timestamps. It shouldn't enforce what
> kind of timestamps are exchanged.

We either have to pick one and hence enforce that, or put the type of 
timestamp in the packet.  I think it's cleaner to have only one on the wire.

------

The root of the problem is smearing.  The current implementation hides it from 
the client software.

Unless we change that, we have to continue with 2 NTP worlds: one set of 
servers that returns smeared time and another set that returns non-smeared 
time.

My suggestion of TAI only on the wire requires that the client implementation 
know about smearing.  The we-want-smearing information moves from hidden in 
the list of servers to an explicit flag in a config file (or whatever).

The NTP stuff for DHCP could get extended to include the smear flag.

How many other things could use tweaking?

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 21 Oct 2021 12:16:55 +0200

>> message), you don't know if it was captured before or after the leap.

Exactly.

> A short term hack would be to drop all packets where a time stamp is ambigious.

How do you find out which timestamp is ambiguous, and which is not?

I think that if you want SO_TIMESTAMPING to return a TAI timestamp you 
have to introduce another mode which requests that.

> the time stamp or a leap-in-progress flag.  That's a few lines of code in the

This would mean that  each time a packet is timestamped, the 
timestamping code would have to grab the timestamp and check and collect 
the status in an atomic way.

I bet this is too expensive, with regard to the execution time.

The same problem has been discussed before about letting user space 
programs retrieve the current time plus status from the kernel, which 
would fix lots of leap second problems.

> The root of the problem is smearing.  The current implementation hides it from

This was exactly the intention when smearing was introduced. Hiding leap 
seconds from clients so that they all have the same time but don't even 
notice there's a leap second.

We've had customers that had to stick with certain, certified software 
versions on the client systems. They weren't even allowed to update the 
kernel which had a known leap second bug, and they wouldn't be able to 
install a cool new NTP client which can do the smearing locally.

Instead, letting the server provide smeared time fixed the problem.

Clients that can do the smearing themselves don't necessarily need 
smearing info from a server.

In fact this has already been done, e.g. following the Markus Kuhn's 
UTC-SLS proposal from 2005:
https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/

If I remember correctly this is at least supported in Pearl.

Similarly, you could let the kernel smear the time if it has received a 
leap second warning.

> servers that returns smeared time and another set that returns non-smeared

Yes. In any case you have to take care about the configuration:

If you have smearing servers, you have to configure clients so that they 
either use only servers that smear in the same way, or only servers that 
don't smear.

If you have smearing clients and non-smearing servers, you have to take 
care to configure each client whether and how it shall smear the time 
when a leap second is approaching.

> the list of servers to an explicit flag in a config file (or whatever).

My preferred solution (in general) would still be to use UTC for the 
timestamps in the packets, and also provide a UTC/TAI offset so that 
systems that only need UTC can use that, and systems that need/want TAI 
can apply the offset to get TAI.

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: "Ulrich Windl" <[email-masked]>
Date: Thu, 21 Oct 2021 13:12:33 +0200

>>> Hal Murray <[email-masked]> schrieb am 21.10.2021 um 11:20 in
Nachricht
<[email-masked]>:

...
...

I wondered: Requiring that smearing servers lower (increase) their startum by one or two?
So when mixing sources, the non-smearing servers might win the selection.

An other question: Can a smearing server be confused when getting smeared time from another smearing server?
(something like: time is "t", but server smeared it to "t-0.5". The receiving server thinks it has to smear it to "t-0.5-1" eventually.)

Regards,
Ulrich

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 21 Oct 2021 15:20:10 +0200

> So when mixing sources, the non-smearing servers might win the selection.

If I remember correctly, the stratum number plays not a big role in the 
selection algorithm of ntpd. It's more important that different time 
sources agree on the "same" time.

So if there's a smearing server in a clique of non-smearing server, the 
smearing server should be outvoted as falseticker. If the majority of 
non-smearing servers have the leap second warning bit set, the client 
should accept it and handle the leap second as usual.

On the other hand, if the majority of configured servers do the same 
smearing, the non-smearing server should be outvoted. And in addition, 
the the smearing servers (which are the majority) do *not* have the leap 
second warning bit set, so the client should not accept the leap second 
warning, but instead follow the smeared time that hides the leap second.

So the client may either smear its time, or step the time for the leap 
second, depending ion the majority.

> (something like: time is "t", but server smeared it to "t-0.5". The receiving server thinks it has to smear it to "t-0.5-1" eventually.)

If a secondary server gets smeared time from a primary server, it just 
follows that time and doesn't even notice the leap second, just like any 
other client.

So it doesn't add some other smearing offset, *except* if the secondary 
has a leap second file that forces it to handle a leap second.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Doug Arnold <[email-masked]>
Date: Thu, 21 Oct 2021 13:36:02 +0000

One thing to keep in mind is that the use case for leap smearing is that it happens in a private network, where all Stratum 1 servers are configured the same.  I still consider it dangerous, though.

________________________________
From: ntp <[email-masked]> on behalf of Ulrich Windl <[email-masked]>
Sent: Thursday, October 21, 2021 7:12 AM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Ntp] Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Nachricht

...
...

Regards,
Ulrich

---

From: Danny Mayer <[email-masked]>
Date: Thu, 21 Oct 2021 11:19:17 -0400

> from the server?  Do they even care about fractions of a second?

You need different server for that on a different port. It won't happen. 
You may as well use roughtime in that case.

> timestamp in the packet.  I think it's cleaner to have only one on the wire.
The only way this is going to work operationally is to use UTC. Sending 
the TAI difference in the packet is sufficient if anyone actually needs TAI.
> The NTP stuff for DHCP could get extended to include the smear flag.
Servers have a fixed IP address and don't use DHCP. Clients like your 
laptop don't care about TAI, they only want UTC.
> How many other things could use tweaking?
How many other things would you have to change in order to make TAI the 
default.

Danny

---

From: [email-masked]
Date: Thu, 21 Oct 2021 21:18:02 +0200

I feel like we might have had this exact discussion before?

The issue is not about users or devices needing or not having access to TAI.
The issue is that the execution of leap seconds is a nightmare where digital equipment with wildly varying implementations (or, none) of that execution is concerned.
It would solve quite a few issues if neither NTP clients nor servers had to deal with that execution.

Kristof

P.S.: Also, the measurable benefit of leap seconds is that your timescale can agree with solar time of one random town in Britain to one second (plus/minus timezone stuff).

This is way past its usefulness now that satellite navigation has replaced solar navigation, and so is (IMO) us clinging to dealing with leap seconds on such a large scale.

-----"ntp" <[email-masked]> schrieb: -----

An: "Hal Murray" <[email-masked]>, "Miroslav Lichvar" <[email-masked]>
Von: "Danny Mayer"
Gesendet von: "ntp"
Datum: 21.10.2021 17:19
Kopie: "[email-masked]" <[email-masked]>
Betreff: Re: [Ntp] Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Danny

---

From: Hal Murray <[email-masked]>
Date: Thu, 21 Oct 2021 14:16:21 -0700

> time from another smearing server? 

If a server doesn't know it is a smearing server and all the servers it uses 
are smearing, then it will be a smearing server just like smearing clients 
don't know they are smearing.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Oct 2021 09:47:30 +0200

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
21.10.2021 um 15:20 in Nachricht
> sources agree on the "same" time.

True. Maybe the "rest of the smear correction" (correction that still has to be done) should be added to the dispersion instead.

>> (something like: time is "t", but server smeared it to "t-0.5". The 
> receiving server thinks it has to smear it to "t-0.5-1" eventually.)
> 

So the assumption is that only stratum-1 servers do leap smearing and higher strati even when seeing a leap announcement do "jump"? Or are they expected to ignore the leap announcement? Or do the smearing servers keep the leap announcement for themselves (not pass it on)?
Thinking about it that would demand that a smearing server always indicates "no leap" (LI==00) to ist clients as it actualy converts the leap event (taking one second) to a "smearing interval" (taking hours).

Regards,
Ulrich

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Oct 2021 10:02:40 +0200

>>> Doug Arnold <doug.arnold=[email-masked]> schrieb am
21.10.2021 um 15:36 in Nachricht
<[email-masked]>

> One thing to keep in mind is that the use case for leap smearing is that it 
> happens in a private network, where all Stratum 1 servers are configured the 
> same.  I still consider it dangerous, though.

We could demand that a smearing server may only respond to authenticated packets (maybe even specific keys), so clients expecting leap smear would have to provide some cryptographic key to the server.
A clients querying the server by mistake wuld not get a response then.

Regards,
Ulrich

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 22 Oct 2021 11:24:50 +0200

Ulrich,

Ulrich Windl wrote:
[...]
> Thinking about it that would demand that a smearing server always indicates "no leap" (LI==00) to ist clients as it actualy converts the leap event (taking one second) to a "smearing interval" (tak…

It's actually the case that ntpd (at least from ntp.org) does *not* set 
the leap second warning bit if it is smearing the time to hide the leap 
second from downstream nodes.

That's the original intention of leap smearing.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 22 Oct 2021 11:43:14 +0200

Ulrich Windl wrote:
> Martin Burnicki <martin.burnicki=[email-masked]> schrieb:
>> Ulrich Windl wrote:
[...]
> True. Maybe the "rest of the smear correction" (correction that still has to be done) should be added to the dispersion instead.

In fact, a smearing server running ntpd (at least from ntp.org) will 
change its refid during the smear interval, so clients that are aware of 
this can detect that smearing is in progress (and thus, a leap second is 
being handled), and can undo the smearing, if required, because the 
special refid provides the current smear offset.

Again, the original intention was to hide the leap second from 
downstream nodes.

[...]
> So the assumption is that only stratum-1 servers do leap smearing and higher strati even when seeing a leap announcement do "jump"? Or are they expected to ignore the leap announcement? Or do the s…

The only problem that exists here occurs if an NTP node gets smeared 
time (from upstream) without a leap second warning, but has a local leap 
second file.

In this case 2 leap seconds were applied: one via the smeared input 
time, and the other one due to the time step forced by the leap second 
announcement from the leap second file. This would result in faulty time.

> Thinking about it that would demand that a smearing server always indicates "no leap" (LI==00) to ist clients as it actualy converts the leap event (taking one second) to a "smearing interval" (tak…

Speaking again for ntpd from ntpd.org.

If a server that has been configured to provide its clients with smeared 
time receives unsmeared time from upstream servers, refclocks, etc., and 
in addition a leap second warning from those sources, or from a leap 
second file, does not smear its own system time but passes the leap 
second warning to the kernel as usual.

The smear offset is only applied to the timestamps in the network 
packets that are sent in reply to queries from downstream nodes.

I don't know whether other implementations work the same way.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 22 Oct 2021 12:00:57 +0200

>> same.  I still consider it dangerous, though.

I fully agree. Smearing is just a hack to circumvent limitations of the 
underlying time synchronization, and avoid even worse problem that would 
occur without smearing.

The main problem is with applications that get confused when the system 
time (UTC, or a local time derived from it) unexpectedly steps back by 1 
second if a leap second is introduced.

In my opinion it doesn't really help if the system clock runs on TAI 
because unless applications have explicitly designed to take care of 
leap seconds would still request UTC or local time from the operating 
system, and thus would observe the same, unexpected time step back if 
the kernel clock runs TAI and adds the TAI/UTC offset in the reply to 
the query.

The only ways to avoid the problems would be to either abolish leap 
seconds, or fix all applications to work with TAI and convert to UTC or 
local time themselves, or to be aware the time steps back due to a leap 
second are a normal case that needs to be handled, similar as the local 
time step back at the end of DST.

> A clients querying the server by mistake wuld not get a response then.

No. Exactly the other way round. Smearing is to hide the leap second 
from downstream nodes, even from dumb clients.

As I've tried to point out earlier, in any case it's the task of an 
administrator to ensure a proper configuration:

- If there are smearing and not-smearing servers, he has to configure 
which clients should query the time from which servers.

- If the clients should do the smearing, he had to configure each 
individual client whether to smear, or not.

- If a smearing server would only reply to authenticated requests, he 
had to configure on each client which server(s) to use, and which keys, 
and it wouldn't even be possible to hide the leap second from dumb clients.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Danny Mayer <[email-masked]>
Date: Fri, 22 Oct 2021 07:43:12 -0400

On 10/22/21 6:00 AM, Martin Burnicki wrote:
>>>>> schrieb am
> I fully agree. Smearing is just a hack to circumvent limitations of 
> the underlying time synchronization, and avoid even worse problem that 
> would occur without smearing.
>
> The main problem is with applications that get confused when the 
> system time (UTC, or a local time derived from it) unexpectedly steps 
> back by 1 second if a leap second is introduced.
>
> seconds, or fix all applications to work with TAI and convert to UTC 
> or local time themselves, or to be aware the time steps back due to a 
> leap second are a normal case that needs to be handled, similar as the 
> local time step back at the end of DST.
>
>> We could demand that a smearing server may only respond to 
>> authenticated packets (maybe even specific keys), so clients 
>> expecting leap smear would have to provide some cryptographic key to 
>> the server.
> had to configure on each client which server(s) to use, and which 
> keys, and it wouldn't even be possible to hide the leap second from 
> dumb clients.
>
You also need to worry about the cascading effects of a server accepting 
smeared time turning around a sending out smeared timestamps in response 
to requests from downstream clients. Smearing cannot be considered in 
isolation.

Danny

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 22 Oct 2021 14:18:57 +0200

> to requests from downstream clients. Smearing cannot be considered in 

Correct. Cascading servers, mixing smearing and non-smearing time 
sources, providing smearing clients with a leap second file, etc. are 
another stage of potential problems an admin has to keep in mind in all 
of the cases I mentioned.

As I said, smearing is a hack, and I just wanted to point out that it's 
not easier to let the clients do the smearing, as some folks here seem 
to assume.

In fact, one of the original reasons why Google introduces server-side 
smearing was that the only had to configure this on a few servers, and 
the configuration of a huge number of clients that were anyway sync'ing 
to those servers didn't need to be touched.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 22 Oct 2021 14:32:50 +0200

>>> Danny Mayer <[email-masked]> schrieb am 22.10.2021 um 13:43 in

> to requests from downstream clients. Smearing cannot be considered in 

That's what my original point was about.

Ulrich

---

From: Doug Arnold <[email-masked]>
Date: Fri, 22 Oct 2021 15:05:34 +0000

My understanding is that Google builds all of its own timing infrastructure, so they can start with smearing as a part of their architecture.

Now everyone wants to copy the Google Spanner approach to distributed data bases, but with timing from vendors and open source projects.  I wish them luck.

On 10/22/21, 8:19 AM, "Martin Burnicki" <[email-masked]> wrote:

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]<mailto:[email-masked]>
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

---

From: Denis Reilly <[email-masked]>
Date: Mon, 25 Oct 2021 21:14:12 +0000

Leap smearing was one of the main topics of the BCP. Because we understand why it’s a good idea in many cases, but also why it can be perilous if handled incorrectly.

In the BCP, we arrived at a few key guidelines, aiming to preserve the most flexibility to operators while still maintaining standard public behavior:

- Don’t mix smearing and non-smearing servers
- Don’t smear if your timestamps are required to be in sync with UTC
- Only smear on totally private installations, do not smear on public servers

In my view, these restrictions exist because there is no standardized way to detect that a server is smearing in ntpv4. So we settled on the notion that public interactions should use the standard timescale, while operators could do whatever they wanted in the privacy of their own networks.

At minimum, NTPV5 should include a standardized way for the server to tell everyone else that it is smearing the timestamps on the wire, so that clients can elect to not use the server. In my opinion, there is no use in saying that smearing on the wire is not allowed in V5 – people will do it anyway.

I think that we should also have a way for the server to broadcast the smearing algorithm in use on the network. This is, of course, valuable when servers are smearing, because then a client which knows about this can back-out the smearing behavior and obtain UTC time if it wants to. But it’s also valuable if the server is not smearing, because it can help coordinate client-side smearing in clients who are intelligent enough. (In other words, if all nodes updated to NTPv5 with support for this, the server could keep the timestamps as RFC-compliant non-smeared UTC on the wire while telling all clients how to apply the leap smear uniformly if they need to, getting the best parts of client-side and server-side smearing together, while keeping the wire timestamps in UTC.)

In my opinion, we should aim preserve the most flexibility. We should make it easier for operators to do client-side or server-side smearing, and we should allow operators using servers outside their administrative domain to reject servers who apply rules they don’t like. We’re not going to get everyone to agree on one behavior, the best we can do is make sure that behaviors are standardized and easy to implement. To me it seems like we would get a lot of benefit out of adding a few extensions. There have been attempts to standardize this in the past, maybe we can get it done in V5 (just in time for leap seconds to be abolished).

--
Denis Reilly
Principal Timing Architect, Equinix Precision Time
[email-masked]<mailto:[email-masked]>  |  +1-585-282-7899

From: ntp <[email-masked]> on behalf of Doug Arnold <doug.arnold=[email-masked]>
Date: Friday, October 22, 2021 at 11:06 AM
To: Martin Burnicki <[email-masked]>, Danny Mayer <[email-masked]>, Ulrich Windl <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt

Martin
--
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [email-masked]<mailto:[email-masked]>
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/<https://urldefense.com/v3/__https:/www.linkedin.com/in/martinburnicki/__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mOfAMNRG$>

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://urldefense.com/v3/__https:/www.meinberg.de__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mMAr9L8v$>  https://www.meinbergglobal.com<https://urldefense.com/v3/__https:/www.meinbergglobal.com__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mPZeVtZc$>
Training: https://www.meinberg.academy<https://urldefense.com/v3/__https:/www.meinberg.academy__;!!PcPv50trKLWG!gybm7Ic-FCTLPuRyEr00WxnwopPwJPP057utZzRBe6qBJBGqem1MRt08mNntA4yb$>

---

From: Doug Arnold <[email-masked]>
Date: Mon, 25 Oct 2021 22:08:18 +0000

Thanks Denis.  I completely agree. When it come to smearing, transparency is safer than trying to ban it.  That is why a proposal like the one which Miroslav has in draft is needed.

Doug

From: Denis Reilly <[email-masked]>
Date: Monday, October 25, 2021 at 5:14 PM
To: Doug Arnold <[email-masked]>, Martin Burnicki <[email-masked]>, Danny Mayer <[email-masked]>, Ulrich Windl <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [EXTERNAL] Re: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] Re: New Version Notification for draft‑gruessing‑ntp‑ntpv5‑requirements‑03.txt
Leap smearing was one of the main topics of the BCP. Because we understand why it’s a good idea in many cases, but also why it can be perilous if handled incorrectly.

Martin
--
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 26 Oct 2021 10:00:20 +0200

Denis Reilly wrote:
> Leap smearing was one of the main topics of the BCP. Because we 
> understand why it’s a good idea in many cases, but also why it can be 
> perilous if handled incorrectly.
> 
> In the BCP, we arrived at a few key guidelines, aiming to preserve the 
> most flexibility to operators while still maintaining standard public 
> behavior:
> 
> In my view, these restrictions exist because there is no standardized 
> way to detect that a server is smearing in ntpv4. So we settled on the 
> notion that public interactions should use the standard timescale, while 
> operators could do whatever they wanted in the privacy of their own 
> networks.
> 
> At minimum, NTPV5 should include a standardized way for the server to 
> tell everyone else that it is smearing the timestamps on the wire, so 
> that clients can elect to not use the server. In my opinion, there is no 
> use in saying that smearing on the wire is not allowed in V5 – people 
> will do it anyway.

Absolutely true.

> I think that we should also have a way for the server to broadcast the 
> smearing algorithm in use on the network. This is, of course, valuable 
> when servers are smearing, because then a client which knows about this 
> can back-out the smearing behavior and obtain UTC time if it wants to.

Hm, I'm not sure what would be the best way to broadcast the smearing 
parameters in a future-safe way. There is the smear interval, when it 
starts and when it ends, and also the smear function: linear, cosine, 
quadratic, or whatever will be invented in the future.

Maybe it's easier and less error prone to let the server indicate *that* 
it provides smeared time, and what the current smear offset is. So 
clients can easily convert this back to UTC, if they want/need to.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 28 Oct 2021 09:09:38 +0200

>>> Denis Reilly <[email-masked]> schrieb am 25.10.2021 um 23:14 in
Nachricht
<[email-masked]>:
> Leap smearing was one of the main topics of the BCP. Because we understand 
> why it’s a good idea in many cases, but also why it can be perilous if 
> handled incorrectly.
> 
> In the BCP, we arrived at a few key guidelines, aiming to preserve the most

> flexibility to operators while still maintaining standard public behavior:
> 
> In my view, these restrictions exist because there is no standardized way to

> detect that a server is smearing in ntpv4. So we settled on the notion that

> public interactions should use the standard timescale, while operators could

> do whatever they wanted in the privacy of their own networks.
> 
> At minimum, NTPV5 should include a standardized way for the server to tell 
> everyone else that it is smearing the timestamps on the wire, so that
clients 
> can elect to not use the server. In my opinion, there is no use in saying 
> that smearing on the wire is not allowed in V5 – people will do it anyway.
> 
> smearing algorithm in use on the network. This is, of course, valuable when

> servers are smearing, because then a client which knows about this can 
> back-out the smearing behavior and obtain UTC time if it wants to. But it’s

> also valuable if the server is not smearing, because it can help coordinate

> client-side smearing in clients who are intelligent enough. (In other words,

> if all nodes updated to NTPv5 with support for this, the server could keep 
> the timestamps as RFC-compliant non-smeared UTC on the wire while telling
all 
> clients how to apply the leap smear uniformly if they need to, getting the 
> best parts of client-side and server-side smearing together, while keeping 
> the wire timestamps in UTC.)
> 
> In my opinion, we should aim preserve the most flexibility. We should make 
> it easier for operators to do client-side or server-side smearing, and we 
> should allow operators using servers outside their administrative domain to

> reject servers who apply rules they don’t like. We’re not going to get 
> everyone to agree on one behavior, the best we can do is make sure that 
> behaviors are standardized and easy to implement. To me it seems like we 
> would get a lot of benefit out of adding a few extensions. There have been 
> attempts to standardize this in the past, maybe we can get it done in V5 
> (just in time for leap seconds to be abolished).

So any future smearing server would add packet extensions to indicate:
* the smearing algorithm (required to indicate smearing is in progress)
* the offset from UTC (or the common time base being used in the NTP packets)

And I guess there will be numbers assigned to smearing algorithms.

Regards,
Ulrich
...