Subject: [Ntp] NTPv5 modular architecture update

From: Doug Arnold <[email-masked]>
Date: Thu, 23 Jul 2020 19:34:14 +0000

Here are some, hopefully, improved slides based on feedback.  More feedback welcome.

Doug

---

From: "Dieter Sibold" <[email-masked]>
Date: Thu, 23 Jul 2020 23:02:12 +0200

Hi Doug,

thanks for the proposed architecture.  From the first reading I have 
following comments:

1. As far as I remember Kristof and Daniel proposed to separate NTP into 
three parts:

(i) the on-wire protocol
(ii) selection and filter engine
(iii) steering engine

This would allow to apply different clock control mechanism independent 
of what selection and filter mechanism are applied.

2. The received packet information are basically NTPv4. I see following 
issues:

(i) all 4 packet timestamps are not needed. See data minimization draft. 
Especially, the client must not send t_1 anymore.
(ii) root delay and root dispersion are accumulated values. If 
traceability is an strict requirement, data per hop would be more 
valuable. Also, the computation of these values are done with respect to 
NTPv4’s clock steering mechanism. If different clock steering 
mechanisms are possible in NTPv5 root dispersion and delay may not be 
good estimators for the desired numbers.

3. Security

Security should be the default. I would even propose to encrypt the 
timing packets per default.

Regards
Dieter

On 23 Jul 2020, at 21:34, Doug Arnold wrote:

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Danny Mayer <[email-masked]>
Date: Thu, 23 Jul 2020 17:26:41 -0400

> timing packets per default.
What are you trying to hide and why? There is no reason at all that I
can tell to encrypt a timing packet. Securing a packet only requires
that it has not been tampered with between sending and receiving.

Danny

---

From: Hal Murray <[email-masked]>
Date: Thu, 23 Jul 2020 14:31:34 -0700

[email-masked] said:
> I would even propose to encrypt the  timing packets per default.

Why?  What is there that needs hiding?

Is data minimization not good enough?

What ever happened to the data-minimization draft?

-- 
These are my opinions.  I hate spam.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jul 2020 21:52:33 +0000

>   Why?  What is there that needs hiding?

Avoiding correlation across network changes can be important, such as home/work Wifi changes.  There are ways to achieve this, of course.  Yeah, where is the data minimization draft? :)

One argument against it is that client code probably needs to know how long the decryption took, to correct for it.

Complicated issue.

---

From: Hal Murray <[email-masked]>
Date: Thu, 23 Jul 2020 15:14:03 -0700

> the decryption took, to correct for it. 

Decryption is not the problem -  you get the time stamp before you even look 
at the packet.

Encryption would be a problem.  Same for the transmit side of NTS and 
shared-key authentication.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 24 Jul 2020 09:00:24 +0200

>>> "Dieter Sibold" <[email-masked]> schrieb am 23.07.2020 um 23:02 in
> Especially, the client must not send t_1 anymore.

What about having an optional data minimization module?

> timing packets per default.

Authentication module and privacy module?

Regards,
Ulrich Windl

---

From: Hal Murray <[email-masked]>
Date: Fri, 24 Jul 2020 01:44:22 -0700

> Authentication module and privacy module?

Privacy and data minimization doesn't seem appropriate for a module or a box 
on the chart.  It's a small change to the basic packet.

Authentication makes sense as a module or two.  It adds a wrapper to the basic 
packet, but no changes to it.

But that brings up an interesting point.  What is the purpose of this chart?