Re: [Ntp] An NTPv5 design sketch

Supporting simple harware implementations in closed specialized networks, like a robot, is a problem already well solved by PTP.  Making NTP do that does not help solve technical problems.  Making a timing protocol that is robust and secure is not at all solved by PTP.  That is how NTPv5 can make the world better.

Doug

________________________________
From: ntp <ntp-bounces@ietf.org> on behalf of Miroslav Lichvar <mlichvar@redhat.com>
Sent: Thursday, April 16, 2020 1:25 AM
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: NTP WG <ntp@ietf.org>
Subject: Re: [Ntp] An NTPv5 design sketch

On Wed, Apr 15, 2020 at 11:57:45AM -0400, Daniel Franke wrote:
> On Wed, Apr 15, 2020 at 3:20 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
> >
> > That code will likely need to be updated to fix security issues.
>
> So will the NTP code itself, not to mention the OS kernel and whatever
> else your device is running.

The device may be very simple. It may not have an OS and NTP may be
the only networking it does. It could be measuring intervals in a
physics experiment, or controlling a robot in a factory. Consider
where and why PTP originated and that NTPv5 with its correction field
might be usable there too.

> Different NTP implementations have had
> serious security issues with widely varying frequency; so have
> different TLS implementations. I'm not going to engage in arguments
> about the precise quantity, severity, or inevitability of these
> vulnerabilities; I'm just asserting the lack of a qualitative
> difference in the historical need for patching.

Well, that would be an interesting exercise, but I think just from the
nature of the domains it's much more likely a TLS code will need to be
patched than an NTP code written with the same care. It would be also
interesting to compare just the protocols alone. How many issues does
NTPv2 from 1989 (which is not that different from NTPv4) have?

> > It would help if you could explain why do you think it should.
>
> NTPv5 (as I've sketched it) depends on NTS for more than just
> cryptographic security; it's also version negotiation (NTS Next
> Protocol), server discovery (Server and Port Negotation), and
> anti-amplification (address-bound cookies). Making NTS optional would
> require alternative approaches to all these issues.

I don't see a big problem with that. Supporting NTS is much more
difficult than supporting those extensions would be.

Being able to use other authentication mechanisms (e.g. symmetric key,
or a successor of NTS) is an advantage.

> It would also
> complicate the packet format and add landmines for implementers
> (granted, already present in v4 NTS) around correct handling of
> unprotected responses.

Protected responses need to be handled in the same way as unprotected
responses. You never know if the server isn't compromised and trying
to attack you.

--
Miroslav Lichvar

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp