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

kristof.teichel@ptb.de Thu, 03 June 2021 07:07 UTC

Return-Path: <kristof.teichel@ptb.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6643A2D79 for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 00:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.719
X-Spam-Level:
X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43DCF4UqpyYR for <ntp@ietfa.amsl.com>; Thu, 3 Jun 2021 00:07:52 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9073A2D77 for <ntp@ietf.org>; Thu, 3 Jun 2021 00:07:51 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 15377mVs015886-15377mVu015886 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <ntp@ietf.org>; Thu, 3 Jun 2021 09:07:48 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id AFEC0B77520 for <ntp@ietf.org>; Thu, 3 Jun 2021 09:07:48 +0200 (CEST)
MIME-Version: 1.0
Sensitivity:
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To:
References:
From: kristof.teichel@ptb.de
To: NTP WG <ntp@ietf.org>
Date: Thu, 03 Jun 2021 09:07:45 +0200
Message-ID: <OFF51374C9.98B99AED-ONC12586E9.002729B7-C12586E9.002729B8@ptb.de>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/pVx1WERX-AYB0bn9TRDn4D8-TJg>
Subject: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption [FORMAL RESPONSES?]
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 07:07:58 -0000

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" <ntp-bounces@ietf.org> schrieb: -----
An: "Miroslav Lichvar" <mlichvar@redhat.com>
Von: "Heiko Gerstung"
Gesendet von: "ntp"
Datum: 02.06.2021 18:13
Kopie: "ntp@ietf.org" <ntp@ietf.org>
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

>
> Am 02.06.21, 15:21 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>:
>
> 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" rel="nofollow">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:
heiko.gerstung@meinberg.de
Web:
Deutsch https://www.meinberg.de" rel="nofollow">https://www.meinberg.de
English https://www.meinbergglobal.com" rel="nofollow">https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog:
https://blog.meinbergglobal.com" rel="nofollow">https://blog.meinbergglobal.com
 
Connect via LinkedIn:
https://www.linkedin.com/in/heikogerstung" rel="nofollow">https://www.linkedin.com/in/heikogerstung
 
 

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp