Re: [Ntp] A simpler way to secure PTP

"Langer, Martin" <mart.langer@ostfalia.de> Mon, 10 May 2021 16:50 UTC

Return-Path: <mart.langer@ostfalia.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 0741A3A236B for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 09:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 c2XsY-uefbWX for <ntp@ietfa.amsl.com>; Mon, 10 May 2021 09:49:58 -0700 (PDT)
Received: from mx2.sonia.de (mx2.sonia.de [141.41.1.238]) (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 5F69E3A2358 for <ntp@ietf.org>; Mon, 10 May 2021 09:49:58 -0700 (PDT)
Received: from mx2.sonia.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8B0ED10800D1; Mon, 10 May 2021 18:49:55 +0200 (CEST)
Received: from exchange05.resource.sonia.de (exchange05.resource.sonia.de [141.41.8.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.sonia.de (Postfix) with ESMTPS id 75B6B10800CC; Mon, 10 May 2021 18:49:54 +0200 (CEST)
From: "Langer, Martin" <mart.langer@ostfalia.de>
To: Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
CC: Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>
Thread-Topic: [Ntp] A simpler way to secure PTP
Thread-Index: AQHXREw51EeX7JeUVkCMmOPnSM/7HarciswAgAAgt4CAAAq2gIAAD+yAgAAmQwo=
Date: Mon, 10 May 2021 16:49:54 +0000
Message-ID: <9aa4df5591554b17b677745c267514ac@ostfalia.de>
References: <CAJm83bCpio5WwigY6nc9Y0Gt_XSdjUV=sHUz04dOQ0zELPwZxw@mail.gmail.com> <YJkrFjnRPJJHz9da@localhost> <AM7PR02MB57657C935D0E94D223B1D703CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>, <CAJm83bCRMJr4V59m97CUtOnF8Dbsg=pGPTD=n359imxUByJhVg@mail.gmail.com>, <AM7PR02MB576597311CBC1EC81F961FB4CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>
In-Reply-To: <AM7PR02MB576597311CBC1EC81F961FB4CF549@AM7PR02MB5765.eurprd02.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.41.8.54]
Content-Type: multipart/alternative; boundary="_000_9aa4df5591554b17b677745c267514acostfaliade_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/NuhQCrDj6Ep1CUypaSOfF4aQvTI>
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: Mon, 10 May 2021 16:50:10 -0000

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


I had the same thought. Simply hang a small device on the PTP network, which pretends to be the best clock via Announce messages.
The BMCA does the rest and adjusts the topology. After that I can roughly fluctuate between about +/- RTT/2 before an NTS/NTP watchdog
intervenes. Thus, the accuracy of the PTP network can be easily decreased. I would imagine that delay attacks can be detected quite well in PTP
networks, since links between PTP nodes typically don't change.  ...Especially since it is a local network. An unauthenticated PTP node that can
freely adjust the time within a certain range, even if it is only 1-2 milliseconds, seems more dangerous in my eyes.

Nevertheless, NTS-secured NTP is a good monitoring solution.


best regards,
martin

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: +49 5331 939 43370
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer


________________________________
Von: ntp <ntp-bounces@ietf.org> im Auftrag von Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>
Gesendet: Montag, 10. Mai 2021 18:18:39
An: Daniel Franke
Cc: Miroslav Lichvar; NTP WG
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>om>, 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<mailto: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.