Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Daniel Franke <[e-mail]>]

On Thu, May 27, 2021 at 6:15 AM Heiko Gerstung
<[e-mail]> wrote:
> Who defines which of the goals are more critical than the others?

The text of the draft speaks for itself authoritatively; anything
further I have to say is just my opinions about it.

> It can just use the Sync messages to roughly initialize its time. Even without a two way delay measurement, a client will be able to synchronize its time to the server time in a good enough way to avoid a 8 minute offset. Only if the RTT is >= 16 minutes, you are in trouble. That means our approach is not usable for space ships that do not carry a solar/battery backed up RTC, which is a limitation I can accept.

So, I think there's an approach that'll work here, and you're close to
it. The key thing is that it's possible to dispense with the 8-minute
check if the client has not yet wrapped its sequence numbers for the
first time since running NTS-KE. At that point there's no risk of
confusing which request a response with a particular sequence number
is replying to, because there's only one possibility. By the time
wrapping begins, the client should be synchronized and therefore able
to apply the 8-minute check. In the unusual case that it isn't
synchronized yet, it needs to re-run NTS-KE.

> I agree that a client can define its own limits for a maximum delay, I just tried to point out that the definition of MAXDIST is a part of NTP and therefore does not exist in PTP - sorry if that did not come across. MAXDIST includes not only the delay between client and server, "but the whole distance back to the reference clock as reported in the Root Delay field" (RFC8915, Section 8.6). I agree that a client, depending on its own requirements, can define a limit for the delay between itself and the PTP server, but MAXDIST is not a term we can use for PTP.

Okay, I don't think we're disagreeing on anything of substance
surrounding this point. Yes, PTP will require different terminology.
And yes, NTP also includes the server's self-reported maximum error
due to upstream hops into its "error budget" when deciding whether a
packet is suitable for synchronization, while PTP can't/wouldn't do
this. But otherwise, the fundamental concept is the same.

> > 1. Send DELAY_REQs at a modest interval. Use the error bounds
> > established by these volleys to sanity-check the timestamps in the
> > SYNC packets.
> That can be done, but it does not require to change the draft - this is standard PTP practice and very implementation/application specific and out of scope for our proposal, as far as I can see.

It doesn't require any *on-wire* change. But the necessary client
behavior of using the delay messages to establish a range of plausible
times that are used to clamp SYNC messages is not described anywhere
in the current draft. And, as you've already taken pains to point out,
using delay messages to obtain the round-trip measurements that are
needed to compute these bounds is definitely not standard PTP
practice.

> > 2. Send DELAY_REQs frequently, and don't bother requesting SYNC packets at a
> > ll.
> This will not work and violates the basic concepts of PTP.

On the basis of Miroslav's explanation, I agree.

> > 3. Get error bounds from altogether outside of PTP and use them to
> > sanity-check PTP SYNC packets.
> This may be a good additional check, but will ultimately reduce the level of accuracy to the accuracy level of the outside method. PTP applications, as already explained, very often require sub-microsecond accuracy and therefore in most cases it is not useful to set up error bounds which are exceeding the minimum accuracy level required for an application to continue to work. An attacker could still bring down the application itself while staying "below the radar", i.e within the error bounds.

Here's what I think you're missing. We need to distinguish between the
precision afforded by PTP under normal network conditions, versus
under adversarial conditions. Under normal network conditions, the
precision afforded by either of our approaches is in the
sub-microsecond range that your customers have come to expect from
PTP. My approach will have literally no impact at all on PTP's usual
precision, because the PTP messages and the way they're processed are
untouched Your draft's approach will have some non-zero impact because
of the time spent computing the MAC tag, but I expect that with some
careful tuning this impact would be too small to measure. So for all
intents and purposes we're equivalent on this score.

Under adversarial conditions, the potential error of my approach is
±half-RTT, ± some other miscellaneous error terms that don't amount to
much by comparison. Without the fixes I've suggested, the potential
error of your approach is unbounded. With these fixes, it again
becomes the same as mine. Doing better than this through cryptographic
means *IS IMPOSSIBLE*. If you want secure sub-microsecond precision,
you must get it by physically securing your network segment. If you
tell your customers otherwise, you will be selling them snake oil.

So, a fixed version of your draft would provide time precision
equivalent to what hybrid NTP/PTP provides, both under normal network
conditions and under adversarial ones. Unlike hybrid NTP/PTP, it would
not provide for client unlinkability or server statelessness, but
perhaps we don't care much, and I wouldn't base my opposition to
adoption on this alone.

My principal objection to adopting NTS4UPTP is that it will be a lot
of work for a lot of people over many years before any end-user has
access to interoperating implementations of it. In contrast, hybrid
NTP/PTP can be had *TODAY*, using linux-ptp and chrony in the
configuration that Miroslav suggested a few weeks ago. All the work
that's needed is for Miroslav to double-check that chrony enforces the
correct the error bounds, and for somebody to write an accessible
HOWTO plus *maybe* an Informational RFC. You've not argued any
marginal benefit to NTS4UPTP that I think comes close to justifying
the development and rollout effort.

If you want to change my mind about this, I suggest you try convincing
me that PTP has functions that are auxiliary to time synchronization
that still need securing. Can an attacker do harm to an unsecured PTP
deployment in ways other than just desynchronizing clocks? DDoS
amplification is one example, but that can be solved in a much
lighter-weight fashion requiring little or no cryptography. What other
examples are there? How about the management functions in section 15 —
what sort of mischief can be done with those? Is there demand for the
ability to use a PKI to secure access to them?

If you do convince me via this avenue that there's worthwhile work to
be done here, I'll still advocate hybrid NTP/PTP for the long interim
before that work is usable.