Re: [Ntp] NTPv5: big picture

[Magnus Danielson <[e-mail]>]

Hi Hal,

On 2021-01-01 06:53, Hal Murray wrote:
> [e-mail] 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