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

Heiko Gerstung <heiko.gerstung@meinberg.de> Tue, 11 May 2021 08:15 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 D99323A166F for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Jh3RZD3x2C-A for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:15:02 -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 CA5DC3A166C for <ntp@ietf.org>; Tue, 11 May 2021 01:15: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 AFB0F71C0BD0; Tue, 11 May 2021 10:14:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meinberg.de; s=dkim; t=1620720897; 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=vJ7Q6WRtKRDUgWTA/D/3XLXt/2bO4rE+eih4Qhz4UtE=; b=mko68hOi4TZFErvrKCoeSKZ/3hfNtQgsGGBHcmnd0Rp3QrJcbwjfy3zQJTRZJr9Eq1xpLf h71J3QZKDkczIFjvAc+ySC4jOZHgDbW3W9uzyQhw/DViwCETOXQzriteMF6vLilumchifb +iqXA9b50hEIM2VLw4GB2I/ciVuHTx/OPtl4QqwbAPAe1OPZfbgAy6ZgO9AN/dvqnaAL9M 5r/KCMz4Aj/gGNEimzRJYg/OFMyZzyn0gTTdovnbhE41h1pRzYdfbyIJwygEktHWWEjwMg 8j9Ivthg7aDV9Vsi2jERxaxGqHjDW2aaCUt9Hcr6xnwAn7DEp+ZUsYlvV1PdMw==
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:14:57 +0200 (CEST)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/16.48.21041102
Date: Tue, 11 May 2021 10:14:55 +0200
Message-ID: <4D727CE5-1D4A-47AA-8FE6-69847C3CBA7B@meinberg.de>
Thread-Topic: [Ntp] Antwort: Re: A simpler way to secure PTP
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> <OFED5B2865.344FE7AB-ONC12586D1.005DE2E1-C12586D1.005DE2E2@ptb.de> <3b5d7881-2cbb-02f4-30d4-4b9627a6a18b@tuwien.ac.at>
In-Reply-To: <3b5d7881-2cbb-02f4-30d4-4b9627a6a18b@tuwien.ac.at>
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MzQ3NGRkNDU4NjE3MWY2NQ==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Joachim Fabini <joachim.fabini@tuwien.ac.at>, "kristof.teichel@ptb.de" <kristof.teichel@ptb.de>, Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>
Cc: Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
X-SM-outgoing: yes
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----C3FBCC4BCE2C2F0A10316B2C5FB5151E"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/E7k4rfqWMW8dAlS0h5YUk6aaMDY>
Subject: Re: [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: Tue, 11 May 2021 08:15:08 -0000

Joachim,

thanks for the provided document references. Both are focusing on multicast operation of NTP and PTP, is that correct? At least that is what I understood from the introduction paragraphs of both papers. 

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
 
 

Am 11.05.21, 09:59 schrieb "ntp im Auftrag von Joachim Fabini" <ntp-bounces@ietf.org im Auftrag von Joachim.Fabini@tuwien.ac.at>gt;:

    On 5/10/21 7:05 PM, kristof.teichel@ptb.de wrote:
    > @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.

    "At best" is too little. 100% certain guarantees (for two-way time sync) 
    apply for *RTT* - and definitely *not* for half of RTT. The link 
    symmetry assumption is one of the weakest point of today's network time 
    synchronization protocols that malicious actors can exploit.

    By knowing physical link properties (delay, capacity) one can restrict 
    the RTT bound and decrease the limits. However, attackers could - in 
    theory and practice - exploit this assumption, too (for instance by 
    inserting new (faster-than)-light-speed paths).

    If anyone is interested: theoretical aspects (and practical 
    consequences) of securing time sync protocols against malicious actors 
    can be found in an older paper (https://arxiv.org/pdf/1705.10669.pdf) 
    and in parts of the subsequent PhD thesis 
    (https://www.annessi.net/data/2019-Annessi_thesis.pdf).

    regards
    Joachim


    > 
    > -----"ntp" <ntp-bounces@ietf.org <mailto:ntp-bounces@ietf.org>> schrieb: 
    > -----
    > An: "Daniel Franke" <dfoxfranke@gmail.com <mailto:dfoxfranke@gmail.com>>
    > Von: "Doug Arnold"
    > Gesendet von: "ntp"
    > Datum: 10.05.2021 18:19
    > Kopie: "Miroslav Lichvar" <mlichvar@redhat.com 
    > <mailto:mlichvar@redhat.com>>, "NTP WG" <ntp@ietf.org <mailto: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 <mailto:dfoxfranke@gmail.com>>
    > *Date: *Monday, May 10, 2021 at 11:21 AM
    > *To: *Doug Arnold <doug.arnold@meinberg-usa.com 
    > <mailto:doug.arnold@meinberg-usa.com>>
    > *Cc: *Miroslav Lichvar <mlichvar@redhat.com 
    > <mailto:mlichvar@redhat.com>>, NTP WG <ntp@ietf.org <mailto: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.
    > 
    > _______________________________________________
    > ntp mailing list
    > ntp@ietf.org <mailto:ntp@ietf.org>
    > https://www.ietf.org/mailman/listinfo/ntp 
    > <https://www.ietf.org/mailman/listinfo/ntp>
    > 
    > _______________________________________________
    > ntp mailing list
    > ntp@ietf.org
    > https://www.ietf.org/mailman/listinfo/ntp
    > 

    -- 
    ---------------------------------------
    Dr. Joachim Fabini
    Senior Scientist
    Institute of Telecommunications
    TU Wien
    Gusshausstrasse 25/E389
    A-1040 Vienna, Austria
    Tel: +43 1 58801-38813
    mailto: Joachim.Fabini@tuwien.ac.at
    ---------------------------------------

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