Subject: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)

From: [email-masked]
Date: Tue, 1 Jun 2021 22:49:10 +0200

I was definitely on that thread, I just didn't register this as a PTP security proposal specifically.

It seems like this really would work just as well with GPS, or any GNSS, with any of the TESLA-secured modes (such as GPS Chimera and Galileo OS-NMA) instead of PTP.

Or unsecured GNSS, or a radio clock like the DCF77 broadcast sender.

It also seems like it would work with something like Roughtime instead of NTS4NTP.

Personally, I believe this is a really important approach to follow up on.

I'm just not sure that it is worth the effort to focus on NTS+PTP specifically and market that as a security solution for PTP... but that gut feeling could definitely be off.

It just feels to me like it might be more interesting and fruitful (long-term) to make this into a generically applicable thing; I would be willing and able to contribute serious amounts of work to such an effort.

-----"ntp" <[email-masked]> schrieb: -----

An: [email-masked]
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 31.05.2021 19:22
Kopie: "NTP WG" <[email-masked]>
Betreff: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)

On Mon, May 31, 2021 at 11:28 AM <[email-masked]> wrote:
> @daniel: you talk about a proposal of yours that is in competition with Heiko's draft, I believe.
> Now  this might be a dumb question, but where can I find that?

My proposal is what's described here; I believe you were on the
thread: https://mailarchive.ietf.org/arch/msg/ntp/-gQcQH915bf7NFTCjJ8LfVe8aa4/

There's no associated I-D right now. I'd be happy to turn it into one
(with Informational intended status) if the WG thinks that would be
useful. If I do, I'd like to have a coauthor (someone who's worked
with IEEE1588 more closely than I have) to write the section on how to
process PTP packets once a plausible interval has been computed.

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

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 16:51:08 -0400

> It just feels to me like it might be more interesting and fruitful (long-term) to make this into a generically applicable thing; I would be willing and able to contribute serious amounts of work to…

You're correct, the general approach of using an imprecise, secure
time source to clamp a precise, insecure one can be applied to many
combinations of the two. But the details of how to commensurate the
two timescales and compute intervals of plausibility would be
different so I'd rather just focus on one particular combination and
note the broader applicability in passing.

Do you want to be my co-author on this? I'll write the first draft.
You should rewrite the section that'll be heavy on IEEE1588-specific
details because I'll probably do a mediocre job with that, and then
you'd be welcome to expand it to cover any additional topics you think
are worth including.

---

From: [email-masked]
Date: Tue, 1 Jun 2021 23:13:59 +0200

Can you elaborate on how the details of timescale commensuration and the workings of plausibility intervals would be different here than in other aplications?

An: [email-masked]
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 01.06.2021 22:51
Kopie: "NTP WG" <[email-masked]>
Betreff: Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 17:22:44 -0400

> Can you elaborate on how the details of timescale commensuration and the workings of plausibility intervals would be different here than in other aplications?

For example, NTP packets have root delay and precision fields that
should be incorporated into error bound computation. Roughtime doesn't
have anything analogous to these so the calculation would be
different. Some time protocols are based on UTC, some are based on
TAI, and if you mix the two you need to do the conversion and have a
secure way of obtaining DTAI. If you're using Roughtime then you
should get this from the DTAI tag in the Roughtime response if
possible, but if you're using NTS4NTP you probably need to find a
secure source from which to download an NTP leap second file and take
it from that.

---

From: [email-masked]
Date: Thu, 3 Jun 2021 14:49:34 +0200

I've had some time to contemplate this

The more I think about it, the more I'm convinced that for this to be (and stay, medium or even long-term) relevant, it would be of interest to mention and ideally cover GNSS applications.

Specifically the pairs GPS Chimera + NTS and Galileo OS-NMA + NTS have already gotten some attention.

- https://www.ion.org/publications/abstract.cfm?articleID=17758

- https://arxiv.org/pdf/1710.05798.pdf

- my doctoral thesis

(I can supply you with pre-prints, if you're interested.)

On the other hand, with PTP it seems to me that it could get its own solid two-way solution, and then it would get both the points for accuracy and those for security guarantees.

At that point, NSCoPE would be irrelevant for PTP altogether.

This is not going to happen anytime soon with GNSS systems, or radio systems.

How much harder do you think it would be to formulate the concept generically, with the assumption that you have an NTS measurement plus another measurement with higher potential accuracy and potentially in a different timescale, and argue the PTP application more as a practical illustration (and perhaps the candidate for a first implementation in software)?

I would definitely have an easier time convincing my higher-ups to let me invest time and effort into this if it were arguable that GNSS was covered.

P.S.: the "P" in "NSCoPE" would have to be re-designated to "precision-measurement" or something... but that part seems manageable.