Re: [Ntp] NTPv5: big picture

[Philip Prindeville <[e-mail]>]

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


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

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?



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

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.


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


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


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


> 
>> Again, that can be a separate document.
> 
> 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


> 
> Cheers,
> Magnus