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

[Daniel Franke <[e-mail]>]

On Thu, May 27, 2021 at 11:13 AM Heiko Gerstung
<[e-mail]> wrote:
> I tried to explain that there is a RTT computation taking place, the client simply uses both sync and delay_req/resp messages for this. Maybe Doug can explain this to you in a better way.
> There is a RTT calculation, and a PTP client uses RTT/2 as a correction for the incoming sync messages.

I'm pretty sure I already understand. In the case of both NTP and PTP,
you have a calculation like

theta = ((t2-t1) + (t3-t4))/2

In NTP, there's just one exchange that gives you all four timestamps.
In PTP, you use DELAY_REQ/DELAY_RESP just for t2 and t1, and then you
get t3 and t4 from the SYNC message.
Trying to do without the SYNC message would give you bad results,
because there's no hardware timestamp on DELAY_RESP to give you t3, so
you'd be forced to treat t3 as equal to t2 or t2 plus some assumed
processing delay.

And then your maximum error bounds are ±((t4-t1) - (t3-t2))/2. Err,
okay, I guess that still works out when you do it with separate
messages? (t4-t1) will be big, but so will (t3-t2) so they'll cancel
each other. But by "works out" I still mean "works out to ±half-RTT".
It is not possible to improve on this.

> I try again to explain what I believe you are missing here. Any application that requires sync has a minimum requirement for synchronization, i.e. any time error greater than this limit is going to affect the application, in most cases it completely avoids that the application can be used anymore. In some cases it degrades the application to a point where financial damages are negatively impacting the owner/operator of that application. And in some cases it can cause physical harm to human beings (think of a power grid protection system which cannot continue to work without very tight synchronization and therefore might trip a circuit breaker as a precaution, creating a blackout for hundreds or thousands of households in the process). For those applications, there is no reduced sync performance under "adversarial conditions", the synchronization solution either delivers the required minimum accuracy or not. Most if not all applications that use PTP require a sync performance of a microsecond or less, that is the reason why they deployed PTP and not NTP.  NTP accuracy is not good enough for these people and therefore it does not help at all to introduce a concept which considers a degraded sync performance under adversarial conditions.

People who have these kinds of requirements *must* physically secure
the network links they use for time synchronization. NTS cannot
provide anything that will help them. My proposal won't do what they
need, and neither will yours. I know you have customers clamouring for
a solution and that you want to give them one, but it is simply. not.
possible.

> OK, you just changed your principal reason why you object to adopting the draft after it seems I convinced you that the initial reasons why you object adoption of the draft do not exist. I am a little bit at a loss here, because I do not know if I can convince you *at all* to support adoption. But anyway, this is too important and I will keep trying ;-) ...

Yes, at first my biggest objection was "this won't work". You've now
offered some clarifications and accepted some corrections that would
allow it to work about as well as my alternative, but still not nearly
as well as you claim it will and not nearly well enough to satisfy the
use cases you've described in the previous quote. And so different
objections rise to the top.

> I am puzzled that your main reason is that you believe this is a lot of work for a lot of people. Three people with a lot of experience in both NTP and PTP already put a lot of work into this draft and tried to reuse as many parts as possible from NTS4NTP to minimize the required work. These three people are willing to continue to work on this draft, and I am sure that others will join. If you personally do not think it is worthwhile, I fully accept that. But I believe you should not speak for others. In addition to that, your new principal reason to object the adoption can be applied to every new standard, especially when it is timing related. For example, you could ahve applied the same reason to NTS4NTP when it first came up as a topic.

Your proposal reuses some parts of NTS4NTP but still involves a lot of
new work, probably including building new silicon. Mine reuses all of
them. NTS4NTP was a lot of work for a lot of benefit, and part of that
benefit is that it gives us a nearly-trivial way to also secure PTP.
Sure, "this is a lot of work for little benefit" is an argument that
can be deployed against any new standard, but sometimes it's true and
sometimes it isn't!

> Nope. There is nothing available *TODAY* that comes even close. You are comparing apples and oranges. The draft offers the same level of protection against cybersecurity threats that are covered by NTS4NTP. It does so by maintaining the full accuracy level of PTP, i.e. sub microsecond time synchronization. An NTP/PTP combo can only protect your time to the accuracy level of NTP. It is not an alternative to what we propose with this draft.

NTS4UPTP does *not* maintain sub-microsecond precision under
adversarial conditions. You are making an impossible claim. I can't
yet tell you exactly where your error in reasoning is, because you
haven't specified the client behavior in enough detail to give me a
stationary target to pick apart. If you'd care to explain exhaustively
what checks and calculations you expect the client to perform, and
what better-than-half-RTT bounds you claim to be achieving, I'll
happily reciprocate with an equally detailed protocol trace that
illustrates how an adversary can mount a delay attack in order to feed
the client time that passes your checks but falls outside your
asserted bounds.

> > 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.
>
> I doubt that this is possible with unicast PTP. I kindly ask you to explain how you want to achieve that without a major redesign of the protocol, at which point it would not be PTP anymore.

That's easy. You just need to require the client to prove that it's
actually able to receive traffic at its claimed address before you
send any significant traffic in that direction. You can do this by
sending the client a random or pseudorandom token that it's required
to echo back before you'll send it anything else, and periodically
repeating this challenge to prove that it's still there. You can do
this with no cryptography at all, or with just a little bit by having
the token be a MAC over the client's network address and a timestamp,
computing using a key known only to the server. The advantage of
constructing it this way is that the server doesn't have to hold any
state related to the client until it has already passed the challenge,
because it can recompute the challenge token rather than having to
store it.