Re: [Ntp] A simpler way to secure PTP

Heiko Gerstung <> Tue, 11 May 2021 07:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 231D93A129F for <>; Tue, 11 May 2021 00:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Status: No, score=-4.398 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, HTML_MESSAGE=0.001, 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 SSkFScu-QVwI for <>; Tue, 11 May 2021 00:15:00 -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 0B5353A129A for <>; Tue, 11 May 2021 00:14:59 -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 4DDAC71C04FB; Tue, 11 May 2021 09:14:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1620717297; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RkVl1FV628nyRLNU7ctR15aPW8UEq7fEiI8JYxJZyUI=; b=RnsZQ9xD9s+jLFLPTR8hnsIjoi8XlXHzPtz/3XSfKCXq865KGtBrVKYbdns9QYzeDTLvCV u3RjrSth9Xm8ay1XajxMHxJ6hGqvV7z30sPMPeuxWkdUBg34SO8U+MkvQzzzViuM9g3BcC PctzxK36UfQciQUse//dLmRH/7c0E5jIZL351GZeUl+4AXrcvhVzlwj7p86O01KSYh+oiX LIJsK+Aa+awWPga9jwfMJLjTzkt6k/NV7YFQZhqmYA/N9NVjJD4GvtZV4bXx2j8CCe+Vzl O9mpkiYHOnbVbhP+ZTVUJj+BDweFGG6xMcf9z+gvZrx7MYAUQrRqAst7mJDnFg==
Received: from ( []) (using TLSv1.3 with cipher AEAD-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 11 May 2021 09:14:56 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Tue, 11 May 2021 09:14:55 +0200
Message-ID: <>
Thread-Topic: [Ntp] A simpler way to secure PTP
References: <>
In-Reply-To: <>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmY2YTczNjlmZDI4MmRiNQ==
From: Heiko Gerstung <>
To: Daniel Franke <>, NTP WG <>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----8DC21BB8EA8E47D7F1C404C7A17A5E8C"
Archived-At: <>
Subject: Re: [Ntp] A simpler way to secure 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: Tue, 11 May 2021 07:15:06 -0000

Thanks Daniel, this is a reasonable approach for every application that requires a sync accuracy level which can be achieved with NTS4NTP, but there are quite a number of applications out there which require more than what NTP can provide. PTP is different from NTP on multiple levels and offers a number of features that you do not find in NTP, for example higher packet rates to increase the number of samples you feed into your statistics. It also offers hardware timestamping in the network infrastructure components, i.e. switches and routers, which can improve your sync performance dramatically. In combination with hardware timestamping it will reduce the time error introduced by the network stacks of client and server and the queueing/delay variation part quite a lot. 


I totally agree that using NTP to secure PTP is a reasonable approach, as Doug pointed out this has already been implemented years ago. See for a description of such an approach applied in the financial industry around 2014. 


However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the general concepts of NTS to secure the other popular time transfer protocol out there. 


I do not see a valid reason not to introduce a standardized way to improve security for this protocol, this will allow to utilize some of the features of (unicast) PTP in networks that currently should not use it. And it will improve security in networks where users need security mechanisms for their critical services and protocols in addition to the ones already in place to protect lower layers of the network. 


Best Regards,



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:




Von: ntp <> im Auftrag von Daniel Franke <>
Datum: Samstag, 8. Mai 2021 um 22:53
An: NTP WG <>
Betreff: [Ntp] A simpler way to secure PTP


As an alternative to Martin's and Heiko's drafts, I'd like to propose a simpler approach to securing PTP. It is compatible with all PTP features, supports the same threat model as NTS-secured NTP, introduces zero jitter, and can be implemented entirely on the client side without the knowledge or cooperation of the rest of the PTP infrastructure.


The trick is: run NTS-secured NTP and regular, unauthenticated PTP side-by-side. Do not use the NTP responses to set the clock; instead, use them only to establish maximum error bounds on the current time, and then clamp all PTP messages to within those bounds.


The client's on-wire interaction with the NTP server is the same as it is in normal NTS-secured NTP, but the way it processes the server's responses is different. The client maintains an estimate `theta` of the offset between a local, unadjusted monotonic clock `t_raw` (implemented e.g. by CLOCK_MONOTONIC_RAW on linux) and the server's realtime clock, along with a continuously-changing error term `lamdba`.


Upon receiving an authentic response from an NTP server, let:


  t_1 = origin timestamp captured from t_raw.

  t_2 = packet receive timestamp

  t_3 = packet transmit timestamp

  t_4 = destination timestamp captured from t_raw.

  theta = ((t_2 - t_1) + (t_3 - t_4))/2

  DTAI = TAI - UTC offset


giving a current estimated TAI time of 


  t_raw + theta + DTAI


For computing error bounds, let


  hrtt = (t_4 - t_1)/2

  rdel = packet root delay

  r_1 = local clock precision

  r_2 = packet clock precision

  PHI = some appropriate upper bound on our local clock's drift rate


and then our error term is plus-or-minus


  hrtt + rdel/2 + r_1 + r_2 + PHI*(t_raw - t_1)


Only the single best clock sample, from a given NTP server, i.e. the one that gives the tightest error bounds, need be retained. Other things being equal, newer samples will be preferable to older ones because the PHI*(t_raw - t_1) term will be smaller, but sometimes this may be negated by other terms such as hrtt being larger.


A client may gain resiliency by using multiple NTS-secured NTP servers. In this case for N servers it lets f=floor((N-1)/2), then discards the f lowest lower bounds and the f highest upper bounds, and then treats anything inside any of the remaining bounds as plausible.


Any PTP message whose time (after applying the usual link-delay correction) is plausible according to these bounds is processed as usual. Any PTP message whose time is not plausible is first clamped to the nearest bound and then processed as usual.


And that's all there is to it!



_______________________________________________ ntp mailing list