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
- [Ntp] Follow-up to yesterday's mic comment about … Daniel Franke
- [Ntp] Antw: Follow-up to yesterday's mic comment … Ulrich Windl
- Re: [Ntp] Antw: Follow-up to yesterday's mic comm… Hal Murray
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Antw: Follow-up to yesterday's mic comm… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Daniel Franke
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Watson Ladd
- [Ntp] Antw: Re: Follow-up to yesterday's mic comm… Ulrich Windl
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … Harlan Stenn
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Heiko Gerstung
- Re: [Ntp] Antw: Re: Follow-up to yesterday's mic … Miroslav Lichvar
- Re: [Ntp] Follow-up to yesterday's mic comment ab… kristof.teichel
- Re: [Ntp] Follow-up to yesterday's mic comment ab… Daniel Franke