Re: [Ntp] NTPv5: big picture

[Magnus Danielson <[e-mail]>]

Philip,

On 2021-01-02 03:49, Philip Prindeville wrote:
> Replies…
>
>
>> On Jan 1, 2021, at 7:01 PM, Magnus Danielson <[e-mail]> wrote:
>>
>> Philip,
>>
>> On 2021-01-02 01:55, Philip Prindeville wrote:
>>> Replies…
>>>
>>>
>>>
>>>> On Dec 31, 2020, at 8:35 PM, Magnus Danielson <[e-mail]> wrote:
>>>>
>>>> Hal,
>>>>
>>>> On 2021-01-01 03:54, Hal Murray 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.
>>>> 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.
>>>>
>>>> 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”.
>> 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.
>
> 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.

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.

>
>>>>> 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.
>>>> 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.
>> 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).
>
> 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.
>>> 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.
>> Things can be installed in places where we just don't have access to
>> normal network.
>
> 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?

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.

>>> 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?
>> 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.
>
> 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/
You are now very much of the mark here.
>>>>> --------
>>>>>
>>>>> 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 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.
>> That was only part of the full interface.
>
> Yes.  So?
If one argues based on what the POSIX CLOCK_* does, then one will not
get the full view.
>>> 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.
>
> 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.

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

>>>>> ---------
>>>>>
>>>>> 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?
>>>> 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… 
>> 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.
>
> 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.
>
>
>>>>> I'd like the answer to be authenticated.  It seems ugly to go through NTS-KE 
>>>>> 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.
>> I've seen many networks where normal rules of internet applies, yet they
>> 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?

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.

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