Re: [Ntp] NTPv5 draft

[James <[e-mail]>]

My responses inline.

On 09-12-2020 08:38, Miroslav Lichvar wrote:
> On Tue, Dec 08, 2020 at 04:51:21PM +0100, James wrote:
>> Given so many existing deployments end up running for many, many years the
>> next version of NTP will also be around for a long time. Extensions and
>> bolt-ons alone will not suffice in assuring the protocol's longevity, and
>> that there is clearly a lot of work that must be done with the core of the
>> protocol to address ossification, agility, as well as security. I would
>> rather see NTPv5 solve these issues and take longer in its design than just
>> deal with the "quick fixes", and I'm prepared to invest a significant
>> portion of my own time and energy to support the efforts.
> How do you know that extensions will not suffice? Maybe it's clear to
> you and others, but not to me. Can you please explain in more detail
> why the core protocol needs to be changed?

I was hoping that the requirements document[1] I had briefly written, 
along with the several[2] emails I have sent to you and the list[3] 
describing more of my use cases and needs as well as those of others 
believed to be relevant would have sufficiently answered this question 
already. To summarise, I believe the core protocol needs to offer 
downgrade-resistant authentication as:

* Many existing NTPv4 deployments (including my own) operate on 
untrusted networks that have a risk and threat profile where packet 
filtering and manipulation is credible or occurring;

* Securing NTP via extensions, IPSec etc adds additional cost and 
integration complexity as well as an increased risk of downgrade or 
misconfiguration in deployments;

* And that the computation/latency costs that would incur would be 
acceptable and reduced as implementations improve over time.

> To me, NTP is a protocol for exchanging timestamps and some related
> metadata over network. Compared to most other protocols it's extremely
> simple. The data can be authenticated or not. For NTP, it doesn't
> matter how it is authenticated. Either the mechanism requires prior
> knowledge of time, or it does not. NTP cannot help you to circumvent
> that requirement.
>
> What do you want NTP to do?

The core function as you put of "exchanging timestamps and related 
metadata" is not being contested here.

What are the use cases you are considering, and what limitations do you 
think that providing authentication will impose on the protocol that 
would not make it suitable for them?

> The issues we have on the wiki are long known, understood and have
> proposed fixes. They are causing issues in existing applications. If
> there is not much bikeshedding, we can have a complete NTPv5 draft in
> couple months. Implementations can follow and people are happy.
>
> Now, suddenly people talk about some non-specific issues that have an
> unknown solution. Where were you when NTS was designed? And why does
> it need to be solved in NTPv5?

I did not get involved with the IETF until mid 2018 which was towards 
the later part of it's design and I was focusing on other areas at the time.

- J


1: 
https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements/

2: https://mailarchive.ietf.org/arch/msg/ntp/l0P0p-Cl0WMDo6COZItFuwEkR1E/

3: https://mailarchive.ietf.org/arch/msg/ntp/uB4VnYTROSr2nCmEFa_J4IdeWLc/