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

Kurt Roeckx <kurt@roeckx.be> Tue, 11 May 2021 09:55 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 808C63A0C2A for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 02:55:51 -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 UPOS2KUcVhVs for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 02:55:47 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 142E93A0C36 for <ntp@ietf.org>; Tue, 11 May 2021 02:55:47 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 2A4E2A8A0E91; Tue, 11 May 2021 09:55:42 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 0078B1FE0E23; Tue, 11 May 2021 11:55:41 +0200 (CEST)
Date: Tue, 11 May 2021 11:55:41 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Joachim Fabini <Joachim.Fabini@tuwien.ac.at>
Cc: ntp@ietf.org
Message-ID: <YJpUnWJvZVCb+BCh@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> <YJpConUHNVvB/K45@roeckx.be> <ef126c62-16c5-1a00-f977-395c11b804de@tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ef126c62-16c5-1a00-f977-395c11b804de@tuwien.ac.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/tBAKJTwkz96iX626Y1tLuR50GPA>
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 09:55:52 -0000

On Tue, May 11, 2021 at 11:50:16AM +0200, Joachim Fabini wrote:
> On 5/11/21 10:38 AM, Kurt Roeckx wrote:
> > 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.
> 
> I guess my concept of error differs - for me it's the slave's uncertainty
> interval. The half RTT error can happen in both directions.
> 
> Assume that the slave sends the request at local time ts0 and receives the
> server response at local time ts1=ts0+1000ms, slave-measured RTT is 1000ms.
> The master inserted its local timestamp tm into the message. We're ignoring
> local drift/skew.
> 
> Theoretical link delay asymmetry for <forwardLink;reverseLink> can range
> anyhwere from <0,1000> to <1000,0>. The only guaranteed bounds for the slave
> is that abs(ts0) < abs(tm) < abs(ts1) (where - an uncertainty interval of
> one full RTT. Unless physical link properties and constraints are known, any
> other assumption is probabilistic.

What we do to reduce the error, is add 500 ms to tm, and then have an
error from -500 ms to +500 ms. Without adding that 500 ms, the
error is from +0 to +1000 ms.


Kurt