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

[Heiko Gerstung <[e-mail]>]

> Am 27.05.21, 15:19 schrieb "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.
Ok, thanks. 

>> It can just use the Sync messages to roughly initialize its time. Even wit
>> hout 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 limi
>> tation 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 jus
>> t tried to point out that the definition of MAXDIST is a part of NTP and therefo
>> re does not exist in PTP - sorry if that did not come across. MAXDIST includes n
>> ot 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 t
>> he 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 st
>> andard PTP practice and very implementation/application specific and out of scop
>> e 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.

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. 

>> > 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 al
>> ready explained, very often require sub-microsecond accuracy and therefore in mo
>> st 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 cou
>> ld 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.

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. 

I do not object to add some text to the draft that explains how to apply error boundaries which rely on half-RTT, but using NTP for establishing the RTT which is readily available from PTP itself and is based on hardware timestamps simply does not make any sense to me.

> 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.
Great, I am open for suggestions how to phrase that and add some explanation to the readers how a PTP implementation can establish error bounds based on RTT. I personally do not think that this is required for a security protocol, because it is more a topic of implementing a time synchronization protocol correctly for a given implementation, but I am happy to add some advice to implementors how they can improve robustness and resilience of their implementations. 

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

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

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.

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

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. 

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

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

The main thing that PTP provides is orders of magnitudes higher accuracy performance. Your approach of combining NTP and PTP does not protect the time synchronization function of PTP without rendering it unusable for a lot of existing PTP applications. I do not understand why you want me to look at auxiliary functions of PTP when protecting its main purpose and reason d'etre is enough of a reason for the draft. 

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

Unicast PTP without NTS is very vulnerable and offers an attacker multiple venues for causing harm to a network (see Section 7 of the draft). The draft provides all the protection that is required to allow using the higher accuracy protocol in a lot of additional applications and hybrid NTP/PTP is not doing the job in most of the current and future use case scenarios for unicast PTP. 

Regards,
   Heiko


-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: [phone] 
Fax: [phone] 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[e-mail]
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung