Subject: [Ntp] NTPv5 draft

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 11 Nov 2020 17:19:47 +0100

As promised on the previous meetings, I wrote an NTPv5 draft. It's
based on the proposal I sent to this list few months ago, with few
improvements like timestamp fields seperated from cookies, etc. It
still needs a lot of work to be able to stand on its own, but I think
it should be good enough for people here to understand how it is
intended to work.

It's too late to submit it for the upcoming meeting. Here is a link to
a txt version if anyone would like to read it and discuss it here:

https://gist.github.com/mlichvar/2bee94a706d60da9ca88d712afef083e

-- 
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Mon, 30 Nov 2020 20:12:06 +0100

Hi Miroslav

Many thanks for your NTPv5 proposal.

With my working group chair’s hat off!

I have following comments:

1. Security

The protocol as proposed is missing a security approach. There are no 
mechanisms described to provide authentication, integrity protection and 
maybe encryption. 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.

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.

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. 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.

Dieter

On 11 Nov 2020, at 17:19, Miroslav Lichvar wrote:

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

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 30 Nov 2020 21:02:40 +0100

On Mon, Nov 30, 2020 at 08:12:06PM +0100, Dieter Sibold wrote:
> 
> 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.

The NTPv4 packet contains 3 fields that's related to the
uncertainty: precision, root delay, root dispersion. I'm not sure if
anybody is using the precision for anything, but it also has an
effect on the uncertainty.

I'm wondering if the combination of those 3 fields is useful, and
if we need other fields to replace them. We at least need some
specification on how to calculate the values. Is the root distance
a mean, filtered or last value? Does the dispersion field have a 95%
(k=2) confidence interval?

> 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.

I think the document, at least the version in git, has an
extension for that.

Kurt

---

From: Steven Sommars <[email-masked]>
Date: Mon, 30 Nov 2020 14:32:35 -0600

Agree, these fields could use better descriptions or (better) replacement.

One manufacturer (LeoNTP) lowers precision to indicate reduced accuracy and
claims to obey the NTP specification.

Should a stratum 1 NTP server report root distance=0  ?   National labs
differ.

Using NTP short format the smallest non-zero root dispersion is 15
microseconds.  One can argue for finer granularity

Steve Sommars

On Mon, Nov 30, 2020 at 2:03 PM Kurt Roeckx <[email-masked]> wrote:

> about

---

From: Doug Arnold <[email-masked]>
Date: Mon, 30 Nov 2020 22:12:56 +0000

RE security: 
I think that there is a possibility of a non safety-critical closed network application of ntp that does not need security.  Especially if the client has a limited processor implementation.  I don't know, a golf course watering system or something.

Mandatory or not, I think that security should be added to the protocol as an extension field, and described in another document.  Security mechanisms change frequently.  I think that there is a good chance that we, or someone, will define a successor to NTS within 10 years.  But the over the wire ntp specification might last longer.  One of the virtues of Miroslav's proposal is that the minimum ptp message and protocol are simple and everything else is an extension. 

Doug

On 11/30/20, 2:12 PM, "ntp on behalf of Dieter Sibold" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Miroslav

    1. Security

    2. Interleave and 2-Step

    3. Traceability

    Dieter

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Nov 2020 23:44:32 +0000

>    I think that there is a possibility of a non safety-critical closed network application of ntp that does not need security.

I am strongly opposed to this for three and a half reasons:
1. The use-case is not known, so we should assume that NTPv4 is good enough.
1.5 If this is not the case, those who need this need to make the argument to this WG.
2. Security should no longer be optional for IETF protocols.
3. "Closed network" is increasingly unlikely; we're seeing more things "in the cloud" for example.

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 30 Nov 2020 17:13:39 -0700

Disagree.

Too many vulnerability exploits have their genesis in things being used in unexpected ways.

I could trick a golf course watering system to stop watering, increase the flammability of the vegetation, and then use it to start an urban wildfire.

I’m okay with using extensions as long as some of them are marked mandatory, or their replacements.

Sorry for the drive-by comments… I know I haven’t been very involved…

> On Nov 30, 2020, at 3:12 PM, Doug Arnold <[email-masked]> wrote:
> 
> RE security:

---

From: Philip Prindeville <[email-masked]>
Date: Mon, 30 Nov 2020 17:19:22 -0700

> On Nov 30, 2020, at 4:44 PM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

Plus everything Rich said.

(2) in particular because there are so many things that might require accurate time that are potentially exploitable if this is defeated.

For instance, if I warp a clock sufficiently forward or backward, I can cause X.509 certificates to be outside of their validity windows, which could cause loadable kernel module (LKM) signature verification to fail, creating a denial-of-service of critical system services, protocol and device drivers, etc.  It could cause other trust-based (PKI) services like DNSSec to fail… Ssh… HTTPS… CRL’s themselves to be ignored (yeah, that’s a bit of a mind-twister, isn’t it?)…  secure firmware updates might fail, so exploitable vulnerabilities never get flushed out of the universe of IoT’s…