Re: [Ntp] NTPv5 draft

[Miroslav Lichvar <[e-mail]>]

On Mon, Nov 30, 2020 at 08:12:06PM +0100, Dieter Sibold wrote:
> 1. Security
> 
> The protocol as proposed is missing a security approach. There are no
> mechanisms described to provide authentication, integrity protection and
> maybe encryption.

The draft describes a MAC extension field, using the AES-CMAC
(RFC8573). It also allows all NTPv4 extension field to be used in
NTPv5, making it compatible with the NTS specification.

> I very much agree with Jame’s proposed draft that a new
> version of NTP must provide these mechanisms by default.  Sure, you can add
> NTS to protect the NTPv5 packets. But in this case protection is always an
> optional add-on whereas it needs to be an inherent part of the basic
> protocol. To achieve this the NTS approach certainly can be transferred to
> the basic v5 protocol and packet format.

You mean to require all NTP packets to be authenticated? I don't like
that idea. The improvements in NTPv5 are orthogonal to authentication.
NTPv5 is not supposed to be more secure. An NTP client that doesn't
want to implement the complexity of NTS shouldn't be restricted to
NTPv4.

> 2. Interleave and 2-Step
> 
> I agree with Doug to decide with approach to provide with NTPv5. Providing
> both 2-Step and Interleave may increase complexity unnecessarily.
> Personally, I find that the 2-step approach with the follow-up message is
> more concise. And since the first message only need to be very small (it
> just needs to contain the information to ensure correlation with the follow
> up) the waste of network bandwidth is very small.

If we must to support only one of them, I think it should be the
interleaved mode.

- It fits better software server implementations, which is what the
  vast majority of NTP servers seems to be.
- It is simpler to implement on clients. It doesn't require timeouts
  for follow-up messages and handling of reordered packets.
- It is inherently resilient to amplification. No risk of an
  implementation having a bug in its cookie generation, or leaking
  key, which would allow attacks.

> 3. Traceability
> 
> It would make sense that the v5-packets optionally provide information about
> the uncertainty of the timestamps taken. These formally for establishing
> traceability.

Isn't that the NTP root delay and dispersion? Together they provide an
estimate of the maximum error in the receive and transmit timestamp.

> Additionally, in order to maintain traceability during the
> time period in which leap smearing is applied the client needs to obtain the
> necessary information to calculate the offset between UTC and smeared time.
> This also is mandatory to maintain traceability.

The smearing offset is provided in the Timescale Offset field.

-- 
Miroslav Lichvar