[Ntp] Antwort: Re: A simpler way to secure PTP

kristof.teichel@ptb.de Mon, 10 May 2021 17:05 UTC

Return-Path: <kristof.teichel@ptb.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 BFFD83A23C6 for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 10:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.719
X-Spam-Level:
X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 KTdxRd9E2PrO for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 10:05:39 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB613A23CA for <ntp@ietf.org>; Mon, 10 May 2021 10:05:38 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 14AH5WF2023605-14AH5WF4023605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 May 2021 19:05:32 +0200
Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id B32F7B54DE0; Mon, 10 May 2021 19:05:31 +0200 (CEST)
MIME-Version: 1.0
Sensitivity:
Importance: Normal
X-Priority: 3 (Normal)
In-Reply-To: <AM7PR02MB576597311CBC1EC81F961FB4CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>
References: <AM7PR02MB576597311CBC1EC81F961FB4CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>, <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <YJkrFjnRPJJHz9da@localhost> <AM7PR02MB57657C935D0E94D223B1D703CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>, <CAJm83bCRMJr4V59m97CUtOnF8Dbsg=pGPTD=n359imxUByJhVg@mail.gmail.com>
From: kristof.teichel@ptb.de
To: Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>
Cc: Daniel Franke <dfoxfranke@gmail.com>, Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
Date: Mon, 10 May 2021 19:05:29 +0200
Message-ID: <OFED5B2865.344FE7AB-ONC12586D1.005DE2E1-C12586D1.005DE2E2@ptb.de>
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-YE_BgkJ_Qb0hr_M0ezmA-5ZnPY>
Subject: [Ntp] Antwort: Re: 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: Mon, 10 May 2021 17:05:44 -0000

@Doug: Daniel is correct; you can apply all kinds of magic, but ultimately, your hard, 100% certain guarantees are going to be at best "half of RTT" for two-way time transfer and "none at all" for one-way transfer.

You can make it *more likely* that what you measured and came up with is better than that.
But if you're going to try to appease some kind of regulatory thing where you have to demonstrably and undoubtably be below an offset better than half of RTT of your best two-way transfer, you might just be out of luck.

@Daniel: I think this is an argument for putting crypto on PTP / White Rabbit, though.
In the end, using two-way transfer with hardware-assisted timestamps is going to be the only way to dissolve the dilemma.

I do like your approach; as Martin hinted at, we've been looking at how to formalize something like it for a while.
Even if it offers no better hard guarantee than NTS alone, it still seems the most reasonable and readily available way forward.


Best regards,
Kristof



-----"ntp" <ntp-bounces@ietf.org> schrieb: -----
An: "Daniel Franke" <dfoxfranke@gmail.com>
Von: "Doug Arnold"
Gesendet von: "ntp"
Datum: 10.05.2021 18:19
Kopie: "Miroslav Lichvar" <mlichvar@redhat.com>, "NTP WG" <ntp@ietf.org>
Betreff: Re: [Ntp] A simpler way to secure PTP

Many of the applications of PTP I know of require time transfer accuracy better than half the RTT.  This is achieved using a variety of mechanisms, including:

  • On-path support

  • High message rates + lucky packet filters

  • Synchronous Ethernet

  • Networks with lightly loaded switches

  • Preemptive switches

  • Asymmetry calibration

  • Multiple PTP domains with different paths to devices needing time

  • Multiple sources of time, that is PTP, plus other non-PTP time transfer mechanisms in a redundant system

 

A switch in the middle could mount a delay attack, which is of course immune to cryptography, but the risk could be reduced by non-cryptographic defenses such as time source, or network path redundancy. 

 

NTS4PTP could help against malicious agents which have gained access to the network and start sending bogus PTP messages, for example impersonating the Grandmaster.

 

Doug

 

 

 

 

 

From: Daniel Franke <dfoxfranke@gmail.com>
Date: Monday, May 10, 2021 at 11:21 AM
To: Doug Arnold <doug.arnold@meinberg-usa.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
Subject: 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" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp