IETF Logo Mail Archive

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

Kurt Roeckx <kurt@roeckx.be> Tue, 11 May 2021 08:39 UTC

Return-Path: <kurt@roeckx.be>
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 426E43A0890 for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 jAY2S7Mfl7hs for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 01:39:05 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a05:7300:0:100::3]) (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 1D2C83A0887 for <ntp@ietf.org>; Tue, 11 May 2021 01:39:05 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 52D14A8A0158; Tue, 11 May 2021 08:38:59 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E7BC11FE0E23; Tue, 11 May 2021 10:38:58 +0200 (CEST)
Date: Tue, 11 May 2021 10:38:58 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Joachim Fabini <Joachim.Fabini@tuwien.ac.at>
Cc: kristof.teichel@ptb.de, Doug Arnold <doug.arnold=40meinberg-usa.com@dmarc.ietf.org>, Miroslav Lichvar <mlichvar@redhat.com>, NTP WG <ntp@ietf.org>, Daniel Franke <dfoxfranke@gmail.com>
Message-ID: <YJpConUHNVvB/K45@roeckx.be>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3b5d7881-2cbb-02f4-30d4-4b9627a6a18b@tuwien.ac.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/N9Uw7zJSWSrh0rHO35AKGdFmMhs>
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:39:10 -0000

On Tue, May 11, 2021 at 09:59:10AM +0200, Joachim Fabini wrote:
> 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.

I don't agree. Because we compensate for half the RTT, the maximum
error is reduced to half the RTT. Without the compensation for
half the RTT I would agree.

Assume the real time it takes between peers is 1 ms and that there
are no other sources of errors. If there is an artificial
additional delay of 998 ms in the reply direction, we measure an
RTT of 1000 ms.

We will then assume that it took 500 ms instead of 999 ms to
arrive, and add 500 ms instead of 999 ms to the received time
as our estimate of the time. So we have an error of 499 ms.
I see no way to get an error that is larger than half the RTT
(ignoring other sources of errors.)

Note that this requires a packet in each direction with
enough meta data to be able to calculate an RTT. If you
don't have a RTT, you don't have a maximum bound.


Kurt

v2.23.0 | Report a Bug | By Email