Subject: Re: [Ntp] NTPv5: big picture

From: Magnus Danielson <[email-masked]>
Date: Fri, 1 Jan 2021 13:29:58 +0100

Hi Hal,

On 2021-01-01 06:53, Hal Murray wrote:
> [email-masked] said:
>> Define "get rid off". Do you meant you want the basic protocol to use a
>> monotonically increasing timescale such as a shifted TAI? If so, I think it
>> would make a lot of sense. 
> I'd like the basic document not to include the words "leap second", except 
> possibly for a chunk that says we-don't-do-that, look-over-there.

I think that might be a mistake, even if I can understand the ambition.
I think carrying the leap-second difference TAI-UTC is mandatory, and as
such, the reference to that other document, if indeed handled as
separate documents, needs to say so.

That the core timing mechanisms do not have to handle leapsecond
processing to keep it simple, that I can support, but not taking the
leapsecond handling out of the required part of the protocol.

> I didn't say TAI because I don't know enough about the politics of using that 
> term.
There is now a separate resolution identifying both UTC and TAI. You can
say shifted TAI in this context.
>
> My straw man is that POSIX time, UTC, leaping, and smearing should be moved to 
> extensions and they be described in a separate document.

Notice, LINUX time != POSIX time. They handle leap seconds differently.

>
>
> [moving leaps out of kernels]
>> I think that would be far to ambitious to rock that boat.
> Yes, but if everybody says that nothing will ever happen.
It never happens quick.
>> Kernels already operate with a double vision and have ways to handle both
>> non-leaping time and leapsecond in parallel. 
> My (Linux) man page has various options for clock_gettime(), but it doesn't 
> say anything about leap seconds or TAI.  Yes, it should be reasonable to add, 
> but it's not there yet.

Which only says that you should not trust your decision-making on what
the man-page for a single command, it's not telling you the full story.

So, there is CLOCK_TAI for starters. Then you also need to look at the
nanokernel support, which is there, and the leap-second handling,
leap-second information it does keep in the kernel. It's been there for
fairly long now, that we can consider the Linux kernel to support it for
all the versions we consider. All we need to do is keep supplying it
with correct time and correct leap-second information.

We also need to acknowledge that the Linux time does not transition over
the leapsecond as the UNIX/POSIX or traditional NTP does, since Linux
time has double 23:59:59 rather than double 00:00:00. This is why I talk
about POSIX and Linux time as different time-scales.

So, Linux have nice support if we only look at the right places. I've
even read part of the code for it.

>
>
> [options]
>> The solution that works for other protocols is that you ask for capabilities
>> (or you get them served as part of basic handshake). This is typically a
>> text-string of well defined capability names. Set of constants or set of bits
>> have also been seen.
> That works fine for cases like SMTP or HTTP where it represents a minor 
> fraction of the overall workload.  The usual context is the client can get 
> their work done without the new feature but do things better if they use 
> new/optional features.  In the context of NTP, we don't want to use a server 
> if it doesn't support a feature we need.  It would be better to discover that 
> without going through NTS-KE.
The initial server handshake where we learn about the servers, its
capabilities, whatever handshakes needed etc. can follow somewhat other
rules than we use for the continuous processing. However, we need to
ensure that we achieve the same security in the initial handshake and
hand-over as we later assumes from the continuous processing, or else we
have a potential security problem. Doing it with different mechanisms
may or may not be wise, depending on the peculiarities. For those
needing good authentification, I think it would be unwise to use another
method unless it can be shown to be as safe. Then again, as per my other
notion, these can exist in parallel if we see a significant benefit.
Whatever, we need to make sure that there is a known safe way that
things start up, that different implementations have ways to handshake
and that no manual intervention is needed, while it all achieves the
intended goal.
>> Do not assume you have it, prefer the authenticated answer when you can get
>> it. I am not sure we should invent another authentication scheme more. 
> An important difference between NTP exchanges and feature requests is that the 
> available features change very slowly.

Indeed. As with management communication, and this is part of the
management interface, it has a completely different profile from the
time-stamping exchange.

We have three types of data, time-stamp exchange (for two-way
time-transfer), clock data and management. They are in that order of
timing criticality.

>> So, we want to be able to poll the server of capabilities. Remember that this
>> capability list may not look the same on un-authenticated poll as for
>> authenticated poll. It may provide authentication methods, hopefully one
>> framework fits them all, but we don't know. As you ask again you can get more
>> capabilities available under that authentication view. Another configuration
>> or implementation may provide the exact same capabilities regardless of
>> authentication.
> Yes, but it we take that approach then we have to consider all the 
> opportunities for the bad guy to forge answers so we get downgraded to a 
> less-good mode of operation.
You can never in a stroke remove that risk. At the same time, NTP is
used is such a wide range of applications, not all the scenarios is
relevant everywhere. If we talk about the "Internet" scenario I would
agree we want to ensure such threats needs to be considered.
>
>
>> Do no assume you have DNS access, the service cannot rely on that. It can
>> however be one supplementary service. NTP is used in some crazy places.
>> Similarly with DNSSEC, use and enjoy it when there, but do not depend on its
>> existence. 
> I'm happy for a config file to use numeric IP Addresses rather than host names.

Depending on scenario you have access to DNS or not. For a wider range
of applications, assuming DNS to always be there is not wise. For the
"Internet" scenario, DNS is usually there, and hopefully we can validate
using DNSSEC. For the "Internet" scenario, we actually want many devices
to use DNS, as we have seen what happens when an IP address gets
default. This however is not to say that all scenarios will involve
access to DNS.

Rather than assuming a particular scenario to always be true, we should
indentify a few particular scenario and then put assumptions and
requirements on implementations tied to the scenario it is used in. A
very important scenario that I call "Internet" will require much more
support, and I would see a whole range of requirements we very
specifically want to put on implementations as they work in that
scenario. For other scenarios, such as "local" where the same
implementations now work on maybe a point-to-point or very small network
with no internet connection, then we want that to be able to work
without as much support. The "secure local" may require as strong setup
for "Internet", but it then comes with the burden of supporting some
additional side-services because the restricted environment. There is
also scenarios where the access to Internet is very very restricted
because of security concerns, but there is limited access and it needs
to be jotted down what that is. Trouble is, I see NTP used in the whole
range of these, so the specifications needs to be flexible enough to
handle these different scenarios and there is some artistery of not
making too much load onto each and every of these scenarios.

When on the "Internet", we should require DNS access. We should require
boxes that have preconfigured servers to have them preconfigured as
DNS-entries rather than fixed IP addresses. We learned that the hard way
(ask PHK). This is not to say it will be the right thing for all other
scenarios we can use NTP in.

Cheers,
Magnus

---

From: Doug Arnold <[email-masked]>
Date: Fri, 1 Jan 2021 16:14:37 +0000

I would say that the unifying themes for ntpv5 are greater flexibility, and higher accuracy, compared to ntpv4.  

Doug

On 12/31/20, 9:54 PM, "ntp on behalf of Hal Murray" <[email-masked] on behalf of [email-masked]> wrote:

    Do we have a unifying theme?  Can you describe why we are working on NTPv5 in 
    one sentence?

    I'd like to propose that we get rid of leap seconds in the basic protocol.

    Unfortunately, we have a huge installed base that works in Unix time and/or 
    smeared time.  Can we push supporting that to extensions?  Maybe even a 
    separate document.

    --------

    Part of the motivation for this is to enable and encourage OSes to convert to 
    non-leaping time in the kernels.  Are there any subtle details in this area 
    that we should be aware of?  Who should we coordinate with?  ...

    ---------

    I think this would bring out another important area: How does a client 
    discover if a server supports an option and/or discover servers that do 
    support it?

    I'd like the answer to be authenticated.  It seems ugly to go through NTS-KE 
    if the answer is no.  Maybe we should distribute the info via DNS where we can 
    use DNSSEC.

    Again, that can be a separate document.

    -- 
    These are my opinions.  I hate spam.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 1 Jan 2021 17:08:01 +0000

>    I would say that the unifying themes for ntpv5 are greater flexibility, and higher accuracy, compared to ntpv4.  

I would like to see security on that list.

---

From: Hal Murray <[email-masked]>
Date: Fri, 01 Jan 2021 13:56:57 -0800

> higher accuracy, compared to ntpv4.   

Do you have any ideas on how to improve accuracy?

What are you thinking of for flexibility?  There has been a lot of pressure to 
require feature X.  Examples are TAI-UTC offset and authentication.  That 
seems like reducing flexibility.

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 2 Jan 2021 00:02:13 +0100

> Do you have any ideas on how to improve accuracy?

Not documenting how it should get implemented, just document the
sources of uncertainty and how you combine them.

Kurt

---

From: Philip Prindeville <[email-masked]>
Date: Fri, 1 Jan 2021 17:55:21 -0700

Replies…

> On Dec 31, 2020, at 8:35 PM, Magnus Danielson <[email-masked]> wrote:
> 
> Hal,
> 
> On 2021-01-01 03:54, Hal Murray wrote:
> monotonically increasing timescale such as a shifted TAI? If so, I think
> it would make a lot of sense.
> 
> If it is about dropping leap second knowledge, it does not make sense.

I think “handle separately” makes sense here.  It shouldn’t be a blocking problem and how we handle it, assuming me handle it correctly, is orthogonal to everything else.  Or should be.  See “assuming we handle it correctly”.

> Mapping of NTPv5 time-scale into (and from!) NTP classic, TAI, UTC,
> UNIX/POSIX, LINUX, PTP, GPS time-scales is probably best treated
> separately, but needs to be part of the standard suite.

I think TAI makes sense, assuming I fully understand the other options.

If NTP v5 sticks around as long as NTP v4 has to date, I think we can’t underestimate the implications in both autonomous flight (the unpiloted taxis that are being certified right now come to mind), as well as the proliferation of commercial space flight… space flight has been commoditized (in part) by the use of commercial-off-the-shelf technologies such as metal 3D printing for generating bulkheads and structural panels.

Why shouldn’t the time standard/format used for space flight also be COTS?

It seems increasingly probably over the next 20 years that interplanetary flight will become common.

Further, assuming we start colonizing the moon and Mars… stay with me here… will the length of a terrestrial day still even be relevant?  Or will we want a standard based not on the arbitrary rotation of a single planet, but based on some truly invariant measure, such as a number of wavelengths of a stable semiconductor oscillator at STP?

> I think that would be far to ambitious to rock that boat.

Divide and conquer.

I think POSIX clock_* attempted this by presenting mission requirements-based API’s.

The next step is to have consumers of time migrate… perhaps starting with logging subsystems, since unambiguous time is a requirement for meaningful forensics.

> Kernels already operate with a double vision and have ways to handle
> both non-leaping time and leapsecond in parallel.

"Double vision" is perhaps an understatement.

Another good example is SNMP using “uptime” as 100Hz ticks since booting… since oftentimes a good external source of time can’t be established until well into the boot process.

As I recall, this is one of the CLOCK_ types in POSIX.

> The solution that works for other protocols is that you ask for
> capabilities (or you get them served as part of basic handshake). This
> is typically a text-string of well defined capability names. Set of
> constants or set of bits have also been seen.

Or ASN.1 OIDs or… 

>> if the answer is no.
> Do not assume you have it, prefer the authenticated answer when you can
> get it. I am not sure we should invent another authentication scheme more.
> 
> Let's not make the autokey-mistake and let some information be available
> only through an authentication scheme that ended up being used by very
> few. You want to have high orthogonality as you do not know what lies ahead.
> 
> So, we want to be able to poll the server of capabilities. Remember that
> this capability list may not look the same on un-authenticated poll as
> for authenticated poll. It may provide authentication methods, hopefully
> one framework fits them all, but we don't know. As you ask again you can
> get more capabilities available under that authentication view. Another
> configuration or implementation may provide the exact same capabilities
> regardless of authentication.
> 
>>  Maybe we should distribute the info via DNS where we can 
>> use DNSSEC.
> 
> Do no assume you have DNS access, the service cannot rely on that. It
> can however be one supplementary service. NTP is used in some crazy
> places. Similarly with DNSSEC, use and enjoy it when there, but do not
> depend on its existence.

Good point.

As someone who works in security, I’ve seen a fair share of exploits that arise when protocols make tacit assumptions about the presence and correctness of other capabilities and then these turn out not to be valid under certain critical circumstances.

Doing X.509 when you don’t have Internet connectivity for CRL’s or OCSP is a good example.

> When DNS is available, what additional values can be put there to aid
> validation and service?

Uh… Available “where”?  The internet is relativistic.  What the server sees and what the client sees can be wildly different, even from moment to moment.

> Sure. I think the final word on slicing and dicing of documents becomes
> an issue once the parts are done. I think one should not focus too much
> on it, as it will become apparent later in the process what will make
> most sense.

I would argue the opposite: let’s keep them as decoupled as possible, and only cede to inter-dependency when we can’t otherwise avoid it.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Fri, 1 Jan 2021 17:55:47 -0700

> On Jan 1, 2021, at 10:08 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 

+1

---

From: Paul Gear <[email-masked]>
Date: Sat, 2 Jan 2021 11:54:38 +1000

> I would like to see security on that list.

Hi everyone,

I would like to add my agreement with the increased security
requirement, add another general theme which will, at times, need to be
traded off against some of the other requirements: commends itself for
wide deployability.

What I mean here is that we have the user base of the public pool, and
many other pools which are publicly-accessible but run independently
(e.g. Apple, Cloudflare, Google, Microsoft, Ubuntu) which collectively
amount to billions of users who depend on NTP, but many (most?) of whom
don't care much about accuracy and may even be ignorant of NTP's existence.

It's great to aim for making NTP more suitable for high-accuracy
environments which can currently only be served by PTP, but we shouldn't
do this at the cost of making NTPv5 less viable for adoption by those
billions by making it harder to deploy (e.g. by requiring changes to
every firewall which allows NTP, or making it hard to work out whether
you're looking at UTC or TAI time).

I'm not saying that the WG is failing at this presently.  But it's easy
to get preoccupied with time-nerd concerns and we need to work hard at
keeping the use case of the massive majority in focus.

Regards,
Paul

---

From: Magnus Danielson <[email-masked]>
Date: Sat, 2 Jan 2021 03:01:18 +0100

Philip,

> I think “handle separately” makes sense here.  It shouldn’t be a blocking problem and how we handle it, assuming me handle it correctly, is orthogonal to everything else.  Or should be.  See “assum…
I think the core time should have a very well known property, and then
we can provide mappings of that and provide mapping parameters so that
it can be done correctly.
> I think TAI makes sense, assuming I fully understand the other options.
Do notice, the actual TAI-timescale is not very useful for us. We should
have a binary set of gears that has it's epoch at some known TAI time.
One such may for instance be 2021-01-01T00:00:00 (TAI). As one can
convert between the NTPv5 timescale and the TAI-timescale we can then
use the other mappings from TAI to other timescales, assuming we have
definitions and other parameters at hand. One such parameter is the
TAI-UTC (and upcoming change).
> It seems increasingly probably over the next 20 years that interplanetary flight will become common.
Things can be installed in places where we just don't have access to
normal network.
> Further, assuming we start colonizing the moon and Mars… stay with me here… will the length of a terrestrial day still even be relevant?  Or will we want a standard based not on the arbitrary rotat…
You can setup additional time-scales and supply parameters to convert
for them. If you need a Mars time, that can be arranged. JPL did that
because they could.
> I think POSIX clock_* attempted this by presenting mission requirements-based API’s.
That was only part of the full interface.
> The next step is to have consumers of time migrate… perhaps starting with logging subsystems, since unambiguous time is a requirement for meaningful forensics.
They will do what the requirements tell them. Many have hard
requirements for UTC.
> "Double vision" is perhaps an understatement.
It is, can be expected from me.
> As I recall, this is one of the CLOCK_ types in POSIX.
It is.
>> constants or set of bits have also been seen.
Sure. There is gazillion ways of doing it, I grabbed a few that seems
popular. ASN.1 isn't popular, just what people is forced to used.
> Doing X.509 when you don’t have Internet connectivity for CRL’s or OCSP is a good example.
I've seen many networks where normal rules of internet applies, yet they
are critical, need it's time and fairly well protected.
> Uh… Available “where”?  The internet is relativistic.  What the server sees and what the client sees can be wildly different, even from moment to moment.
I didn't say it was on Internet at all times. I can see things like a
point-to-point wire, I can see a heavily fortified network air-gapped
from Internet, I can see networks heavily fortified with very indirect
access to Internet. I can see things with a NAT or just a simple
firewall to the Internet. For some of these scenarios DNS will be
available, for some not. They all use the same "Internet technology"
because that is COTS. So, designing and internet technology also entails
to design for these other scenarios. A succsessful design also
understand and respect the problems of the more isolated scenarios.
> I would argue the opposite: let’s keep them as decoupled as possible, and only cede to inter-dependency when we can’t otherwise avoid it.

It's really not being the opposite, rather that is needed to get a
decent structure, because all you argue for is that we please please do
not make the specification a spagetti-coded one. Nobody wants that. How
the pieces is fit into a document or several is a complete orthogonal
property in that case. I was reacting on the over-focus on document here
and document there.

Cheers,
Magnus

---

From: Philip Prindeville <[email-masked]>
Date: Fri, 1 Jan 2021 19:23:00 -0700

> On Jan 1, 2021, at 6:54 PM, Paul Gear <ntp=[email-masked]> wrote:
> 

I occasionally bang on the default set of rules for OpenWRT, perhaps the most pervasive Open Source router package out there today.  What are your specific concerns about what’s not being done?

The current model for OpenWRT is that it’s a suborned peer to more accurate (lower stratum) servers out there, and then in turn provides time to the clients inside its perimeter.  It typically doesn’t support queries from external sources (which helps avoid spoofing attacks).

If there’s something we’re not doing that we should be, please call it out now.  Or conversely, something we’re doing that we shouldn’t be...

Thanks

---

From: Philip Prindeville <[email-masked]>
Date: Fri, 1 Jan 2021 19:49:52 -0700

Replies…

> On Jan 1, 2021, at 7:01 PM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 

Jon Postel would frequently tell us, “protocol, not policy”.

The mapping doesn’t have to be embedded in the protocol if it’s well understood and unambiguous.

> TAI-UTC (and upcoming change).

I’m hoping to avoid further proliferation of timescales if possible.

> Things can be installed in places where we just don't have access to

Can you say what a “normal network” will be in 20 years?  I can’t.

When I wrote RFC-1048 in 1988 I hardly thought there would be more than 4B IP-enabled smartphones with 2-way video capability less than 30 years later.

I’m not even sure what 10 years down the road looks like.  And I’ve been trying for almost 4 decades.  My track record is nothing to brag about.

What’s the shelf-life on WiFi6 or 5G?

Will residential US ISP’s finally have rolled out IPv6?

> for them. If you need a Mars time, that can be arranged. JPL did that

KISS

The Mars Climate Orbiter impacted the planet in 1999 because NASA was using imperial units while everyone else was using metric.  That’s a catastrophic mistake arising from the existence of a SECOND scale of measurement.

https://everydayastronaut.com/mars-climate-orbiter/

> That was only part of the full interface.

Yes.  So?

> They will do what the requirements tell them. Many have hard

Many will also migrate to whatever provides them with unassailable (unambiguous) timestamps in the case of litigation.  I’ve worked on timing for natural gas pipelines so that catastrophic failures (i.e. explosions) could be root caused by examining high precision telemetry… not the least of which was to protect the operator in the case of civil suits of criminal negligence, etc.

> popular. ASN.1 isn't popular, just what people is forced to used.

If popular equates to ubiquitous, then you can’t do SSL without ASN.1… and that makes it “popular” (though not “well liked” by any measure).  But I’m splitting hairs over semantics.

> are critical, need it's time and fairly well protected.

Not quite following what you’re saying.  Are you alluding to operating a (split-horizon) border NTP server to hosts inside a perimeter, that in turn don’t have Internet access themselves (effectively operating as an ALG)?  Or something else?

> understand and respect the problems of the more isolated scenarios.

FWIW, a border forwarding/caching recursive DNS server is a degenerate case of an ALG.

-Philip

---

From: Hal Murray <[email-masked]>
Date: Fri, 01 Jan 2021 21:05:01 -0800

> I would like to see security on that list.

What do you want that isn't already covered by NTS and/or shared keys?

(I think we need to move the MAC for shared keys into an extension.  That's 
not a "big picture" item.)

-------

As far as I can tell, the problem with NTP security is deployment of NTS.  The 
pool has captured a large portion of the market and it is fundamentally 
insecure.

HTTPs works because lots of sites want your money.  Nobody is paying for NTP.

I see two ways to get a wide deployment.  One is to get ISPs to run secure NTP servers for their clients.  The other is to deploy something similar to the DNS root and top level servers.  I don't know how that works, in particular, who pays for it.

---

From: Hal Murray <[email-masked]>
Date: Fri, 01 Jan 2021 22:02:21 -0800

> I think that might be a mistake, even if I can understand the ambition. I
> think carrying the leap-second difference TAI-UTC is mandatory, and as such,
> the reference to that other document, if indeed handled as separate
> documents, needs to say so. 

I think this is exposing an interesting area we need to work on.

Both TAI-UTC and security have been nominated as requirements.  Yet a TAI 
based protocol makes perfect sense without either.

I think it will be inappropriate to just drop a MUST in the description.  We 
need a way to say that most of today's implementations will need them but 
there are reasonable use cases today and things may change.  I don't want the 
baggage of a MUST to complicate or distort future work.

---

From: Hal Murray <[email-masked]>
Date: Sat, 02 Jan 2021 00:16:03 -0800

>> My (Linux) man page has various options for clock_gettime(), but
>> it doesn't say anything about leap seconds or TAI.  Yes, it should be
>> reasonable to add, but it's not there yet.

> Which only says that you should not trust your decision-making on what the
> man-page for a single command, it's not telling you the full story.

> nanokernel support, which is there, and the leap-second handling, leap-second
> information it does keep in the kernel. It's been there for fairly long now,
> that we can consider the Linux kernel to support it for all the versions we
> consider. All we need to do is keep supplying it with correct time and
> correct leap-second information.

Thanks for the heads up.

It's been in the Linux kernel for years.
       CLOCK_TAI (since Linux 3.10; Linux-specific)
              A nonsettable system-wide clock derived from wall-clock
              time but ignoring leap seconds.  This clock does not
              experience discontinuities and backwards jumps caused by
              NTP inserting leap seconds as CLOCK_REALTIME does.

It was recently added to the Linux Man Pages.  The new text is in Fedora 34, 
not in Fedora 33, not in Debian 10/buster.

It's not in NetBSD or FreeBSD.

A quick search for >CLOCK_TAI Windows< didn't find anything indicating it was 
implemented.

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 2 Jan 2021 14:01:27 +0000

>    What do you want that isn't already covered by NTS and/or shared keys?

Perhaps nothing.  But not seeing security on the NTPv5 list as a first-class requirement does not engender good thoughts.

Then we should consider making NTPv5 require security.

>    HTTPs works because lots of sites want your money.  Nobody is paying for NTP.

Nobody pays for much of the Internet, including DNS BGP etc. But those protocols are moving toward secure-by-default.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 15:14:33 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 01.01.2021 um 13:29 in
Nachricht <[email-masked]>:

...
> When on the "Internet", we should require DNS access. We should require

At least (regarding IPv6 addresses) being able to resolve a host name to an
address.
An interesing point is whether that's part of the protocol, because on-wire we
do not have host names, do we?

> DNS‑entries rather than fixed IP addresses. We learned that the hard way

I also prefer DNS names, for documentation reasons.

When demanding DNS use, it will be interesting to specify _when_ DNS is being
used: Obviously not for each packet, but preferrably more than once in the
lifetime of the daemon.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 15:16:39 +0100

>>> Doug Arnold <[email-masked]> schrieb am 01.01.2021 um 17:14
in
Nachricht <[email-masked]>:
> I would say that the unifying themes for ntpv5 are greater flexibility, and

> higher accuracy, compared to ntpv4.  

I'd like to add: Updated monitoring and management capabilities.
Should dynamic addition, reconfiguration and deletion of time sources be a
SHOULD for v5 at least?

> 
> Doug
> 
> 
> On 12/31/20, 9:54 PM, "ntp on behalf of Hal Murray" <[email-masked]
on 
> behalf of [email-masked]> wrote:
> 
> 

>     if the answer is no.  Maybe we should distribute the info via DNS where

> we can

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 15:20:47 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 02.01.2021
um
01:55 in Nachricht
<[email-masked]>:

...

>> constants or set of bits have also been seen.

I think in the spirit of NTP that would be overkill if some simple token like
"text/plain" would do.
Maybe a 64-bit unsigned with well-defined bits would also do.

...

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 15:27:13 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 02.01.2021
um
03:49 in Nachricht
<[email-masked]>:

...
> The Mars Climate Orbiter impacted the planet in 1999 because NASA was using

> imperial units while everyone else was using metric.  That’s a catastrophic

> mistake arising from the existence of a SECOND scale of measurement.

...while the second actually was not guilty ;-)

...

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 15:33:06 +0100

>>> Hal Murray <[email-masked]> schrieb am 02.01.2021 um 09:16 in
Nachricht <[email-masked]>:

>> Which only says that you should not trust your decision‑making on what the
>> man‑page for a single command, it's not telling you the full story.
> 
>> nanokernel support, which is there, and the leap‑second handling,
leap‑second
>> correct leap‑second information.
> 
> Thanks for the heads up.
> 
>        CLOCK_TAI (since Linux 3.10; Linux‑specific)
>               A nonsettable system‑wide clock derived from wall‑clock

The interesting question is whether TAI is the native scale, or whether TAI is
derived from POSIX time plus some extra bits.

> A quick search for >CLOCK_TAI Windows< didn't find anything indicating it
was 

Actually when viewing the event logs of Windows 10, messages seem to indicate
it knows the TAI offset at least.

Regards,
Ulrich

> ‑‑

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 4 Jan 2021 15:35:00 +0100

> Should dynamic addition, reconfiguration and deletion of time sources be a

I think the draft should not document a protocol for how to do
that. That is an implementation detail. It should probably not
even go over the UDP port.

Kurt

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 04 Jan 2021 16:08:20 +0100

>>> Kurt Roeckx <[email-masked]> schrieb am 04.01.2021 um 15:35 in Nachricht
> even go over the UDP port.

Well, maybe not an on-wire protocol, but maybe an algorithm. So the implementer still has the choice how to trigger the algorithm.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 4 Jan 2021 16:18:13 +0100

> Do we have a unifying theme?  Can you describe why we are working on NTPv5 in 

There is a list of issues in NTPv4 I would like to see fixed in NTPv5:
https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

A major issue is that NTPv4 doesn't support short extension fields due
to conflicts with legacy MACs, so fixing all those issues by adding
new extending fields to NTPv4 seems impractical. Some things, e.g. the
timescale selection, makes more sense to have in the header.

> that we should be aware of?  Who should we coordinate with?  ...

I don't think that should be the job of the NTP WG. The kernels will
need to support a leaping UTC timescale for as long as it is needed
for civil time.

NTP should keep support for the existing use cases. It is a protocol
for exchanging timestamps. The client and server need to agree on the
timescale. If both have support for TAI, that's great. They can use it
to avoid ambiguous timestamps around leap seconds. But this shouldn't
be a requirement. NTP needs to support UTC and it needs to announce
leap seconds before they happen. Forcing some servers or clients to
implement an unreliable TAI clock on top of an UTC clock only to make
NTP slightly simpler is not a good idea.

> discover if a server supports an option and/or discover servers that do 

With most options I think the client can simply send a request using
that option and see if the server's response has it. It can do that
with every request, or try it only occasionally to reduce the average
length of the request and response.

For more complex or conflicting features, the support can be indicated
with a flag in an extension field.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 4 Jan 2021 16:21:01 +0100

> even go over the UDP port.

I agree. NTPv5 should not define the "control" or "private" modes.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 16:49:43 +0100

Hi Hal,

> based protocol makes perfect sense without either.

I agree. Using a core time-stamp being TAI-related makes immense sense
for all processing. It will not be "the" TAI though, it will be some
form of engineered time-scale that can be related to TAI. TAI is a very
specific product out of BIPM and we never actually get access to that.
We can however produce technical manifistations that has defined
relation to TAI. The PTP and GPS time-scales does this, both with their
different set of technical gears to fit their technical needs. This is
what I think NTPv5 should do.

Using the well-defined relationship to TAI, we can then use other well
defined relationships to other time-scales, and the requirement to
represent UTC when falls out of TAI from NTPv5 translation, TAI-UTC
information and then UTC from TAI translation. Since the TAI-UTC
relationship is not static, we need to transport that to support it. The
NTPv5 and TAI relationship we just make through definition with only
static relationships, so no additional information will be needed.

However, the continuously increasting monotonic behavior of TAI is
perfect for simple processing of core handling.

> baggage of a MUST to complicate or distort future work.

It can be discussed where different parts is required. There is many
ways to play the game. I want to make sure that the protocol can
transport all that is needed, and that in the end, for several uses,
those mechanisms will be in place. Notice that the requirement we put on
what a full protocol solution is required to have can be more than what
will require all nodes to support.

Cheers,
Magnus

---

From: Doug Arnold <[email-masked]>
Date: Mon, 4 Jan 2021 16:05:47 +0000

Separating the algorithms from the message formats, and sequence allows for more flexibility for niche applications.  I know of a company that successfully sells a proprietary non-standard variant of ntpv4 for just this purpose.  More accuracy can be achieved with on path support, higher message rates and different servo filters.  

Doug

On 1/1/21, 4:57 PM, "Hal Murray" <[email-masked]> wrote:

---

From: Doug Arnold <[email-masked]>
Date: Mon, 4 Jan 2021 16:19:41 +0000

The original question was what does ntpv5 have, that ntpv4 doesn't.  Are you wanting more security work beyond what nts adds to ntpv4?

Doug

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 17:27:58 +0100

Philip,

> The mapping doesn’t have to be embedded in the protocol if it’s well understood and unambiguous.

You are mixing the cards quite a bit here. Policy is not being discussed
at all here.

"protocol" is missleading as well. Also, in the old days it was a lot of
protocols, but lacking architectural support providing needed technical
guidance. We moved away from that because more was needed.

The mappings I talk about needs to be not only known, but referenced or
else the "protocol" will not be able to implemented in a consistent way,
which we badly need. If a new relationship is introduced, it needs to be
specified.

None of this have anything to do with policy as such, that is as best a
secondary concern that has nothing to do with what we discuss here.

> I’m hoping to avoid further proliferation of timescales if possible.
It's a lost cause because it builds on a misconception. It's not
creating a timescale that competes with TAI and UTC, it's the technical
way that those time-scales is encoded for communication in order to
solve practical problems and be adapted to those technical challenges.
Very few use the actual TAI or UTC encoding as they communicate, for
good technical reasons. That will continue to be so, and there is no
real case for proliferation as such.
> Will residential US ISP’s finally have rolled out IPv6?

I think you completely missed my point. To the level that you missed
what I was really saying is that there is a wide range of difference
scenarios already today, and as we design a core protocol, no single one
of them will provide the full truth.

You only illustrate that you do not know me when you attempt to
challenge me like that.

> https://everydayastronaut.com/mars-climate-orbiter/
You are now very much of the mark here.
>> That was only part of the full interface.
If one argues based on what the POSIX CLOCK_* does, then one will not
get the full view.
> Many will also migrate to whatever provides them with unassailable (unambiguous) timestamps in the case of litigation.  I’ve worked on timing for natural gas pipelines so that catastrophic failures…

There is many ways to show traceability to UTC, while technically
avoiding problems. This however often involves knowing the TAI-UTC
difference one way or another such that the relationship to UTC is
maintained. The requirement to be traceable to UTC will still stand in
many many cases. The way that one technically avoids problems is to some
degree orthogonal to that.

Then again, may seems to misunderstand what the term "traceable" means.
It does not mean "locked to".

> If popular equates to ubiquitous, then you can’t do SSL without ASN.1… and that makes it “popular” (though not “well liked” by any measure).  But I’m splitting hairs over semantics.
I think you missed the hidden joke.
> Not quite following what you’re saying.  Are you alluding to operating a (split-horizon) border NTP server to hosts inside a perimeter, that in turn don’t have Internet access themselves (effective…

There is indeed a lot of scenarios where you operate NTP inside setups
which have no, or very limited Internet access. Yet it is used because
it is COTS "Internet technology" that fits well with what is used. As we
design things we also need to understand that there is a wide range of
usage scenarios for which our normal expectation of what we can do on
"Internet" is not necessarily true or needed. What is a very wise thing
to do for "Internet" may be overly burdensome and even prohibitive in
other scenarios, and vice versa, things that we may think is wise to do
in those scenarios can be wildly bad in the "Internet" usage scenario.
This is why I try to point out that we might consider to keep the core
behaviors as independent of such usage scenarios, but then enable the
ability to drop in or even require components and behaviors as needed
for each such scenario.

> FWIW, a border forwarding/caching recursive DNS server is a degenerate case of an ALG.

Sure, but not always available, and sometimes the operation of those may
prohibit uses further into the network because well, politics within
organization or even between organizations. So, you may not always have
it available as you would like it. Thus, you have another usage scenario.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 17:34:21 +0100

Hi Hal,

>> correct leap-second information.
Happy to assist!
>               NTP inserting leap seconds as CLOCK_REALTIME does.
Considering how long it's been in the kernel, I consider that for most
Linux systems, it can be used. I reason similarly about the NTP
nanokernel interface that's been there for considerable time. The
problem with the nanokernel interface was that glibc was not updated
even if the kernel was that, which only goes to show that kernel
features should not be exposed that way. Regardless, that is solved now.
> not in Fedora 33, not in Debian 10/buster.
Yes. Also illustrates the problem again.
> It's not in NetBSD or FreeBSD.
Unfortunately not. However, that could probably be changed if enough
interest exists.
> A quick search for >CLOCK_TAI Windows< didn't find anything indicating it was 
Again, if enough interest exists, that could probably be fixed eventually.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 17:39:30 +0100

Ulrich,

> derived from POSIX time plus some extra bits.
Considering the many different time-scales the kernel already handles,
it's hard to even discuss it as being one common time-scale any longer.
There is a fair bit of code to handle things. What we need to do is to
ensure we transport the right bits to feed the code so it will do the
right thing.
> it knows the TAI offset at least.

Interesting!

Cheers,
Magnus

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Jan 2021 16:41:30 +0000

>    The original question was what does ntpv5 have, that ntpv4 doesn't.  Are you wanting more security work beyond what nts adds to ntpv4?

I want it integrated into the protocol.  This probably means, for example, that the concept of extensions that aren't part of the integrity and privacy guarantees are no longer possible.

Are you okay with assuming NTPv5 starts with "assume NTS" ?

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 4 Jan 2021 17:44:49 +0100

On Mon, Jan 04, 2021 at 05:34:21PM +0100, Magnus Danielson wrote:
> Linux systems, it can be used.

The Linux system TAI clock can be read by applications, but there is
no support for timestamping of packets with this clock, i.e. it is
currently not useful for NTP.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 17:46:33 +0100

Doug and Hal,

Indeed. You can do much much better in fact. Many times it's not the
protocol format that is the main limit, but other protocol features.

I know of designs which while not using NTPv4 use a propriate format, it
could very well have been NTPv4 format packets.

So, it's more than how NTP packets look, it's how typical
implementations are done with the implementation constraints that NTP
comes with. Release constraints and think differently, and you can get
far better quality.

While future NTP may not need to go into all the available design space,
as some is already taken by for instance PTP or proprietary protocols,
there is still good reasons to leave room for future enhancements.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 17:54:43 +0100

> do not have host names, do we?
No, we do not use host names on the wire-protocol. However, there could
be several benefits if we did get that as side-information, because we
could use DNS as one way to support how we validate things. It's a good
service to assist for that when available, especially as DNSSEC
validation is possible.
> used: Obviously not for each packet, but preferrably more than once in the

For sure, there is good reasons to consider such things. However, it
borders the limit to implementation details.

Requirement for how often the DNS may need to be consulted should be
considered with due care.

For the scenario of wide-scale Internet use of various appliances with
preconfigured NTP servers, the ability to use DNS to update and share
load is very very strongly needed. NTP-pools of various types was
invented for a reason and that reason have not gone away, and we shall
not forget it for that use. What I do say is that this may not be
necessarily a wise thing for all possible use-cases.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 18:15:00 +0100

Hi,

> even go over the UDP port.

I think there can be good reasons to actually put it into a standard, as
with gazillion of boxes and implementations, making less issues of how
to manage this hurd of equipment with a wild mix of open source and
various vendors interpretations of things, it will be a pain never the less.

Now, this does not need to be the core standard, but a separate
management standard. Then, those needing it, can require conformance
with that separate standard and then may the market forces decide if it
needs to be implemented or not. In practice, it is probably needed.

There is a limit to how much one can deferr to "implementation issues".
Management and monitoring issues is a huge issue in practice. While we
can keep such things out of the core specification, it probably needs to
be in the suite of standards offering a set of solutions for various
uses. The alternative is that some will risk divert away from using NTP.

Cheers,
Magnus

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 04 Jan 2021 18:31:31 +0100

> with a flag in an extension field.

If security-by-default is enforced the NTS-KE could serve as a robust 
mean to exchange the server’s capabilities.

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 10:35:20 -0700

> On Jan 4, 2021, at 7:33 AM, Ulrich Windl <[email-masked]> wrote:
> 

TAI is inherently canonical in that it’s always unambiguous.  Let’s stick to a canonical format as the “source of truth” and map that into other less canonical formats when necessary.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 10:40:13 -0700

> On Jan 4, 2021, at 8:18 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

I disagree.  The kernel doesn’t inherently require UTC.  It could just as easily use TAI or some other format.

The kernel needs to provide into user-space some format which is then convertible to UTC, for as long as UTC is in-use by applications.

This could be handled by libc.

-Philip

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 18:48:16 +0100

Hi Miroslav,

> currently not useful for NTP.

The hardware time-stamping support will support PTP-timescale, which has
a know relationship to TAI. With whatever relationship there will be
between NTPv5 transport time-scale and TAI, the PTP relationship will
also be known and thus can be used.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 19:00:01 +0100

Philip,

> This could be handled by libc.

While I agree that kernel very well could operate in some suitable TAI
format, and the PTP scale would be the low-hanging fruit for that, as it
intends to be that blend of TAI and classical UNIX/POSIX time_t.

However, the only way I know with spreading in which TAI and UTC is
maintained is through the kernel interface provided by the NTP
nanokernel, and that is supported on effectively most Linuxes.

What can be done better is to use it properly and that libc would
provide the needed glue. If libc does that, then from the user's point,
if this is done completely in libc or shared between kernel and libc the
user do not care, as long as they get correct time-stamp and the machine
is setup to feed the needed data.

But then again, I do not think it's the NTP WG job do decide where it is
implemented, rather we shall make sure the NTP side of things can
support the needed features so that it works well.

Cheers,
Magnus

---

From: Warner Losh <[email-masked]>
Date: Mon, 4 Jan 2021 11:25:34 -0700

On Mon, Jan 4, 2021 at 10:35 AM Philip Prindeville <
[email-masked]> wrote:

>
>
> > On Jan 4, 2021, at 7:33 AM, Ulrich Windl <
> [email-masked]> wrote:
> >
> >>> that we can consider the Linux kernel to support it for all the
> versions
> > we
> TAI is inherently canonical in that it’s always unambiguous.  Let’s stick
> to a canonical format as the “source of truth” and map that into other less
> canonical formats when necessary.
>

Yes. It's also not a time scale realized in real time, but one that must be
derived from those that are (UTC) plus extra metadata that needs to be up
to date. That's one reason it's not been added to FreeBSD...

Warner

---

From: Warner Losh <[email-masked]>
Date: Mon, 4 Jan 2021 11:29:05 -0700

> Unfortunately not. However, that could probably be changed if enough

There were a number of issues with it in Linux. If there's a clearer
definition of what it should be and how things should be updated as leap
second knowledge evolves, I'd be happy to get it into FreeBSD...

Warner

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 12:28:30 -0700

> On Jan 4, 2021, at 11:00 AM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 

It might not be our job, but by wearing many hats we can ease or even accelerate adoption.

When I was trying to get RFC-2597 and 2598 into widespread use in Internet traffic, I had to submit a PR glibc to get the IPTOS_DSCP_* definitions included, the IPTOS_CLASS_* definitions for RFC-2474, etc.

Then I (personally) wrote PR’s for Thunderbird, Firefox, Proftpd, Apache/APR, Sendmail, Postfix, Cyrus IMAPD, and yes, NTP, etc. and painstakingly ushered them through the integration process.  Often there were questions that needed to be addressed about why marking traffic for “high latency, high throughput” wouldn’t cause them to be disadvantaged as SLA-oriented provisioning was rolled out (there were a LOT of misconceptions about QoS).  I had to explain that traffic with no markings or default markings often would get the “whatever happens to be left” bandwidth category which could dynamically shrink to zero, and wasn’t where anyone wanted to be.  Sometimes having the same discussion over and over again in different forums.

Today a lot of traffic is correctly marked with the appropriate DSCP QoS that wasn’t 15 years ago when I started on this quest (well, to be honest the quest started 5 years before THAT when I was part of the Cisco initiative to make IOS-based routers and firewalls have bounded jitter so they’d be VoIP and IPTV-friendly).

My point is this: a necessary part of getting a new standard adopted is evangelizing its benefits, and removing its obstacles.

The work doesn’t stop when the standard gets published, or even a couple of interoperating implementations get released…

Does the WG collectively own this extra work?  No, that’s outside of our scope.  Do individual members of this WG have a higher probability of making the WG succeed if they apply that practical understanding of the problem into the world at large?  Most definitely.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 12:30:23 -0700

> On Jan 4, 2021, at 9:44 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

That sounds like it’s really easily addressed…

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 12:39:41 -0700

> NTP needs to support UTC and it needs to announce

I don’t subscribe to this line of reasoning.  It sounds a lot like getting the camel’s nose under the tent for justifying why leap information needs to be part of the protocol.  It doesn’t.  It’s an ugly vestige that should be jettisoned.

If we used strictly monotonic timestamps, and had a well understood mechanism for mapping from that to any other required format out-of-band, that would be more than adequate: it would be ideal.

It would KISS the protocol, plus allow us to quickly adjust to new, updated mappings, without reconfiguring NTP servers or (worse) being required to push out a new release.

Personally I think zoneinfo is the ideal single-source of all authoritative information about leap seconds, and trying to “fix” the same problem in multiple, uncoordinated places if fraught with risk.

Also zoneinfo is very well maintained, regularly updated, and overseen by several appropriate standards bodies.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 13:20:55 -0700

> On Jan 4, 2021, at 9:27 AM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 

It very much is.  It’s a “policy” decision to state, for example:

"NTP needs to support UTC and it needs to announce leap seconds before they happen.”

No, we could have a leapless monotonic timescale and leave it to the application layers or runtime environment to convert kernel time to UTC, etc.

Just as it’s a policy decision to have a machine’s clock be UTC or local time, or to have the epoch start at 1900, 1970, or 1980, etc.

> guidance. We moved away from that because more was needed.

Sorry, this is a bit of a generalization.  What prior parallels that apply to us can you point to so I have a better sense of what you’re referring to?

> which we badly need. If a new relationship is introduced, it needs to be

We can “reference” the mapping without needing to embed it in the protocol as we’ve previously done, yes.  Agreed.

> secondary concern that has nothing to do with what we discuss here.

What goes into a protocol is in itself a policy decision.

> real case for proliferation as such.

Again, that sounds to me like a generalization.  Or perhaps it’s an assertion that’s well understood by everyone else but me… so maybe you can enlighten me?

PTP uses TAI.  It doesn’t seem to have been an impediment for them.  What am I missing?  And how did these “good technical reasons” not apply here?

> of them will provide the full truth.

The corollary of that is that whatever we design, there will be use cases where we don’t apply well… or at all.

I think it’s a fool’s errand to pursue a “one size fits all” solution to a highly technical problem.

> You only illustrate that you do not know me when you attempt to

I’m not challenging anyone.  I’m acknowledging that there are unknowables, particularly about the future.

The larger a period one considers, the more numerous and significant in magnitude the unknowables are in retrospect.

> You are now very much of the mark here.

Sorry, typo?  “On the mark”?  “Off the mark”?

> If one argues based on what the POSIX CLOCK_* does, then one will not

The “view” that I am going for is that API’s can be extended to accommodate shortcomings that we’re understood previously, but later come to light.

> degree orthogonal to that.

I disagree with this premise:  we don’t need to be traceable to UTC.  UTC needs to be derivable from our timescale, so that it’s meaningful to applications (and eventually, humans).

> It does not mean "locked to".

Maybe I’m one of the many misunderstanding then.  For me “traceable to” is synonymous with “originating from”.

> I think you missed the hidden joke.

Quite probably.

> "Internet" is not necessarily true or needed.

That should be a tipoff right there:  We’re working on “Internet standards”.  Not “Intranet standards”.

We don’t need to solve every problem in every scope.  There’s a reason the term “local administrative decision” appears in many, many standards.

Again, protocol, not policy.  Deciding that we need to accommodate rare/one-off usage scenarios in isolated cases is a policy decision.  It’s choosing to insert ourselves into an environment that’s not strictly within our purview.

What people do on their own intranets with the curtains drawn (and the perimeter secured) is very much their decision…

> What is a very wise thing

Again, we’re not the “Other scenarios Engineering Task Force”.

> ability to drop in or even require components and behaviors as needed

We might actually agreeing here, though for different motivations.  I like to keep things simple and keep policy out of protocol, which has the end effect of making the protocol inherently more widely applicable (including beyond the originally mandated scope).

> it available as you would like it. Thus, you have another usage scenario.

Um…  So what’s to stop such users from operating a GPS clock and driving their time from that, etc, etc?

If they’re choosing to NOT participate in the Internet at large then I’m not really sure how the Internet Engineering Task Force bears any obligation to accommodate them.

In other words, “not my problem”.

-Philip

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 4 Jan 2021 21:21:29 +0100

Warner,

On 2021-01-04 19:29, Warner Losh wrote:
>
>
> On Mon, Jan 4, 2021 at 9:34 AM Magnus Danielson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> There were a number of issues with it in Linux.
What issues are these that you refer to?
> If there's a clearer definition of what it should be and how things
> should be updated as leap second knowledge evolves, I'd be happy to
> get it into FreeBSD...

I think that part of the discussion is really not part of NTP WG
discussion, but I am sure things can be figured out.

Cheers,
Magnus

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 13:33:45 -0700

> On Jan 4, 2021, at 1:21 PM, Magnus Danielson <[email-masked]> wrote:
> 
> Warner,
> 
>> If there's a clearer definition of what it should be and how things should be updated as leap second knowledge evolves, I'd be happy to get it into FreeBSD...
> I think that part of the discussion is really not part of NTP WG discussion, but I am sure things can be figured out.
> 

Again, disagree.  I remember the days of the IETF where (1) a document describing a protocol was required, and (2) a successful “bake-off” demonstrating 3 unrelated interoperating implementations was equally required…

FreeBSD is as good a platform as any to demonstrate one of those implementations.

-Philip

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 00:03:16 +0100

Philip,

> Again, disagree.  I remember the days of the IETF where (1) a document describing a protocol was required, and (2) a successful “bake-off” demonstrating 3 unrelated interoperating implementations w…

Which is fine if it was relevant, which it really isn't.

The details of how various implementations choose to do things is really
not what the protocol should go into, but it is good that the protocol
and details is done so the implementation becomes feasible. Wither the
kernel use TAI only or can handle various time-scales in parallel is in
my mind to very much degree an implementation detail. There Linux and
BSD can make different approaches with various benefits, and this is why
you want at least two implementations, with assumed different
implementation decisions, to bring it up on the standard track so that
you learned something. There are many ways to implement things, and not
all involve even the kernel to be involved at all. So, I think the
discussion about how the kernel handling things in itself is not the NTP
WG issue, other than showing it's feasible to do. If we agree that it's
feasible, we move on. If someone has an issue for another way to
implement, sure we try to resolve that. The WG should however not
specify how that should be done, and that was the actual question at
hand which I discussed.

> FreeBSD is as good a platform as any to demonstrate one of those implementations.

For sure. That was not the topic at all.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 01:26:46 +0100

Philip,

> Just as it’s a policy decision to have a machine’s clock be UTC or local time, or to have the epoch start at 1900, 1970, or 1980, etc.

It's not a policy decision of ours. It's a requirement the surrounding
world bring us. If we do not find a way to provide what others need that
will work for them, they become forced to use another solution.

The only policy here is to make it relevant enough, and then try to make
it come of as cheap as possible through engineering.

> Sorry, this is a bit of a generalization.  What prior parallels that apply to us can you point to so I have a better sense of what you’re referring to?

For instance RTP. When RTP was built, it did not really provide a model
for how the clock was related to the media transported, especially when
spread over multiple streams. It was only over several generations of
specifications that the NTP clock was replaced by a common media clock,
and then related to the timing between the streams etc. and their meaning.

In the context it was discussed, we talked about the NTPv5 time-scale.
That needs to have some know relationship to some other know time-scale,
such that the set of gears needed to convert time-stamps in and out of
the NTPv5 time-scale is known. It could be TAI-like, but it would not be
the actual TAI, just as the PTP timescale for instance. Whatever it is,
it needs to be known, so that implementation A, B and C of the protocol
knows how to convert it to the same time so they become consistent. So
there the mapping becomes important part of the protocol behavior such
that the intended service is achieved, leaving it to an implementation
issue to figure out the mapping is not good standardisation making. It
needs to be known, either specified directly, or through reference.

> What goes into a protocol is in itself a policy decision.
Well, there is already policy that it needs to be clear enough that
multiple implementations can cooperate. Thus, it needs to have all the
necessary details to make that feasible and demonstrateable, but that
policy applies not only to NTP. It's a requirement for it to be meaningful.
> PTP uses TAI.  It doesn’t seem to have been an impediment for them.  What am I missing?  And how did these “good technical reasons” not apply here?

PTP does not use TAI. PTP has a defined mapping of TAI into a
PTP-timescale, which is different. You can convert PTP time to and from
TAI. The PTP epoch, thus when the PTP time-stamp was 0 is defined in
clause 7.2.2 of IEEE1588-2008 as:

"7.2.2 Epoch
The epoch is the origin of the timescale of a domain.

The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969
23:59:51.999918 UTC.

NOTE 1—The PTP epoch coincides with the epoch of the common Portable
Operating System Interface (POSIX) algorithms for converting elapsed
seconds since the epoch to the ISO 8601:2004 printed representation of
time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17].

NOTE 2—See Annex B for information on converting between common timescales."

TAI just simply count as seconds.

Similarly, the GPS time-scale has it's epoch defined to be at
1980-01-06T00:00:00Z, thus locking in the TAI-UTC offset of 19. This is
referred to as proliferation of TAI-variants, but really isn't as it's
not attempting to fill the position of either TAI or UTC. Both the GPS
and PTP internal time-scales is just technical scales for internal
representation. Regardless if your GPS receiver output GPS time or UTC
time (as GPS-UTC difference is transported), you will never get the
actual GPS or UTC time, but local replicas. From a metrology calibration
stand-point, they have unknown properties, due to the lack of
calibration and through calibration achieved traceability. Similarly
with PTP, you can out of the PTP time produce a TAI replica as well as
UTC replica, as PTP transports the TAI-UTC difference.

So, these conversions or mapping between timescales is practical
engineering things we do, but not really proliferation issues. It's the
thing we need to do. Just using TAI at the side of UTC has been an
issue, as some feel it should be UTC and only UTC to rule them all.
Well, in practice we need TAI-properties alongside the UTC properties.
We kind of actually do not the actual TAI, but it is handy if we can
provide the replica. We will never get the actual UTC, but it is very
handy if we can produce a replica. Since we need to be better than 1
second in our achieved precision for several applications, we end up
needing to handle leap-seconds better than doing the POSIX or Linux
mapping, which is just other mappings. The NTPv4 time-scale is just one
more of those mappings of UTC.

BTW, Annex B in IEEE1588-2008 is handy informative annex of the IEEE1588
standard.

> I think it’s a fool’s errand to pursue a “one size fits all” solution to a highly technical problem.
Which isn't what I say, if you listened a little more careful to what I
say. I actually say the opposite. One size do not fit all, and the
trouble is that I see that the same protocol design may end up being
used in so diverse settings that we might consider these as just that,
different scenarios. I think most of the things we want to do will be
the same, but some aspects will be quite different. However, if we treat
them with sufficient care so they can be added and removed for the
various scenarios, we can make sure the core protocol remains the same
and the set of things needed for the "Internet" scenario is clear and
required as we implement that, and wise to do in that scenario.
> The larger a period one considers, the more numerous and significant in magnitude the unknowables are in retrospect.
As if I where not already alluding to that.
> Sorry, typo?  “On the mark”?  “Off the mark”?

Off

The only relevance to that story is with Mars. It was not a timing
issue, it was a huge engineering debacle quite complex that it's hard to
see it's relevance here.

> The “view” that I am going for is that API’s can be extended to accommodate shortcomings that we’re understood previously, but later come to light.
Sure they can. Also, there can be API's that is already there which can
be considered if they are not sufficient and already implemented.
> I disagree with this premise:  we don’t need to be traceable to UTC.  UTC needs to be derivable from our timescale, so that it’s meaningful to applications (and eventually, humans).
For many uses I agree with you. However, there are other uses at which
it becomes a requirement. The question then becomes if we engineer NTPv5
to be able to deliver sufficient properties to fulfill that, or not.
> Maybe I’m one of the many misunderstanding then.  For me “traceable to” is synonymous with “originating from”.

It is a very common misunderstanding, yes. The term "traceable" refers
to the unbroken chain of calibrations to the SI units and the
traceability record that produces, as each calibration will measure the
deviation and precision achieved. I can use a complete djungle clock
that is unsteered and then through continuous calibrations be able to
convert the readings of my clock into the readings of UTC. This is a
mapping with defined parameters from that calibration. Adjustment of the
clock during a calibration, is about re-setting the clock so that the
calibration parameters compensate directly, which is more a practicality
in how the conversion is made, but not strictly necessary. In practice,
the actual clocks building up the EAL/TAI/UTC is free-running, and then
the laboratory replica of TA and UTC is steered to be neat TAI and UTC,
but the actual clocks is not steered. Also, the trouble is that gravity
pull on the various labs needs compensation, which is done in the ALGOS
algorithm as post-processed by BIPM, and not the labs. Never the less,
all clocks have traceability to TAI/UTC. Derived clocks then show their
traceability to the lab replica of UTC. This just to show how
traceability actually is a bit different in metrology than you would
first want to believe. Vocabulary of International Metrology (VIM) is
free to download from BIPM.

One may then wonder why we need to follow the VIM and Metrology use of
the terms, well, the trouble is that if we don't, we end up creating
confusion, because they end up doing calibration and dissemination of
time using NTP. It is their time-scales of TAI and UTC we use. I try to
be strict in order to avoid confusion, and I think there is enough
alternative vocabulary to use so we do not need to add that confusion.

> What people do on their own intranets with the curtains drawn (and the perimeter secured) is very much their decision…

If it where that easy. The success of Internet protocols and standards
forces things to be used where normal Internet rules do not apply. This
is very much so with NTP. I think there is things we can relatively easy
do to identify some other usage scenarios that can be supported without
too much work. Then again, I'm not saying that it needs to be the main
focus, but rather, allowing for it and think that through may also be a
good vehicle to support future changes to NTP itself as it is adapted
for that unknown future.

Part of this was "I want this being authenticated". Well, the vehicle to
transport the TAI-UTC difference in NTP ended up being wrapped into the
NTP Autokey specification, which to work needed to create means to
provide extension field to allow for Auotkey to work in, and then that
also allowed for the TAI-UTC difference transport that needed that
extension mechanism too. Also, it was felt that we want that
authenticated, and sure the TAI-UTC differnce is kind of important. Now,
a couple of years down the line the security of the Autokey mechanism
was found faulty and with that the TAI-UTC difference transport got
thrown out. So, this is when I said that we should be careful not to
connect it too hard, and then about feature capabilities, because then
in future we may loose it if we do not treat it a bit more orthogonal.
If we 5-15 years down the line need to replace the authentification
mechaism, we should not loose the things wrapped and secured by it. We
might actually want to have ways of knowing capabilities when we first
knock on the NTP server door just to know which authentification
mechanisms is there, so we can transition and change foot. The other
extensions there is should move over as we migrate. We failed to do that
well in NTPv4. And then the realization that some of this may not be
applicable for all uses, and specific requirements be for others.

> Again, we’re not the “Other scenarios Engineering Task Force”.
Well, if life was that simple.
> We might actually agreeing here, though for different motivations.  I like to keep things simple and keep policy out of protocol, which has the end effect of making the protocol inherently more wid…

The trouble here is that we want to keep things simple, but not too
simple so that it no longer solves the problems that needs to be solved.
Whenever one tries to simplify too much, what looks simple and good,
ends up being an engineering nightmare as workaround upon workaround is
needed to achieve what is needed.

> In other words, “not my problem”.

Well, it may not be your problem, but it ends up being our problem as we
then needs to solve those issues. Internet technology is being used
outside of what you would call Internet, it's just a fact of life. It is
assumed that COTS boxes can operate there, and when not it becomes a
problem, and because it's "Internet technology" it is assumed to work
together regardless in a multi-vendor setup. You end up with a
proliferation of various variants and it's a pure pain to handle. Easing
some of that pain will always be welcome, such as understanding that it
may not always be that you can count on say DNS to always save the day
for all cases. At the same time, the best current practice for Internet
devices is for sure on topic, and have particular requirements we do not
want to get wrong.

Cheers,
Magnus

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 20:40:40 -0700

> On Jan 4, 2021, at 4:03 PM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 
> my mind to very much degree an implementation detail.

It’s as relevant as it’s ever (always) been: the implementations are in theory to be written “blind” with only the proposed RFC to guide the developers.  If the RFC isn’t sufficiently clear for at least 3 implementations to converge on a common interpretation, then it’s not adequately explained.

I’m not talking about TAI being what the kernel uses; I’ve been talking about the on-the-wire canonical representation of time.

> There Linux and
> feasible, we move on.

That’s not what I was saying at all.  It was pointed out that the kernel uses UTC internally.

I replied pointing out that (1) it doesn’t matter what the kernel uses internally if applications can get whatever time they need through run-time support (i.e. libraries like libc) and (2) internally the Linux kernel at least (and I figure most POSIX compliant kernels) are capable of maintaining multiple timescales.  As long as whatever the clock runs in natively can be converted unambiguously into any other format, it doesn’t matter which is used.

For the sake of the kernel, the notion (or distinction) of days, years, and leap-days seems to be arbitrary or even irrelevant.

All the kernel really cares about is maintaining accurate, stable, unambiguous time which can then be converted to the timescale being requested by a process in user-space.

And because of this freedom, NTP can use whatever timescale it wants on-the-wire… and the kernel can likewise independently use whatever timescale it wants to use internally… as long as there’s a mechanism to convert to whatever applications want.

I hear people repeating that the kernel, the protocol, and applications all need to use the same timescale.  They don’t.  This is a fallacy.

-Philip

> If someone has an issue for another way to

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 4 Jan 2021 21:53:26 -0700

> On Jan 4, 2021, at 5:26 PM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 
> It's not a policy decision of ours. It's a requirement the surrounding world bring us. If we do not find a way to provide what others need that will work for them, they become forced to use another solution.
> 

Well, you’re half right.  It’s a requirement that a lot of the world has, but as long as the timescale is convertible AT SOME POINT somewhere between the packets on-the-wire and returning to a library call in libc, THEY DON’T REALLY CARE AND THEY SHOULDN’T HAVE TO.

This is why we have layers of abstraction, instead of a single monolithically linked image running on bare metal in a single context.

I think we did away with that with batch entry systems in the early 1960’s.

> The only policy here is to make it relevant enough, and then try to make it come of as cheap as possible through engineering.

I’ll take “correct” over “cheap” most days.  Incorrect ends up being quite costly.

> For instance RTP. When RTP was built, it did not really provide a model for how the clock was related to the media transported, especially when spread over multiple streams. It was only over several generations of specifications that the NTP clock was replaced by a common media clock, and then related to the timing between the streams etc. and their meaning.

Are we talking about multiple streams from the same source to the same endpoint?  Or converging streams from multiple sources?

> 
> In the context it was discussed, we talked about the NTPv5 time-scale. That needs to have some know relationship to some other know time-scale, such that the set of gears needed to convert time-stamps in and out of the NTPv5 time-scale is known.

Not disagreeing that the conversion needs to be well-understood (and unambiguous).

But it doesn’t need to happen inside NTP itself.  Or even the kernel.

> It could be TAI-like, but it would not be the actual TAI, just as the PTP timescale for instance.

My understanding is that PTP uses TAI as the default timescale.

> Whatever it is, it needs to be known, so that implementation A, B and C of the protocol knows how to convert it to the same time so they become consistent. So there the mapping becomes important part of the protocol behavior such that the intended service is achieved, leaving it to an implementation issue to figure out the mapping is not good standardisation making. It needs to be known, either specified directly, or through reference.

You’re conflating things: NTP as a user-space process (as most daemons are) just needs to use the same run-times that query the kernel for the time and serve it up in the requested timescale of choice, converting from the kernel’s internal canonical representation of time.

> Well, there is already policy that it needs to be clear enough that multiple implementations can cooperate. Thus, it needs to have all the necessary details to make that feasible and demonstrateable, but that policy applies not only to NTP. It's a requirement for it to be meaningful.

Not to split hairs, but that’s our ratification process.  The policy is that the protocol needs to be sufficiently clear that an implementation can be written “in the blind” using just the text of the standard, to prove out the completeness and accuracy of the standard.

The above is the process that validates adherence to this policy.

> PTP does not use TAI. PTP has a defined mapping of TAI into a PTP-timescale, which is different. You can convert PTP time to and from TAI. The PTP epoch, thus when the PTP time-stamp was 0 is defined in clause 7.2.2 of IEEE1588-2008 as:
> 
> 
> "7.2.2 Epoch
> The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC.
> 
> NOTE 1—The PTP epoch coincides with the epoch of the common Portable Operating System Interface (POSIX) algorithms for converting elapsed seconds since the epoch to the ISO 8601:2004 printed representation of time of day; see ISO/IEC 9945:2003 [B16] and ISO 8601:2004 [B17].
> 

Okay, I should have said, "PTP uses a direct 1:1 mapping to TAI without divergence."

> TAI just simply count as seconds.

Right.  Which goes back to my point that a time protocol doesn’t need to care about how you slice time up into larger units of measure like minutes, hours, days, years, and leap-seconds.

That’s a “presentation” issue, which is more applicable to other protocols like logging (which requires human readable timestamps) or calendaring (which deals with purely human notions of time).

> 
> Similarly, the GPS time-scale has it's epoch defined to be at 1980-01-06T00:00:00Z, thus locking in the TAI-UTC offset of 19. This is referred to as proliferation of TAI-variants, but really isn't as it's not attempting to fill the position of either TAI or UTC. Both the GPS and PTP internal time-scales is just technical scales for internal representation. Regardless if your GPS receiver output GPS time or UTC time (as GPS-UTC difference is transported), you will never get the actual GPS or UTC time, but local replicas. From a metrology calibration stand-point, they have unknown properties, due to the lack of calibration and through calibration achieved traceability. Similarly with PTP, you can out of the PTP time produce a TAI replica as well as UTC replica, as PTP transports the TAI-UTC difference.

But it doesn’t have to.  That’s a convenience for devices that don’t have external sources of conversion information.

An E3 digital cross-connect doesn’t typically receive updates of Zoneinfo, for example… even though it very much cares about accurate time (or it will have frame-slips, etc).

> So, these conversions or mapping between timescales is practical engineering things we do, but not really proliferation issues.

Or conversely it’s mixing up unrelated topics because of some intangible and incorrectly perceived benefit that it *may* provide, and we overcomplicate what should be a lean protocol unnecessarily.

We could, if we wanted to, come up with a protocol to distribute the Zoneinfo database to “dumb” devices like video conferencing systems, which would then mean that they had a separate mechanism for knowing when to apply leap-seconds, and we could remove that from what should be a strictly clock synchronization protocol… instead of laboring under the misconception that we need to solve all these problems in a common place, just because they’re both time-related.

> It's the thing we need to do.

And there’s that conflation.  No, it’s the thing you want to do, because it kills two birds with one stone.

> Just using TAI at the side of UTC has been an issue, as some feel it should be UTC and only UTC to rule them all.

And yet UTC isn’t inherently unambiguous, especially if we believe that a day contains 86,400 seconds, 24 hours of 60 minutes, 60 minutes of 60 seconds, and each second being an SI…

> Well, in practice we need TAI-properties alongside the UTC properties. We kind of actually do not the actual TAI, but it is handy if we can provide the replica. We will never get the actual UTC, but it is very handy if we can produce a replica. Since we need to be better than 1 second in our achieved precision for several applications, we end up needing to handle leap-seconds better than doing the POSIX or Linux mapping, which is just other mappings. The NTPv4 time-scale is just one more of those mappings of UTC.
> 
> BTW, Annex B in IEEE1588-2008 is handy informative annex of the IEEE1588 standard.

I’ll look it over when I have some time.

> Which isn't what I say, if you listened a little more careful to what I say. I actually say the opposite. One size do not fit all, and the trouble is that I see that the same protocol design may end up being used in so diverse settings that we might consider these as just that, different scenarios. I think most of the things we want to do will be the same, but some aspects will be quite different. However, if we treat them with sufficient care so they can be added and removed for the various scenarios, we can make sure the core protocol remains the same and the set of things needed for the "Internet" scenario is clear and required as we implement that, and wise to do in that scenario.

If people try to use the wrong protocol in their given circumstances, there’s not much we can do to stop them.  At least not in any practicable way.

Worrying about how our protocol operates in outlying cases beyond our scope or control is a waste of time.  And there will always be more such permutations than we can foresee.

> As if I where not already alluding to that. 

Okay, well, we’ve found something else to agree on then.

Converging on an acceptable normative standard is not unlike eating an elephant.

> The only relevance to that story is with Mars. It was not a timing issue, it was a huge engineering debacle quite complex that it's hard to see it's relevance here. 

The relevance is that some people were thinking in metric while others were thinking in imperial.

Had metric been the single common unit of measure, there never would have been any confusion about the values being discussed.

Similarly, it would be nice to have a single, unambiguous timescale from which other timescales (including those which are inherently ambiguous due to leap-seconds, etc) could be derived…

> Sure they can. Also, there can be API's that is already there which can be considered if they are not sufficient and already implemented.

Sorry, if they “are not” sufficient and already implemented?  Or if they “are”?

> For many uses I agree with you. However, there are other uses at which it becomes a requirement. The question then becomes if we engineer NTPv5 to be able to deliver sufficient properties to fulfill that, or not.

Again, this is a generalization that I have a hard time grounding in anything concrete.

Can you explain when/where/what this might be?  What are these “other uses”?

> It is a very common misunderstanding, yes. The term "traceable" refers to the unbroken chain of calibrations to the SI units and the traceability record that produces, as each calibration will measure the deviation and precision achieved. I can use a complete djungle clock that is unsteered and then through continuous calibrations be able to convert the readings of my clock into the readings of UTC. This is a mapping with defined parameters from that calibration. Adjustment of the clock during a calibration, is about re-setting the clock so that the calibration parameters compensate directly, which is more a practicality in how the conversion is made, but not strictly necessary. In practice, the actual clocks building up the EAL/TAI/UTC is free-running, and then the laboratory replica of TA and UTC is steered to be neat TAI and UTC, but the actual clocks is not steered. Also, the trouble is that gravity pull on the various labs needs compensation, which is done in the ALGOS algorithm as post-processed by BIPM, and not the labs. Never the less, all clocks have traceability to TAI/UTC. Derived clocks then show their traceability to the lab replica of UTC. This just to show how traceability actually is a bit different in metrology than you would first want to believe. Vocabulary of International Metrology (VIM) is free to download from BIPM.
> 
> One may then wonder why we need to follow the VIM and Metrology use of the terms, well, the trouble is that if we don't, we end up creating confusion, because they end up doing calibration and dissemination of time using NTP. It is their time-scales of TAI and UTC we use. I try to be strict in order to avoid confusion, and I think there is enough alternative vocabulary to use so we do not need to add that confusion.

Okay, thanks for clearing that up for me.

>>>>>>>> [snip]
> If it where that easy. The success of Internet protocols and standards forces things to be used where normal Internet rules do not apply.

I’m not sure anything is being forced.  I think people are lazy.  And when a hammer is the closest tool to you, everything in your reach becomes a nail…

We can’t stop them, but nor do we have to overly concern ourselves with enabling or facilitating this behavior.

People use self-signed certificates even though it’s a travesty (read: insecurity) and certificates should be rooted to valid, well-known root CA’s.  Knowing this to be the case, I’m not going to bother asking myself “what happens to my protocol when self-signed certs are used”.  The answer is: “not my problem”.

> This is very much so with NTP. I think there is things we can relatively easy do to identify some other usage scenarios       that can be supported without too much work. Then again, I'm not saying that it needs to be the main focus, but rather, allowing for it and think that through may also be a good vehicle to support future changes to NTP itself as it is adapted for that unknown future.

If I were redoing SMTP again, I would spend no time at all trying to accommodate the existence of X.400, Bitnet, Decnet architecture, Microsoft MAPI/Exchange, etc.  Refrain: not my problem.

> Part of this was "I want this being authenticated". Well, the vehicle to transport the TAI-UTC difference in NTP ended up being wrapped into the NTP Autokey specification, which to work needed to create means to provide extension field to allow for Auotkey to work in, and then that also allowed for the TAI-UTC difference transport that needed that extension mechanism too. Also, it was felt that we want that authenticated, and sure the TAI-UTC differnce is kind of important. Now, a couple of years down the line the security of the Autokey mechanism was found faulty and with that the TAI-UTC difference transport got thrown out. So, this is when I said that we should be careful not to connect it too hard, and then about feature capabilities, because then in future we may loose it if we do not treat it a bit more orthogonal. If we 5-15 years down the line need to replace the authentification mechaism, we should not loose the things wrapped and secured by it. We might actually want to have ways of knowing capabilities when we first knock on the NTP server door just to know which authentification mechanisms is there, so we can transition and change foot. The other extensions there is should move over as we migrate. We failed to do that well in NTPv4. And then the realization that some of this may not be applicable for all uses, and specific requirements be for others.

Cautiously, it sounds like we found yet another thing to agree on: that we should decouple as much as we can from unrelated features, rather than unnecessarily munging them together.

So while I don’t mind the notion of carrying the TAI-to-UTC conversion and traceability information as an optional field, I don’t think that argues for (i.e. justifies) making UTC be the canonical time format that NTP uses natively.

> Well, if life was that simple.

First step: don’t add new complexity.  Second step: purge existing unnecessarily complexity wherever you find it.

> The trouble here is that we want to keep things simple, but not too simple so that it no longer solves the problems that needs to be solved. Whenever one tries to simplify too much, what looks simple and good, ends up being an engineering nightmare as workaround upon workaround is needed to achieve what is needed.

“Require components and behaviors as needed for each such scenario” sounds dangerously like “dictate policy” to me.

Not sure I agree with that generalization.

MIME was added to Mail to add multi-media capability, and it worked.  It’s not pretty, but it’s highly functional.

Telnet options were from the very beginning open-ended.  When local line-editing was needed because remote editing over high-latency lines was just too painful, it “dropped right in”.  As did TN3270 interoperability for people who needed to talk to IBM Mainframes.

> Well, it may not be your problem, but it ends up being our problem as we then needs to solve those issues.

Sorry, but you keep waving your hands on this issue.  Who says we have to solve these problems?  How does it end up being “our problem”?  If they’re on an isolated intranet, with no possible connection to us, it’s a bit like a tree falling in the forest with no one around, isn’t it?  Whether it makes a sound or not changes nothing from my perspective.

> Internet technology is being used outside of what you would call Internet, it's just a fact of life. It is assumed that COTS boxes can operate there, and when not it becomes a problem, and because it's "Internet technology" it is assumed to work together regardless in a multi-vendor setup. You end up with a proliferation of various variants and it's a pure pain to handle.

Again, I’m not ending up with anything here, because what you describe is happening on an Intranet that bears no connection or relevance to me.

And I don’t assume that COTS boxes that require the Internet operate anywhere that the internet is not connected.  If they can’t be pushed software updates, for instance, then they will eventually have a critical software vulnerability which can’t be patched for and I want nothing to do with them.

But again, none of this is “a pure pain to handle” because it’s happening somewhere that I am insulated from, isolated to, and blissfully ignorant of.

> Easing some of that pain will always be welcome, such as understanding that it may not always be that you can count on say DNS to always save the day for       all cases. At the same time, the best current practice for Internet devices is for sure on topic, and have particular requirements we do not want to get wrong.
> 
> Cheers,
> Magnus

It sounds like you’re sending a mixed message, but maybe I’m just not understanding.  What I’m hearing you say is, “be sparse [or ‘economical’] in your assumptions about what where things might be used”, but I’m also hearing you say “make sure that, as an Internet protocol, it operates properly in the total absence of Internet connectivity”… which is a huge burden to assume.

-Philip

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 05 Jan 2021 08:20:08 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 04.01.2021 um 19:00 in
Nachricht <[email-masked]>:
>>>> Do we have a unifying theme?  Can you describe why we are working on
NTPv5 
>>>> Part of the motivation for this is to enable and encourage OSes to
convert 
> to 
>> The kernel needs to provide into user-space some format which is then 
> convertible to UTC, for as long as UTC is in-use by applications.
>>

Now that you mention it: I think it was also a bad design in NTPv4 to require
a nanokernel to handle TAI: Instead of storing and reading the TAI in/from the
kernel, the daemon should have a "working copy". The other bad thing was that
TAI processing was tied to autokey protocol extensions.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 09:33:28 +0100

> also be known and thus can be used.

With hardware timestamping there is a separate (hardware) clock used
for timestamping. It's not related to the CLOCK_TAI system clock
discussed here. I assume we don't want NTPv5 to require a hardware
clock.

NTP is used for synchronization of various clocks. Most of them are
based on UTC. NTPv5 cannot support only TAI.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 09:54:23 +0100

> PTP uses TAI.  It doesn’t seem to have been an impediment for them.  What am I missing?  And how did these “good technical reasons” not apply here?

PTP doesn't support TAI only. It supports TAI and an "arbitrary"
timescale. TAI is used for synchronization of hardware clocks, which
is the primary use case of PTP. If you wanted to synchronize a system
clock with PTP, the timestamps would typically be in the arbitrary
timescale (UTC).

To anyone proposing NTPv5 to support only a non-leaping timescale I'd
suggest them to try to implement it first.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 10:07:53 +0100

On Mon, Jan 04, 2021 at 06:31:31PM +0100, Dieter Sibold wrote:
> If security-by-default is enforced the NTS-KE could serve as a robust mean
> to exchange the server’s capabilities.

NTS-KE is supposed to be used only rarely (clients should save
cookies and keys), so I don't think it would be a good mechanism for
discovery of the server's capabilities, even if NTS was required by
NTPv5. They can change due to an upgrade or reconfiguration without
breaking the NTS context (requiring new NTS-KE session).

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 10:17:45 +0100

> I don’t subscribe to this line of reasoning.  It sounds a lot like getting the camel’s nose under the tent for justifying why leap information needs to be part of the protocol.  It doesn’t.  It’s a…

It's ugly, but we need NTPv5 to be based in reality and be useful.
The TAI-UTC offset is not always known and clocks are sometimes
synchronized in isolated networks.

> If we used strictly monotonic timestamps, and had a well understood mechanism for mapping from that to any other required format out-of-band, that would be more than adequate: it would be ideal.

Yes, that would be nice, but it's not possible if we want to support
existing use cases of NTP and be implementable on current operating
systems.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Tue, 05 Jan 2021 01:52:39 -0800

[email-masked] said:
> NTS-KE is supposed to be used only rarely (clients should save cookies and
> keys), so I don't think it would be a good mechanism for discovery of the
> server's capabilities, even if NTS was required by NTPv5. They can change due
> to an upgrade or reconfiguration without breaking the NTS context (requiring
> new NTS-KE session). 

Agreed.

But given that you have to talk to the KE server before contacting the NTP 
server we should consider taking advantage of that connection.  (The answer 
might be "no".)

I could see additions like "I need a server that supports the xxx time scale." 
or "TAI offset is xxx, next leap at yyy."

I don't know the details of TLS.  Can I change hats without reopening a 
connection??

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 12:04:53 +0100

Philip,

> I’m not talking about TAI being what the kernel uses; I’ve been talking about the on-the-wire canonical representation of time.
Trouble is, this particular thread started out with a discussion of what
the kernel should do, and I objected to the NTP WG to dictate what a
particular implementation would do. The protocol on the wire is a
different thing, that is for sure what the NTP WG should care about.
> That’s not what I was saying at all.  It was pointed out that the kernel uses UTC internally.
Actually, they do not use UTC internally, except some under very
specific conditions.
> I hear people repeating that the kernel, the protocol, and applications all need to use the same timescale.  They don’t.  This is a fallacy.

Agree, it's a fallacy indeed. I have tried to make that very point.

The particular thread started out with an ambition to steer how kernel
implement things, that I think is outside the scope of the WG. What is
inside is that regardless of how it is implemented, the needed
definitions, information and similar is provided such that
implementations (the notion kernel and user space may actually be
completely irrelevant in some implementations) can reasonably be
implemented, both in clarity and consistency.

If the NTP WG feels like it, it can provide informal information to
guide implementors, at least for some model. That is usually handy, as
it tends to provide alternative explanation of things fits together.
Here the NTPD implementation has acted as the reference, the golden
standard if you so like. Trouble is, it attempts to be both reference
implementation and the actual implementation. This can be troublesome,
as the reference part becomes obscured by the many details of real life.
This is not to say that NTPD is not without value, but it is problematic
in terms of reference implementation in this regard. There is quite a
bit of reading to do to be able to penetrate the many things going into
it. Dave Mills provides information in books and webpages for sure, I
have seen far worse examples, but one could consider a somewhat cleaner
slate.

Cheers,
Magnus

---

From: Hal Murray <[email-masked]>
Date: Tue, 05 Jan 2021 04:45:44 -0800

[email-masked] said:
> NTP is used for synchronization of various clocks. Most of them are based on
> UTC. NTPv5 cannot support only TAI. 

This is a tangled area.

I think that a TAI only NTPv5 protocol would be much cleaner and easier to 
document.  Yes, I agree that we need a story for UTC, but the answer doesn't 
have to clutter up an RFC for NTPv5.

All the kernel and/or libc need to convert TAI to/from UTC is the TAI-UTC 
offset (a small integer) and the date of the next leap second, a flag for 
insert/delete/none, and the valid-until date of the info.

We could provide that data in an extension.  The same extension would allow a 
NTPv4 server to provide clients with enough info to let current UTC based 
kernels provide TAI and/or leap when appropriate.

We could provide that data in a new protocol.  Or a new packet type on the NTP 
port.  Or via DNS.

An extension would piggyback on whatever we use to authenticate NTPv5.  DNSSEC 
would authenticate the DNS approach.

If we implement this on the network, we should be sure to emphasize that the 
data only changes every 6 months and that we expect clients to remember the 
answer rather than ask every time.

We could provide code that lets systems process leap-seconds.list
ntpd already does.
A copy of the leap seconds file is included by the Time Zone project and 
distributed by IANA.  Most distros are already setup to keep the time zone 
info up to date.  It should be simple for the leap file to go along for the 
ride.  Debian already does it.

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 14:34:46 +0100

Philip,

> Well, you’re half right.  It’s a requirement that a lot of the world has, but as long as the timescale is convertible AT SOME POINT somewhere between the packets on-the-wire and returning to a libr…
I wonder how you came to the conclusion that I was arguing for something
else?
> I think we did away with that with batch entry systems in the early 1960’s.
Now you are preaching to the choir again, what have you misunderstood? I
never claimed anything requiring that mentioned.
> I’ll take “correct” over “cheap” most days.  Incorrect ends up being quite costly.
Indeed. Incorrect is very expensive, so the "cheap solution" is the very
expensive solution. The trouble is that sometimes the cost does not show
where the cost reduction was made.
> Are we talking about multiple streams from the same source to the same endpoint?  Or converging streams from multiple sources?
Actually both these days.
> But it doesn’t need to happen inside NTP itself.  Or even the kernel.
I never said it needed to be done inside NTP itself or the kernel. I
only said it needed to be well understood for the implementation. The
details of the implementation, daemon, kernel, libc or whatever is
really not what we should care about, except that we care about
providing the needed information for them to do their job properly. I do
not know where you got the notion that I it necessarily needed to be
done in NTP or kernel itself, I never claimed that. I did however claim
the specifications needed to be clear, which is a completely different
thing.
> My understanding is that PTP uses TAI as the default timescale.

It doesn't really. Similar enough, but not really. See further down.

> You’re conflating things: NTP as a user-space process (as most daemons are) just needs to use the same run-times that query the kernel for the time and serve it up in the requested timescale of cho…
Well, that was tried an found problematic, so the nanokernel API was
added. David Mills have written about that. The timing interface from
many kernels have developed much much further since. However, this is
again handy information to discuss to aid developers, but not related to
the actual NTP protocol. We need to know the models for how things is
translated, but not really how they are implemented. I kept those very
distinct here, where as you seem to confuse what I mean with it.
> The above is the process that validates adherence to this policy.
Sure, and as we do the protocol documentation, we need to make sure we
fulfill everything that is needed to pass that test. Thus, it becomes a
requirement to the protocol writing that needs regular internal testing
before release to meet the validation process.
> Okay, I should have said, "PTP uses a direct 1:1 mapping to TAI without divergence."

Maybe, the thing is, there is multiple mappings that has TAI-like
properties. PTP is one and GPS is another, and there is more. The "there
is more" part is also part of objections to the TAI proliferation over
use of UTC. That is a wide discussion that you may not have seen, but
it's there anyway. I think it is better to avoid talking about PTP using
TAI, but consider that PTP uses a TAI-like or TAI-based timescale of
it's own.

Anyway, so now I think it should be clearer why I think it is better to
say that it forms a time-scale in it's own right. It has known mapping
to other time-scales, in particular TAI or UTC. Some of these mappings
can be made correct where as others will not achieve accurate mapping.

As we go forward, I think there is already a rough consensus that NTPv5
will use a new internal time-scale that has TAI like properties. I think
that is very very wise, I strongly recommend it because it's provide to
work well in many cases, while keeping implementation fairly "linear" in
that regard.

> That’s a “presentation” issue, which is more applicable to other protocols like logging (which requires human readable timestamps) or calendaring (which deals with purely human notions of time).

Which I have been trying to point out all along. We could choose an
arbitrary epoch for NTPv5, make it behave like TAI and that will keep
the core protocol handlings clean. Then provide models to map that out
to deliver the user time-scales, and if necessary provide the needed
mapping parameters, and the TAI-UTC difference is one such parameter. If
you want a smoothed leap-second, and there seems to be people that want
that, well then we can describe another model that provide that out of
the same core time.

Rather than providing alternative time-scales on the core timing
protocol, which will be confusing to combine, consider server A
providing TAI, server B providing UTC and server C providing leap-second
smoothed UTC, then being able to do any of the fancy multiple server
combinations becomes very troublesome. If they keep a common time-format
in the core that is also TAI-like, thus no jumps etc. then that core
becomes very easy to process. Then, out of that core time, regardless
from which set of servers it was derived, we can map it out to a number
of user formats. TAI and UTC both seems to be formats we need to
support, and even if it's to my disliking, the leap-second smoothed
UTC-like time. Other such user formats is the UNIX/POSIX time_t and the
Linux time_t. Being able to achieve PTP time-scale is needed in modern
media production, such as SMPTE 2110 does, based on the SMPTE 2059-1/2
mappings. This also used in AES 67, and in particular the lack of PTP
presence while running AES 67 prompted a very long deviation away from
audio transport protocols, because the time needed was not well described.

> But it doesn’t have to.  That’s a convenience for devices that don’t have external sources of conversion information.
Which then turns the issue over to a feasibility aspect of doing it
large scale. I think it does not require much trouble to transported the
needed parameters, while not obstructing the core processing. The
additional parameters is very low-bandwidth data that with a bit of
thought put into it can be taken sufficiently of the critical timing
path, even if there is a few "loose" real time requirements.
> An E3 digital cross-connect doesn’t typically receive updates of Zoneinfo, for example… even though it very much cares about accurate time (or it will have frame-slips, etc).

The PDH and SDH/SONET does not use time in any such sense, at best you
attempt to "synchronize" (actually syntonize) just to keep quality good
enough. Having the time and date on the device has really nothing with
the switching itself to do, as that is controlled by framing and control
information, but the management to put time-stamps on events when things
failed etc, and that has far lower requirements on precision. As it
happens, I've spent a few decades designing equipment and sorting out
synchronization for telecom.

> We could, if we wanted to, come up with a protocol to distribute the Zoneinfo database to “dumb” devices like video conferencing systems, which would then mean that they had a separate mechanism fo…
I am not in favour of using the zoneinfo database for that, I think it
complicate matters and becomes troublesome to make the overall function
operate as needed, at least for what I consider is the core service.
> And there’s that conflation.  No, it’s the thing you want to do, because it kills two birds with one stone.
You may think so, but I end up seeing that what you try to push is going
to be problematic to operate properly, and I try to keep things together
when they belong together. NTP provides the time-service, the
time-service requires us to achieve certain things. Spreading things out
to other places is like breaking layers, it complicate things. This is
where trying to make simpler than it needs to be becomes a burden.

Splitting it off is extremely ill-adviced in my bitter experience. It's
drawing the wrong conclusions from previous troubles.

> And yet UTC isn’t inherently unambiguous, especially if we believe that a day contains 86,400 seconds, 24 hours of 60 minutes, 60 minutes of 60 seconds, and each second being an SI…
UTC is unambigous. You keep talking about what ambigous mappings of UTC
produce, but that result will not be compliant with UTC. Do not confuse
the properties of UTC with that of derivate time-scales such as NTPv4,
POSIX and Linux produce. The underlying UTC is unambigous itself. It's
very simple, if you cannot represent a leapsecond as :60, you do not
have the UTC. NTPv4, POSIX time_t and Linux time_t fail that test, so
you cannot talk about them as being UTC. At the best, they can represent
an UTCesque time. For some uses, that's good enough, and that's fine if
that is all you need. If you need better consistency or you need the
actual UTC, you need to do more. This goes back to what I said earlier,
I see many uses needing (as in requiring, sometime by law) UTC.
> I’ll look it over when I have some time.
It's a fairly quick read, not only a full 3 pages, but it is useful and
handy.
> Worrying about how our protocol operates in outlying cases beyond our scope or control is a waste of time.  And there will always be more such permutations than we can foresee.
It tends to be a useful exercise, even if one does not complete all
assignments.
> Okay, well, we’ve found something else to agree on then.
I do not really understand how you came to disagree with me, but ah well.
> Converging on an acceptable normative standard is not unlike eating an elephant.
I do not eat elephant, nor uneat. If I had to, I would make an overall
plan an then eat small chunks at a time. Then again, discussing elephant
eating is way off topic.
> Had metric been the single common unit of measure, there never would have been any confusion about the values being discussed.
The actual flaw was much more problematic, because first of all you had
a very asymmetric bird for economical reasons and the balance setup
required remote control. Turns out that the command and control
interface specifications where not checked between the satellite and the
ground control segment, so the lack of conversion on the ground became
apparent only in the investigation where it was uncovered that data was
interpreted as being of a different unit than sent, because the
interface specifications had not been fully reviewed by all relevant
parties.
> Similarly, it would be nice to have a single, unambiguous timescale from which other timescales (including those which are inherently ambiguous due to leap-seconds, etc) could be derived…
Sure, that part is exactly what I have been advocating for here.
> Sorry, if they “are not” sufficient and already implemented?  Or if they “are”?
Now, I come to believe there is sufficient interface already
implemented, it's just not included in what you referenced. Not all
implementations have this. I think we can look at what is already there
and see how that can be used. However, as per our other discussion, this
is more of an implementation issue. It is however relevant to some
degree if people think there is no support, and I think it is.
> Can you explain when/where/what this might be?  What are these “other uses”?

OK, so let's start with some case which I think you agree with.

Let's say you have a router or a server, it produces logs. We want
time-stamps on these logs to know when things happens. Fine, we get time
from some NTP server and the box seems be ticking away, and for many
purposes we have sufficient correct time that we can correlate the logs
in several boxes. If this time is off by some arbitrary time does not
care as long as it is consistent between what you see, but it's good
that it matches time of day and UTC seems good enough, probably with
some local time-zone tossed in.

Then, let's consider a mobile base station, you have the same needs for
logs there as in any operational environment, and for most uses the
original description works. However, now the law enforcement puts
requirement that key events relating to phones interaction with the
network becomes critical, as they use these to record the presence of a
phone to a particular base station (antenna), they record when voice and
text messages is sent etc. Now, the regulator then puts the requirement
on the operators that the time of those things needs to be traceable to
UTC, and they can put some requirements on that. In practice, a lot of
those base-stations get their time using NTP (it will shift with 5G as
PTP is expected to take over that role, but it does not diminish the
example).

The regulators and law makes have chosen to include these requirements
on more and more systems, and their golden standard is to say "traceable
to UTC". Notice that this is the UTC as being kept by BIPM, and
traceability achieved through any of the signatory national labs, so non
of the ambigous UTC derivates we talked about.

Another example is how some regulators check that the time in call data
records (classically a hated term in IETF, I know), is correct, such
that the correct fair for the time-span is put on the customers record.
Again traceability to UTC.

Depending on applications, the requirements for timing range from +/- 15
min to +/- 100 ns (if I ignore the needs to metrology labs). Some of
these requirements will for sure be outside of NTP reach, because of
it's limitations. Some of them can do with very weak solutions, even
SNTP. However, there is only so many parallel systems that you want to
operate, so it makes sense to be able to handle most requirements one
simpler system (NTP that is) and then the more stringent in more
dedicated systems. The border-line between these is roughly in the 1-10
ms span in my judgement.

Now, traceability could mean we run djungle time and provide corrections
on the side, we covered that separately. However, it becomes messy to
keep a side-system to correct after the fact for most things, so it is
again practical to make continuous adjustments to keep the system in
line. The traceability records still being collected for the paper-work
side of things to prove one achieves it, keeping the actual system
adjusted close enough to UTC with that kind of span means that we need
to follow UTC, it makes leap-second smearing not useful for those
applications (not to say there is not other applications where it may be
a sensible solution), I end up concluding that it makes sense to do it
properly.

I used mobile case as one particular demonstrator, but there is more of
them. These mobile networks do not sit on public networks (aka Internet)
but on separated networks. These are huge separate networks. Exactly how
much of the public Internet allowed "in" depends on so much. The
operations of these is quite different and changes to the network can be
cumbersome.

> Okay, thanks for clearing that up for me.
Happy to assist.
> People use self-signed certificates even though it’s a travesty (read: insecurity) and certificates should be rooted to valid, well-known root CA’s.  Knowing this to be the case, I’m not going to b…
Well, for some of these things I agree we should not fix them,
self-signed certificates is just one in a row. However, I'm not saying
we should solve all those problems, but realizing just the diversity of
uses that protocols we design have, can be a good exerices as to ask
ourselves what we can learn from it, as we take a step back from just
considering what is the right thing for the case of "Internet". Some
design decisions we make can turn out to be unwise even for that case,
but we may not see them. I've always found it good to understand
multiple scenarios as things scale up and down, as it illustrates issues
about assumptions being made, which may not be what we want even for our
primary scenario. Some of the reasonable releases of concerns may not be
that expenseive and we can gain a mode modular and workable protocol
that makes it more future resistant. It's a somewhat more effort, but in
my humble experience, it's well worth the effort and exercise.
> If I were redoing SMTP again, I would spend no time at all trying to accommodate the existence of X.400, Bitnet, Decnet architecture, Microsoft MAPI/Exchange, etc.  Refrain: not my problem.
Which is not really on the same scale here.
> So while I don’t mind the notion of carrying the TAI-to-UTC conversion and traceability information as an optional field, I don’t think that argues for (i.e. justifies) making UTC be the canonical…

I have been advocating the ability to carry such as extension fields,
and use a simple TAI-like time-scale in the core. Then on a separate
notion, I think that for many it will end up being a requirement to get
that TAI-UTC offset so the field may not be as optional as one thinks,
but that is a separate issue from that of not having even the extension
field as such to transport it in.

So, due decoupling, but keep the ability to transport needed dynamic
parameters.

> First step: don’t add new complexity.  Second step: purge existing unnecessarily complexity wherever you find it.
Only true if you achieve the minimum complexity the problem require, and
there comes the hard part, agreeing what is in that scope. I've found
that people cut out and fail to add the needed complexity needed. Thus,
you need to understand what is needed, and then add the capability for
it with the least complexity.

For NTP, in NTPv4 you have an uncessary complex thing due to the basic
properties of the core time-scale jump around. That's based on some
history and how things kind of work. We can replace that with a simpler
time-scale to do the core things in. Then, we seem to need a few other
outputs, and then we need to add the capability for those, while trying
to have least complexity. In my experience the answer is a TAI-like core
time, mapping of core-time into TAI and then further though known
definitions.

Along the discussions, there have been some confusing to what represents
TAI and UTC, I think we now sorted some of those out. I think it is fair
to transport the TAI-UTC difference, complete with heads-up information
of next upcoming event. With that, the core time can be easy to process,
we can produce a TAI replica, an UTC replica, an NTPv4 replica, an PTP
replica, an UNIX/POSIX time_t replica, an Linux time_t replica and even
if we so like an GPS time replica. Those all within the precision of the
core time-scale, if implemented correctly. We have then not provided a
leap econd smoothed UTC replica or UT1 replica (which achieves a similar
property). We can discuss wither that should be done through static
mapping (as possible for the leap second smoothed case) or through
additional dynamic parameters. As long as there is optional fields to
support such dynamic parameters for particular transformations, we could
support future formats, even if intermediary servers do not understand
these formats, as it will be a service to those end nodes that require them.

Now, one could discuss the merit of transporting these dynamic
parameters either inside NTP or through side-channel forms, and I tend
to think that it become troublesome to use side-channel forms for a
number of reasons, including operational concerns. This is why I have a
strong preference to keep it in a NTP extension field.

> Telnet options were from the very beginning open-ended.  When local line-editing was needed because remote editing over high-latency lines was just too painful, it “dropped right in”.  As did TN327…
As you overinterpret the generalization, it indeed becomes dangerous,
and way way way outside of what I mean to the degree I wonder why you
keep mocking with me all the time. You end up sounding very disgraceful,
and I do not think you intended to. However, the way you try to put
limits on it, that too becomes dangerous, as you can end up with a too
restricted thing and the end result risk becoming more complex as a
result. I've done both mistakes multiple times myself, and seen it done
many many more times than I care to explain.
> Sorry, but you keep waving your hands on this issue.  Who says we have to solve these problems?  How does it end up being “our problem”?  If they’re on an isolated intranet, with no possible connec…

No, you keep waving you hands around "Internet", when in reality the
same technology is used in many large networks, with more or less
connection to "The Internet". Quite large portions of the boxes is used
in more or less hidden applications, while built on the same technology.

> But again, none of this is “a pure pain to handle” because it’s happening somewhere that I am insulated from, isolated to, and blissfully ignorant of.

Yes, well that is why I bring it up. What may seem like a good decision
for Internet, may not be that for other cases, which then forces them to
break away and solve it by some other means, which means more divide in
features used and well, IETF can do what they feel like and we cherry
pick the good stuff and we do what we want to do. That ends up just
deepening the divide there is. Rather, if one can look at other
scenarios and see what can be useful for them, one at least can reduce
the divide a little. IETFers can see the same thing as they look at the
IEEE 802 group, where IETF cherry picks some of the IEEE 802 output, but
then ignores some of the things.

Now, I think there is some lessons to be learned by looking at different
scenarios, realizing that not all solutions fit all. I think one can do
reasonable generalizations, that is generalizations not going overboard,
but that provide means for variations that may be useful already for the
base scenario. It's a little more than the minimum, minimum, but maybe
more future proof. Adding extensions afterwards end up being a little
bit messy. MIME is one, ARP, multicast group mapping and IGMP with IGMP
snooping going towards the more uglier side of things.

> It sounds like you’re sending a mixed message, but maybe I’m just not understanding.  What I’m hearing you say is, “be sparse [or ‘economical’] in your assumptions about what where things might be…

If the message was that simple as you like, it would rule out necessary
parts, then the message is overly simple and not useful. I can reduce
the message a lot, but not below the most basic complexity it needs, and
some of the things are contradictory. If you try to think I have one
simple message, you read me all wrong.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 14:59:33 +0100

> > UTC. NTPv5 cannot support only TAI. 

I'd say it's fairly simple.

> have to clutter up an RFC for NTPv5.

Much cleaner? It's just a single field needed to negotiate the
timescale.

> insert/delete/none, and the valid-until date of the info.

Even if the kernel+libc fully supported TAI (they currently don't), it
cannot work when the TAI-UTC is unknown, e.g. in an isolated network
with a reference clock which doesn't provide this information. It
doesn't matter how it is called or specified, but NTP has to support
synchronization of UTC clocks when the TAI-UTC offset is unknown.
Otherwise, it would be just an academic project of very limited value.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 15:10:55 +0100

On 2021-01-05 09:33, Miroslav Lichvar wrote:
> discussed here.
So, you are saying that the kernel sense of TAI is not used to control
the time of the hardware clock? Fine, but some driver is doing that,
because the hardware clock of a typical is very stupid and is controlled
even with simpler forms than that for which the kernel clock is steered
by NTPD over the nanokernel interface.
>  I assume we don't want NTPv5 to require a hardware
> clock.
While we do not want to require it, we also do not want to exclude it
either. When it is there, the implementation should be able to use it.
> based on UTC. NTPv5 cannot support only TAI.

I agree that NTPv5 cannot support only TAI.

However, there comes the first challenge, do the core time-stamp format
be that of a single format or of any timescale format. I think we agree
that formats having the POSIX, Linux and NTPv4 type of leap-second jumps
is to be avoided. OK, so we want something more continuous and then
concluding some variant of TAI-like property, similar to that of PTP is
useful, not at all saying or suggesting it needs to be the PTP one.

Second challenge, if we have a TAI-like core format, and we indeed can
rebuild a TAI replica, and we do not consider this enough, would a TAI
format allows us to fairly cheaply adapt that to other formats? Turns
out that this comes very cheap and is easy to do robust, if and only if,
one has access to the TAI-UTC difference and information about an
upcoming one as that eventually approaches.

Will that satisfy all needs? Maybe not. OK, but will this provide a
vehicle for more variants. Seems likely if we have a standard way of
augmenting the core timing with additional parameters and users add the
mapping.

Sure, I am advocating for a particular part of the solution space. But I
think it is doable without any of the parts becoming cumbersomely
complex to test and verify. An example is how PTP has extension fields
extended by SMPTE 2059-2 and the various output mappings documented
separately in SMPTE 2059-1 to show how the transported parameters
generate all the legacy timing things. SMPTE 2110-10 then extends SMPTE
2059-2 and 2059-1 for the application within the SMPTE 2110 transport
protocols and timing model of media used there. Anyway, I think it is a
fair model that seems to work.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 15:34:36 +0100

> TAI processing was tied to autokey protocol extensions.

Well, there is a long line of technical decisions spread over a long time.

For instance, the fact that the NTP time would mimic the time_t behavior
on leap seconds is one very clear case where a specific user behavior
was pushed onto the on the wire protocol.

Then, the original nanokernel interface was concerned with scheduling
issues and the state of time-stamp mechanisms available at that time. We
have since gained access to several additional time-stamp mechanisms
even in user-space, both running as counter on the bus-clock and
CPU-clock cycles, the later which may vary over time due to dynamic
cycle handling to avoid overheating.

Then, the notion that we want to also keep the TAI-UTC difference, and
that this would allow for a CLOCK_TAI in the first place. However, as
that was added, it was the TAI-UTC difference that was added to the
Autokey transport (but never really to the Autokey itself).

The pre TAI-UTC difference version of the nanokernel interface was for a
long time stuck in the glibc headers not being updated, despite the
linux kernel had the capability for it. Again illustrating how a
side-channel became problematic rather than a solution, which I keep
having to point out is an issue.

So, yeah, it became ugly for sure, but it was a consequence of history,
not because it was inherently bad. I think the proper lesson to learn is
to actually build for it from the start. Then if it is implemented in
the kernel or in libc for a particular operating system, well that I
think is not what the working ground should care about as such, but we
can discuss it. I think it is not inherently bad to keep both TAI and
UTC sense in the kernel, and I am much more keener to push out UTC in
that case than TAI. The low-hanging fruit for UNIX/Linux type operating
systems would be to use the PTP time definition, then you could move UTC
adaptation and classical time_t variants out of the kernel and only use
the new time_t internally. The needed things in libc would be fairly
trivial. A common way to access the TAI-UTC difference is however
needed, one could let the kernel take on that task only for practical
reasons, but really not process on them itself. That provides fairly
small burden, but then again, that would be an implementational detail
for the OS, that we can hide behind libc, as long as we can do the right
things and access it all the times. The overall requirements for such
interface contains a bit of details to know if we "have" things right
now and it's error handling, but not very complex. Using a form of
nanokernel interface to steer the rate of the system time, is probably
still a good idea, but I think reposition the problem will simplify it
significantly.

So, make sure to learn the right things from history.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 15:41:55 +0100

Hi,

> clock with PTP, the timestamps would typically be in the arbitrary

PTP actually support both providing a TAI and UTC replica, as it also
carries the TAI-UTC difference in addition to having the core time-stamp
format that derives from TAI.

Now, most (all?) PTP grand masters (a term that I expect to go away)
that I know of use GPS and other GNSSes to create a TAI-respecting
PTP-timescale replica with correct TAI-UTC difference.

For media clocks, it is the PTP time and thus TAI-based time that is
used, not the UTC based time.

> suggest them to try to implement it first.
Regardless how we turn, we can not push the leap-seconds completely off
the table. They need to be handled up front. If so, they can be handled
fairly OK, where as trying to ignore them just create a number of
problematic side-cases. I know what I prefer based out of my experience
of building timing systems.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 15:42:25 +0100

> by NTPD over the nanokernel interface.

The kernel and driver have no idea in what timescale the hardware
clock is keeping time, if any. That's up to the applications. Unlike
with the system clock, there is no support for inserting/deleting leap
seconds, so it needs to use a non-leaping representation.

> upcoming one as that eventually approaches.

Yes, that's the problem I'm trying to point out. The TAI-UTC offset is
not universally available, but it is required for conversion between a
leaping and non-leaping representation of time. It doesn't matter if
it is in the kernel, libc, or the NTP implementation. When I want to
synchronize two UTC clocks, which is probably the most common case,
there is no point in converting the timestamps to a non-leaping
representation and back. If it cannot be done reliably, as is the case
with current systems, it will just make the synchronization less
reliable.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 15:57:14 +0100

> format that derives from TAI.

It does provide the TAI-UTC offset, but it is optional. There is a
flag to indicate the value is valid. PTP supports operation in
UTC-only and TAI-only environments.

> of building timing systems.

I think the problems of NTPv4 wrt leap seconds are well understood.
We need to announce leap seconds earlier and provide the TAI-UTC
offset if known. We should also add support for timestamps in a
non-leaping timescale to support the less usual case of clocks keeping
time in TAI.

--  
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 16:14:45 +0100

Hal,

> have to clutter up an RFC for NTPv5.

Look at the SMPTE 2059-1 and SMPTE 2059-2 solution for instance. 2059-1
provides the detailed mapping mechanisms for all various formats. 2059-2
augments the IEEE1588-2008 with fields to carry the necessary
information. so that the set of gears in 2059-1 will work.

So, you can keep one RFC with a TAI-based (but not actual TAI) NTPv5
protocol. Then another RFC providing the mapping mechanisms and
extension fields for them. If then the extension is carried in the NTP
core protocol, an extension data variant of NTP that also gets
transported through is then another separate issue. There is no secret
that I lean towards one that follows the overall distribution of time
itself, at least for most part (I know it sounds confusing, but it's a
separate point).

> insert/delete/none, and the valid-until date of the info.
Yes. Actually, you do not need a flag to indicate insert/delete/none.
You can do with something to indicate upcoming leap-second event, and
then the encoding of that event will include information of when the
event occurs and the resulting difference. The flag should not
necessarily indicate direction, that's a specific encoding from history
that we may choose to ignore.
> kernels provide TAI and/or leap when appropriate.
They are not really UTC based kernels. Some of them is however also able
to do UTC, but most have the POSIX or Linux time_t, which isn't UTC. We
can let libc provide the historic time_t in implementations.
> We could provide that data in a new protocol.  Or a new packet type on the NTP 

If one looks at PTP for instance, it has an "event interface" and a
"general interface". The event interface is the only packets that
experience time stamping, where as the general interface does not. The
type of data we describe here would fit what goes on the general
interface rather than the event interface. I think it's a good model.
See Figure 2 in IEEE 1588-2008.

I have also already made the point that management related data, which
have been discussed as potential DDOS tool, do not even have to be
carried on what looks like NTP. Thus, it may not need to be limited to
UDP but could use the TCP stack of solutions. That would for sure not be
event interface, but general interface.

> answer rather than ask every time.

No. It still can change every month. It's just a preference to change on
the end of each half year, and that preference have been honored so far.
However, I've seen bugs show up because of interpreting things
incorrectly. Whatever mechanism is being used, it needs to respect the
underlying capability of inserting leap seconds at the end of every UTC
month, and it also needs the ability to indicate that when an upcoming
leap second shift is to occur, it needs to be able to indicate when that
shift occurs and what the new value will be. The exact encoding of that
can then differ naturally, but it needs to unambigously convey the same
information as I stated.

> ride.  Debian already does it.
A curious note there thought. It uses the older NTPv4 time of timestamp
format. It will be less well adapted to a new TAI-based NTPv5 timestamp
format. It may actually be wise to revise that and eventually to
unentangle it, as it has historical limits to it. The way that NTPv4
time-stamps work, you kind of need the table, but if you use a TAI-base,
you only need the current TAI-UTC offset and potentially the future. You
do not need the history. The leap-seconds.list is another form of
artifact that is not without it's issues. Even the comments in them can
be somewhat confusing if read outside of the NTPv4 context.

Cheers,
Magnus

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 15:49:40 +0000

connection??

Basically no.

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 16:51:13 +0100

Miroslav,

> with current systems, it will just make the synchronization less

Actually, here lies a problem. There seems to be fairly wide agreement
that we want the core time-stamping to use a TAI-like form of time. This
means, it keeps ticking, behaves like a well-functioned linear ramp.
That makes any processing of it easy and so does all encoding.

UTC fails to be such a ramp in many encodings. When the leapsecond is
inserted in 23:59:60, that becomes an encoding challenge for all the
formats I know.

TAI achieves this ramp property, and so does TAI-like things like PTP
and GPS.

UNIX/POSIX time_t fail this ramp property, as they recode the 23:59:60
into 00:00:00, which is followed by another 00:00:00.

NTPv4 fail this ramp property, as it recode the 23:59:60 into 00:00:00
and a leap-indication, which is followed by another 00:00:00.

Linux time_T fail this ramp property, as it recode the 23:59:60 into a
second 23:59:59.

So, when forces say they really, really want to get rid of these
encoding issues in the core transport of time-stamps, it's a real thing.
It will be completely incompatible with UTC transport without means to
handle things.

Now, if the source side is unable to derive the TAI-UTC difference from
it's timing source (say a simple GPS-receiver), when to resolve this,
some other means of resolvement needs to be done at the server. You
could use a leap-second.list file. You could use DNS based methods. You
could listen to other trusted NTP servers only to attain the TAI-UTC
difference and then re-distribute that. Regardless of which, when
achieved you can provide the full service for all clients.

Then, what happens if neither of these methods become at hand. Shall we
have a way to indicate this. This we should for sure discuss. So, if you
now know you have a good UTC-source, but it is unaided with the TAI-UTC
difference. Can I use it? Sure, it will provide the right frequency and
phase, it's annotation of time can jump strangely on leap-seconds, but
most of the time we will be able to handle it. OK, so a form of reduced
service, but still a service. Here comes the thing to discuss, do we
want to put the burden to handle this on the clients or push it to the
servers?

I think we need to agree on either really just have one time-scale in
the core which will be the same for all NTPv5 users, and with that say
that either you are able to deliver that, or you do not provide the
service. Thus, you require a basic set of adaptation mappings as you go
into the network and then with that you can pick and choose from a set
of adaptation mappings as you go out.

If we say that we indeed can have different time-scales, then each user
then needs to be able to handle the situation of conflicting time-scales
from different servers, either separate or at the same time. I end
thinking madness lies within. One of the things that NTP traditionally
allows us to do is to use multiple servers and weigh them together to a
new composite clock based on their performance (to the client). This is
really derived out of David Allan's clock algorithm work originally.
That will be more difficult to implement if we have diverse time-scales
to source from, notice now that I'm not saying impossible, but more
difficult. We may have to alter those details in the algorithm to handle
the various ways clocks can behave. We would need to know how a
leap-second smoothing clock is doing it's smoothing for instance.

It is exactly these things which makes it such a great idea to have a
very linear ramp type of clock in the core timing, it is a very
attractive technical solution. It will require the handling of TAI-UTC
difference as we get the clock, using one of many ways to do it, and
while it may be an implementation detail, we can provide hints and
potential solutions to many ways of achieving it. Once we done that, we
will actually have both TAI and TAI-UTC knowledge, so as a side effect
we might as well distribute it along.

Now, if you know the current TAI-UTC difference, often you can apply
heuristics to the jump you see on an input clock. Problem is you are now
late with that knowledge and the ambition to distribute it before the
event. So, for that reason I view that observation is not very useful
for the problem at hand.

So I think we need to choose between two different scenarios, either one
where we allow multiple timescales being sent, without TAI-UTC
difference at all times, or we go for a unified timescale meeting the
ideal model properties, and say that we need to be able to resolve the
issue. There is no real way around that central question.

I lean towards pushing the conversion requirement onto the NTP source
nodes just to achieve the intended cleanness of the rest of the
infrastructure.

It is only as a side-consequence that I note that it will come with very
low additional cost to also provide the TAI-UTC difference as needed
when we have done that, but it is not my primary motivation although a
very nice positive upside. Thus, a nice secondary gain.

Cheers,
Magnus

---

From: James Browning <[email-masked]>
Date: Tue, 5 Jan 2021 08:00:00 -0800

> Do we have a unifying theme?  Can you describe why we are working on NTPv5

I think the theme is herding cats and the mission statement should be
'For all the things NTP4 can't or won't do.'

My shortlist is to shift the epoch to 2020, (a)symmetric authentication
to extensions, and the timescale to TAI based not UTC based.

Others might be mandated security or (from off-list) a JSON derived
protocol.

> smeared time.  Can we push supporting that to extensions?  Maybe even a

An extension containing two offsets pre/post-shift, an integer second
offset from the epoch for the shift time, an expiration time, a text
scale identifier, a certificate name for who says so, and their
signature. The offsets would then be something like a signed 16/16 bit
fixed-point number.

:::snip:::

Send a packet with everything and see what returns? Autokey for its
failings had a capability negotiation as the first step IIRC.

> if the answer is no.  Maybe we should distribute the info via DNS where we

Not sure what you mean. Perhaps have a DNS TXT record containing a
comma-separated caps list returned along with the address.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 5 Jan 2021 11:09:39 -0500

> to extensions, and the timescale to TAI based not UTC based.

Can we have something less cursed? The engineers of our civil calendar
chose the birth of their savior, and you want to choose *2020*?

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 5 Jan 2021 17:09:47 +0100

>> UTC. NTPv5 cannot support only TAI. 

I fully and strongly agree with Miroslav.

NTP isn't only used on Linux, which supports TAI time, and FreeBSD,
which doesn't support TAI right now but can easily be extended to
support it in the near future (if I have understood some earlier
messages correctly).

Instead, there are more operating systems like other Unix-like systems,
Windows, VxWorks, QNX, and last but not least embedded systems and IoT
devices which are not even mentioned here. In many cases at least the
latter won't even run a full-featured NTP daemon but some simple NTP
client software just to keep their system time basically synchronized so
that their logs etc. are based on a fairly accurate time, which is
UTC/POSIX or a local time derived from that.

In the past, moving from NTPv3 to NTPv4 was easy and could be done
seamlessly due to the (IMO very good) evolution of the protocol, e.g.
that the format of the base packet was unchanged and new features were
implemented using extension fields.

When the NTP daemon (at least the original implementation from ntp.org)
received a request from a v3 client, it just had to change the set the
version field in the response packet to v3 instead of v4 to keep v3
clients happy.

>From the point of view as a manufacturer of time server appliances this
is much easier to maintain than the mess we had with PTP, where v2
packets had a totally different layout than the original v1 packets. The
only thing that limited the impact of that change was that PTPv2
appeared soon after v1, and v1 wasn't much widespread at that time.

For NTP, things are different. There is a huge base of NTPv4
installations, and making NTPv5 basically compatible with v4 would IMO
strongly increase the acceptance of NTPv5.

Yes, I know that it *may be* possible to design the protocol new, from
scratch, without any compatibility with v4, but IMO this would just
keeping lots of folks from using it for a long time, so the question is
if this was really a better approach than taking care of compatibility.

> have to clutter up an RFC for NTPv5.

Yes, of course. If you only care how easy it is to document it, you
could simply say that NTP provides TAI time stamps, and that's it. This
would leave all the problems of the details how to convert that to UTC
and/or local time to the implementers of the system timekeeping.

In my opinion it would make much more sense to keep the NTP base packet
compatible with v4 and maybe make some extension fields mandatory for
v5, for example some correction information that let the client derive
TAI from the timestamps, if required or supported.

IMO this would strongly increase the acceptance of a v5 protocol because
existing clients still can use the same server as new, full-featured v5
clients, which can derive TAI if they want or need it.

> insert/delete/none, and the valid-until date of the info.

And there needs to be an API call that returns the current TAI or
UTC/POSIX) time *plus* the associated UTC offset atomically, with an
execution time as short as possible.

If you have to call several API functions after each other, you know in
worst case the kernel could just step the time between the 2 calls, so
the result ing timestamp/offset pair would be inconsistent.

I know there is already the ntp_gettime() call available on some
systems, but if you have a huge number of clients, the execution time of
that function significantly reduces the performance of the NTP server.

> kernels provide TAI and/or leap when appropriate.

Why not do it the other way round, and provide the time scale that is
required by default by the clients, and provide a way to derive TAI for
those who really need it?

Yo still have to keep in mind that if you use TAI, you need a reliable
source not only for leap second announcements but also for the current
TAI offset. The latter is not provided by all reference time sources,
e.g. DCF77 doesn't have it.

> We could provide code that lets systems process leap-seconds.list

Yes, but "someone" has to provide the file, at some point.

> ride.  Debian already does it.

Except the versions that aren't updated anymore, or embedded of IoT
devices. This has been discussed many times before.

IMO it's a step back to force using TAI just because it can easier be
described because it just shifts the existing limitations to a different
location in the time synchronization chain.

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: Martin Burnicki <[email-masked]>
Date: Tue, 5 Jan 2021 17:11:54 +0100

> Otherwise, it would be just an academic project of very limited value.

+10 (+1 wouldn't be enough, IMO ;-)

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 5 Jan 2021 17:24:11 +0100

Magnus Danielson wrote:
> is to be avoided.

I really wonder what the "NTPv4 type of leap second jumps" is. If the
system supports leap seconds at all, at least ntpd just passes the leap
second announcement to the kernel. And the daemon relies on the
timestamps returned by the kernel.

If the kernel handles this in a way we don't consider "appropriate",
what could an NTP (or PTP or whatever) daemon do to fix it? Applications
will still suffer from limitations of the operating system.

> OK, so we want something more continuous and then

Agreed.

> augmenting the core timing with additional parameters and users add the

That's also fine, but by default it should IMO be possible to provide
simple clients with time in a way as compatible as possible.

> fair model that seems to work.

If a *simple* client needs to do this just to derive UTC (what's
probably the case for most not telco devices) than it's a wrong approach
to provide TAI and derive UTC from it.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: James Browning <[email-masked]>
Date: Tue, 5 Jan 2021 08:25:04 -0800

> chose the birth of their savior, and you want to choose *2020*?

(/topic)I picked something with 136 years of future instead of throwing 50,
120, or 2020 years into the past.(topic)

Do you have a better year that is _after_ some of us were born?

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 5 Jan 2021 17:29:01 +0100

> That makes any processing of it easy and so does all encoding.

Yeah, I don't agree with this idea. It will create more problems than
solve. I'd like NTP to be versatile and support multiple timescales,
as PTP does for instance.

> It will be completely incompatible with UTC transport without means to

You cannot get rid of these issues until operating systems fully
support a non-leaping timescale and the TAI-UTC offset is always
known. I don't expect that happen anytime soon. You can specify a
nice protocol that supports only a non-leaping representation of time,
but it will just make implementations more complicated and less
reliable on those systems if the protocol actually gets implemented.

> achieved you can provide the full service for all clients.

That's not always practical. If you start to rely on humans doing
something once every few years, you can be sure it will be broken. We
have few CDMA-based NTP servers in our network. They need to be
manually programmed for each leap second. You can guess how many times
I have seen that done correctly. Not once. It's fixed only when people
notice their clocks are off by one second. Before another leap second
occurs, it's all forgotten.

> thinking madness lies within.

I don't expect it to be a problem, at least not a bigger problem than
trying to convert everything to a common timescale. In the case when
the server cannot provide the service in the requested timescale and
the client cannot convert the timestamps locally, how could it
work if the protocol allowed only one timescale?

> nodes just to achieve the intended cleanness of the rest of the

It makes sense to require servers to convert the timestamps if they
have the offset, but for some hardware implementations (one-step
clocks) that might not be possible.

-- 
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 5 Jan 2021 11:30:21 -0500

I'd rather just add more bits to the timestamp so that ±100 years of range
doesn't have to be a concern.

On Tue, Jan 5, 2021, 11:25 James Browning <[email-masked]> wrote:

> (/topic)I picked something with 136 years of future instead of throwing
> 50, 120, or 2020 years into the past.(topic)
>

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 5 Jan 2021 17:32:33 +0100

> inserted in 23:59:60, that becomes an encoding challenge for all the

So you can opt to change the encoding of UTC, and use a
combination of days and seconds in that day.

Kurt

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 5 Jan 2021 17:33:19 +0100

Miroslav Lichvar wrote:
> offset if known.

Hm, IIRC ntpd provides the leap second warning via the protocol about 24
hours in advance, *if* that information is available from some source.
Shouldn't that be enough?

Also IIRC, PTP provides a leap second warning on 12 hours in advance.

The only limitation for NTPv4 (without Autokey) is that the current TAI
offset can't be provided, which can easily be improved by an extension
field.

> We should also add support for timestamps in a

I fully agree, but as I said before, I also think it should be done by
providing UTC by default, and a correction to derive TAI from it.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Tue, 5 Jan 2021 18:09:30 +0100

> into 00:00:00, which is followed by another 00:00:00.

Yes, that's a problem in the operating system, or more accurately in the
definition of the POSIX time.

> and a leap-indication, which is followed by another 00:00:00.

Hm, AFAIK daemons just grab the system timestamp, and they don't even
see a 23:59:60, maybe except in a refclock driver. *If* the daemons sees
it at all, it is already much too late to send a leap second warning to
a client.

And the same problem exists with a PTP daemon if "just sees 23:59:60".

Thus, a proper configuration is required to provide the daemon with
information of an upcoming leap second from a reliable source. And if
you use TAI, you need *in addition* a proper source for the UTC/TAI offset.

> It will be completely incompatible with UTC transport without means to

As I mentioned before, IMO the default timestamps in the protocol should
represent UTC, for compatibility reasons and because it's probably the
most common use case.

IMO, a possible solution in the role of a server that sends time to its
clients could be

1.) If the operating system doesn't support TAI, things can be the same
as they are now. Just grab the "system time" (CLOCK_REALTIME on POSIX,
GetSystemTimePreciseAsFileTime() on Windows, or whatever) and send it to
clients.

2.) If the OS does support TAI, the server daemon *should* have been
configured in a way that a reliable source for leap second announcements
plus the TAI offset is available, so when the daemon disciplines the
system time, it can write the TAI offset plus a possible leap second
warning to the kernel, so the kernel really has a proper TAI time, and
it knows the TAI offset, and the TAI time at which the UTC offset will
jump due to a leap second.

If a client request is to be handled, the daemon can read the TAI clock
to grab a transmit timestamp, compare the timestamp to the TAI time of
the leap second, determine if the current TAI time is before or after
the TAI time for the leap second, and knows if the old or new TAI offset
is appropriate to compute UTC.

It can then apply the determined UTC/TAI offset to the transmit
timestamp, so simple clients get "UTC" as usual. In addition, the
associated UTC/TAI offset can be put into an extension field. This
allows "enhanced" clients to easily and consistently convert it back, if
they want or need it.

So this approach could be a compatible but enhanced solution for old and
new clients.

If you need to support other time scales for special (telco?)
applications, it should be easy to provide more extension fields that
provide the necessary information for the conversion.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 5 Jan 2021 18:18:19 +0100

> seconds, so it needs to use a non-leaping representation.

As I understand it, the hardware clock is one that's running in the
ethernet controller. It can be that it's counting cycles since
boot based on it's own cristal. And you get that clock without any
processing when you request hardware timestamping. So the
application also has to compensate for the difference between the
ethernet clock and the system clock.

Kurt

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 18:48:53 +0100

Martin,

> will still suffer from limitations of the operating system.

Sure. It's a multi-front battle.

With "NTPv4 type leap-second jump" i mean the way that the NTPv4 clock
ticks in combination with the leap second flag. It's not a very neat
format, even if it works. Alone it does not give us TAI-UTC difference,
but if we setup that correctly, we have padded the leap-second and a
good implementation can get things right.

>> upcoming one as that eventually approaches.
Good we have agreement on that.
> simple clients with time in a way as compatible as possible.

Indeed. I am confident that the client can be very simple and provide
the right time, even with leap seconds occurring.

> to provide TAI and derive UTC from it.

Well, it may seem so at first, but if we taken on the burden of getting
TAI and TAI-UTC and transport that, the client can be very simple and
provide TAI, UTC, POSIX, LINUX, PTP, GPS time scale replicas using very
little code or complexity. The mappings provided will not require many
pages and it will be easy to implement them all.

Check your inbox for a separate example.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 18:56:45 +0100

Daniel,

On 2021-01-05 17:09, Daniel Franke wrote:
> On Tue, Jan 5, 2021 at 11:00 AM James Browning <[email-masked]
> <mailto:[email-masked]>> wrote:
>

We can choose 1 Jan 2021 as I proposed as an arbitrary point, we could
choose my birthday on 27th April as an even more arbitrary point, not
that I would recommend it. It would be a nice gesture thought, but I am
not going to ask for it. :)

We could also choose the low-hanging fruit of the PTP-epoch, which is
engineered to look like the old UNIX time_t, but defined in a suitable
TAI point such that normal UTC pops out as the TAI-UTC difference is
applied.

I'm not saying we need to use the PTP-epoch, it can be arbitrary and the
only real thing we should consider is that we actually have from now
integer SI-second difference to TAI and to UTC, which would align up
well with all the major time-scales we would like to consider. I am
however saying that the PTP-epoch and time-scale might be very very
handy to use.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 5 Jan 2021 19:02:01 +0100

Daniel,

On 2021-01-05 17:30, Daniel Franke wrote:
> I'd rather just add more bits to the timestamp so that ±100 years of
> range doesn't have to be a concern.
>
I do like the way you think. In one design I made, I made it Y10k safe,
because I could. Throwing a few bits on it ended up being cheap, and
with current life expectancy of me considering current lack of
time-travels and life-extension techniques, I think I've moved the
wrap-around sufficiently far out that neither me or the technology will
be around. All for a handful of bits.

Now, if we going to follow James suggestion of some timestamp after some
of us was born, the PTP epoch is actual before I was born, and I turn 50
soon.

Cheers,
Magnus

> On Tue, Jan 5, 2021, 11:25 James Browning <[email-masked]
>     On Tue, Jan 5, 2021, at 8:09 AM Daniel Franke
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Tue, Jan 5, 2021 at 11:00 AM James Browning
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Can we have something less cursed? The engineers of our civil
>         calendar chose the birth of their savior, and you want to
>         choose *2020*?
>
>
>     (/topic)I picked something with 136 years of future instead of
>     throwing 50, 120, or 2020 years into the past.(topic)
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ntp>
>
>

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 11:05:23 -0700

> On Jan 5, 2021, at 4:04 AM, Magnus Danielson <[email-masked]> wrote:
> 

I don’t agree.

It’s completely acceptable for the WG to mandate certain requirements like “must have RTC”, “RTC must be accurate to <= 16 ppm”, “must have persistent storage for storing […]”, etc.  Look at RFC-1122, 1123, and 1812…

Such a requirement was that the sysUpTime in MIB2 required a 100Hz (or better) clock.

There’s a reason that CONFIG_HZ_60 has long since disappeared from the Linux kernel sources.

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 11:08:09 -0700

> On Jan 5, 2021, at 5:45 AM, Hal Murray <[email-masked]> wrote:
> 

That seems like a good argument to NOT include it in the protocol, if it’s already available out-of-band.

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 11:27:55 -0700

> On Jan 5, 2021, at 7:10 AM, Magnus Danielson <[email-masked]> wrote:
> 

Not to be banging the same drum, but… Zoneinfo has the necessary information.  People shouldn’t be operating hosts that aren’t getting regular updates if they’re on the Internet, because vulnerabilities aren’t being patched in that case.  Indeed, even hosts that aren’t on the internet should still be receiving patches: that’s just good hygiene.

So hosts are covered.

My concern is for embedded devices that require accurate time (video cameras, smart appliances, power and water meters, industrial instrumentation, etc.) not having such updates.

Maybe a separate protocol is required to handle Zoneinfo dissemination… or at least a relevant slice of it… delivered to IoT’s.  They don’t need the entire table: just for their timezone, and from now for as far forward as the table goes (or at least through the next transition/event).

Does anyone else see value to handling that orthogonally?

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 12:56:20 -0700

> On Jan 5, 2021, at 8:51 AM, Magnus Danielson <[email-masked]> wrote:
> 

It might help to stop conflating issues.

Clock synchronization is a simple problem requiring linear, non-leaping time.

Calendaring is an orthogonal issue of breaking groups of seconds into human-friendly units of minutes, hours, days, years, etc.

NTPv4 tried to resolve both issues because it seemed convenient at the time: in retrospect, it’s not clear that it didn’t create more problems.

I say that we drop the unnecessary encumbrances, and shift attention to the necessities that have since emerged that NTPv4 didn’t address (like clarity, good security, better extensibility, etc).

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 13:11:19 -0700

> nodes just to achieve the intended cleanness of the rest of the

I’m going to push back against that.

I think that many protocols embed human-readable time notation unnecessarily.  Take the syslog protocol.  Is there a reason why it couldn’t just have used TAI time in seconds and milliseconds (or microseconds), and left it to some browser to do the rendering or “presentation” into a human-preferred format?

Take video security cameras.  Do they need to know that a particular timestamp corresponds to a minute/day/month/year/leap-second?  I don’t think so.  I think the browser there, too, could do the conversion.

Has anyone ever tried to run a “make” on a large code base just as a second leaped?  It’s a mess.  A lot of things get rebuilt unnecessarily.  And that’s with forward leaps.  If we ever need to shorten a day, I can’t begin to image how badly things will break.

This wouldn’t happen if we let machines deal with a representation of time that’s optimal for them (i.e. simple and unambiguous) and held off on conversion to human-readable format until it was actually necessary.

As a postmaster for 30 odd years, I’ve had to struggle with Received: lines having local dates and times that require me to pay attention to the UTC offsets to be aware of when DST took place (if it took place at all) for each timezone that a server lived in as it handled a message.  It’s a mess.  RFC-822 should have mandated UT or Zulu time (as that was the best we had at the time).

Or having logs sent to me, or logging into remote machines, and having to know the timezone of the provenance of those logs, then doing the math in my head to match that up with other events elsewhere.

Simple, unique, unambiguous, and universal time is what machines need.

Conversion to something that’s convenient for humans should be deferred until absolutely necessary (and it may never be!).

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 13:12:53 -0700

> On Jan 5, 2021, at 9:09 AM, Martin Burnicki <martin.burnicki=[email-masked]> wrote:
> 

The logical corollary to this argument is that because there ARE a lot of servers, it’s not unreasonable to think that there will be a lot of both NTPv4 and NTPv5 servers co-existing in the future, and the user is free to peer with either.

Which eliminates the need for NTPv5 servers to also speak NTPv4.

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 13:20:15 -0700

> devices. This has been discussed many times before.

If those devices aren’t updated any more, it’s equally possible that they’ll never get an NTPv5 compatible client, either.

That would necessitate an “update” of sorts, which we’ve both agreed isn’t going to happen.

---

From: Doug Arnold <[email-masked]>
Date: Tue, 5 Jan 2021 22:24:37 +0000

Perhaps an informative document on implementation for security and robustness?

Doug

On 1/4/21, 11:46 AM, "ntp on behalf of Magnus Danielson" <[email-masked] on behalf of [email-masked]> wrote:

    Doug and Hal,

    Cheers,
    Magnus

---

From: Doug Arnold <[email-masked]>
Date: Tue, 5 Jan 2021 23:11:02 +0000

Two commercial time server vendors I have worked for tell customer that you should always use the default timescale, and make any needed corrections at the ptp slaves/ntp clients.  Most customers do so, but there are always some who insist on putting local time, or GPS time or whatever timescale right in the protocol timestamps.  Given that I think that the best thing we can do is make the timescale visible, and have a strongly recommended default.

Doug

        connection??

    Basically no.

---

From: Hal Murray <[email-masked]>
Date: Tue, 05 Jan 2021 15:32:01 -0800

>>    I don't know the details of TLS.  Can I change hats without reopening a 

Thanks.

So we would either have to extend the NTS-KE protocol or add our own 
multiplexing layer.

Is there any prior art in this area that we should/could copy?  (or avoid?)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Jan 2021 23:42:07 +0000

What does "change hats" mean?

In general, the TLS WG has removed renegotiation from the TLS protocol because it's proven to be a source of security issues. (In TLS 1.3 it's basically gone)

So what, in more detail, are you trying to do?

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 6 Jan 2021 00:53:06 +0100

Miroslav,

> as PTP does for instance.

I'm not at all convinced. PTP has little, at least as I can see in
IEEE1588-2008, that really supports the UTC with time-stamps. I should
check IEEE1588-2019 for more details, but you will have to explain very
clearly how that support comes about in PTP, because as I see it, if you
run UTC only it's hand-wavey at best. If you can show clearly how PTP
handles UTC and especially as a leap-second occur without hickup.

> reliable on those systems if the protocol actually gets implemented.
Well, I think it can be done.
> occurs, it's all forgotten.

Yeah, so I did suggest several ways to remedy that.

As a secondary note, do take a look at the expected lifetime of the CDMA
service, as that may be phased out as 5G roll-outs starts to come
closer. A lot of them have already closed.

> work if the protocol allowed only one timescale?
I never said it could not be done, I said it would be complex and
troublesome. Avoiding comlexity seems to be one of the driving forces
behind NTPv5. If so, one will have to choose what things remains and
what one trade out. I am very sure that people is not fully coherent on
that and what it endtails, therefore one needs to ask the hard questions
so people learn what challenges lies ahead. If we are not agreeing on
basic properties, the discussions further down the line will not be very
fruitful.
> clocks) that might not be possible.
What one-step clocks would that be? Surely, I expect none of the
existing NTP clocks to automatically support NTPv5, almost regardless
which shape it will take.

Cheers,
Magnus

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 5 Jan 2021 20:59:24 -0700

> You could use DNS based methods.

I want to quash this approach.

DNS has means to attempt some form of weak security, but a lot of people don’t do it or don’t do it properly.

This will be a weakness in time, plus it introduces circular dependencies since DNS records are themselves timestamped for expiration (TTL’s), though that’s an offset from now and not an absolute time…

We already bloat DNS with too much, such as RSA keys and SPF… we’re attempting to use it as a distributed clearinghouse database, which it was never meant to be.

Oh, for the love of Grapevine.

---

From: Hal Murray <[email-masked]>
Date: Wed, 06 Jan 2021 00:16:10 -0800

[email-masked] said:
> In general, the TLS WG has removed renegotiation from the TLS protocol
> because it's proven to be a source of security issues. (In TLS 1.3 it's
> basically gone)

> So what, in more detail, are you trying to do? 

I was fishing for a way to combine 2 TLS sessions to the same host using 
different ALPN codes into one session.

The context was adding something like a way to distribute a supported features 
list without polluting the KE protocol.

I could imagine other infrequent lightweight NTP related protocols that could 
also benefit from being authenticated.  The obvious one is distributing leap 
info.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 6 Jan 2021 09:57:56 +0000

I clearly don't understand the resistance to go to a linear TAI like 
form for the core time-stamping format as long as the TAI-UTC offset is 
part of the core protocol frame. It could not be an option.
- it is cleaner, doing timekeeping math full of time steeping corner 
cases is a mess and ask for always buggy implementations
- it map directly to hadware time-stamping clock and which are not able 
to step and which are already used with TAI epoch by PTP control plane 
opening the opportunity to be able to share the clock and time-stamping  
hardware between PTP and NTP.
- all future stratum 1 NTPv5 servers will have one way ore another the 
TAI-UTC offset available, in the TZ database or given by the GPS clock 
or by any other mean. As long as it is a day 1 requirement, the 
requirement will be fulfilled automatically (GPS, PTP, new methods) or 
manually as a maintenance procedure (update of the TZ database manually 
or by OS updates, update of the leap file )
- all clients and upper stratum ones will no longer have to care about 
how to get the offset, it is there. All arguments for iot/never updated 
clients will be moot. All NTPv5 clients will be self containing.

You will have to do some conversions and adaptations in the OS 
adaptation layer, as today for all NTP implementations, and this layer 
will not be messier as the core is today. No need to wait that operating 
systems fully support a non-leaping timescale, or TAI-UTC offset natively.
It will open the opportunity for some of us to do work on the OS 
interfaces and time keeping code to extend it on Linux or BSD to be able 
to discipline the CLOCK_TAI directly for example, and the opportunity to 
have a complete cleaner and better system some days.

As long as the core protocol include the TAI-UTC offset, and 
good/unambiguous leap announcement, I consider TAI-like form of time for 
timestamps a great improvement on all fronts.

But if TAI-UTC offset is envisioned as an extension only, it does not 
work. This extension could be great for NTPv4 but sub-optimal for a new 
v5 specification.

Emmanuel.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 11:24:21 +0100

Magnus Danielson wrote:
> ticks in combination with the leap second flag.

Hm, isn't that a limitation of the system clock, depending on the
operating system?

> It's not a very neat

Right, and if we stick with the timestamps in the scale that is
currently used (as I proposed earlier), the protocol is useful for
applications that want/need both UTC and TAI, as well for UTC-only
applications of which there are zillions.

> the right time, even with leap seconds occurring.

Of course. But the limitation is in the server. Right now, it is
sufficient to have a time source like DCF77. If you enforce using of
TAI, that's not sufficient anymore.

You only need the UTC/TAI offset if your system supports TAI, but there
are many applications where this isn't supported, and where it's not
even a requirement.

> Check your inbox for a separate example.

I've seen it. I know conversion between different time scales can be
done easily *if* all required information is available. I've also
written lots of functions that convert between different time scales.

AFAIK, there's no current OS that doesn't support UTC, but there are
systems that don't support TAI. So why not use the time scale that is
most supported, and support other scales if they are supported/required?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 11:31:07 +0100

> It’s completely acceptable for the WG to mandate certain requirements like “must have RTC”, “RTC must be accurate to <= 16 ppm”, “must have persistent storage for storing […]”, etc.  Look at RFC-11…

Sorry, I disagree here.

There are lots of simple clients that don't have a RTC and simply get
the initial time via NTP.

Having a hard requirement for a battery buffered RTC chip would just
limit the number of scenarios where NTP can be used.

> Such a requirement was that the sysUpTime in MIB2 required a 100Hz (or better) clock.

It's OK that a specific application has such requirement, but I don't
think a protocol like NTP should have it.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 11:36:24 +0100

> That seems like a good argument to NOT include it in the protocol, if it’s already available out-of-band.

If you force using TAI for NTP but don't include the relevant
information in the NTP protocol, this means that you are generally
unable to operate NTP properly unless you always take care and maintain
the additional information.

In the past there was no such requirement, and I think it's a drawback
if you add such a requirement now.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 6 Jan 2021 11:48:48 +0100

> TAI, that's not sufficient anymore.

If you combine it with the leap second info, you can get TAI and
UTC from DCF77.

> AFAIK, there's no current OS that doesn't support UTC.

I would argue that no OS really supports UTC. They support
something like UNIX time, which is not the same as UTC since it
can't represent the leap second.

If the OS has TAI support, you can calculate UTC from it if you have
leap second information. But the OS or libraries don't support UTC,
it's currently up to the application to make UTC from TAI.

Kurt

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 11:50:00 +0100

> The logical corollary to this argument is that because there ARE a lot of servers, it’s not unreasonable to think that there will be a lot of both NTPv4 and NTPv5 servers co-existing in the future,…

So you think it's not necessary to upgrade v4 nodes to v5, as it has
been done from v3 to v4? Simply systems should stick with v4 and only
enhanced system should start using v5?

In this case, wouldn't it be better to start defining a completely new
protocol and e.g. call it "Extended Time Protocol", which can be chosen
instead of NTP? This would be similar to PTP, which you can use instead
of NTP. ;-)

> Which eliminates the need for NTPv5 servers to also speak NTPv4.

If you have a large network with different types of client you will need
to provide NTPv4 and "ETP" (AKA NTPv5) if NTPv5 has requirements that
are not needed and can't be supported by some clients.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 11:58:57 +0100

> If those devices aren’t updated any more, it’s equally possible that they’ll never get an NTPv5 compatible client, either.

And if these clients are part of a huge network, you have to provide a
one server that talks NTPv5 for the cool clients, and another server
that provides NTPv4 for existing IoT and embedded devices?

> That would necessitate an “update” of sorts, which we’ve both agreed isn’t going to happen.

Or you would have to provide (and maintain) an NTP server implementation
that supports both v4 and v5, depending on the version of the request.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 12:11:26 +0100

> If you combine it with the leap second info, you can get TAI and

Of course, I know.

My point is simply to avoid dependencies on other mechanisms if you only
need the current UTC or wallclock time.

This works perfectly fine with the current NTP version.

> can't represent the leap second.

Of course I know that, too.

However, for many applications this is sufficient, and for those with
higher level requirements it can easily be extended if the protocol
provides "UTC-like" time and a *consistent* TAI offset. See my example
in a previous message.

> it's currently up to the application to make UTC from TAI.

Anyway, the current version of the protocol provides what these systems
need, and with the proposed way you can easily satisfy other requirements.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 6 Jan 2021 11:28:37 +0000

Le 06/01/2021 à 11:50, Martin Burnicki a écrit :
>>> On Jan 5, 2021, at 9:09 AM, Martin Burnicki<martin.burnicki=[email-masked]>  wrote:
>>>
The "basically" mean nothing. Is is 100% compatible or not compatible. 
It is NTPv4 or NTPv5. The "not so different" between v3 and v4 was much 
a source of problems than an adoption catalyst.
I even view it in the opposite for a psychological/marketing acceptance 
point of view: being  v4 compatible is so restrictive for v5 that people 
would prefer to stick to v4 as v5 would give nothing more than v4 
(unless being an expert to understand the difference/gain).
Do we want to do a NTPv4 revision or NTPv5 ?
> are not needed and can't be supported by some clients.
But the "can't" is wrong as long as the offset is always transmitted and 
for the "need" argument, the same clients would have stick to 
time/daytime service if it is a real one.
A v5 server could still provide v4 frame and for v4 clients if needed 
but without hw times-stamping support which it would reserve for v5 
clients if it has some actives. But it is implementation and policy details.

Emmanuel.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 6 Jan 2021 11:43:28 +0000

> that supports both v4 and v5, depending on the version of the request.
As the vast majority of today ones which still support v1/v2/v3/v4, 
being based on ntpd,  and v3/v4 for most of the others.

Emmanuel.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 15:18:36 +0100

> The "basically" mean nothing. Is is 100% compatible or not compatible. 

As I tried to explain in earlier messages, you can easily make it fully
compatible and support new features by extensions.

> It is NTPv4 or NTPv5.

In the first place it is NTP. If you think you need to completely
redesign it, just give it a different name.

> The "not so different" between v3 and v4 was much 

I'm working with NTP for a very long time now, and I don't remember any
problem when moving from v3 to v4. Exactly the opposite was true: there
were no problems because the protocol was compatible to a very high
degree, so it was no problem to have a mixed v3/v4 environment an slowly
changeover to v4. And according to my job I've seen *many* different use
cases, both for the client and for the server side.

So which problems exactly do you mean?

> Do we want to do a NTPv4 revision or NTPv5 ?

IMO the protocol should evolve from v4 to v5 in a compatible way.

As I already mentioned before, I've seen real incompatibility problems
when PTPv2 was introduced because even the base packet was incompatible
with v1. Luckily this wasn't a too big problem because PTPv1 wasn't
widespread when v2 was introduced.

> time/daytime service if it is a real one.

Sorry, but you are competing apples to peaches. Do you really suggest
that NTPv4 clients fall back to time/daytime (which, by the way, are
also different protocols than NTP) ?

> clients if it has some actives. But it is implementation and policy details.

I think whether hardware timestamping is supported or not isn't related
to the packet format. Even NTPv4 can use timestamping in the kernel
driver, if the OS supports it.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 15:29:06 +0100

> being based on ntpd,  and v3/v4 for most of the others.

I don't thing NTPv1 and v2 are really supported by current
implementations, maybe except for a v2 version code in the mode 6 packets.

If I remember correctly, NTPv2 wasn't even widespread, but some fields
of the packet were changed in v3. When that happened, NTPv2 wasn't very
widespread, either.

The only thing a v4 server has to do to when it receives a v3 request is
to copy the v3 version code into the reply packet instead of the native
v4 code. That's it.

In a compatible approach you could set up the reply packet as usually,
and only append extension fields with more detailed information if the
protocol version sent by the client is v5.

A possible approach could be that

- a v5 client could send an initial v5 request

- when the server sees v5 it replies with a base packet and one or more
extension fields indicating its features/capabilities

- the client could send further requests with extension fields
requesting for additional information

- a v4 client would simply send and receive a v4 packet without the
extensions

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 6 Jan 2021 15:09:02 +0000

> - a v4 client would simply send and receive a v4 packet without the
Ok we mostly agree.
You advocate for a v5 format which permit to do less implementation work 
in a dual v4/v5 server.
And I prefer a departure from UTC like timestamps which imply a little 
more bit of work on the server side for v4 clients as the base packet 
will not have the same meaning and will contain some "mandatory" extensions.

> driver, if the OS supports it.
Yes but as the common time-stamping hardware only has and support only 
one time-stamping clock and is responsible to put this clock value in 
the outbound packet, format matter.
You could not share the same interface with hardware time-stamping 
between NTPv4 and PTP for this reason unless you are on custom or very 
uncommon hardware.
For the receiving part it does not matter as the timestamp is purely a 
local measure which could be converted to whatever you want.

Emmanuel.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 16:09:50 +0000

I don't think you can do that, but perhaps posting to tlswg@ietf might stir some of the real experts.

One work-around is to define an ALPN that covers both protocols, of course, but that might not scale.

Martin Thomson has this in draft, https://datatracker.ietf.org/doc/draft-thomson-tls-snip/, which might be applicable or give food for thought.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 6 Jan 2021 11:32:02 -0500

> list without polluting the KE protocol.

This isn't pollution at all! Negotiating little bits of information that
define how the session should proceed is exactly what NTS-KE is designed
for, and the reason it includes a large space for defining new record
types, and a critical bit so that you don't have to rely on the other party
understanding the records you send it.

---

From: Martin Burnicki <[email-masked]>
Date: Wed, 6 Jan 2021 17:59:12 +0100

> between NTPv4 and PTP for this reason unless you are on custom or very 

However, timestamping a packet with SO_TIMESTAMP and modifying an
outgoing packet on the fly (PTP Onestep) are still 2 different things.

I know there is no clean and pretty solution to hardware-timestamp
outgoing NTP packets right now, so this could indeed be an option for a
v5 version which can have TAI support anyway.

However, if you want hardware timestamping support for NTP to yield the
level with accuracy you can yield with PTP, the question that comes to
my mind is whether a timestamper in a NIC can recognize and timestamp
NTP packets in the same way as PTP packets, and if PTP-aware switches
that measure the packet delay can also be configured to measure and
provide the delay of NTP packets.

Otherwise you can simply use PTP for such cases, and use NTP for cases
with different requirements.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Watson Ladd <[email-masked]>
Date: Wed, 6 Jan 2021 14:50:15 -0800

On Mon, Jan 4, 2021 at 7:40 PM Philip Prindeville <
[email-masked]> wrote:
<chop>
> It’s as relevant as it’s ever (always) been: the implementations are in
theory to be written “blind” with only the proposed RFC to guide the
developers.  If the RFC isn’t sufficiently clear for at least 3
implementations to converge on a common interpretation, then it’s not
adequately explained.
>
> I’m not talking about TAI being what the kernel uses; I’ve been talking
about the on-the-wire canonical representation of time.
> I replied pointing out that (1) it doesn’t matter what the kernel uses
internally if applications can get whatever time they need through run-time
support (i.e. libraries like libc) and (2) internally the Linux kernel at
least (and I figure most POSIX compliant kernels) are capable of
maintaining multiple timescales.  As long as whatever the clock runs in
natively can be converted unambiguously into any other format, it doesn’t
matter which is used.

Unfortunately that is not the cas: the usual time functions return Unix
time, which loses information compared to UTC, and therefore cannot be
translated into TAI.  ntp_adjtime seems to be the best candidate from a
portability perspective but may only be callable by privileged processes
even when trying to read the current time. It also can't be used when
software or hardware timestamping of packets is being used since the
structure that is returned from those functions is a timespec, which
doesn't have a leap second indicator.

When discussing hardware the situation is somewhat better as network cards
use PTP which distributes TAI, and some have support for stamping with it.

The other problem is that in kernel steering can introduce stability issues
compared to userspace steering as Miroslav demonstrated for us some time
ago.

Sincerely,
Watson Ladd

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 6 Jan 2021 17:27:52 -0700

> On Jan 6, 2021, at 3:31 AM, Martin Burnicki <[email-masked]> wrote:
> 

SNMP isn’t an application either.

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 6 Jan 2021 17:31:15 -0700

> On Jan 6, 2021, at 3:36 AM, Martin Burnicki <[email-masked]> wrote:
> 

That’s a non sequitur.  It can be a requirement of NTPv5 that the host environment includes a leaping database, daylight time calendars, etc. to put canonical time into both UTC and local time...

> if you add such a requirement now.

Like I said, it’s an effort to remove inherited encumbrances from NTP that never should have been there:  if we add any complexity at all, it should be to its core requirements (like security).

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Wed, 6 Jan 2021 22:58:04 -0700

> On Jan 5, 2021, at 6:34 AM, Magnus Danielson <[email-masked]> wrote:
> 
> Philip,
> 

“Related to each other” isn’t “inter-dependent”, “intertwined”, etc. They just happen to be about the same topic.

“The time-service requires us to achieve certain things.” Again, that’s a vagary.  What “things” does “it require”?

I think NTPv5 at is core is a secure clock synchronization protocol.  Period.

Calendaring (converting groups of seconds into larger human-readable units) is an orthogonal issue.  “Related” only in that it also deals with “time”, but the similarity ends there.

The whole point of the “layering” model is explicitly to decouple one layers’ knowledge of or understanding of what happens in other layers to a minimum.  Saying they should be intermingled just because they deal with a commonality is NOT layering.

[snip]

> plan an then eat small chunks at a time. Then again, discussing elephant

Not any more off-topic than bikesheds.  Both are metaphors about how progress is made (or not made).

> on the side, we covered that separately.

Sorry, no idea what “djungle time” is.

> However, it becomes messy to

Things using “Internet protocols” are not The Internet, or the purview of the IETF, any more than a 9V alkaline battery is the concern of my local electric power company.

The IETF normally goes out of its way to avoid non-Internet connected scenarios, the obvious except being RFC-1918, and there only to specifically call out that a chunk of Internet number-space was being carved out of the Internet and divorced from it.

> my humble experience, it's well worth the effort and exercise.

And thinking about a service operating without working DNS, operating in the case of a partial network partition, etc. is reasonable.

Designing for an isolated Intranet is out-of-scope.

> keep mocking with me all the time.

I’m not mocking anyone.  Telnet options are a reasonable parallel to NTP extension fields, and we can learn from its success.

> You end up sounding very disgraceful,
> and I do not think you intended to.

You might be reading too much into what I’m writing.

> However, the way you try to put
> result.

I think that being a minimalist and an adherent to KISS is a perfectly valid position to have; and you’re stating that my advocating for simplicity will eventually lead to greater complexity without substantiating that.

> in more or less hidden applications, while built on the same technology.

Again, that someone uses Internet protocols somewhere that’s not the Internet isn’t really our problem, any more than it’s the fault of a Pharma company when their drugs aren’t used as prescribed… or someone using the grip of a loaded pistol as a nutcracker and then being surprised when it discharges into their ceiling.

The fact that you’re describing it as “hidden applications” tells you everything you need to know: that whether it works or doesn’t the result (as perceived by us) is the same.  Both are “hidden”.

> deepening the divide there is.

What the IETF does is already succeeding on tens of billions of devices.

That doesn’t seem like a “cherry-pick” nor an insignificant accomplishment.

Its success is NOT, however, a reason for it to exceed its mandate.

What we “want to do” is efficiently and in a timely fashion satisfy our charter.  Spending more time worrying about things outside of our charter defeats both of these goals.

> Rather, if one can look at other

Wait… so I draw a parallel to Telnet options or MIME mail, and that’s a mockery, but…

In the case of the IETF, they ignored the Ethernet v2 (DIX) standard and came up with IEEE 802.3 SNAP… which no one uses.

> base scenario.

Saying “let’s design an Internet protocol that works not-on-the-Internet" is an overboard generalization.

We’re not even talking about an Internet with reduced connectivity (a network partition or asymmetrical paths), or service outages such as no operable DNS… we’re talking about "off the Internet” (i.e. an isolated Intranet).

> It's a little more than the minimum, minimum, but maybe

ARP was a layer 2 mechanism.  The Internet starts at layer 3.  I fail to see any equivalence here.

> parts, then the message is overly simple and not useful.

You’re conflating “convenient” or “expedient” with “necessary”.

> I can reduce

No, I’m well aware that there are contradictions in some of the things that you say, like “let’s intertwine unrelated things in the interest of preserving ‘layering’”.

-Philip

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 08:33:00 +0100

>>> Daniel Franke <[email-masked]> schrieb am 05.01.2021 um 17:30 in
Nachricht
> doesn't have to be a concern.

Or like IPv4 to IPv6 ("think big"): 64 bit for the second and 64 bits for the
fractional part. That should be enough.

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 7 Jan 2021 00:43:00 -0700

> On Jan 6, 2021, at 3:50 AM, Martin Burnicki <[email-masked]> wrote:
> 

No, where did I say that?

I’m saying that as part of the upgrade process, they can be re-configured to use different servers.  That’s hardly a rare occurrence.

> instead of NTP? This would be similar to PTP, which you can use instead

Except we’re not a parallel track, we’re the next stepping stone on a migration path.

> are not needed and can't be supported by some clients.

Sorry, something isn’t parsing…  If they’re not needed then are they really requirements?  Aren’t requirements “needed” by definition?

But if they’re not really needed after all and the clients don’t support them anyway, isn’t that a non-issue?

I’m not following…

-Philip

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 7 Jan 2021 00:49:58 -0700

> On Jan 6, 2021, at 3:58 AM, Martin Burnicki <[email-masked]> wrote:
> 

Yup.  Just like I remember running “nameserver” (IEN-116) protocol for some IPv4 hosts that didn’t understand DNS, and Bind for others that did… even though both provided name-to-address mapping.  Of course that was 35 years ago…

I also remember running proxy-ARP for hosts that didn’t understand classless subnetting (RFC-1519), etc.

> that supports both v4 and v5, depending on the version of the request.

Yeah… except that I want to shed legacy encumbrances… Like leap-seconds, which really have nothing to do with clock synchronization.

-Philip

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:03:22 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 05.01.2021
um
20:56 in Nachricht
<[email-masked]>:

> Calendaring is an orthogonal issue of breaking groups of seconds into 
> human-friendly units of minutes, hours, days, years, etc.
> 
> NTPv4 tried to resolve both issues because it seemed convenient at the time:

> in retrospect, it’s not clear that it didn’t create more problems.
> 
> I say that we drop the unnecessary encumbrances, and shift attention to the

> necessities that have since emerged that NTPv4 didn’t address (like clarity,

> good security, better extensibility, etc).

But don't forget: Even if NTP is able to keep perfect time within it's
processes, it's of little use if the operating systems have no access to that
"perfect time".
And AFAIK "struct timespec" is the best UNIX-like operating systems have; I'm
unsure about the MS-Windows world. So we need a solution to fill the gaps
between NTP and OS.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:07:44 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 05.01.2021
um
21:11 in Nachricht
<[email-masked]>:

> I think that many protocols embed human-readable time notation 
> unnecessarily.  Take the syslog protocol.  Is there a reason why it couldn’t

> just have used TAI time in seconds and milliseconds (or microseconds), and 
> left it to some browser to do the rendering or “presentation” into a 
> human-preferred format?
> 
> Take video security cameras.  Do they need to know that a particular 
> timestamp corresponds to a minute/day/month/year/leap-second?  I don’t think

> so.  I think the browser there, too, could do the conversion.
> 
> Has anyone ever tried to run a “make” on a large code base just as a second

> leaped?  It’s a mess.  A lot of things get rebuilt unnecessarily.  And
that’s 
> with forward leaps.  If we ever need to shorten a day, I can’t begin to
image 
> how badly things will break.
> 
> This wouldn’t happen if we let machines deal with a representation of time 
> that’s optimal for them (i.e. simple and unambiguous) and held off on 
> conversion to human-readable format until it was actually necessary.
> 
> As a postmaster for 30 odd years, I’ve had to struggle with Received: lines

> having local dates and times that require me to pay attention to the UTC 
> offsets to be aware of when DST took place (if it took place at all) for
each 
> timezone that a server lived in as it handled a message.  It’s a mess.  
> RFC-822 should have mandated UT or Zulu time (as that was the best we had at

> the time).
> 
> Or having logs sent to me, or logging into remote machines, and having to 
> know the timezone of the provenance of those logs, then doing the math in my

> head to match that up with other events elsewhere.
> 
> Conversion to something that’s convenient for humans should be deferred 
> until absolutely necessary (and it may never be!).

Yes, it's quite easy to talk about the mistakes made in the past. Maybe it was
the KISS principle.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:16:53 +0100

>>> Philip Prindeville <[email-masked]> schrieb am 06.01.2021
um
04:59 in Nachricht
<[email-masked]>:

> This will be a weakness in time, plus it introduces circular dependencies 
> since DNS records are themselves timestamped for expiration (TTL’s), though

> that’s an offset from now and not an absolute time…
> 
> We already bloat DNS with too much, such as RSA keys and SPF… we’re 
> attempting to use it as a distributed clearinghouse database, which it was 
> never meant to be.

But compared to LDAP it's still "light-weight".

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:23:08 +0100

>>> FUSTE Emmanuel <[email-masked]> schrieb am 06.01.2021 um
12:43
> being based on ntpd,  and v3/v4 for most of the others.

My initial feeling is that a NTPv5 server should respond to v3 and v4
requests. If networks really have v2 clients or older, they'd need some
"gateway" to translate the time.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 07 Jan 2021 09:29:45 +0100

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
06.01.2021 um 15:18 in Nachricht
<[email-masked]>:
>>>>> On Jan 5, 2021, at 9:09 AM, Martin 
> Burnicki<martin.burnicki=[email-masked]>  wrote:
>>>>>

I still think the v4 extension field mechanism was a big mistake and the
mechanism should be redone for a clean design.
So v4 should remain v4 and v5 should be something better.

> redesign it, just give it a different name.

Do you see "NTP" as "packets" only? I think "packets" can be changed easily;
they are just the representation of information, not the information itself.

>>>> The logical corollary to this argument is that because there ARE a lot of

> servers, it’s not unreasonable to think that there will be a lot of both 
> NTPv4 and NTPv5 servers co-existing in the future, and the user is free to 
> peer with either.

---

From: Hal Murray <[email-masked]>
Date: Thu, 07 Jan 2021 01:13:30 -0800

> "gateway" to translate the time. 

Requests arriving at a pool server:
    136711  0.221% NTPv1
     10626  0.017% NTPv2
  16845809 27.269% NTPv3
  44782460 72.492% NTPv4
         3  0.000% NTPv6 - length 48
         1  0.000% NTPv6 - length 68

---

From: Paul Gear <[email-masked]>
Date: Thu, 7 Jan 2021 19:17:06 +1000

> to copy the v3 version code into the reply packet instead of the native

I just took a sample 10 Mb of traffic to one of my pool servers.

Total packets: 82092

v1 packets: 1240 (1.5%)
v2 packets: 10 (0%)
v3 packets: 18530 (22.6%)
v4 packets: 62312 (75.9%)

The server (ntpd 4.2.8p12+dfsg-4) responds to all of them with the same
version number as the source.

Regards,
Paul

---

From: Paul Gear <[email-masked]>
Date: Thu, 7 Jan 2021 19:44:18 +1000

>          1  0.000% NTPv6 - length 68

Interesting - I checked for other versions when I did my sample and
didn't see anything other than v 1-4.  Maybe if I had run it for a
couple of orders of magnitude longer... :-)

Paul

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Jan 2021 12:25:06 +0100

> handles UTC and especially as a leap-second occur without hickup.

PTP has the arbitrary timescale, which is typically used for a UTC
transfer when serving time from an OS clock (as opposed to a hardware
clock). It also has a leap announcement bit. That's all what is
needed to synchronize two UTC clocks without knowing the TAI-UTC
offset. It can work exactly the same as NTPv4.

> which shape it will take.

If the transmit timestamp in the NTPv5 packet is at the same location
as in NTPv4 and has the same meaning, as it is in my proposal, the
same hardware can be used for timestamping NTPv4 and NTPv5 packets.
It doesn't need to know anything about the packet itself, just that it
is supposed to put the timestamp there.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Jan 2021 12:52:26 +0100

On Wed, Jan 06, 2021 at 09:57:56AM +0000, FUSTE Emmanuel wrote:
> part of the core protocol frame.

That offset is not always available, e.g. with a DCF77 refclock.
Relying on other sources is not always acceptable.

> systems fully support a non-leaping timescale, or TAI-UTC offset natively.

No, it will be messier. That's the other problem.

If your OS doesn't have a TAI clock or it doesn't support timestamping
with the TAI clock, you will have to resolve the ambiguity in your NTP
implementation. That will not be 100% reliable as you cannot be sure
if the timestamp is captured before or after the leap. You are only
guessing. If the client doesn't know that the server is only guessing,
it may get unexpected errors in measurements and its clock disrupted.

The best thing you can do on such an OS is to suspend the operation
around leap second, the same thing as when using a leaping timescale.
In other words, there is no advantage of using a non-leaping timescale
for the time transfer. It would only make things even more messier
than they already are.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 7 Jan 2021 15:19:34 +0100

Martin,

> Hm, isn't that a limitation of the system clock, depending on the
It's both. It has affected both the on-wire protocol and how some
operating systems happens to behave. I think we need those as separate
problems. It will be a benefit if we can abondon it from the on-wire
protocol while ensuring we can maintain the mapping over to whatever
operating system mechanism used in a particular machine.
> applications of which there are zillions.

I do not really agree with that. It does come with a burden that is
actually being challenged if we want to keep bearing as it makes many
parts of the core processing more complex, as is adaptation processing.
There is a will to simplify, and if you want to simplify you can do
that, but then one has to face some tough decisions. Personally, I think
those steps are worth taking, and I think there can be good ways to
mitigate many of the concerns, but I do understand that it can be hard
to take in all the various aspects.

> are many applications where this isn't supported, and where it's not

Actually, your logic is NTPv4 centric. Now, I tried to make very clear
it would push requirements onto servers if you would take the suggested
path. I'm not going to hide that, rather, I want people to understand
that this would be the logical consequence. However, once that is taken,
the other parts would become much easier.

If you attempt to go the other route, in which you have a proliferation
of how many time-scales servers can support, you then push out to
intermediary and clients nodes to handle the hurdles. There are many
part of the algorithms we are used to use that will become complex, or
you would have to push to the users only to choose servers with
compatible time-scales, which would be even worse as it would deepen the
division we already seeing.

> written lots of functions that convert between different time scales.
Yes, I know you know that field very well. I just wanted to be explicit
so we where agreeing what we where talking about.
> most supported, and support other scales if they are supported/required?

Exactly what do you mean with "support UTC"? Does all OSes you know
support time as 23:59:60Z? If they don't, they do not fall into "support
UTC" in my book. Some do support mechanisms that enables user layer to
print 23:59:60Z, but far from all. Those that does just renumber UTC
leap second to either 23:59:59 or 00:00:00 with no other indication does
not support UTC in my book.

Keeping a "full UTC" support core time-scale in NTP can be done, but it
comes at a cost.

Cheers,
Magnus

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 16:27:56 +0100

>> On Jan 6, 2021, at 3:50 AM, Martin Burnicki <[email-masked]> wrote:
[...]
> But if they’re not really needed after all and the clients don’t support them anyway, isn’t that a non-issue?

What I meant is that TAI support is a requirement for NTPv5 (or whatever
you call it), even if the involved systems don't need or even dsupport this.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 16:35:22 +0100

[...]
> So v4 should remain v4 and v5 should be something better.

For the original extension fields, I agree. What I meant are the new
extensions fields that have been defined in the recent past.

> they are just the representation of information, not the information itself.

Of course, not.

However, the basic packet is what provides the basic information that is
available to the algorithms that exchange the packets.

Since most systems use UTC or local time derived from it, that is IMO
what should be in the base packet.

If systems support or even need TAI, you can provide the necessary
information in an extension field. Similar with authentication like NTS.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 16:53:23 +0100

>          1  0.000% NTPv6 - length 68

The v3 spec is from 1992 and was current when I first heard about NTP at
that time. In fact I've never seen a piece of software according to the
real specs for v1 or v2.

I think the at least the v1 and maybe the v2 packets just originate from
dump implementations that send and expect the standard v3/v4 packet but
put a wrong version code into the request.

Over the years I've seen several reports about such clients.

I don't know which request exactly have been counted, but v2 requests
can also be mode 6 packets sent by clients when trying to find out
details about the server.

I wonder if the v6 packets are real clients, or just someone who is
trying to find out if and what a server responds when it receives such a
request.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 16:55:32 +0100

> for the time transfer. It would only make things even more messier

Once more, I strongly agree.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 7 Jan 2021 17:20:22 +0100

> to take in all the various aspects.

My opinion is that if you simplify here, you just shift the problem
elsewhere, and you probably get even more problems if you have to care
about that.

> Actually, your logic is NTPv4 centric.

No, my logic is based on the application and usability, for systems with
high requirements as well as for simply systems, of which there are lots.

> Now, I tried to make very clear

At the server side, if you want or need to provide time synchronization
for TAI-based systems and for systems that don't need/use it, in any
case you have to take care to get a timestamp and TAI/UTC offset
*consistently*.

The only question is whether you put TAI into the base packet and apply
the offset to yield UTC, or vice versa, where IMO the latter is much
more appropriate for simple systems.

> not support UTC in my book.

OK, then let us call it POSIX time. We all know that you'll never see a
second 60 in the kernel clock because it only counts binary seconds anyway.

A huge part of the whole problem is that an inserted leap second is
originally defined as a numbering of seconds like 58, 59, 60, 0 in
human-readable format, which is totally unsuitable for timekeeping in an
OS kernel.

However, you can convert this properly from the binary format to a
second "60" on a display *if* you have some associated status
information available with the timestamps, *and* the conversion routines
in the runtime library evaluate that status.

For example, the API calls for Meinberg PCI cards return seconds in
POSIX format *and* an associated status that tells you the current
timestamps *is* part of the leap second.

If that status information is not available, you just pulsh the problem
to a different location, but you don't solve it.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 7 Jan 2021 12:06:48 -0700

> On Jan 7, 2021, at 8:35 AM, Martin Burnicki <martin.burnicki=[email-masked]> wrote:
> 

Protocols shouldn’t concern themselves with what “most systems” use.

Are we going to change from big-endian to little-endian when the majority of systems use that?

Or are we continue to say that “we have a canonical format, that is convertible to/from little-endian, and even PDP-endian”?

In the case of network byte order, either one would have been fine and we could have used a coin-toss.

But in the case of timescale, we should go with whatever is the most universally (losslessly) convertible.

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 8 Jan 2021 02:38:38 +0100

Martin,

> elsewhere, and you probably get even more problems if you have to care

But that is the whole point of the exercise! For sure the issue do not
disappear, but the hope is that it can move into a corner where it makes
less harm.

> high requirements as well as for simply systems, of which there are lots.
How then is leap-seconds handled, easily. I fail to see that being done
easily.
> more appropriate for simple systems.

Except that when you do your core processing, you need that to handle
the occurrence of leap-seconds in all it's processing. If you use a
TAI-like time-base in the core. There is a whole line of checks and
balances in that core which just never add to their complexity... in a
simple system. It's this which is the actual point of achieving that.
But then that will come at a cost. It will have the side-consequence of
servers needing to know what to do. Simple clients will shift some of
their complexity from core processing to the output adaptations, sure.
It is only by looking at all those checks and balances we can make the
informed decision.

> second 60 in the kernel clock because it only counts binary seconds anyway.
POSIX time is one such time, yes.
> human-readable format, which is totally unsuitable for timekeeping in an
Agree.
> in the runtime library evaluate that status.
Completely agree.
> timestamps *is* part of the leap second.
Which is just what a well designed interface do, and I am not surprised
you did it well, rather I expect it without checking the details.
> to a different location, but you don't solve it.

Which is part of the problem that needs to be solved one way or another.
I am very aware of these problems.

Now, the trouble is that people confuse POSIX time_t to represent UTC
and think that any POSIX time_t like system will do UTC on it's own, and
that does not work out if you do not one way or another have that extra
information. Also, you need to have heads-up. Different systems enables
or requires (max and min time) pre-information about pending
leap-second. Some limited have ability to indicate without heads-up. So,
if you now needs heads-up, and previous NTPv4 had 1 day heads-up, for
NTPv5 we seem to opt for allowing more, you need to know that the
TAI-UTC number is to shift. For NTP on wire protocol we have to recall,
the leap-second can occur between a pair of packets, so we need to know
in advance. So, if you need to know of the shift, you have almost the
same problem as knowing which TAI-UTC you have and when that will step.

The whole problem of leap-second handling to support UTC thus require
heads-up already at the server, and for all the intermediary nodes all
the way to the client, so that the client can do the right thing for
it's kernel and user process when the leap second do occur. There is no
way around that part.

If you say that only non-leapsecond time-scales is supported, you can do
much simpler things. Then again, you have ended up ruling out the proper
UTC support. So either we make these properties split fully, or we fuse
them together in such way we agree it will be the simplest and most
robust way, and then certain UTC specific consequences will end up
defining a number of properties.

Then, there is a strong wish to keep the core time-processing as clean
as possible, and the properties of a TAI-like timestamp format is
attractive. That will create challenges for servers and clients.

However, making all servers provide compatible time has additional
advantages as one wants to entertain the capability of combining
responses from servers. Now, traditionally that have not been an issue.
However, we see servers doing UT1 and others doing smeared leap-seconds
in parallel with thus providing UTC based time (more or less good,
depending on implementation, driver etc). In fact, people wish there to
be a more open bag of time-scales. That will end up driving further
division rather than improving strength.

So, we either have to take favorite topics of the table, or find a way
to fuse them into a system that achieves all he goals, and with the wish
list I have seen, using TAI-like base and provide mappings in and out is
the only one I can forsee to be fruitful, and even that will come with
it's costs, where the servers will hurt most, but I am greatly
considering that being worth the cost. Yes, a simple client will need to
do a little more to convert time, but that will be the small pain
compared to the server side, which I still consider worth having.

Cheers,
Magnus

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 08 Jan 2021 08:31:55 +0100

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
07.01.2021 um 16:55 in Nachricht
>> around leap second, the same thing as when using a leaping timescale.

Does "around the leap second" mean "until leap smear is complete" in case of
leap smearing?

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 08 Jan 2021 08:38:08 +0100

>>> Martin Burnicki <martin.burnicki=[email-masked]> schrieb am
07.01.2021 um 17:20 in Nachricht
<[email-masked]>:
...
...

Even for a traditional "three-hands analog clock" (hour, minute, second) second "60" is quite a challenge ;-)

Regards,
Ulrich

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 8 Jan 2021 14:04:13 +0100

Miroslav.

> offset. It can work exactly the same as NTPv4.

OK, I can accept that considering heads-up is provided as needed per
IEEE1588 and that the UTC to time-stamp mapping is found that details
how UTC 23:59:60 is time-stamped and progressed. How will be know the
actual UTC read-out from such as setup?

The leap second announcement needs to be at least two announce messages
before, so you need to have heads up information about the upcoming
leap-second. With this, you are in the heads-up part of solution space
already for servers, which is similar enough to knowing coming and
current leap-second difference (a leap-second file achieves the
difference, and update of that or through leap-second indications).

So, in the end I am not very convinced.

> is supposed to put the timestamp there.
Now, others have already raised that they want a TAI-like time-stamp
format. The reason is that the POSIX-like properties makes core
algorithms a bit more complex. It's not aiding to make a simple client
being simple.

Cheers,
Magnus

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 15:52:59 +0100

Magnus,

> disappear, but the hope is that it can move into a corner where it makes

If you are not involved in the corner where it is shifted then it's fine
for you, but not for those involved in the corner.

For example, look at the specs of the IRIG codes. I'm sure you know that
the most commonly used IRIG codes (e.g. B122) only provided a
day-of-year number and the time of day, but the original IRIG specs
didn't even provide a way for a receiver to find out whether the
transported time was something like UTC, or some local time with an
offset to UTC.

This in why in 1995 the IEEE 1344 standard was released, which used some
"reserved" bits of the B122 format to provide the time code receivers
with some useful information, e.g. a 2 digit year number, a local time
offset that could be used to derive UTC from the transported local time,
and even some flags like a DST indicator and a leap second warning.

This extension was (and still is) very useful if you do synchronization
using these time codes. However, 10 year later, when IEEE 1344 was well
established and known, the specs were revised, and some folks meant that
the way the time offset is to be applied to convert local time to UTC
had to be reverted because in other (unrelated) scenarios this would
also have to be subtracted instead of being added (or vice versa, but
that doesn't matter here).

Anyway, the revised standard was called C37.118 according to the new
IEEE naming scheme, the information transported in the code were the
same as before, plus some more details, but the way the *existing*
information had to be handled exactly the other way round.

Even worse, some manufacturer adopted C37.118 but still called it "1344
extensions", which resulted in a huge mess.

But guess who had to take care about customers and other users, explain
to them why "1344" suddenly worked differently than before, and how they
could solve their problems?

It was *not* the guys who had written and changed the specs. It was the
guys that provide devices and services who had to provide support for
these "corner cases".

I really wouldn't appreciate if this was repeated with NTP, where just
another version works completely different than earlier versions, and
manufacturers and service provider have to take care and teach the users.

As I said before, if you want to make such basic changes to protocol
that has been long existed and is known to use UTC time stamps, you
should give a very different name to the beast.

> How then is leap-seconds handled, easily. I fail to see that being done

As has been pointed out before, you only shift the problem elsewhere but
don't solve it by using TAI.

Even if you do all the computation in TAI, and adjust the TAI system
clock, which benefit has an application that needs time based on UTC?

How is the kernel improved by this so that applications don't see a time
step back in CLOCK_REALTIME when a leap second is inserted?

> the occurrence of leap-seconds in all it's processing.

Maybe, but it shouldn't be too hard if you have consistent time stamps,
and it also works like before on systems that don't support TAI.

> If you use a
> TAI-UTC number is to shift.

The question how long in advance to announce a leap second has also been
discussed zillion times.

Some folks tend to accept a leap second only at the end of June or
December, which is current practice from IERS. Have you seen the new
bulletin C 61, which has just recently been published? This triese to
avoid accepting "false alarms" e.g. as we have seen from broken GPS
receivers at the end of September.

Then other folks say that a leap second had to be accepted at the end of
*any* month, because this could happen in theory, and in worst case.

Also you want to pass the leap second warning down to a chain of clients
as soon as possible. On the other hand, a Linux kernel must not receive
it more than 24 hours in advance, so even if you implement the
transmission in the protocol in a more sophisticated way,
implementations have to take care how to evaluate this.

> For NTP on wire protocol we have to recall,
> in advance.

You *do* know in advance, if the server has the information available
early enough.

> So, if you need to know of the shift, you have almost the

Again, in most cases where the OS supports leap seconds, the algorithm
just passes the warning down to the kernel, and as long as the OSs are
not fixed / improved, the problems seen by *applications* that use the
system time are the same, regardless whether the on-wire protocoluses
TAI or UTC-like POSIX.

> it's kernel and user process when the leap second do occur. There is no

Agreed, but this already works pretty well in NTPv4. If at the top of
the chain a wrong leap second announcement is inserted, you have a
problem. If at the system clock level the leap second is handled in a
strange way, you also have a problem, though a different one.

None of these can be solved by just using TAI timestamps on the wire.

> attractive. That will create challenges for servers and clients.

That's perfectly fine with me, but IMO it shouldn't be called NTP then.
For example, if you called it ETP, you could say:

"Unlike NTP, which assumes UTC timestamps, the ETP protocol works with
TAI, just similar to PTP."

That would avoid a huge amount of confusion.

> responses from servers.

Of course, if you can determine UTC/POSIX or TAI from the server
response, everything is fine, regardless whether you can consistently
derive UTC from TAI, or vice versa. ;-)

In a previous email I gave an example how you can consistently derive
TAI from UTC, if you need TAI.

> Now, traditionally that have not been an issue.

Hm, I disagree here. If you can properly determine determine UTC and TAI
from the core protocol and algorithms, there should be no problem to
support other time scales for special cases as well e.g. by using
associated extension fields.

> compared to the server side, which I still consider worth having.

And what about simple servers that don't support TAI, or don't have a
source for the TAI/UTC offset?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:06:02 +0100

> Does "around the leap second" mean "until leap smear is complete" in case of

ntpd from ntp.org as a server returns "not synchronized" to clients from
one second before until one second after the leap second.

If a client with a 64 s or even longer poll interval happens to send a
request during this short moment, it receives a single response that it
just discards, and the next packet exchange works well again with the
"new" UTC timestamps after the leap second.

This usually doesn't hurt the client, and avoids that the client sees a
sudden huge 1 s offset if the leap second occurs in the middle of a
packet exchange.

This has been proposed by Miroslav some time ago and works very well.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Doug Arnold <[email-masked]>
Date: Fri, 8 Jan 2021 15:17:40 +0000

I think that the point of a leap smear is that no special handling of leap seconds is needed by the client.  It is introduced gradually over a number of polling periods.

Doug

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:19:18 +0100

>> offset. It can work exactly the same as NTPv4.

Yes, but the arbitrary timescale is only *typically* used for a UTC, it
can also mean something else. So PTP isn't distinct in this case, either.

> leap-second.

If I remember correctly, the leap second warning is sent by the
grandmaster 12 hours in advance, *if* the information is available.

If there's a faulty leap second warning from the time source, the
grandmaster has the same problem as an NTP server that has received a
faulty warning.

And if the PTP slave passes the leap second warning to a Linux kernel so
that the Linux kernel can update its CLOCK_REALTIME at the right opint
in time, applications that are based on UTC/local time will encounter
exactly the same problem as with NTP.

So from this point of view (the use case for applications), there's not
much advantage on using TAI timestamps for the protocol.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:22:28 +0100

> I think that the point of a leap smear is that no special handling of leap seconds is needed by the client.  It is introduced gradually over a number of polling periods.

That's exactly the point. You want to hide the leap second from the
client to avoid that *applications* run into problems when the kernel
just steps the time back by 1 second.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Doug Arnold <[email-masked]>
Date: Fri, 8 Jan 2021 15:27:20 +0000

When I first heard of leap seconds I thought it was a terrible idea, a clumsy hack.  Since then I've come to understand that database and other application programmers are not timing people and often don't handle the possibility of leap seconds, or don't handle it correctly.  I believe that Google and other large data center companies have figured out that it causes less problems to mess up the time for a while than to have leap seconds.

Doug

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

    Martin
    -- 
    Martin Burnicki

    Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:28:26 +0100

> Protocols shouldn’t concern themselves with what “most systems” use.

Maybe not, but at least they should have the final use cases in mind.

> Are we going to change from big-endian to little-endian when the majority of systems use that?

That would cause similar confusion as starting to change the scale of
the time stamps. ;-)

> But in the case of timescale, we should go with whatever is the most universally (losslessly) convertible.

Maybe, but why have to call it NTP if such basic things are changed?

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Warner Losh <[email-masked]>
Date: Fri, 8 Jan 2021 08:30:43 -0700

On Fri, Jan 8, 2021, 8:22 AM Martin Burnicki <martin.burnicki=
[email-masked]> wrote:

> Doug Arnold wrote:
> > I think that the point of a leap smear is that no special handling of
> leap seconds is needed by the client.  It is introduced gradually over a
> number of polling periods.
>

My fundamental position on leap seconds hasn't changed in 20 years: they
are evil and must die. Earth clocks and atomic clocks need a different way
to synchronize. Leap seconds generate dozens of edge cases, operational
difficulties and data dependencies that complicate time for everyone and
all that added complication has a cost that far exceeds the benefit.

Smearing is the latest way to paper over all this and keep applications
naive. I'm not sure if I view it as a brilliant hack to protect the
applications from a rushed standard we are stuck with, or a deeply worrying
"enabling" of bad behavior by applications, libraries and operating
systems.

Warner

Martin

---

From: Doug Arnold <[email-masked]>
Date: Fri, 8 Jan 2021 15:35:14 +0000

Well said.

From: Warner Losh <[email-masked]>
Date: Friday, January 8, 2021 at 10:30 AM
To: Martin Burnicki <martin.burnicki=[email-masked]>
Cc: Doug Arnold <[email-masked]>, Ulrich Windl <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ntp] Antw: [EXT] Re: CLOCK_TAI (was NTPv5: big picture)

On Fri, Jan 8, 2021, 8:22 AM Martin Burnicki <martin.burnicki=[email-masked]<mailto:[email-masked]>> wrote:

My fundamental position on leap seconds hasn't changed in 20 years: they are evil and must die. Earth clocks and atomic clocks need a different way to synchronize. Leap seconds generate dozens of edge cases, operational difficulties and data dependencies that complicate time for everyone and all that added complication has a cost that far exceeds the benefit.

Smearing is the latest way to paper over all this and keep applications naive. I'm not sure if I view it as a brilliant hack to protect the applications from a rushed standard we are stuck with, or a deeply worrying "enabling" of bad behavior by applications, libraries and operating systems.

Warner

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/

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

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:41:42 +0100

> When I first heard of leap seconds I thought it was a terrible idea, a clumsy hack.  Since then I've come to understand that database and other application programmers are not timing people and oft…

With the systems (and specifically the *applications*) we have now, you
have 2 different choices when a leap second is inserted:

a) Let the kernel step the time back by 1 s, so applications may observe
duplicate time stamps. This can only be avoided if each application that
is possibly affected is aware of leap seconds, e.g. on Linux systems it
could periodically query the kernel if a leap second has been announced,
and then try to handle it properly.

The advantage of this approach is that the system time can be very
precise *except* during the leap second.

b) The system time can be smeared around a leap second, in which case an
application doesn't even notice there is a leap second, so there is no
problem with time steps back.

The disadvantage of this approach is that the system time is off by up
to 1 s if you smear the time completely before or after the leap second,
or up to +/- 0.5 s if you do symmetric smearing before and after the
leap second.

If you can accept such a time offset (which is huge, compared to the
normal millisecond offset) depends on the application.

In any case this is a dilemma that can't be fixed by simply using TAI
time stamps instead of UTC time stamps in a protocol.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Fri, 8 Jan 2021 16:47:15 +0100

Warner Losh said:
> On Fri, Jan 8, 2021, 8:22 AM Martin Burnicki
> <martin.burnicki=[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Doug Arnold wrote:
>     > I think that the point of a leap smear is that no special handling
>     of leap seconds is needed by the client.  It is introduced gradually
>     over a number of polling periods.
> 
> are evil and must die. Earth clocks and atomic clocks need a different
> way to synchronize.

Agreed. But as long as there is no decision to abolish them, we have to
live with them, and have the same discussions over and over again. ;-)

> Leap seconds generate dozens of edge cases,
> operational difficulties and data dependencies that complicate time for
> everyone and all that added complication has a cost that far exceeds the
> benefit. 
> 
> applications from a rushed standard we are stuck with, or a deeply
> worrying "enabling" of bad behavior by applications, libraries and
> operating systems. 

The biggest problem I see with smearing in general is to decide if
applications that require millisecond accuracy can tolerate offsets up
to +/- 0.5 or even 1 s in this special case.

Beside this, there are lots of potential problems due to different
shapes and intervals for the smearing.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Doug Arnold <[email-masked]>
Date: Fri, 8 Jan 2021 16:01:15 +0000

I started working on network timing in 1998.  At that time they told me not to worry about leap seconds because they were about to get rid of them in UTC.  I can always tell when someone is new to timing, because they tell me they heard that leap seconds are going away soon.   Unfortunately many technical standards and government regulations specify UTC rather than TAI.  So we definitely have to live them

Doug

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

    Martin
    -- 
    Martin Burnicki

    Senior Software Engineer

---

From: Hal Murray <[email-masked]>
Date: Fri, 08 Jan 2021 08:03:37 -0800

martin.burnicki=[email-masked] said:
> Beside this, there are lots of potential problems due to different shapes and
> intervals for the smearing.

Is that a real problem?  I thought that the big boys had agreed on linear over 
24 hours centered on the leap.

---

From: Steve Allen <[email-masked]>
Date: Fri, 8 Jan 2021 08:57:34 -0800

On Fri 2021-01-08T15:27:20+0000 Doug Arnold hath writ:
> When I first heard of leap seconds I thought it was a terrible idea, a clumsy hack.

So also did every technical member of the committees who consulted on
the change that resulted in leap seconds.  In their technical niches
all of them announced that their systems would not use leap seconds,
but the only official document that hinted about that was CCIR
Recommendation 485, but that was suppressed in 1997 right around when
the effort to abolish leap seconds began.

The problem that led to leap seconds was not technical, it was finding
a time scale which could achieve international agreement for use by
the existing time distribution systems without being explicitly
illegal in any jurisdiction.  This concern was redacted from the
official documents and records and is only visible in memoirs of the
participants.  The same sort of problem cropped up in 2015 when the
ITU tried to abolish leap seconds, and that discussion is also missing
from official documents.

Until there is international agreement that the calendar day is not
determined by observing the earth rotate the best strategy for a time
system is to follow the lead of the original participants and use a
TAI-like time scale as the basis.

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

---

From: Magnus Danielson <[email-masked]>
Date: Fri, 8 Jan 2021 22:42:00 +0100

Martin,

> for you, but not for those involved in the corner.
I had no intention of not caring for that corner. Quite the opposite. I
want the overall system architecture, all the encodings be very explicit
and complete such that all those parts will be clear so that it can be
correctly implemented. It's exactly because of that for which I think
that if we make sure the core timing is easy, without extra checks to
workaround, the resulting output mapping needed can be worth the price,
yet easy and simple enough that even simple implementations can do it
right.
> extensions", which resulted in a huge mess.
For sure a big mess. I know about this line of history. Today we should
consult C37.118.1 and not the older C37.118, but as I recall there is no
difference on the IRIG-encoding between the two.
> could solve their problems?
I hear your pain, for sure.
> should give a very different name to the beast.

We do, we do call it NTPv5. It's also a version number in the header so
that each packet can be treated according to the protocol it says it is.
This is why the version number is in the protocol in the first place.

When one steps the major version of a protocol, in this context this
means that things will be quite different. Look at IPv4 vs IPv6 for
instance. While they service-wise provide similar service, there is a
number of changes. The header is larger, the fields for source and
destination addresses is larger and thus gets shifted positions of
things in the header. Never the less, we have the ability to handle IPv4
and IPv6 in parallel on the same wires and same machines. Sure, there is
bugs, but those resolve itself over times. Similarly there exists other
protocols such as IGMPv1, IGMPv2 and IGMPv3, and today we battle between
having to use IGMPv3 vs IGMPv2, but not because of bugs, but if one
deems the simpler IGMPv2 sufficient feature-wise or one needs to go to
IGMPv3.

So, this concern of yours is indeed very valid, and I do feel your pain,
but we do have methods to handle it.

Now, one can make the comment that someone could make a NTP client that
does not look on the version number, and keep asking and interpret NTPv5
servers as being NTPv4 replies, something which should only occur if
they falsly sent NTP packets marked as NTPv5. If we make incompatible
formats, as some advocate for, these will not work, but also, these will
be considered buggy. The remedy for that would be that such clients is
directed to NTPv4 servers until upgraded to support proper NTPv5
support. I think that is starting to be fairly thin problem, as it would
require pure deception of those clients to start with. I don't see that
we have prohibited a server of serving NTPv4 clients with NTPv4 replies
and NTPv5 clients with NTPv5 replies. If you can show me how that would
work out incorrectly, I really would appreciate the insight.

So, I really feel your pain with regards to IRIG-B, but I think the
lesson do not apply here, as I think we have sufficient means to avoid
the problem just by using the version field. For each version, it must
be extremely clear how to implement things to do it correctly, that I am
very committed to. It needs to be extremely clear in the full documented
model and is part of the protocol specification.

> don't solve it by using TAI.
I never said anything else? Where is this notion coming from that I was
about to run away from that responsibility, no, quite the opposite, it
becomes a responsibility!
> clock, which benefit has an application that needs time based on UTC?
It has been stated multiple times, that the core computations becomes
easier with a time-scale which is linear, because you can now avoid
having to handle the consequences of the timestamps not directly
represent an linear progression of time, but needs augmenting, with
extra checks etc.
> step back in CLOCK_REALTIME when a leap second is inserted?

Actually, the issue of kernel in operating system isn't the same as the
core calculatings I talk about.

The processing hurdles related has really nothing to do with the kernel,
and the end product can be delivered to the kernel processing as needed
without that changing.

> and it also works like before on systems that don't support TAI.

Not being too hard etc. is well, sure, but that moves the complexity
there, and it moves the complexity to a very timing sensitive part, and
also bug-prone part. It is exactly this which drives the wish for a
linear time-scale, thus having TAI-like properties.

Having implemented similar enough stuff, I know there is enough of
hurdles in that core time-processing as it is. Adding UTC support ended
up being relatively cheap. Being able to build full IRIG-B with
C37.118.1 support was a reasonable challenge.

> *any* month, because this could happen in theory, and in worst case.

Actually, reading the ITU-R definition of UTC, which IERS decisions
honours, allow for it at the end of each month but with first preference
on end of UTC June and end of UTC December, second preference on end of
UTC Mars and end of UTC September, and then for any other month.

I have a GPS receiver which take the upcoming leap second indication
flag of the Motorola OEM GPS receiver to indicate upcoming leap second
at the end of current quarter, thus any of first or second preference
choices. If it would have implemented reading out the meta-data in the
GPS announcement, the actual GPS date of the new leap second would be
the one to use, but they didn't do that. Now this may not sound like a
bug, until the fact that GPS Ground Segment operations then insert the
data for upcoming leap second fairly quickly after IERS Bullentin C has
announced one, so typically more than 5 months in advance. Most
receivers will correctly execute this leapsecond into its outgoing UTC
replica, except this reciever as it will schedule if 3 months in advance
because of this bug. The transport format they chose to use did not
allow for how the groundwork system of IERS, GPS specification
(IS-GPS-200), GPS operation worked. It is exactly because of this I try
to advocate for us to have a system which does not build on our own
assumptions of how that is probably going to be used, but rather
understand that we can expect the full dynamics of this and those
operating it expect us users to comply to it because they have shown
clearly how it could potentially be used and want to maintain their
freedom to use the full dynamics to operate as needed to go forward,
thus you can expect assumptions to be broken. This is why you need to be
able to indicate in good time advance, and tell WHEN the event occurs.
When that has been designed such, and respected, it has worked.

Also, if you want to build a receiver that is robust, you can observe
the announcement early, you can observe it from the full set of
satellites you see, for over 5 months before the actual event. You can
store it in non-volatile memory such that a power-cycle or full restart
does not make you to forget it. Naturally, you should be able to whipe
it out if incorrect, and that is also part of the DHS Common framework
for PNT resilience require, at resilience level 1.

> implementations have to take care how to evaluate this.
Of course. Exactly how the Linux kernel implement things right now and
in the future is two different things. Actually, as long as we feel it
reasonable to implement, we don't care.
> You *do* know in advance, if the server has the information available
Yes. That's my point. You need to know in advance. There is interesting
consequences out of that.
> system time are the same, regardless whether the on-wire protocoluses

This is a discussion I feel is very much confused by mistaking "core
calculations" with that of kernel. With "core calculations" I mean the
overall basic processing of time-stamps, accepting packets, producing
the time error and round-trip, conclude how this relates to the steered
clock and then produce steering. That's the core calculations. As you go
over to steer a clock, you may or may not directly hit on what timescale
that the steered clock operates in, and any needed time-scale mappings,
which is a concern being there all the time.

We do not let kernel implementation details control how the on-the-wire
protocol looks, we just must sure they fit with reasonable
implementation burden. Within that reasonable implementation burden is
both the core-calculations and the adaptations.

> None of these can be solved by just using TAI timestamps on the wire.

If people felt it was working "pretty well" in NTPv4, why are they then
very interested in getting a linear time-scale for timestamp, the only
real reason I know of is because it reduces the processing in one part
which is already a bit messy.

Interestingly enough, there is ways to mitigate incorrect leap-second
errors. Using the same basic rule of using at least three servers, you
can do majority voting. You can do that way before the event, as you
have more than 5 months for most servers. Done correctly, you can even
provide heads up that a server is problematic with it's announcement in
good time before, and mitigate that servers knowledge in good time
before the event. The needed check will not be advanced if you want to,
and it can be a standard reporting outlier that you can have months of
time to fix.

> That would avoid a huge amount of confusion.
Again, we do that when we say it's NTPv5.
> TAI from UTC, if you need TAI.
Which is just the same process, in reverse. I've used that one for many
years now.
> associated extension fields.
You confuse the case of there being the timestamp time-scale being
NTPv4, leapsecond-smeared UTC, UT1 etc. from when you have a common core
time-scale and provide mappings to the others. I already advocate for
the later, but you and I disagree on the common core time-scale being
that of NTPv4 or a TAI-based time-scale.
> source for the TAI/UTC offset?

If you go back in the mail-thread, you will find a discussion on how
that can be resolved. There is multiple ways that servers can be
supplied with the TAI-UTC difference such that they can resolve the
issue. The whole point is that if you support UTC, you need to support
leap-seconds, and then you need to have advanced knowledge of them in
order to get correct time, regardless of using NTPv4 or other
core-timescale. You end up already needing to resolve quite a bit of the
problem.

Now, if you is in the realm of doing UTC with leap-seconds as NTP-time,
then you need heads up information. Getting the TAI-UTC difference puts
a bit additional requirements on the server.

If you are in the realm of doing leap-second smeared UTCish as NTP-time,
then you need heads up information at the server.

If you are in the realm of doing TAI-based with TAI-UTC leap seconds as
NTP-time, then you needs heads up information, you need to acquire TAI-UTC.

So, we end up having similar enough requirements on the server side and
the source you derive timing from. Even for a simple server.

I think it is doable either way, but the differences isn't as dramatic
as it may first look. However, as we consider the various systems,
consequences on implementation become different.

Cheers,
Magnus

---

From: James <[email-masked]>
Date: Fri, 8 Jan 2021 23:04:43 +0000

They have, however they take different approaches to the smear:

* Google[1] and Amazon Web Services[2] use a linear smear that runs over
  ~48 hours, starting 24 hours before, and ending 24 hours afterwards
* Bloomberg[3] appears to not apply the leap second (59 -> 00) but then
  smears over the subsequent 2000 seconds.

- J

1: https://developers.google.com/time/smear
2: https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/
3: https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 11 Jan 2021 07:56:01 +0100

>>> Doug Arnold <[email-masked]> schrieb am 08.01.2021 um 16:17
in
Nachricht <[email-masked]>:
> I think that the point of a leap smear is that no special handling of leap 
> seconds is needed by the client.  It is introduced gradually over a number
of 
> polling periods.

But if you have two servers using leap smear, and to servers not using leap
smear, all will claim to return the correct time one second after the leap
event.
With the same logic as claiming UNSYNC during theleap event for non-smearing
servers, smearing servers should return UNSYNC until the time is "correct"
again IMHO.

Regards,
Ulrich

> 
> Doug
> 
> On 1/8/21, 2:32 AM, "ntp on behalf of Ulrich Windl" <[email-masked]
on 
> behalf of [email-masked]> wrote:
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 11 Jan 2021 08:13:33 +0100

>>> Hal Murray <[email-masked]> schrieb am 08.01.2021 um 17:03 in

> 24 hours centered on the leap.

Why not a week before and a week after? I mean there are many arguments for
and against different intervalks.

---

From: Hal Murray <[email-masked]>
Date: Sun, 10 Jan 2021 23:22:08 -0800

> servers, smearing servers should return UNSYNC until the time is "correct"

No.  The whole point of smearing servers is to lie to clients.

if you are using smearing servers you have to be careful to not use any 
non-smearing servers.

If you are using real/correct (non-smearing) servers, you have to make sure 
you don't use any smearing servers.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 11 Jan 2021 08:33:23 +0100

>>> Steve Allen <[email-masked]> schrieb am 08.01.2021 um 17:57 in Nachricht
<[email-masked]>:

...
> TAI‑like time scale as the basis.

I'm afraid that won't happen, as it will create problems on the long term.
You could use TAI, but you still need leap-second information.

> 
> ‑‑
> Steve Allen                    <[email-masked]>              WGS‑84 (GPS)
> UCO/Lick Observatory‑‑ISB 260  Natural Sciences II, Room 165  Lat 
+36.99855
> 1156 High Street               Voice: +1 831 459 3046         Lng
‑122.06015

---

From: Hal Murray <[email-masked]>
Date: Sun, 10 Jan 2021 23:48:08 -0800

> and against different intervalks. 

It has to be long enough and the transition from normal-to-smear gentle enough 
so that ntpd will follow the smearing servers.  As long as the interval is 
long enough, how long doesn't matter.  The big boys agreed on a number.  There 
is no reason to pick a different one.

Some of the early work used cosine rather than linear so the transition was 
smooth.  That complication was unnecessary and dropped.

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 11 Jan 2021 10:47:50 +0100

> 24 hours centered on the leap.

There are not only the big boys, and in the past some of them did it in
different ways.

For example, folks who have their own NTP servers for their internal
network but want the time of their local machines synchronized to cloud
machines provided by the big boys they have to carefully check if and
how the time from the different NTP servers is smeared.

In the past, some big boys have even changed what they think is the best
way of smearing, so if smearing went fine in a mixed environment during
one leapsecond, that doesn't necessarily mean everything will still be
fine when the next leap second occurs.

And unlike the folks on this mailing list, many admins aren't even aware
of the details they'd have to look at.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 11 Jan 2021 10:50:06 +0100

Hal,

> you don't use any smearing servers.

Which is exactly the division of servers and problem to handle them at
client side, as client operation needs to know which servers too choose
from. As you create a wider range of server types, all of a sudden you
create less servers that we can use for any type of operation. This is
why putting this on the server side is unhelpful for the community. If
we have a common NTP core time and then map that out to whatever format
the client need, we can have a common set of of servers, serving a wide
range of clients need together.

Cheers,
Magnus

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 11 Jan 2021 10:58:27 +0100

> smear, all will claim to return the correct time one second after the leap

The general problem is admin have to be very careful when leap second
smearing comes into the game. Specifically in a mixed environment with
time servers that don't smear, and other time servers that smear in a
different way.

> servers, smearing servers should return UNSYNC until the time is "correct"

Sorry, that wouldn't be useful. If NTP servers smear the time, it's not
for the sake of the NTP servers but for the sake of the clients.

If you returned UNSYNC during the smear interval, the clients would stop
accepting the servers and not follow the smearing at all. Instead they
would re-synchronize to the servers and STEP the time after the leap
second, which is exactly what you want to avoid when smearing a leap second.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 11 Jan 2021 11:05:55 +0100

> is no reason to pick a different one.

Right.

On the one hand, it has to be long enough that clients can easily follow
the changing clock frequency from the server, but on the other hand, the
smeared time is off the real current time during the smear interval, so
you want an interval as short as possible.

Finally, the length of the smear interval has to be a compromise.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: Martin Burnicki <[email-masked]>
Date: Mon, 11 Jan 2021 11:27:17 +0100

Magnus,

Magnus Danielson wrote:
> create less servers that we can use for any type of operation.

Once more I disagree. If you want smearing at the client side, client
software could be modified to do this right now.

If the client receives a leap second warning from the server, it could
include apply a smear offset when adjusting the system time, and each
client had to be individually configured if and how to smear its own
system time.

The reason for letting the NTP server send smeared time to its clients
is that you *only* have to configure your server(s) accordingly, and
*all* NTP clients get the same, smeared time.

> This is

Of course you can run into a mess if you use smearing and non-smearing
servers at the same time.

However, admins who have to take care how the clients behave just need
to select a few appropriate servers for their clients instead of having
to check that each client supports smearing at the client side in the
same way. If you have a huge number of different clients, the effort is
probably much higher and more error prone than just having to select a
few servers.

Martin
-- 
Martin Burnicki

Senior Software Engineer

---

From: FUSTE Emmanuel <[email-masked]>
Date: Mon, 11 Jan 2021 10:36:07 +0000

> Finally, the length of the smear interval has to be a compromise.
Why pursuing with a sub-optimal server side implementation ?
We are defining NTPv5. v5 client are to be implemented an deployed. 
There is no install base.
v4 smearing servers where done to cope with a v4 base where no provision 
was made for smearing instead of jumping.

On the client side, you could implement a very very short optimal smear 
interval on top of the main algo.
If this smear "profile" is defined in the v5 spec. All client side 
smearing clients will behave the same, and even the mapping between 
smearing and non smearing clients will be know.
No more lies, no more client following problems, no more smearing/non 
smearing servers. It 's purely a client capability or policy problem and 
should be done on the client side.

Emmanuel.

---

From: Hal Murray <[email-masked]>
Date: Mon, 11 Jan 2021 02:52:45 -0800

Martin Burnicki said:
> The reason for letting the NTP server send smeared time to its clients is
> that you *only* have to configure your server(s) accordingly, and *all* NTP
> clients get the same, smeared time.

Another consideration tangled up in this mess is the availability of client 
software.

If you are a single organization with several NTP servers and many clients running different OSes and/or different versions, it's much simpler to modify the servers.  (Of course you have to make sure that those servers aren't serving any clients who don't want smeared time.)

If the context is something like the pool, it will be much simpler if the servers distribute unsmeared time and the clients turn on the smear-me option.  That assumes the NTP software on the clients gets updated which may not work for people who run old/stable software.  I don't see a simple solution.  My guess is that anybody with that problem will have to continue to run old/smearing NTP servers until their clients are all, eventually, upgraded.

Actually, they don't have to upgrade all the servers, only the ones that have to run over a leap second.  They can turn off the others and turn them back on after the leap.

What's the effective lifetime of long-lifetime distros?  Typical numbers that I see are 5 years.  I think we could live with that.  I think a few entries in a FAQ would explain most of the problems.

But how many sites keep running the old distro, perhaps paying for extended support?

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 11 Jan 2021 12:00:47 +0100

Martin,

> *all* NTP clients get the same, smeared time.
The trouble is not technical, but the consequence of what that leads to.
While I agree that there is technical benefits of doing it on the server
side, I also see downsides with doing it that way. The proliferation of
various server time-scales also leads to higher division of servers into
groups for which most clients cannot use outside of any of those groups.
This leads to problem regardless if it is within a dedicated network or
Internet. The users require to know about the different type and
configure the right set. It also makes it difficult to meet different
requirements on the same machine (and today virtual machines). You might
end up having to divide the server farm depending on which time it uses.
That's the path we already face, and I ask the question if this is the
path we want to maintain? I think it would be unwise.
> probably much higher and more error prone than just having to select a

This is a scalability issue for sure. That's exactly my point. In the
end, the configuration of the clients needs to consider this regardless.
So the question is how we make this work out as we scale up.

In the ideal world, the OS would provide multitude of time-scales and
applications would use the appropriate for their need and the timing
structure supports them all. We are for sure not there yet, but I think
we should consider how we create needed support to get there, at least
if you want.

Cheers,
Magnus

---

From: FUSTE Emmanuel <[email-masked]>
Date: Mon, 11 Jan 2021 11:01:59 +0000

> But how many sites keep running the old distro, perhaps paying for extended support?
Your observation is right, but we are talking about NTPv5 which is today 
implemented and deployed nowhere.
For me it advocate for the "smear-me" client side option only for v5.

Emmanuel.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 16 Jan 2021 11:02:32 -0800

> Then we should consider making NTPv5 require security.

I'd like to see some input from people who operate the pool on what
solutions would work for them. Right now we're sort of flying blind.
Perhaps we can discuss at IETF 110?

--
Astra mortemque praestare gradatim

---

From: James Browning <[email-masked]>
Date: Sat, 16 Jan 2021 14:49:33 -0800

> Perhaps we can discuss at IETF 110?

Only a user of the pool, but I basically see three ways to manage that.
1) Have the pool serve up SRV records and rewrite the pool code, the spec,
and clients to compensate.
2) Have the pool run a common NTS-KE server for all NTS servers in the pool.
3) Convince TLS certificate vendors to sell IP based certificates.
I am not particularly fond of any. Someone should find a fourth way.

----
Removing all doubt.

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 17 Jan 2021 00:35:25 +0100

> and clients to compensate.

I think if we want to do it with DNS, it would require DNSSEC, and
that the client validates DNSSEC.

> 2) Have the pool run a common NTS-KE server for all NTS servers in the pool.

As far as I understand things, that would not be a good idea.

> 3) Convince TLS certificate vendors to sell IP based certificates.

There are CAs that sell this.

> I am not particularly fond of any. Someone should find a fourth way.

Open a TLS connection to ask for servers, get a list of hostnames.

Kurt

---

From: James <[email-masked]>
Date: Sun, 17 Jan 2021 00:57:25 +0100

My aims for NTPv5 would be to remove refid being tightly coupled to IP
addresses, making #3 not necessary as a requirement.

A few other options:
4) NTPv5 pool participants could run their own servers instead of a
common server, with the pool able to describe which are trusted as
they are part of the pool.
5) NTS isn't used, and instead a different approach is used instead. I
have a few very primitive ides on this subject but not enough
knowledge yet to shape them.

- J

- J

On Sat, 16 Jan 2021 at 23:50, James Browning <[email-masked]> wrote:
> 1) Have the pool serve up SRV records and rewrite the pool code, the spec, and clients to compensate.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 16 Jan 2021 16:43:21 -0800

> that the client validates DNSSEC.

I neglected to mention my now expired
https://datatracker.ietf.org/doc/draft-ladd-nts-for-ntp-pool/ as an
example of this approach.
> As far as I understand things, that would not be a good idea.

Agreed. The key management and synchronization in such a system is a pain.

> > 3) Convince TLS certificate vendors to sell IP based certificates.

I have some issues with this rather not fleshed out proposal. Please
feel free to tell me I am completely misunderstanding it.

My first concern is that there is no easy analogue of DCV to perform
in the IP based certificate setting. SNI based shared hosting is the
most problematic case, and dooms the obvious techniques. This makes
for a big barrier to adoption. The second issue is that this does
little to secure the delegation from the pool to the server: an
attacker who legitimately controls an IP address can forge the DNS
response. This can be solved through DNSSEC and dynamically signing
the response, but then option 1 is equally easy.  Plus the pool can
generate names for the IPs for ACME to use.

> Open a TLS connection to ask for servers, get a list of hostnames.

This has some interesting advantages.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 16 Jan 2021 17:13:35 -0800

> that the client validates DNSSEC.

How do you reliably use DNSSEC if you don't know what time it is?

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Hal Murray <[email-masked]>
Date: Sat, 16 Jan 2021 17:34:52 -0800

[email-masked] said:
> I'd like to see some input from people who operate the pool on what solutions
> would work for them. Right now we're sort of flying blind. Perhaps we can
> discuss at IETF 110? 

I think there are 2 levels to discuss.  One is technical.  If I have something 
like the pool, how can I distribute the information about which systems are 
"in the pool" from pool-central to pool clients in a secure way that allows 
clients to verify that they are talking to the specified server.

The other is how to setup a system run by many many volunteers so that you 
only get "good" volunteers.

Until we solve the second problem, I think discussing the technical issues is 
misleading.

---

From: James Browning <[email-masked]>
Date: Sat, 16 Jan 2021 17:44:21 -0800

> How do you reliably use DNSSEC if you don't know what time it is?

1) don't
2) if not taking a big step it should already be well under ~17 minutes off.
3) if taking a big step store the result and evaluate later.
4) whatever handwaving will be used for the TLS certificates.
Probably those in reverse order.

---

From: Philip Prindeville <[email-masked]>
Date: Sat, 16 Jan 2021 19:13:51 -0700

> On Jan 16, 2021, at 3:49 PM, James Browning <[email-masked]> wrote:
> 

(2) seems very insecure.

(3) SAN (Subject Alternate Name) can be a domain name OR an IP address.

---

From: Philip Prindeville <[email-masked]>
Date: Sat, 16 Jan 2021 19:23:21 -0700

> On Jan 16, 2021, at 6:34 PM, Hal Murray <[email-masked]> wrote:
> 
> 

Google "Trust in loosely federated distributed systems"... zero hits...

Okay, I'm exaggerating, but it's not a big body of work.  Saw this:

https://onlinelibrary.wiley.com/doi/book/10.1002/9780470751787

But it's already 11 years old.

---

From: Hal Murray <[email-masked]>
Date: Sun, 17 Jan 2021 01:25:35 -0800

[email-masked] said:
> I neglected to mention my now expired https://datatracker.ietf.org/doc/
> draft-ladd-nts-for-ntp-pool/ as an example of this approach.

That mentions ACME several times.  I don't know anything about ACME.  A few 
words about what it does might be helpful.

 From page 3:
> Clients MAY periodically resolve the pool associated domain
> names to confirm the server is still trusted by the pool.

That doesn't work.  The DNS servers for the pool reply with several IP 
Addresses out of many in the pool.  If a client asks again later, they will 
probably get a different subset.

This issue comes up even without NTS.  There is no way for a current pool 
client to verify that a server is still in the pool.

I think it should be easy to fix.  The pool DNS servers would have to support 
a new mode, something like an A record for d.c.b.a.pool.ntp.org that returns 
the address if the address is still in the pool.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 17 Jan 2021 13:59:09 +0000

It is an HTTP application protocol designed to automate getting certificates from a CA. It has a framework for defining new challenges; a common one is "prove you own the HTTP server"; others include getting a cert for an IP address, an email cert, etc. I like "prove you own this cellphone number" which will be part of preventing spam calls.

ACME is supported by several commercial CA's. The most notable user, and spark that created the IETF WG, is LetsEncrypt.

Hope this helps.

	/r$, ACME co-chair

---

From: Watson Ladd <[email-masked]>
Date: Sun, 17 Jan 2021 13:53:47 -0800

> client to verify that a server is still in the pool.

I don't think I wrote this as clearly as I would have liked. My idea was
you would have names like bob-server.servers.pool.ntp.org that SRV records
could point to and that could use ACME to get certificates. These names
would no longer resolve when a server is untrusted.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Mon, 18 Jan 2021 09:29:46 +0000

Le 16/01/2021 à 23:49, James Browning a écrit :
> On Sat, Jan 16, 2021, at 11:02 AM Watson Ladd <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
Or start to discuss a DANE usage for NTS.
Basicaly use DANE-EE or TA certificate usage
Ot the pool could use it's own specialized pki for the pool participants 
with DANE-TA.

I think the most simple and flexible would be the EE in the pool 
hierachy. The validity of the certificate is only tied to the validity 
of the DNSSEC signature of the TLSA record.
And all bootstrapping problems could be solved with CD / DO flags 
controls and validation back checking with the first returned time of day.

Even out the pool context, a specified DANE usage for NTS would be very 
valuable.

Emmanuel.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 18 Jan 2021 11:12:48 +0100

> Agreed. The key management and synchronization in such a system is a pain.

Also, format and content of cookies is implementation-specific, so
that NTS-KE server would need to specifically support all common
implementations.

I suspect a bigger issue would be the resources required for the
NTS-KE service. I don't think it's likely it would be able to run on
the core pool's infrastructure. (One of the main points of the pool is
to share the costs.)

> > > 3) Convince TLS certificate vendors to sell IP based certificates.

IIRC, ZeroSSL (one of the LetsEncrypt alternatives) can issue
certificates for IP addresses. But I'm not sure if availability of
such certificates changes anything. The clients of the pool would
still need to get the addresses in a secured way.

> This has some interesting advantages.

And it shares the scalability issue with the common NTS-KE server. I
think the load needs to be shared among the volunteers' servers.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Mon, 18 Jan 2021 03:38:06 -0800

[email-masked] said:
> And all bootstrapping problems could be solved with CD / DO flags  controls
> and validation back checking with the first returned time of day. 

How is that back checking going to work?  You don't know the time yet.

Sure, it will say "OK" if you are talking to an honest server, but if you are talking to a bad guy, it can lie consistently.  Am I missing something?

---------

I know of 2 solutions for the 10 years on the shelf problem.

1) Have a battery that lasts long enough.  Watches are good for ballpark of 1 second per day so 10 years will be within an hour.  (worse if the device is stored in hot or cold)

2) Preload the box with whatever is needed to get off the ground without good time.  I think that is long lifetime certificates and long lifetime IP Addresses.

Neither is easy, but I think both are possible.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Mon, 18 Jan 2021 12:02:04 +0000

> Sure, it will say "OK" if you are talking to an honest server, but if you are talking to a bad guy, it can lie consistently.  Am I missing something?
DNSSEC and/or DANE validation will fail if it is really a "bad guy" eg 
it is not really the guy you tried to connect to, even if the given time 
is "good" for DNS resolutions.
For long time on the shelf, you will have to update the root DNS key if 
the device is operating on the Internet, but only that.

For standard X509 model, you will have to update the certificate 
authority list/public key anyway. And if we talk about security, DNSSEC 
validation capability is something that should be mandatory for any 
device that is connected to the Internet today.

Emmanuel.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Jan 2021 23:03:53 +1100

A long lived cert is identical to DNSSEC.  The only difference is that DNSSEC uses signature validity periods measured in days rather than years. 

-- 
Mark Andrews

> On 18 Jan 2021, at 22:38, Hal Murray <[email-masked]> wrote:
> 
>

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 18 Jan 2021 13:23:07 +0100

On Mon, Jan 18, 2021 at 12:02:04PM +0000, FUSTE Emmanuel wrote:
> authority list/public key anyway.

There aren't really much differences between X509 and DNSSEC.

> And if we talk about security, DNSSEC 

See:
https://blog.apnic.net/2020/03/02/dnssec-validation-revisited/
https://stats.labs.apnic.net/dnssec/

We're at about 25% that's currently validating, and 10% that has
both a validating and non-validating resolver.

Software can use a library to do the validation itself rather than
rely on resolver to do it.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 18 Jan 2021 13:39:17 +0000

>    A long lived cert is identical to DNSSEC.  The only difference is that DNSSEC uses signature validity periods measured in days rather than years. 

On the Web, cert lifetimes are 825 days.  LetsEncrypt, the largest CA, is 90 days.

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 18 Jan 2021 16:46:22 +0100

Hi,

> Sure, it will say "OK" if you are talking to an honest server, but if you are talking to a bad guy, it can lie consistently.  Am I missing something?

So, you only need to have sufficiently accurate time that DNSSEC will
give thumbs up.

Also, it only really need to match of that handshake.

So, if you talk to server A, you can query which NTP server A say I
should be able to trust.

1) Query A for NTP server B for A.

2) Query B for NTP time to use in initial exchange.

3) Query A for DNSSEC verified answer, using the time as initiated from B.

4) With verified answer, now handshake B using verified DNS records. If
not verified, it fails.

5) Query B for NTP time.

6) If verified time matches that of the initial handshake request (as
updated using local time progess), then unauthenticated time in step 2
and 3 was valid, and thus the verification was valid and progress, else
fail.

So, we see how unauthenticated time can be used to bootstrap the
handshake. Notice that this is not used to initiate node time, but only
for that handshake. Only after things is secured, you accept time as
being secured.

This will work if the DNSSEC part and the consistency check in 6 leave
enough margin.

If it fails, it fails. This is why you want multiple sources for redundancy.

Cheers,
Magnus

---

From: FUSTE Emmanuel <[email-masked]>
Date: Mon, 18 Jan 2021 16:04:46 +0000

Le 18/01/2021 à 16:46, Magnus Danielson a écrit :
> mailman/listinfo/ntp
Exactly what I have in mind.
My reference to CD/DO flags are misleading, and is implementation details.
It for the case where your talk to a local DNS Server do do validation 
when you not embed the complete DNSSEC validation in your code (SMTP 
current usage deformation...).
With a proper embedded validation library (as Kurt said) the dependence 
on a local  (or non-local) validating resolver is no longer relevant 
(this library will do the necessary CD/DO flags dance if/as needed).

Emmanuel.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 18 Jan 2021 17:25:17 +0100

> for that handshake. Only after things is secured, you accept time as

I don't quite follow. If A was compromised at some point, how do you
know you are not talking to the attacker intercepting your requests
and giving you old signatures? Isn't the whole point of the validity
period to prevent such attacks? If you don't know the current time,
how can you validate anything that's not supposed to be trusted
forever?

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 18 Jan 2021 21:17:49 +0100

Hi,

> how can you validate anything that's not supposed to be trusted
You actually do not trust the time you get initially. You validate it.
If your DNSSEC is invalid because of time, then the DNSSEC does not
validate. If your DNSSEC is invalid because false data, the DNSSEC does
not validate. Then, if and only if DNSSEC validate, only then you get
time but using the data-validated path, and only then you validate if
the original time and the validated time match up. If they don't, then
you do not trust either. If you can spoof the DNSSEC to validate, you
are toast anyway, if you have put your trust there.

Now, one *could* argue that the validated time from A can be trusted
even if the non-validated initial time mismatch. This could be used for
relaxed rules, but should result in warning.

If someone feeds you DNS-records that is wrong, DNSSEC should not validate.

If someone feeds you initial non-validated time that is wrong, that is
caught later. It may be "good enough" for the DNSSEC to be valid, but we
do not trust that value any further, it's only used in the boot-strap
procedure to hand-off to the secured form.

Cheers,
Magnus

---

From: Marcus Dansarie <[email-masked]>
Date: Mon, 18 Jan 2021 21:38:10 +0100

> 2) Have the pool run a common NTS-KE server for all NTS servers in the pool.

When we wrote the draft for NTS, I basically envisaged something like
this for a pool:

1. Each NTP server in the pool has a unique cookie encryption key which
is known only to that NTP server and the pool NTS-KE server.

2. If the pool DNS name is pool.example.org and the NTS-KE server's DNS
name is ke.pool.example.org, there is an SRV record for
_ntske._tcp.example.org pointing to ke.pool.example.org. Clients
configured to use pool.example.org can then find the NTS-KE server
automatically. (SRV records for NTS-KE are currently not standardized.)

3. A client can perform a NTS-KE handshake and request cookies for its
assigned NTP server by specifying its IP address in an NTPv4 Server
Negotiation record. We could specify a Warning Code for the server to
indicate that the specified IP address does not belong to a pool member.

This scheme only requires the clients to configure a single cookie
encryption key and share it with the NTS-KE server out-of-band. The
NTS-KE server, which would presumably be run by the pool controller, is
the only party which needs to be trusted.

Kind regards,
Marcus

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 18 Jan 2021 13:47:12 -0700

> On Jan 18, 2021, at 1:17 PM, Magnus Danielson <[email-masked]> wrote:
> 
>> [...]

I think I could live with this.  Rich?  Emmanuel?

-Philip

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 18 Jan 2021 22:15:44 +0100

> are toast anyway, if you have put your trust there.

In case keys are compromised, an attacker can send you an invalid
initial time. That same attacker can create DNSSEC records, which
you're happy to validate with the wrong time. So now you think DNS
is working properly and ask for the time again, and still get the
wrong time.

As far as I know, this requires at least 2 things to be compromised:
Both DNSSEC and the X509 certificate. This is less likely than
just 1 being compromised, but still possible. It would at least
help that the DNSSEC and X509 certificate are not managed by the
same organization.

The only options I see is:
1) You have enough sources so that all being compromised is
   unlikely enough for your use case. This can be things like:
   - A battery to keep your clock
   - A source of time that makes you a stratum 1 servers like a
     GPS receiver.
   - 1 or more ntp servers (using NTS)
   - Other sources of time like roughtime
2) The machine should trust something external:
   - A human that sets the time correct
   - An external DNS server that does DNSSEC validation for it,
     and probably uses 1) itself.

Kurt

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 18 Jan 2021 22:28:41 +0100

Kurt,

> is working properly and ask for the time again, and still get the
The DNSSEC records need to validate data-wise for the time-attack to do
any good. The design goal was just to enable the DNSSEC validation to
have good enough time for time-validation for bootstrap.
> help that the DNSSEC and X509 certificate are not managed by the

For sure. If you have updated your basic DNSSEC key to be valid enough,
DNSSEC validation should be difficult. At the time it is "broken" we are
not alone to need the upgrade.

>    - Other sources of time like roughtime
Regular update that RTC. I've seen NTP fail because the RTC drifted away
and was not maintained.
>      and probably uses 1) itself.

If you trust DNSSEC and that key-chain as well as trust the X.509 chain,
then you put your core trust there. The bootstrap procedure I describe
is to bootstrap out of the situation you do not trust your own time well
enough. In fact, as you wake up, you also need to consider that your own
local time can be at error, and you need to bootstrap out of that. You
can test it through similar enough procedure, but if that fails, you
need to bootstrap time from external source.

Look at the DHS Resilient PNT common framework, already for Level 1 you
need to be able to in the field be able to reset to "factory settings"
to override any internal state that can be incorrect. It turns out from
bitter experience, you can't trust that at all times. Once you done your
homework, that's another story, and you need to maintain it just as with
keys.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 10:42:17 +0100

> have good enough time for time-validation for bootstrap.

I think the point is that you cannot bootstrap secure time out of
nothing. You either do full validation using some trusted time source
(e.g. RTC), or you don't. It doesn't matter if multiple systems are
involved and their data seem consistent with each other.

Even if we assume the attacker didn't manipulate the DNS(SEC) records,
there is a possibility the name or address is no longer under the
control of the original owner when those records were valid. In the
pool that happens frequently.

-- 
Miroslav Lichvar

---

From: FUSTE Emmanuel <[email-masked]>
Date: Tue, 19 Jan 2021 09:52:36 +0000

> is working properly and ask for the time again, and still get the
The lying  time windows will not be very huge to continue to be valid 
for all the chain.
It will so be valid for the other configured servers and you want to 
configure multiple ones and eject bad ones the standard way.

Validating reverse DNS records is a good thing too, as the two are 
managed generally by different organization and definitively use another 
trust chain and key.
For the pool, with what I have in mind with DANE and DNSSEC, you will 
have the trust dispatched between the DNS hierarchy of the pool, the  
DNS hierarchy of each participant and a simple x509 authority operated 
by the pool and published in a DANE record.
Why not a "classic" public authority ? Mainly for the bootstrapping 
problem as you don't have to distribute the authority certificate chain 
to the clients, and on a very personal point of view because I consider 
this external "moral" authority trust model broken.

Anyway compromised machine will still be compromised and dealt as usual.

This and all  the local possible trusting possibilities options/policies 
(RTC, trusted sources like GPS/GNSS, human validation etc...) permit a 
very robust time trust model.

Emmanuel.

---

From: FUSTE Emmanuel <[email-masked]>
Date: Tue, 19 Jan 2021 10:20:31 +0000

> pool that happens frequently.
This is a completely different and non technical problem, specific to 
the pool.
And even in this case, you could cross enough sources to get better time 
than most RTC ones.
When time matter, you will have RTC and other out of band validation 
process to ensure correct time.

The main point is that if I have a very simple device without RTC, which 
point to my own Internet NTP servers, I could bootstrap it with perfect 
confidence only by ensuring that the root DNS key are up to date. If I 
do not trust the root servers, this is another out of topic problem.

Emmanuel.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 12:10:51 +0100

On Tue, Jan 19, 2021 at 10:20:31AM +0000, FUSTE Emmanuel wrote:
> Le 19/01/2021 Ã  10:42, Miroslav Lichvar a Ã©critÂ :

It's not specific to the pool. IP addresses and domains are sold,
lost, hijacked, etc.

> And even in this case, you could cross enough sources to get better time 

Having multiple sources doesn't protect you against a focused MITM
attack.

> do not trust the root servers, this is another out of topic problem.

I'd say it's just shifting the responsibility. "Not my problem"
doesn't make that problem disappear.

If an attacker hijacks your domain and makes their own records, how
will your simple device know they shouldn't be trusted later when you
get it back? You will need to make some modification on the device.

When using NTS with your own servers, it might be easier to use a
self-signed certificate or your own CA. You can disable the time
validation, or make the certificate valid even in the initial boot
date (e.g. 1970). Of course, if the key is compromised, you will need
to update the device.

-- 
Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 19 Jan 2021 13:24:37 +0100

Hi,

On 2021-01-19 10:42, Miroslav Lichvar wrote:
> nothing.
That's a conjecture, yet to be proven.
> You either do full validation using some trusted time source
> (e.g. RTC), or you don't.

RTC is not a trusted time source. I can be just as much a false-ticker
as any source you see. Do not trust the RTC to be near true time, it's
failed before and it will fail again. It's just another source of time,
it can be helpful to bootstrap things, but until validated you do not
trust it. This is really about doing a trust analysis.

We seem to accept that we can trust the authenticity of messages we get
through DNSSEC validation.

We seem to accept that we can trust the authenticity of messages we get
through X.509 and NTS validation.

Both these is data validity.

Now, to bootstrap things, we need time to achieve the DNSSEC validation,
but we say we do not trust the time until we achieved both DNSSEC and
NTS validation. So, if we acquire a time-stamp from what should be an
authentic time-source, without authentication being done, we can first
see if that checks out through the data validation part, which does not
require precise time. As we then have gone through both data validations
we then say that we trust the data of time, and using this we validate
the original time-stamp to see if that is consistent. If we can also
after the fact authenticate that time-stamp data-wise, so much better.

In this process we only assumed that the original timestamp was valid
durign the data-validation phase, and we already stated that we trust
the data validation part, and later test that assumption.

Now, regardless of which time-source led you astray, on the network or
local as the RTC, you must have a way to get away from that. If you have
local time source which pass the test of being valid, then it can be
used to speed things up, but whenever you put too high trust in
something that may lie to you, you end up in a dead-lock situation.
Treat the RTC as a read-cache. It may be valid and help you, but that's
about that.

The trick I used was that I did not trust any time, but I did trust the
data. If the initial time (really regardless where you get it) does not
make data validate, this could be because either the time or the data is
incorrect, or indeed both but not consistent. If we manage to get
through the trust loop of the data (potentially lying with the time to
make the DNSSEC validation check out even if it should be invalid), we
have yet not proved something. Now, then the independent data check of
the X.509 NTS path validate the data of the timing, again. Using DANE we
can provide a hand-off between DNSSEC and X.509 path that also needs to
be correct and valid, and again more data-trust that needs to be there.
Only as we built this data-trust and combine that we attain a time-stamp
we trust in data, and then we use that to check the validity of the
original time given. If consistent within some reasonable time (and here
we need to compensate for elapsed time naturally), and the process took
reasonable time, the trusted time we got helps in the end.

Now, this is jumping a bunch of loops in a strange way. Notice that the
time taken initial is not set as node time at all, it's just a timestamp
we use for the other processing as an assumed correct time to see if it
all checks out. If you want to be really careful you run the process
again but now with the trusted time, but since you already checked the
original first time was consistent with what came out validated, it ends
up being the same thing.

Then, you should do this to all your time-sources and do the normal
validation of trust in time that way too. But, if you do your tricks
properly, you can indeed pull your bunny out of an empty hat.

If someone compromise both the DNSSEC and X.509 path, it's game over. We
are not alone in that fight, but rather we use the same tools and their
development further to also acquire some confidence in the time we get.

Throughout the discussion, the ability to validate the root certificates
for DNSSEC and X.509 is assumed. Those public keys needs to be updated
regular enough. Failure to validate would indicate that those keys could
be out of date.

>  It doesn't matter if multiple systems are
This comes into how we disseminate the trust in particular boxes. That's
a separate issue, albeit we should also talk about that. There is those
I trust more over others. My choices there will not be the same as the
next guy. For NTP pool that much more an issue than specific known
servers. I aimed to solve the problem of how to bootstrap getting time
to a server we assume to be trusted in the first place, but we might not
trust that we get all the right pieces from what looks to be it. I think
the sub-problem is solved, the other pieces is outside of that scope.

Do not overly trust your RTC.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 14:04:08 +0100

> trust it. This is really about doing a trust analysis.

Yes, RTC can fail, but it's the only source of time you usually have
for time validation of certificates, DNSSEC records, etc. The idea is
that you check or set it manually once, and then allow it to be
synchronized to secure time sources only, so it can be always be
trusted to be close to the true time.

If you cannot trust the RTC and you don't have a different trusted
time source, it's game over. You cannot perform a full validation. You
can accept the security implications and disable the time checks, but
that's not generally acceptable.

> the data validation part, and later test that assumption.

In this process you have only verified consistency of the time and
other data you have received. It was valid some time ago, but it may
not be valid now. If the attacker captured all that data, it can be
reused later in a MITM attack. You need to know the current date to
avoid that. That's why certificates and DNSSEC records have a validity
period.

You have a loop in your trust analysis.

-- 
Miroslav Lichvar

---

From: FUSTE Emmanuel <[email-masked]>
Date: Tue, 19 Jan 2021 13:15:57 +0000

Le 19/01/2021 à 14:04, Miroslav Lichvar a écrit :
> reused later in a MITM attack.
How ???
- If it replay my DNS data fine, it will do the work of my DNS servers 
for me as he could not resign.
- For the NTS part you are saying that TLS and NTS are subject to MITM 
attacks ?

>   You need to know the current date to
A very rough one. And primly for crypt analysis reasons.

Emmanuel.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 14:51:15 +0100

On Tue, Jan 19, 2021 at 01:15:57PM +0000, FUSTE Emmanuel wrote:
> Le 19/01/2021 Ã  14:04, Miroslav Lichvar a Ã©critÂ :
> >

Yes, the attacker has the old private key.

The assumption is that both your DNSSEC and NTS was compromised at
some point. You found out and rebuilt your infrastructure from
scratch, but the attacker can still perform a MITM attack on your
device if it doesn't know the current date in order to validate the
certificate/records.

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Tue, 19 Jan 2021 16:36:30 +0000

Isn't this the problem that roughtime is trying to solve?  Maybe ntpv5 should have some simple semi-secure options for start up:
RTCs,
setting the time from your watch,
getting time from multiple insecure servers.  

After one of these, move to ntp + nts.

If the device is in a less secure network or is mission critical, then start with roughtime before moving to ntp + nts.  

Doug

On 1/19/21, 8:51 AM, "ntp on behalf of Miroslav Lichvar" <[email-masked] on behalf of [email-masked]> wrote:

    -- 
    Miroslav Lichvar

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 19 Jan 2021 17:45:34 +0100

Hi,

> that's not generally acceptable.
RTC cannot be given any extra trust. It is exactly the fallacy of that
which proven fatal. When it has drifted to far away it will be the main
attack point for your system to accept any time, and you must be able to
override that. It is at best hopefully useful to bootstrap, but only that.
> other data you have received.
I never claimed anything else. You need to bootstrap that process to go
further with other validation. If you think I claimed anything else,
then I am sorry about the confusing wording.
>  It was valid some time ago, but it may
Which is why you need rough time to start with, but only that.
> You have a loop in your trust analysis.
Not really. You misunderstood what I was attempting to prove.

Cheers,
Magnus

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 19 Jan 2021 17:50:20 +0100

> Yes, the attacker has the old private key.
What? How did the attacker get the private keys? How did the attacker
fool that system? So, what references for this attack do you have?
> device if it doesn't know the current date in order to validate the
Outside of our scope. Way outside. We assume we can trust whatever these
mechanisms provide and our trust becomes tied to them. If you have ways
to attack that, this is not really the place to document those.

Cheers,
Magnus

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 18:07:28 +0100

> After one of these, move to ntp + nts.

RTC and manual input is ok, but unsecured NTP wouldn't be acceptable
as it is trivially spoofed in a MITM attack.

> If the device is in a less secure network or is mission critical, then start with roughtime before moving to ntp + nts.  

Starting with roughtime is certainly better than an unauthenticated
NTP source. IIRC it relies on long-term trusted keys, no PKI involved.
You could do the same with NTS using self-signed certificates.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 19 Jan 2021 18:26:24 +0100

> to attack that, this is not really the place to document those.

I don't agree. The mechanisms should be trusted only if used as
intended, i.e. a full validation is performed. Skipping the time
checks is a security risk. You seem to be saying that's ok, that you
can combine outputs from two separate mechanisms using untrusted data
and get a trusted output. I don't think that's the case. We can ask
the DNS and CFRG groups.

-- 
Miroslav Lichvar

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 19 Jan 2021 18:48:45 +0100

> and get a trusted output. I don't think that's the case. We can ask

I agree that you can't combine two things that are not validated
and end up with something that's validated. But everything really
is about probabilities and amount of work needed to break it. The
more keys that need to be compromised before you accept something
wrong, the more unlikely it is. I think it's really up to the
users to decide what is an acceptable risk.

Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Jan 2021 17:53:38 +0000

Strongly agree with this.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 20 Jan 2021 10:07:15 +0100

> users to decide what is an acceptable risk.

Ok, as long as it is clear that the proposed mechanism for
bootstrapping time it is not supposed to be secure (in threat models
commonly assumed with DNSSEC and TLS), just more difficult to be
exploited, I have no problem with that.

There are other recommendations that could be made if you cannot
perform the certificate time check using a trusted time source, which
might be easier to implement, e.g. require multiple independent NTS
sources.

-- 
Miroslav Lichvar

---

From: FUSTE Emmanuel <[email-masked]>
Date: Wed, 20 Jan 2021 09:43:53 +0000

> might be easier to implement, e.g. require multiple independent NTS
Which was always been part of the proposed mechanism too.
DNSSEC should be put into the equation because it is a necessity to 
have/use at term.
So you have do to exactly the same: disable DNSSEC validation, acquire 
the time using multiple independent NTS sources, re-enable DNSSEC and 
re-enable DNSSEC/re-validate the server direct/reverse records and be done.
If we do not explicit this scenario, some will object that they do-not 
will-not implement DNSSEC validation because it is incompatible with NTP 
bootstrap/startup.
Using locally configured CA or the proposed DANE refinement for the NTS 
certificate validation is just another possibility/trade-of. Your could 
put the cursor where you want/need.

Emmanuel.

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 21 Jan 2021 19:30:31 -0700

> On Jan 19, 2021, at 4:10 AM, Miroslav Lichvar <[email-masked]> wrote:
> 

Don't forget critical traffic being routed through China because major carriers and ISPs can't be bothered to use BGP rPKI.

---

From: Philip Prindeville <[email-masked]>
Date: Thu, 21 Jan 2021 19:34:28 -0700

> On Jan 19, 2021, at 5:24 AM, Magnus Danielson <[email-masked]> wrote:
> 

No, that's basic Information Theory.  Lost or non-existent information can't be recreated from a void.

...

> RTC is not a trusted time source. 

I think I'm more likely to trust that which I can control or verify for myself, than that which I can't.

-Philip

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 Jan 2021 18:46:04 -0800

On Tue, Jan 19, 2021, 8:36 AM Doug Arnold <[email-masked]> wrote:
>
> Isn't this the problem that roughtime is trying to solve?

Yes! But solving requires more implementations, more text on
impeachment, more monitors, and yes more code by me. Our deployment
isn't implementing the latest draft yet.

Send comments! Run servers! Run monitors! Roughtime, like CT, is an
ecosystem. It's beyond my resources to do it myself, but I hope to
have good news to share at IETF about deployments of the draft
version.

> Maybe ntpv5 should have some simple semi-secure options for start up:
> RTCs,

---

From: FUSTE Emmanuel <[email-masked]>
Date: Fri, 22 Jan 2021 08:54:36 +0000

> No, that's basic Information Theory.  Lost or non-existent information can't be recreated from a void.
Exactly. And here the information is present/existent in a lot 
of/multiple source.
As there is a possibility that some are compromised and your must sort 
out/validate them.
Depending of your needs, you could startup with pretty low known 
validation materials with very good confidence, up to multiple 
cryptographic factors and less than a second away trusted local time and 
very very high confidence.
Look at today real world status  ! This is terrific, more than 99.9% of 
devices, phone, computers, wifi routers, etc ... using NTP even with 
local RTC blindly trust ANY ntp source without any validation procedure 
/ validation material and only rely on NTP algorithms to try to sort the 
sources, on the better implementations.

Emmanuel.

---

From: Marcus Dansarie <[email-masked]>
Date: Fri, 22 Jan 2021 13:59:09 +0100

> have good news to share at IETF about deployments of the draft

I am happy to report that my Roughtime server implementation was updated
to the latest draft in December. Connection information is available in
the draft and at https://roughtime.se.

/Marcus

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 28 Jan 2021 11:27:32 +0100

Philip,

> No, that's basic Information Theory.  Lost or non-existent information can't be recreated from a void.
Which needs to be properly proven to apply, because we end up shutting
this WG down if it truely applies.
> I think I'm more likely to trust that which I can control or verify for myself, than that which I can't.

Which makes it an operational issue, which turns out to fail eventually,
and when it fails and NTP is your only way to resolve, you do not have
time and hence you are out of service. That is not leading towards a
robust solution.

So, in conclusion, rather than quickly dismiss the notion of being able
to bootstrap, it needs to be revisited. I through out a proposal to get
something to test. People did not like that, so now I let others find a
solution to replace it, and the purpose of my proposal was to provide
something for people to think and analyze, and find flaws and then fix
those flaws. What you ended up doing was dismissing the bare thought.

The lack of interest to solve this means that I see less use and
therefore less interest in NTPv5.

Cheers,
Magnus

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 28 Jan 2021 12:26:56 +0100

>>> Magnus Danielson <[email-masked]> schrieb am 28.01.2021 um 11:27 in
Nachricht <[email-masked]>:
> Philip,
> 
> On 2021‑01‑22 03:34, Philip Prindeville wrote:
>>
>> No, that's basic Information Theory.  Lost or non‑existent information
can't 
> be recreated from a void.
>>
>> ...

When "a void" means "maximum entropy" you actually cannot create new
information as creating information increases the entropy.
But fortunately we wouldn't exist in such a state any more, so no reasons to
worry ;-)
Otherwise you are actually not creating information "from a void". Maybe all
out new ideas are just some transformation of information that is already
there...

> myself, than that which I can't.

So you don't trust the RTC initially, but you trust yourself (self-signed
certificate, so to say).

> therefore less interest in NTPv5.

Out of curiosity: Does anybody know a solution that deduces rough time and
position using a camera pointed at the night sky, using some star almanach?

Regards,
Ulrich

---

From: Watson Ladd <[email-masked]>
Date: Sat, 30 Jan 2021 16:51:39 -0800

Dear WG,

Right now we have interop on the wire format of version -03. What we
don't have is a serialization format for reports of malfeasance.

In order to move forward I'm considering reducing the draft to just
the wire format for the protocol leaving the malfeasance serialization
to a subsequent draft. This would let us start a WGLC on the parts
that aren't going to change, and potentially accelerate deployment of
servers and clients.

I'd appreciate feedback on this plan. In particular I think some of
the question of timing algorithm will be explicitly out of scope:
Roughtime is intended for secure time checks and ensuring *rough*
synchronization.

Sincerely,
Watson Ladd

---

From: Daniel Franke <[email-masked]>
Date: Sat, 30 Jan 2021 20:16:17 -0500

SGTM. Impeaching a Roughtime server should anyway be rare enough that
"write an angry blog post and submit it to Hacker News" is a scalable
enough protocol as a stopgap.

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 31 Jan 2021 09:39:25 +0100

> that aren't going to change, and potentially accelerate deployment of

I think it's important to at least define a basic serialization schema
for both malfeasance reports and lists of servers. If we don't, we risk
ending up with several incompatible formats for data exchange in the
Roughtime ecosystem.

A de facto standard for server lists already exists (ecosystem.json) and
only needs to be documented in the draft. A simple malfeasance report
format in the same spirit as the server list format could be a JSON
object with an ordered list of objects, each containing a nonce and a
server response, both in base64 format. Verifying the report would be as
simple as (1) verifying that the list is a valid list of chained
Roughtime responses and (2) applying the same validity tests as clients.

Tal Mizrahi and others raised a number of issues with how the security
model is described in the draft. [1] I don't think they where ever
addressed. We should probably be proactive in fixing this in the draft,
as it is something that the IESG will have opinions about. In
particular, I think we need to be very clear about the fact that all
trust in Roughtime is rooted in the long-term keys and that they are
expected to be valid for a very long time indeed.

After fixing these two two points, I would be happy to support a WGLC.

> Roughtime is intended for secure time checks and ensuring *rough*

Fully agree.

Kind regards,
Marcus

[1] https://mailarchive.ietf.org/arch/msg/ntp/wsm0sjAagWfr8FBxje_5mZL07A4/
https://mailarchive.ietf.org/arch/msg/ntp/JLNNAkI-eD_Nmoi8P5rr-BYRVUU/
https://mailarchive.ietf.org/arch/msg/ntp/uADaxiNDQT8BQi5pyVwd_rcFw8Y/
https://mailarchive.ietf.org/arch/msg/ntp/4OyvMuxHQnOcwmvFBa1099us3P4/

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 31 Jan 2021 10:16:58 +0100

> After fixing these two two points, I would be happy to support a WGLC.

I just realized that I forgot to add one important point: We need to
specify how revocation of long-term keys is performed, even if it is as
simple as knowingly generating invalid time responses and impeaching
oneself.

Kind regards,
Marcus

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 31 Jan 2021 16:40:24 +0000

to a subsequent draft.

Sensible.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Jan 2021 08:46:21 -0800

On Sat, Jan 30, 2021 at 5:16 PM Daniel Franke <[email-masked]> wrote:
>
> SGTM. Impeaching a Roughtime server should anyway be rare enough that "write an angry blog post and submit it to Hacker News" is a scalable enough protocol as a stopgap.

Isn't that the protocol we use for CAs via
mozilla.dev.security.policy? Maybe I should set up
comp.security.roughtime for similar purposes.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 31 Jan 2021 17:26:27 +0000

As a stop-gap.  But the real revocation is when the browser's act and users update.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Jan 2021 11:48:08 -0800

> Roughtime responses and (2) applying the same validity tests as clients.

This seems simple enough to add that it won't delay the process. I
should be able to throw up some text this week... emphasis on should.

> expected to be valid for a very long time indeed.

Since then we've added Section 4 which directly addresses the concern
of Tal that delay attacks were still possible, but it sounds like we
would want to add detail to Section 11 and probably the introduction.

Downthread you mentioned revocation, and I think signing a
specifically formatted recovation message would work fine. This would
be a roughtime message, just one with a special tag alone that
demonstrates the operator considers the key compromised.

---

From: Marcus Dansarie <[email-masked]>
Date: Sun, 31 Jan 2021 20:57:14 +0100

> would want to add detail to Section 11 and probably the introductio

Agree with the suggestions above. I should probably also be able to
spend some time on it this week. The cutoff date for IETF 110 is 22
February. It would be nice if we had something ready for WGLC by then.

Kind regards,
Marcus

---

From: Hal Murray <[email-masked]>
Date: Sun, 31 Jan 2021 13:02:25 -0800

[email-masked] said:
> Downthread you mentioned revocation, and I think signing a specifically
> formatted recovation message would work fine. This would be a roughtime
> message, just one with a special tag alone that demonstrates the operator
> considers the key compromised. 

Without a valid key, you can't verify that message so bad guys can forge one.  
That seems like a nasty complication.  Do you want to go down that path?

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Jan 2021 13:14:12 -0800

> That seems like a nasty complication.  Do you want to go down that path?

I miswrote: It would of course be signed by the key involved.

---

From: Hal Murray <[email-masked]>
Date: Sun, 31 Jan 2021 15:30:04 -0800

> I miswrote: It would of course be signed by the key involved. 

It's still an additional complication to analyze.

You have to handle the case of bad-guy has a stolen key so now he can forge 
responses with bogus time.  How does being able to respond with key-invalid 
help things and is that worth the complexity of discussing key-invalid?