Re: [Ntp] NTP over PTP

Heiko Gerstung <> Mon, 28 June 2021 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FBD03A0C49 for <>; Mon, 28 Jun 2021 08:02:53 -0700 (PDT)
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 YPTXMHsuRZ_y for <>; Mon, 28 Jun 2021 08:02:48 -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 E1D783A0C46 for <>; Mon, 28 Jun 2021 08:02:47 -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 AD71771C1376; Mon, 28 Jun 2021 17:02:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=d2021; t=1624892565; 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=OBOjimaPOHlm6gijHAphHW09Q/kSzw5fzuVwbON05MY=; b=jmgb+g4NsI9MkS0GWEDl/4Gtlxs7p/MezrPcWiSmHusXY7QuChUwS+QD9qnrhgUqYH4ieU YW4Q7WXhJRoeFGGpd5AdKfQdE+lQ7Ue5s2yFsIzyhIvxQQ+nQVOWSBMaCxLE4fxSX/rBPQ sgKvI1AhswjKNyeQEKGgZpL5Q1O9CWtSDz3drccXfM7nRc0UKGK+XwKynLtP4SMGnVxn4Q 3tD2QGSW3UdhnktfrH52aJw7GSUhTmRv6WSsR3WK+5wmZ+JHVYigqL5k5E9DUssM3LONaX BHK+mU12tBRyVnAV6/Zyb4S2K0VcxYs5ntMwByHh72urDBQVdibvDnG5+cHCog==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 28 Jun 2021 17:02:45 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.50.21061301
Date: Mon, 28 Jun 2021 17:02:43 +0200
Message-ID: <>
Thread-Topic: [Ntp] NTP over PTP
References: <YNRtXhduDjU4/0T9@localhost> <> <YNnSj8eXSyJ89Hwv@localhost>
In-Reply-To: <YNnSj8eXSyJ89Hwv@localhost>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NDJhN2EyODFjMTJjOGIyYg==
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="----812EA358C81F6046832E93DC6F730201"
Archived-At: <>
Subject: Re: [Ntp] NTP over PTP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jun 2021 15:02:54 -0000

> Am 28.06.21, 15:46 schrieb "ntp im Auftrag von Miroslav Lichvar"
> < im Auftrag von>:
> On Fri, Jun 25, 2021 at 03:00:25PM +0200, Heiko Gerstung wrote:
>> If I follow your argument that unicast PTP is like the NTP control mode
>> then yes, both mode 6 and unicast PTP are not secured against replay and
>> amplification attacks. The NTS4UPTP draft is exactly addressing this for
>> unicast PTP and provides the required protection. I outlined in the draft that
>> the proposed approach achieves most of the stated objectives/goals of NTS4NTP,
>> which is well secured (we certainly agree on that).
> If I understand it correctly, your draft is addressing the
> amplification issue by requiring client authentication. That's
> probably the best one can do, but it doesn't make it comparable to NTP
> or NTS4NTP. The operator will still have to trust the clients to not
> abuse their credentials and also trust them to not get compromised.
> That's nothing like NTS4NTP where you can run a public server without
> any worry about someone exploiting your server for amplification.
That is true and it is a result of the way the protocol is designed. 

>> In the interim meeting I believe there have been multiple participants
>> that agreed that
>> a) PTP should be secured (it is worth it)
> At least for the normal non-unicast mode, I agree.
> The unicast mode seems to be intended for networks with partial
> on-path hardware support, where requirements on accuracy are less
> strict, and I think this might already be better supported by NTP.
They might be less strict but that does not mean they are worse/equal compared to NTP. With HW timestamping on the server and client, you can remove the impact of the multitasking OS network stack in the end devices and "partial" on path support means that at least some of the switches/routers can have PTP support. Plus there are use cases where you can have full on-path support because you are running a private network of a certain size (for example a whole full blown hyperscale DC). In those cases (and probably many more), NTP is not an alternative.

>> Arguing that the two drafts on the table might just need TLS instead of
>> NTS-KE is something I cannot understand, too. PTP already has a security
>> mechanism that is standardized and, with some extensions (provided by the
>> submitted drafts), can be used to significantly enhance security of the
>> protocol. What is needed is a key exchange mechanism and some additional
>> features to close the security holes (i.e. no protection for the source IP
>> address) - again, exactly what the two drafts provide.

> Ok, but to me it seems it would be simpler if you have skipped NTS-KE
> and went with TLS directly. Anyway, for adopting the document that
> shouldn't matter.


>> Regarding "NTP over PTP": trying to trick the hardware timestamping
>> engines of a large variety of vendors into timestamping a PTP packet is bound
>> to fail IMHO. There is no standard for how these timestamping engines work,
>> some may even look at sizes of packets (they should not do that, as PTP
>> messages can theoretically carry TLVs, but sometimes hardware vendors take
>> shortcuts). Some implementations will forward packets to a management CPU when
>> the forwarding plane detects a PTP frame. The CPU will not recognize that this
> is NTP and will probably throw away the packet. Again, most likely not the
>> right way to do it, but alas ...
> If there is some hardware that can timestamp only fixed-length PTP
> messages with no TLVs, then that will not work with any form of
> NTS4UPTP either, right? There has to be some TLV to authenticate the
> message and the hardware needs to accept that.

No, that's not correct. The hardware timestamping is only required during phase 3 (packet transmission), which does not require an NTS TLV as it relies completely on the AUTHENTICATION_TLV and the integrated PTP security. See 3.3 of my draft. The NTS TLV is required in phase 2 where client and server only exchange messages to negotiate the transmission, and those are not hw timestamped. 

> The same applies to one-step clocks. If implemented in silicon, that
> will not work in any case.

Again, depends on the implementation and the choices made by the designers. I do not want to say that such a flawed implementation is the rule, and I also do not want to imply that the whole concept cannot work, but I am sure that it is not the solution to the problem we wanted to solve with NTS4UPTP. 

Best Regards,

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