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

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 02 June 2021 16:12 UTC

Return-Path: <heiko.gerstung@meinberg.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 59FB73A1050 for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 09:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=meinberg.de
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 r_GInzK6vYea for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 09:12:33 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3F73A104C for <ntp@ietf.org>; Wed, 2 Jun 2021 09:12:32 -0700 (PDT)
Received: from seppmail.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id C455771C06D6; Wed, 2 Jun 2021 18:12:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622650349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8inHuU+q5m9tL2ME2fvN9c16KCz7nN/rNqDuuZ2TErQ=; b=eM0ud/I4TzWq2i7oZ+97RHsaVX5WXdNrMejhOFOxZ2132v+9wui92nQ7m4OfG/0pTt/6vZ ht5WqWzgh9EQ2yGDCvNbTE1QlwnVnqWVWZu55UOv9UUjrD5Lxd0daNUiUn0oKx221UJi+u pBEKx4i+KT7mqrkc17mK7Pcl96CSzySJt68oS1AMM34v5lZBn27sYbJacRMhgpiCo9Dhpa xOFDh71XF+79tNsA0ec4/9wMeMirCAjzuBfpOzOi+sIJq/AHHdnQJ6Zr5HvUTH48oOEzMW SQNAEADFAYkUod9eI4G+gC8SDa13p9fVrsbAn0DWV/gqMg7OYjZa5S5ObHLwBw==
Received: from srv-kerioconnect.py.meinberg.de (srv-kerioconnect.py.meinberg.de [172.16.3.65]) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by seppmail.py.meinberg.de (Postfix) with ESMTPS; Wed, 2 Jun 2021 18:12:29 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Wed, 2 Jun 2021 18:12:28 +0200
Message-ID: <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <YLYCLIEA4/unB6/5@localhost> <1DAA3605-CC04-46DE-8CFC-975BED7D4160@meinberg.de> <YLYheZYTSflAdlrF@localhost> <CEB3F4AA-E318-4540-BD6C-4437E3F5F58A@meinberg.de> <YLY3f2/5k1Hjebf7@localhost> <7167BC2B-1889-4DF5-AF7C-BAAAB3586841@meinberg.de> <YLZVS4jwGOnMIk6g@localhost> <24DF9BF2-3072-4152-80D6-9F10D53A59AF@meinberg.de> <YLeFyqZp6bZY9nY9@localhost>
In-Reply-To: <YLeFyqZp6bZY9nY9@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----8EE59AA10D96FDD321EE4E1791812600"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Kr4MeyiUVYa75zE7fQsvm51HjOw>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
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: Wed, 02 Jun 2021 16:12:39 -0000

> 
> Am 02.06.21, 15:21 schrieb "Miroslav Lichvar" <mlichvar@redhat.com>om>:
> 
> 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: 
heiko.gerstung@meinberg.de
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