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

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 02 June 2021 11:22 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 C24603A3F73 for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 04:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 UHojSBYH_5cB for <ntp@ietfa.amsl.com>; Wed, 2 Jun 2021 04:21:55 -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 75D4D3A11A8 for <ntp@ietf.org>; Wed, 2 Jun 2021 04:21:55 -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 7B95271C0899; Wed, 2 Jun 2021 13:21:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1622632912; 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=3A2onTzLtuUhAWBPboLRwUVZ3+MTw9U2R+VT+mvf2ck=; b=SVf3DyVzx0G5Lle2bXCHmqYnyxIBrZQnSxJF5wC6eHDWhRgba5SP57ScqKVwhQdaB3BjbD YMdRaReBTplKyRX4YooiljUYWiWNbBKUJmILtnAdgfq866jiLUruTiNRc8HLauxkA5CFb1 LR65DjUvskLHclYbdTwwgYtbTDx9hdqK1V4QgqIir5mSaf3ZfXc1ZuDrPWD0CE3LfMm8l9 X96BnlUrRBN4IOmryON+UTdqymxI9BxLBs3ewyTSSh9djw2+BOr4uGVLPw+h63vGq3VKxS EaswdzlZZSoorkHNydezwvqzYKNBWNDWCm1HQ85e/GKJGkjNARpORuDMydqVag==
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 13:21:51 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Wed, 02 Jun 2021 13:21:45 +0200
Message-ID: <D7E29A33-6197-46DE-8DFE-BF498C6374C7@meinberg.de>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <7F9B8D13-BC90-4E15-9BDF-81714DF0F0C6@meinberg.de> <CAJm83bD1yGjtCkSkCQbXKznyPDZC6-bXigsm_BFiprNXkEY49Q@mail.gmail.com> <CAJm83bAXZmJX-7tUFefCMWPsn2QHpxsqe_n=HbjwW4YQSvT23A@mail.gmail.com> <AM7PR02MB57657BD65E85DC1E8F679EFDCF3E9@AM7PR02MB5765.eurprd02.prod.outlook.com> <AM7PR02MB57654101271B9891ABA357B5CF3D9@AM7PR02MB5765.eurprd02.prod.outlook.com> <YLc3k1NM5sXnuY5N@localhost>
In-Reply-To: <YLc3k1NM5sXnuY5N@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Miroslav Lichvar <mlichvar@redhat.com>, Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>
Cc: Heiko Gerstung <heiko.gerstung=40meinberg.de@dmarc.ietf.org>, NTP WG <ntp@ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----638C11AB5EC4C24BCBD6346DF23E6130"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/uJSL_6fMvirQykk9pQeog6pwONs>
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 11:22:01 -0000

> 
> Am 02.06.21, 09:49 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ie
> tf.org im Auftrag von mlichvar@redhat.com>:
> 
> On Wed, Jun 02, 2021 at 12:27:24AM +0000, Doug Arnold wrote:
>> Sorry about the dangling PTP is at the end.  I hit send accidently,
>>
>> I was going to say that PTP is … going to have a security mechanism, becau
>> se industry is making it a requirement.  It would be easiest for implementers an
>> d network operators if it was as much like NTS as possible.  The NTP working gro
>> up is the group in the best position to help solve this problem because you have
>> just been through it for NTP, and because of the security expertise in the IETF
>> .
> 
> The trouble is that PTP is very different from NTP. It's more like the
> NTP broadcast mode, which the WG tried to cover in NTP, but ultimately
> gave up. If the PTP folks want all of the security of NTS4NTP, they
> need to add an NTP-like mode to PTP. A stateless mode where an event
> message has an event response. You know, something like the Sync
> Monitor extension specified by Meinberg.

I strongly disagree with this paragraph. Unicast PTP is unlike NTP in every aspect, even multicast PTP is also not like NTP broadcast mode. 
The PTP folks want security for PTP and our proposal delivers that for unicast PTP. Introducing a stateless mode for unicast PTP would certainly something to look at, but why should we do this if my draft protects unicast PTP as-is, without a requirement to change another standard? 

Today there is NTS4NTP and (unsecure) unicast PTP. Our draft tries to re-use the good work that went into the NTS4NTP draft as much as possible while retaining the unicast protocol and its mechanics as much as possible. Why do you think PTP users should switch to a different protocol or modify the protocol they use to a point where it is more or less a complete rewrite? This is a surprising request to make to entire industries and user communities that chose to use PTP as their time sync protocol instead of NTP in the 19 years of its existence. 

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