Subject: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption [FORMAL RESPONSES?]

From: [email-masked]
Date: Thu, 3 Jun 2021 09:07:45 +0200

So, we've had lots of discussion about the general topic that is associated with the draft.

What I feel we as a group are losing sight of is the core of the question that Heiko asked: are we as a WG in favor of adopting the NTS4UPTP draft?

Maybe at this point it is time to take a tally, because I definitely see how a lot of the discussion could be read as criticism/rejection of the draft when it isn't necessarily that.

So far, we've had responses on this overall thread from 14 people, as far as I can see.

On an arbitrarily chosen scale of "strong reject / weak reject / undecided / weak support / strong support", we've heard exactly one voice that I would call a strong reject, one strong support, and at least my own weak support (arguably, a number of comments could be read to represent weak support, but it would really be better to not have to do much interpretation there).

Mostly, people have forgone giving a clear statement on the core question (although we have a number of statements that some draft in this vein should be adopted).

From the NTS drafts times, I remember that I occasionally wished the WG had a more formal approach to these inherently formal matters.

To anyone who feels hasn't given an explicit statement: could you please make an effort to do so - or try to describe what you still require to form an opinion?

Best regards,

Kristof

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

An: "Miroslav Lichvar" <[email-masked]>
Von: "Heiko Gerstung"
Gesendet von: "ntp"
Datum: 02.06.2021 18:13
Kopie: "[email-masked]" <[email-masked]>
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

>
> Am 02.06.21, 15:21 schrieb "Miroslav Lichvar" <[email-masked]>:
>
> On Wed, Jun 02, 2021 at 01:00:27PM +0200, Heiko Gerstung wrote:
>> Yes, it needs to be fleshed out in more detail in a draft. My point is tha
> t you could use a different approach than what we chose in our proposal, but you
> then have to put this down in writing and submit a draft if you are convinced i
> t has enought benefits when compared to our approach. If you believe it would be
> a lot shorter, more compact document with less complexity and provides the same
> or a higher level of protection/efficiency, then please write it down so we can
> compare it in its entirety.
>
> I'm not interested in writing a new NTS4UPTP draft, at least not at
> this time. I'm asking you to reconsider your design or at least
> describe how it compares to possible alternatives.

Well, I tried to describe how it compares to all the alternatives that you and others brought up. Please excuse my confusion, but I am not sure how to proceed from here. I was told numerous times in the past that if I wanted other people to discuss a proposal of mine, then I should come up with a draft. This is exactly what I did with NTS4UPTP. But instead of discussing my proposal, people start to propose alternative approaches (by mentioning them in a sentence or two, most of the time claim that this alternative is either already available or requires only a very short and compact document to describe it and matches or exceeds the security gain of our proposal).

It is pretty hard to try and compare our proposal against a bunch of ideas that are thrown into the discussion. Most of the proposed alternatives seem simple and easy to describe with two or three sentences, but when we drafted our proposal, we found out (once again) that when you try to describe something in written form, a lot of details and corner cases come up that you have to deal with. In the end, you often end up with at least 10-20 pages, no matter how simple the idea sounds in the beginning.

Your last proposed alternative is to use NTP4NTS instead of securing PTP. This is not a request for reconsideration of my design, it is basically a rejection of the entire design. It is not doing the job of securing unicast PTP, instead it introduces a way to increase the accuracy of NTP (and/or NTS4NTP). Users already using or planning to use unicast PTP in their networks would have to completely redesign their sync architecture and infrastructure. They cannot use the security mechanism that is a part of the PTP standard, instead you suggest they should switch to a different protocol.

The first question was why not using MACsec or IPsec. I explained that it will not work because of the loss of the hardware timestamping capabilities.

After that, you proposed to use DTLS instead of NTS-KE. I do not know enough details to be able to compare it. From the few sentences you wrote, I would guess that it will work and would offer a way to secure PTP synchronization as well, but when I compare this idea with our draft, I see these following points:

* DTLS: Asymmetric cryptography would have to be required to be carried out by every PTP server separately for each client (even if this happens only once at the beginning to initialize the DTLS communication). This requires a major modification to the PTP software on the server side and is also requiring more processing power on each PTP instance
* NTS4UPTP: Asymmetric cryptography can be handled on a separate NTS-KE server and is not required by the PTP server to handle the clients.

* DTLS: would require to protect delay responses and announce messages from the server (in the packet transmission phase)
* NTS4UPTP: only requires to use the integrated PTP security mechanism in phase 3 for all message types

* DTLS: would require to write a completely new draft, no volunteers yet
* NTS4UPTP: draft is already there and could be discussed right away, three authors committed to work on it

Not sure if this is more like what you would like to see from me in regards to a comparison.

At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol. I do not think that this is reasonable, it has been mentioned numerous times now that there are quite a number of users operating both NTP and PTP sync infrastructure in parallel and I am still convinced they appreciate to be able to set up one NTS-KE server infrastructure that handles both NTS4NTP and our proposal. And: ee wanted to use the latest and greatest key exchange protocol that has been designed by security experts and time sync specialists.

>> > If you used only NTP4NTS over PTP, you would still have only one sync
>> > protocol. Just the transport is different. That's a couple lines of
>> > code.
>>
>> A couple lines of code? OK, if you volunteer to modify chrony, I would vol
> unteer to test this with our hardware time stamping engine. Just add a comment w
> here you want to get the hw timestamp from our engine and we will add the necess
> ary function call to actually get it from the hardware. Please ensure that you n
> eed to read out at least the sequenceId and MessageType from the PTP header as t
> hat is required to find the correct timestamp in the queue. See my comments to K
> ristof earlier today regarding the requirement to add support for different time
> stamping hardware, but a first test if this actually works would certainly be in
> teresting, so why not give it a shot if it's only a couple lines of code!
>
> It is 7 lines for a quick hack that hardcodes a PTP prefix for all NTP
> messages [1]. Both server and client ports need to be configured to
> the PTP port. If your timestamper doesn't use the Linux timestamping
> API, it will probably require significant changes. I'll leave that up
> to you if you think it's worth the trouble.

Thanks, I do not think it is worth the trouble. There would still be code missing to use the obtained hardware timestamps and replace/adjust the timestamps of NTS4NTP with it. But you brought it up and I believe it could fly and improve the accuracy of NTP/NTS4NTP. Still not sure how to get the time into the hardware timestamper for a server that supports this, but it might be worth working on it.

> I tested it on two NICs: Intel XL710 (40Gb) and Broadcom BCM5720
> (1Gb). Both seem to work as expected. It seems their filter only
> checks the message type and version, ignoring the length and other
> fields. If all HW worked like that and it was acceptable to generate
> invalid PTP messages, the messages could be only two octets longer.
Yes, the good thing about PTP messages is that they are not fixed length due to the TLV concept.

>> The NTS_TLV is not used for the actual sync / delay / announce messages in
>> our draft, that means you have the authentication_TLV as an overhead compared t
>> o standard unicast PTP. This TLV has a size of 42 octets (if I assume a ICV size
>> of 256 bit). The Common PTP message header is 34 octets in size, the size of th
>> e Sync and Delay_Req messages is another 10 octets, resulting in 44 octets in to
>> tal, which proves your point.

> Another thing to consider is that PTP exchanges more messages per
> measurement than NTP. In NTP it's 2 messages to get all 4 timestamps.
> In PTP it's 4 or 5 to get the timestamps and there are also announce
> messages and unicast-specific messages. NTP4NTS over PTP might
> actually save some network bandwidth.

Yes, maybe 300kbit/s per client (~300 bytes less, 128 pkt/s).

> [1] https://fedorapeople.org/~mlichvar/chrony/chrony-ntpoverptp.patch
Thanks a lot.

Best Regards,
Heiko

--
Heiko Gerstung
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: +49 (0)5281 9309-404
Fax: +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
[email-masked]
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

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

---

From: Hal Murray <[email-masked]>
Date: Thu, 03 Jun 2021 02:06:54 -0700

I don't know anything about PTP (except what the draft explains).

I'm working from draft-gerstung-nts4uptp-02.pdf  (which I got a few minutes 
ago)

I don't see any fatal flaws, but it doesn't feel good.

You will have to prove that phase 2 is secure.  That doesn't look easy to me, 
but I'm not a crypto geek.

Why not move phase 2 to the TLS connection?
If you do that, is there any need for cookies?

-- 
These are my opinions.  I hate spam.

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 14 Jun 2021 08:22:48 +0200

> Am 11.06.21, 17:14 schrieb "ntp im Auftrag von Hal Murray"
> <[email-masked] im Auftrag von [email-masked]>:
> 
> 

You can find more explanations about PTP in our blog (https://blog.meinbergglobal.com/), since unicast PTP is quite different from multicast PTP, I recommend these articles:

https://blog.meinbergglobal.com/2014/04/16/unicast-ptp/

https://blog.meinbergglobal.com/2013/09/14/ieee-1588-accurate/

These are short articles. I am sure Doug is happy to answer any questions regarding PTP. 

> but I'm not a crypto geek.

We did come up with this proposal after quite a number of iterations and a lot of discussions and we are quite sure it is secure. As already mentioned earlier, nothing provides 100% security, therefore it is important to define what "secure" means. We believe that the proposed draft describes a method of securing unicast PTP to a point where it is "secure enough" for almost all applications.

> Why not move phase 2 to the TLS connection?
That would be an option, but it would require a lot more resources on the uncast PTP server. The current proposal requires the PTP client to establish a TLS connection once or twice a day to the NTS-KE server. Moving phase 2 into the TLS connection would require every PTP client to establish a TLS connection to each unicast PTP server it uses every couple of minutes (or even more often, depending on the duration of the contract (subscription) for the packet transmission). 

> If you do that, is there any need for cookies?
I do not think you would need a cookie in this case.

Best Regards,
    Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: