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

Greg.Dowd@microchip.com Wed, 02 June 2021 20:52 UTC

Return-Path: <Greg.Dowd@microchip.com>
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 E82C23A12F8 for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 13:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=microchip.com header.b=1nj9pqAf; dkim=pass (1024-bit key) header.d=microchiptechnology.onmicrosoft.com header.b=bcoj1ziO
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 k-fHIy9IhJUJ for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 13:51:57 -0700 (PDT)
Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) (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 8AE0D3A1AA2 for <ntp@ietf.org>; Wed, 2 Jun 2021 13:51:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1622667117; x=1654203117; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ObxP4ZMBhT8UDhA18puyi0y9YzjFF3XypRJQ4RtHbnE=; b=1nj9pqAfTTZgZMQ0CNJWBBEUM61mT7hBl+iXhAE6aSAzr/nfdJ0bpLvC VilT6lH0HdK+NxIpIHAH49gLu604iTyCAIbHyWJ4Ey3q4/muAtuJBCSYg 5Ak4Kl25SRmEeNjY4spZoCiiJ5KQ6eOmRb5/XzI/8ORq6pK5RFGwMc5gH PS/dtkoKxFcpva+mQiieG+MIW2WpFwuZWCBBg+SqhOnFGZXuSeTFPuvIC KvkqlmO0B+N7rs2w02AsCTSfk7Ai2frukru9qIOCULUN2eNuKEOwI2Kr1 ILm+mSuYWzb7/d4B4Bc76rP9dTbgXxfY95VSZMsgpiNcnmN89ztk0l7On g==;
IronPort-SDR: DUdGwpspnUOh52bdwvWulDqVCANluP3mPGepvyzwvuTFyNy9Gaz8HSSnVHB3tJH6hXLkeSoDMB bV/26WGZ8/E38i8K6yptQlykuPwc3S8aaEXnYwdO7LpPSSuVvdbssGKYa8c9hJU9i0W3K9ixTB 0XemdN310OH8PEsSG/AC7R4iXJloJVQgyQNK2obnVcxT265XuWWZtiITvyDarW9pjjJB9oVNFi 7xUMkNAPT1jk09DcTY9iEPCK4+C8B4A/0RoRjt+iri/qVMnjI4/tr7gYT+fmSNg/4XZZcsTnMw NgM=
X-IronPort-AV: E=Sophos;i="5.83,242,1616482800"; d="scan'208";a="57678017"
Received: from smtpout.microchip.com (HELO email.microchip.com) ([198.175.253.82]) by esa6.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 02 Jun 2021 13:51:56 -0700
Received: from chn-vm-ex02.mchp-main.com (10.10.87.72) by chn-vm-ex02.mchp-main.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 2 Jun 2021 13:51:55 -0700
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (10.10.215.89) by email.microchip.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Wed, 2 Jun 2021 13:51:55 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d1uSw+K9szoMarylWngOm2ugE+/TAf/7/+gV7bmcqjV4sINM7guTP4GjdoURuYDtv0N4YhOjaNdy/kwHu+lbkscKPDeEyLPNZ5GkHrUF2jJKQvfoMlra/h3sMR2BI3tQOZDuEGxnXqVWS2f/DokyK7raiT0h7R/TaVBSnP56Q7k37M519ADjKqI2CbYJlafRs0sYVBtQ6Y2EaRLQfb96VSKZWOrofN8y9tkE1WkaDhfISYMs+prg0eRY1SfHUbJ90B8dRoAEXAGoKMeyXpvlsPtcAwTro0dRrQcEWim6iOh32gTZ968quyieEhTslUo7wduNO+eGWf16gK2/vGvRtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ObxP4ZMBhT8UDhA18puyi0y9YzjFF3XypRJQ4RtHbnE=; b=AjmfakdIYV2PmX3rrpovx3pZLJDp2EHFS72n63KSWumgdulnRlyOw7MhfmP+gC7pcIAnqSyxuywBx/gLGLfUCJN7zJ6vWvUseTG8gUk6V+ApxYZ1L1BfA9Aj+IsRnDTqGqnH+Dux7+Km7axi+BxtkDSAfoHnuTDf2Y8OcPYINNy64Wg576CIrCXRM6ennrGs2nNjMcS20qYK4i55vYXxxxH/Dlx3rcN+vXYL8xNRiKLtJnWkFBWPIKu3hlOMTKZi0HHKpAekq1GUeCiiUTa1RynRNUqaImTizt7m7QLhzCHW+7x/PhAkRUkSRjBEgiuM7mfRI75fVtYXFnkr7njmFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microchip.com; dmarc=pass action=none header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microchiptechnology.onmicrosoft.com; s=selector2-microchiptechnology-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ObxP4ZMBhT8UDhA18puyi0y9YzjFF3XypRJQ4RtHbnE=; b=bcoj1ziOqOrKB5pra0VONQFA2bcJZ6jR9mbKAgGA32Hj6SsyVtOJCv26QI1BcjYQBMnmQbSy5LrhnAPoH2fYEtcCvfYO4dcQlNDQGB4YbD1p3HViJXhlNufy7GY9qSly9mtCIG2walB4RiDHp0GYi+k7JsUvhVvOuewqnSNWIrE=
Received: from BYAPR11MB2760.namprd11.prod.outlook.com (2603:10b6:a02:c0::26) by BYAPR11MB3238.namprd11.prod.outlook.com (2603:10b6:a03:7e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.22; Wed, 2 Jun 2021 20:51:53 +0000
Received: from BYAPR11MB2760.namprd11.prod.outlook.com ([fe80::79c0:74f:190:d146]) by BYAPR11MB2760.namprd11.prod.outlook.com ([fe80::79c0:74f:190:d146%3]) with mapi id 15.20.4173.030; Wed, 2 Jun 2021 20:51:53 +0000
From: Greg.Dowd@microchip.com
To: heiko.gerstung=40meinberg.de@dmarc.ietf.org, ntp@ietf.org
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
Thread-Index: AZ2x3tU+ZTljNmQ4N2MwN2VmZGRlN/NJ2JQAAAMO24AAAZtGgAABqW4AAAGes4AAAYKJgAAC7iCAACh054AABOqzAAAF+vIAAAlL93A=
Date: Wed, 02 Jun 2021 20:51:53 +0000
Message-ID: <BYAPR11MB27603F696ADE803AEDA6A25CFC3D9@BYAPR11MB2760.namprd11.prod.outlook.com>
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> <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de>
In-Reply-To: <B5F7602A-B084-4B21-9EB2-D25AB030E1EA@meinberg.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microchip.com;
x-originating-ip: [12.177.68.254]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: aba261ae-2758-43d4-7f67-08d92608408f
x-ms-traffictypediagnostic: BYAPR11MB3238:
x-microsoft-antispam-prvs: <BYAPR11MB3238985ED7E8F9177747920EFC3D9@BYAPR11MB3238.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:913;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0snF4Vyv64mYoE3iO3/x2gu4zM5XzG2rFHicJsAH6x6B14i3k0+mrF2aXo3u4F78sGGt/PvI8OvI0s4nXW8jQ07ybaJ5ZNDi4NqC57mjLpGwwEv/5+BY/NyvTYAKYhYkA//IQeVZ7aWnPKBoz20eYAL5iOVeHXszqzfo554Q2ypVbvXzo1oux++juPeHHt50JWMv93gXP9LkWIogvk+woFKhQnnO2FLiAWaRbnK+aUZEtkn0/pIzGQnONQtprrm34uClu3aa/IiF0Sv5VhX4dZdsMbfkn4PyaSfl0jTW0QU1bCf3OQoxF42qdFKcGv36QRIDUkONAdJC6mvRy5TctWzQTe6jyopshXtLvyajBJslXZISQRi2Q7C50RRn/3TIktGEN9mUcB7c+qmooZL7dHcf5UyDvcmmR2B0Uavd5ht9IqU7oFRdQhuW71Uh74yjIIYg2Vs37Jcy8L/mA46bM20xiTJOXPtcXXUR7QsTLrmNrX9LwfEijgASg+V2WQTkwnYyxzfkpP9F6gsd+PRQVi1M1NwYy/gJYgMUnFaaOoMyuQRT920czFbupgSs6PKPTP8uOW/4m7ehIX663+WH0DlZVtdsWXbKXe6EATOhovcKehh/zU+6CIZeyIUoetJGd8vf9epTQN2Ln/YJBGTR8lDzt7PmEPUxTcZMkSriy/GvbbRd6htqihlxRXHg15CjCxinDO64ODEu8RQnUGlHYYS1g91dY15wR9QHIgrO3fIoYyemO6sC2Xn+XKXANrBQaFph7i9ufHaVTvjyM8DXnw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2760.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(366004)(39850400004)(376002)(136003)(186003)(66946007)(966005)(66556008)(83380400001)(64756008)(66476007)(66446008)(5660300002)(478600001)(122000001)(86362001)(66574015)(2906002)(76116006)(45080400002)(33656002)(6506007)(8676002)(30864003)(9686003)(316002)(7696005)(110136005)(53546011)(8936002)(38100700002)(71200400001)(55016002)(52536014)(26005)(32563001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ycx73dKMByzJFz+mxWN7iffZw2DU49aSHPBAPOzzJN065QtZRS72jp/iUbLzFmAO37XyNeucqKZs3Jj6W4ayQUY82pEIOhBaF/ErT0v+y31jikb2/zsDiLWa2iPCr0CuhRKeI6xMcPuMn+q4kUjOIIaEcHKQK5R5b8sd1jkMxWeKJw7gg0LYcO1X3i6dAK/ac4fRy+SWvbPAvFqnB40Dc3iWjx71OkJkYybQOuwTpA4liaOrhimef+AQ8GLugslesV3ORmA9C2pSAMdwuChj8GzXmc5c+/FgRajnh8T6peuNBKdNcvl+q3O23c7rKR9L8+Ca01t+LVSQUkZZvcZ+L6kpLlaJuPu6qrGIOfc+DMHSChzoKo8uZIZFn2UVkZBwtMeZGJO66ci6j5wZJ4zSXPR+luUsiw+R+q1ftAKJx6uqQYj44kogbd2k37cJNgix9WFbya9wr8Q0c/bqWrYNCozDb0zt4O/1/W7m7tGzx0pyV9w+Z0Pi1l3/gTRrQGNJPLXdJiZyKo5lbDR6MsFfaYbEE6n++BWEdJwin+GoiYyVZ1k3UMdK1avQ9+w3zwXHsyIaf5+jWO1uqm47O22yxpufSzI6fddvX07LS3YDRuHxDoQk7bfu5OjUlZH+ZWy9xT0FuxbaS6UIGmeKYBMGwL5kEjL+pQdkZcEO17ABtMBrE8anJ5PvdXRWDPagCyRnrqh/Pp6qVNPC6q3G7LpiABkClEkKYIQGiUeC7g4Ah37twSUOePLh0BCuqOAKVK1JzliqlPD51utKaYmUNipJMtL58VzRH0Nl9+WlCrdfLhE/ITlLC+r4Ry4utc8CRMw9TKRmZWyaIC2I1HHNabfEkYTRNNzQsq+6S00SsujMaM9XHvAuP8CEPDMMnakHaZ5QvT4nTYtwTMRMx/YgxBldHgY03xVsLL4AMsIUSt5l7DRJOLDmwY1Ob8qivEeH8wlB6hTko79npoliCBHFy54WvrMTXbwWHTviX7d2IdISQ/9D6ss1mAbS32n+iKMSZ1Yq6Z7irXZ++bg3xexZrOv90gg1augDUV7/BiUdNq+Ch+P+8joAgRaTDPB57f5wjkbDs1Elvxt5wtPXFjnNJ6Rn7jA3DTWM3EHXkVTbRWLDtz7N0oQxGpvw2Mh7KMhmHK3EPtQQXWOwfvvFtINi8A8cBPXuCeS1OxLzaTuoV584JrJMmU2Da4cGZkx6XeUbvv8a/XG4AV6Lv/Zh6kM2jOneCVi1tDVMIORk453ZjNFWzK+W/TdIIkSrAcDQ/xsNj2OEvvJu0qWaFmBSCwOcEhE21zpAp423GCsTG3MV/teuPi4cWVHIvtWJjTJHr0cOieaO
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2760.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aba261ae-2758-43d4-7f67-08d92608408f
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2021 20:51:53.3056 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: W2841cSvgRRXPiRVitEWuPTLo+2+zkkg7qh40NeLD8xCVZqR0cGBPlbKrfBmey4D0p7+qJi2vyu69wokFOCScA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3238
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-lCDTtWNRMVw3ISHNuY8iTU4q3Y>
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 20:52:03 -0000

This sounds like a lively and interesting thread.   I'm sorry I have been missing out 😊  I think the NTS4UPTP makes a lot of sense from the position of having generic utility for implementing network timing protocols and has security optimized for the large number of small, ephemeral timing packets.  This is something that has come up in the past and it looks like this draft does a good job of covering the ground.  In the way back, when S/NTP (secure NTP) was being developed, the feedback was that unique implementations from protocol providers was not a good idea and we should leverage existing security protocols.  The same argument was applied to Autokey and the recently proposed new version of Autokey.  8915 looks to be the closest thing to a standardized timing protocol security model we have implemented today.  It seems like that is what this draft covers, extending the security model to support an alternate timing protocol which has many attributes in common with mode 3/4 NTP.  I don’t know that they actually need to be the same, but I wonder why they would instead need to be different?  8915 has the extensible message types that are designed to support extending the protocol, why not use them?  C/S, or L/F PTP and NTP are quite similar in actual use although the use of hardware acceleration is far more common in PTP (and its associated strengths and weaknesses).

Thanks...Greg

Greg Dowd  Microchip - Freq & Time Div.

Assoc. Technical Fellow – Engineering
3870 N First St, San Jose, CA 95134
Direct: 408-964-7643
Greg.Dowd@microchip.com

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Heiko Gerstung
Sent: Wednesday, June 2, 2021 9:12 AM
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: ntp@ietf.org
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

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