Re: [Ntp] A simpler way to secure PTP

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 11 May 2021 08:08 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 D6E023A15EE for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, 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 fHcU-UVuhew5 for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:08:01 -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 715C73A0B20 for <ntp@ietf.org>; Tue, 11 May 2021 01:08:01 -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 7542071C0B0E; Tue, 11 May 2021 10:07:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1620720479; 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=y2yHbggr9j2HNWuYHbKNBdbthZSzeu+jIlaYybwv/Dc=; b=S7vC8OVg80hFJE43+dwwdaaV9NDTrxBcA0v4Pk6zHkH0iRH9YrSdBqfaUT8RQI3ekWmdH/ tzzqgWl40GIozuhqmqLRp7+6WcKL+SZIUEcWSeer+eYs9iIZPOZcF3ITE14VjAY6MUUKB5 wBNMNKgxVGFfxWYNt8bGtCx5pm9uggXTPeMEsuiorCoAP7HwhiOf2FcEJzRrF70L9fs65/ k2/4amD9hgLzhjMkK/knMQKckILZpE4joC1Eqt+Xnnvl+iW9csye/myC97DJBVR/sjO0MG 69mwI0XKKq3SFzi8V5k+KpQQvRvpCqrJaIbnNi1bZRPoRFYH9wZDLQxIDoZmJw==
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; Tue, 11 May 2021 10:07:58 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Tue, 11 May 2021 10:07:57 +0200
Message-ID: <ACB0668D-51AF-4CE5-B76A-03B153C5B176@meinberg.de>
Thread-Topic: [Ntp] A simpler way to secure PTP
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <YJkrFjnRPJJHz9da@localhost> <AM7PR02MB57657C935D0E94D223B1D703CF549@AM7PR02MB5765.eurprd02.prod.outlook.com> <CAJm83bCRMJr4V59m97CUtOnF8Dbsg=pGPTD=n359imxUByJhVg@mail.gmail.com>
In-Reply-To: <CAJm83bCRMJr4V59m97CUtOnF8Dbsg=pGPTD=n359imxUByJhVg@mail.gmail.com>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+NmY2YTczNjlmZDI4MmRiNQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Daniel Franke <dfoxfranke@gmail.com>, Doug Arnold <doug.arnold@meinberg-usa.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----FF5D75AEB2B9D8FF5E3BE24001E5A1AA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/WRUXZ1oXQzNXsDDuo1sbgl2VdYo>
Subject: Re: [Ntp] A simpler way to secure PTP
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: Tue, 11 May 2021 08:08:07 -0000

Daniel, with hardware timestamping in the end nodes you can improve the delay measurement considerably. With hardware timestamping in the network infrastructure, e.g. using TCs, you can improve this even further. These mechanisms are not available to NTP nodes. Applying lucky packet filters at a packet rate of 128 packets/s will improve your calculated RTT by using only 1% of the RTT measurements. There is quite a lot you can do to improve accuracy over a network link that you cannot currently do with NTP. Due to all the above mentioned measures, the precision with which PTP can measure the RTT is typically orders of magnitudes higher than with NTP resulting in a much better “worst outcome”. 

 

As Doug already mentioned, there are quite a lot of PTP applications in the field which require better than 1us accuracy, and even more that require better than 10us accuracy. I do agree that, in a perfect network with (more or less) static delays and end nodes with low latency network stack implementations, you can achieve the same level of accuracy with NTP that you achieve with PTP, but there are many networks and applications out there with not-so-perfect conditions. I am sure we all do not want to get into a PTP vs NTP discussion here, there are just a lot of applications that require/use PTP and I believe it is a good idea to improve security for it. 

 

And, to me a network time security approach is not limited to a protection against time manipulation. It should also add protection against abusing the protocol to carry out amplification attacks and disrupt the protocol in any possible way. Yes, if you have a man-in-the-middle being able to simply drop your packets to deny synchronization to your end nodes, you are screwed. But at least your end nodes immediately notice that they do not receive any packets anymore. You can also carry out a delay attack and do a lot of other nasty things. However, protecting the protocol against some malicious attacker being able to inject arbitrary packets into the network is still a desirable goal IMHO.

 

Best 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

 

 

 

Von: ntp <ntp-bounces@ietf.org> im Auftrag von Daniel Franke <dfoxfranke@gmail.com>
Datum: Montag, 10. Mai 2021 um 17:22
An: Doug Arnold <doug.arnold@meinberg-usa.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>om>, NTP WG <ntp@ietf.org>
Betreff: Re: [Ntp] A simpler way to secure PTP

 

On Mon, May 10, 2021 at 10:43 AM Doug Arnold <doug.arnold@meinberg-usa.com> wrote:

I have heard of people actually doing this in the field as a sanity check.

 

However, some applications that use PTP can be broken by introducing timing errors that are less than the expected difference between PTP and NTP.

 

You cannot solve this with cryptography. An adversarial network is, by definition, one where you can't rely on statistical behavior and can't neglect the probability of worst-case outcomes. The worst-case outcome for any unicast protocol is going to be at least half the measured RTT, and for a broadcast protocol the worst case is unbounded. As I've mentioned before, you can improve this a little bit if you know a lower bound on the physical distance `d` between the client and server, in which case you can shrink each of your bounds by `d/c` where `c` is the speed of light, but this still won't get you anywhere near the kind of precision you have in mind. If worst-case, let alone typical-case, NTS4NTP behavior is going to break your application in critical ways, then you MUST have a physically-secure link to your time source. If you have an adversary on your communication path, you're just screwed and cryptography can't save you.

_______________________________________________ ntp mailing list ntp@ietf.org https://www.ietf.org/mailman/listinfo/ntp