Re: [Ntp] Antw: Re: Follow-up to yesterday's mic comment about PTP security

Miroslav Lichvar <mlichvar@redhat.com> Thu, 25 July 2019 07:46 UTC

Return-Path: <mlichvar@redhat.com>
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 91C8B120326 for <ntp@ietfa.amsl.com>; Thu, 25 Jul 2019 00:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 AMH-QnhRumay for <ntp@ietfa.amsl.com>; Thu, 25 Jul 2019 00:46:39 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E147412030C for <ntp@ietf.org>; Thu, 25 Jul 2019 00:46:38 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7D72130860BD; Thu, 25 Jul 2019 07:46:37 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0431460BEC; Thu, 25 Jul 2019 07:46:35 +0000 (UTC)
Date: Thu, 25 Jul 2019 09:46:34 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: kristof.teichel@ptb.de
Cc: Harlan Stenn <stenn@nwtime.org>, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, Daniel Franke <dfoxfranke@gmail.com>, ntp@ietf.org
Message-ID: <20190725074634.GA7477@localhost>
References: <CAJm83bD89oPE+WouWUD=qVqFzZ5-vw6E3RVsdVRteH0cEXyYjg@mail.gmail.com> <OFBC3F40BE.7ED6BF0D-ONC1258441.0023FF5E-C1258441.002675FE@ptb.de> <CAJm83bA74UiYbVbfYOHk4Vsw=go0d5P70uwbJ7CDvFrkdtcbfw@mail.gmail.com> <5D3941DA020000A100032624@gwsmtp.uni-regensburg.de> <b0672060-2d15-8339-22b2-c647480af9d6@nwtime.org> <OF046B14CA.397A024F-ONC1258442.0026A9AB-C1258442.0026F91D@ptb.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <OF046B14CA.397A024F-ONC1258442.0026A9AB-C1258442.0026F91D@ptb.de>
User-Agent: Mutt/1.12.0 (2019-05-25)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.44]); Thu, 25 Jul 2019 07:46:38 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/J2Iz8NFUNj3I-7gt4Qi85Of1Q24>
Subject: Re: [Ntp] Antw: Re: Follow-up to yesterday's mic comment about PTP security
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: Thu, 25 Jul 2019 07:46:42 -0000

On Thu, Jul 25, 2019 at 09:06:30AM +0200, kristof.teichel@ptb.de wrote:
> None of that matters for what Daniel is saying.
> A packet can still not have arrived *faster* than with lightspeed via the 
> shortest line between the two devices.
> And that's all you need to derive that the situation is in fact marginally 
> better than "half of RTT (plus oscillator-related delta)".

There is a variant that can be used in local networks with known
HW/topology. Instead of physical distance, which is negligible in
local networks, the metric is the number of network devices between
the stratum 1 server and client. If the minimum forwarding delay of
all devices is x (under all conditions) and packets between the server
and client always have to go over at least n devices, the root
delay reported by the client can be reduced by 2*n*x. The maximum
error of the client's clock (root distance) then may be shown to be
smaller than the required accuracy (e.g. 100 microseconds in the case
of MiFID).

With PTP (which assumes a constant network delay and doesn't have a
concept of root delay/dispersion) it's more difficult to determine the
maximum error.

-- 
Miroslav Lichvar