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

Heiko Gerstung <> Wed, 02 June 2021 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31F913A3EDF for <>; Wed, 2 Jun 2021 04:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Status: No, score=-4.399 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v1wX-qgCO3ME for <>; Wed, 2 Jun 2021 04:00:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE7313A3EDD for <>; Wed, 2 Jun 2021 04:00:36 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5F3E971C0626; Wed, 2 Jun 2021 13:00:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1622631634; 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=PhReSqs9+V5Q+Lit1dL6SQ9+pRuhIrQC31GWdzYnUkM=; b=KMc9/0fdXjVElEtqKHwUBth5gwKRWkUKswRE0O9nYX1Fo9ee+l5WIq+lzUD1PIXFpBGlPc zZ/FO4xoNUypDGJIC0UFVfVhxE0fTGi+kCHNZ0l48WHG2x2zy9PVuilutLocOLSjHiRvfL pgoDlmcTxo7PpmFoSvSDEXq1PS/N1ITO6kI696w43Sp3FXKOjlbv6HQTx4LN2RkAzRMRgk mc2jLuqGELgKH3du/67rtOvVs8bcg8Nk0ygY7u669xK3Qnr2m8JUQvDADgg6uVrB1ocdQy IpHN+YgQ96p7YWPuRb74COm5I75EKTBr9wrm6DdgqVu3yrCU4cl2GlH03itURg==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Wed, 2 Jun 2021 13:00:33 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.49.21050901
Date: Wed, 2 Jun 2021 13:00:27 +0200
Message-ID: <>
Thread-Topic: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
References: <> <YLYCLIEA4/unB6/5@localhost> <> <YLYheZYTSflAdlrF@localhost> <> <YLY3f2/5k1Hjebf7@localhost> <> <YLZVS4jwGOnMIk6g@localhost>
In-Reply-To: <YLZVS4jwGOnMIk6g@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MTY2Mzc3M2Q1NjU3YjNiNw==
From: Heiko Gerstung <>
To: Miroslav Lichvar <>
Cc: "" <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----7FC6A2E5D6BE208884FA8D6A3945380C"
Archived-At: <>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jun 2021 11:00:42 -0000

> Am 01.06.21, 17:42 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ie
> im Auftrag von>gt;:
> On Tue, Jun 01, 2021 at 04:18:09PM +0200, Heiko Gerstung wrote:
>> > Am 01.06.21, 15:35 schrieb "Miroslav Lichvar" <>om>:
>> > The idea is that DTLS protects everything except the sync and delay
>> > request messages. The unicast negotiation would be protected, of
>> > course.
>> OK, that is something you have to describe in detail.
> The PTP general port (320) would move to a new port, which would be
> protected by DTLS. The client would open a DTLS session with the
> server on that port and use it for all messages normally transmitted
> on the general port. The key needed for authentication of event
> messages could be generated by the client and provided to the server
> in a new TLV together with the request-unicast-transmission TLV. The
> server would use the key to authenticate sync messages for the client
> and verify ICV in its delay requests. Just the first thing that came
> to my mind. I'm sure it could be improved.

Yes, it needs to be fleshed out in more detail in a draft. My point is that 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 it 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.

>> > You can wrap NTP messages in a PTP event message to get hardware
>> > timestamps and keep all the benefits of NTS4NTP. It seems your plan is
>> > to provide NTS4NTP in any case. Do you see any disadvantages?
>> Yes, because unicast PTP does not work in the same way as NTP. NTP is base
>> d on a request/response exchange while unicast PTP is not. I would certainly be
>> possible to put NTP4NTS messages into PTP, but that would have the same drawback
>> that I see with Daniel's proposal to use NTP4NTS to secure the time error of PT
>> P: you need to setup an NTS4NTP infrastructure and basically run two sync protoc
>> ols plus one security/key exchange protocol in parallel. NTS4UPTP only requires
>> you to run one sync protocol and a key exchange protocol.
> 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 volunteer to test this with our hardware time stamping engine. Just add a comment where you want to get the hw timestamp from our engine and we will add the necessary function call to actually get it from the hardware. Please ensure that you need to read out at least the sequenceId and MessageType from the PTP header as that is required to find the correct timestamp in the queue. See my comments to Kristof earlier today regarding the requirement to add support for different timestamping hardware, but a first test if this actually works would certainly be interesting, so why not give it a shot if it's only a couple lines of code!

>> I would also not be happy with the efficiency, because an NTS4NTP packet p
>> robably has some redundant or unnecessary information in it that is not required
>> when I run unicast PTP. And, the other way around, adding a full "dummy" PTP pa
>> cket header to enable using the hw timestamping engine to hardware timestamp my
>> NTS4NTP packets is a waste of bandwidth and CPU cycles.
> If you compare the PTP header to the NTS uniq ID and cookie, I don't
> think it's so bad.
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 to 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 the Sync and Delay_Req messages is another 10 octets, resulting in 44 octets in total, which proves your point. 

>> Such a NTS4NTP protocol also does not address the other advantage that uni
>> cast PTP has over NTP: higher packet rates. You can change that too, of course.
>> In the end you created a third time sync protocol which to me looks more like a
>> Frankenstein monster version of NTP/PTP and is a completely different beast. It
>> will be neither compliant to NTP, nor PTP.
> I'm not sure I follow here. You can send NTP requests at any rate you
> like. That doesn't require a new protocol. The poll field is a signed
> 8-bit integer if you had a server that actually looked in the content
> of the field.
Yes, I agree.

> Yes, server performance might be worse due to the need to decode and
> encode a cookie with each request, but that's a price you need to pay
> if you want all the benefits of NTS4NTP. I'd expect in most cases the
> HW-timestamping to be the bottleneck. If not, you could use
> AES-GCM-SIV instead of AES-SIV-CMAC for cookie encryption to get a
> better performance.

It's a tradeoff, but you get almost all the benefits of NTS4NTP with NTS4UPTP and I am convinced that a lot of current PTP users would choose to use NTS4UPTP and users NTP in need for hardware timestamping might choose to go for "NTS4NTP over PTP".  

>> It may work and add more accuracy to NTP4NTS, but has nothing to do with P
>> TP. And yes, you can argue that nobody needs PTP anymore in that case, but I am
>> not sure it will be a pleasant discussion.
> Right. :)


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 
Do not miss our Time Synchronization Blog:
Connect via LinkedIn: