Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

Heiko Gerstung <> Mon, 08 March 2021 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE2C93A0ACB for <>; Mon, 8 Mar 2021 08:31:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kjdD01RlgZ_3 for <>; Mon, 8 Mar 2021 08:31:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 022303A0A06 for <>; Mon, 8 Mar 2021 08:31:52 -0800 (PST)
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 8EDD371C11E5; Mon, 8 Mar 2021 17:31:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1615221109; 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=PpHVDxwKkAYecSHOf898mXQcjv1GbqpodJXGlcOHHp8=; b=WCngxAs8eJgb7wfgNJNyr1X58JoPv5fBLJMutkCtMMhG29yk7vXEIWHv1KhRcx6bK3pf/e mqbwzOyYJPk3o/OzzGlBRMZrUfs4miJLJr+BHR8Y9ItkgrlI8bXF40vwZwyGnEFqUXp4sa EAo5o+OTc/NFKYiXLARAPF/m7l6dCblCGSS9LvNlGx9XezXs0AkT59YnoOpb6rpdUCPzw/ sLOY9NgbEz+dKUpyYG7wFsedzOmi4Jv/ojnSRqkI9URKPBpwfqotWGesynjMzyxWuvy4t1 EAxZzEQnVLZ9GEEn2Djbas72ZzwKq7NIviGMAK18iepLs0ubftLtTgIvwo/B8g==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 8 Mar 2021 17:31:48 +0100 (CET)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.46.21021202
Date: Mon, 8 Mar 2021 17:31:45 +0100
Message-ID: <>
Thread-Topic: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
References: <> <> <> <YEYHHhIrYv4ZhTkl@localhost> <>
In-Reply-To: <>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmUxZmZlYTJhY2NhZTU2Mg==
From: Heiko Gerstung <>
To: Dieter Sibold <>, Miroslav Lichvar <>
Cc: Watson Ladd <>, NTP WG <>, "Langer, Martin" <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----6D7892FB6663CE2CAE5ECB68761D4BF0"
Archived-At: <>
Subject: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Mar 2021 16:31:56 -0000

Am 08.03.21, 13:13 schrieb "Dieter Sibold" <>:

>    On 8 Mar 2021, at 12:14, Miroslav Lichvar wrote:
>   > On Mon, Mar 08, 2021 at 11:43:29AM +0100, Heiko Gerstung wrote:
>    >> As far as I can see, up until this point the mechanism can be very 
>    >> similar to NTS4NTP. We most probably need a different cookie format, 
>    >> but the rest should be OK. Once we did 1 + 2, the unicast master will 
>    >> start the PTP packet transmission to the authenticated (via the 
>    >> cookie) PTP client. The client will also start sending Delay Req 
>    >> packets and requires the GM to respond with unicast delay responses.
>    >>
>    >> During this packet transmission phase I propose to use the S2C to 
>    >> secure the packets from the GM to the client (ANNOUNCE, SYNC, 
>    >> DELAY_RESP) and the C2S key to secure the packets from the NTS/PTP 
>    >> client to the GM (i.e. DELAY_REQ).
>    >
>    > I don't think it makes sense to use NTS cookies in PTP, even if you
>    > limit the NTS support to the unicast mode. The main point of the
>    > cookies is to avoid having client-specific state on the server. That's
>    > not possible in PTP as announce and sync messages are not responses to
>    > requests. They are sent at their own interval, which can be different
>    > from the delay request interval.
>    >
>    > In PTP there has to be some client-specific state and the clients need
>    > to be authenticated. Very different from NTS-for-NTP.

>    I agree with Miroslav. There is already state information defined in the 
>    IEEE 1588-2019 version in the context of the Authentication TLV. It 
>    should be possible to use them also for this purpose. This would make 
>    things easier compared to offload state information via cookies to the 
>    slaves and would minimize computational for the master.

A PTP unicast master can respond to 128 delay req/s and send 128 sync packets per second to each slave, we are talking quite powerful machines here and I do not think we have to store state information in the cookie. 

A client - just like with NTS4NTP - uses the cookies it gets from the NTS-KE server to authenticate itself vs the unicast GM. The cookies basically provide proof that the client successfully communicated with the NTS-KE and correctly ran phase 1. We would need a little bit of extra state information that needs to be stored on the unicast GM (which already stores state information for every client that successfully requested a unicast transmission). 

My biggest point here is this: yes, it would be possible to design a more lean and more efficient protocol for PTP because PTP already requires some state information being stored on the server. But I believe that this would only save an insignificant number of bytes and CPU cycles on the GM and also on the unicast PTP client. As a benefit, we would get something that is close to how NTS4NTP works, allowing simpler implementation (the NTS-KE part is almost identical and an NTS-KE server would only require some minor modifications to work with unicast PTP clients) and a much faster adoption by the PTP hardware vendors. 


 >  >
 >   > -- 
 >   > Miroslav Lichvar
 >   >
 >   > _______________________________________________
 >   > ntp mailing list
 >   >
 >   >

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: