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

Joachim Fabini <Joachim.Fabini@tuwien.ac.at> Tue, 11 May 2021 09:50 UTC

Return-Path: <joachim.fabini@tuwien.ac.at>
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 2397F3A0BF3 for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 02:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 vsKpR8dFExyL for <ntp@ietfa.amsl.com>; Tue, 11 May 2021 02:50:32 -0700 (PDT)
Received: from secgw2.intern.tuwien.ac.at (secgw2.intern.tuwien.ac.at [IPv6:2001:629:1005:30::72]) (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 44D333A0B20 for <ntp@ietf.org>; Tue, 11 May 2021 02:50:32 -0700 (PDT)
Received: from totemomail (localhost [127.0.0.1]) by secgw2.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 14B9oSwp030578 for <ntp@ietf.org>; Tue, 11 May 2021 11:50:28 +0200
Received: from localhost ([127.0.0.1]) by totemomail.intern.tuwien.ac.at (Totemo SMTP Server) with SMTP ID 497 for <ntp@ietf.org>; Tue, 11 May 2021 11:50:27 +0200 (CEST)
Received: from edge19a.intern.tuwien.ac.at (edge19a.intern.tuwien.ac.at [IPv6:2001:629:1005:30::45]) by secgw2.intern.tuwien.ac.at (8.14.7/8.14.7) with ESMTP id 14B9oROs030563 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <ntp@ietf.org>; Tue, 11 May 2021 11:50:27 +0200
Received: from mbx13c.intern.tuwien.ac.at (128.130.30.63) by edge19a.intern.tuwien.ac.at (128.130.30.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.858.5; Tue, 11 May 2021 11:50:27 +0200
Received: from [IPv6:2001:871:222:b6a0:16ca:c15f:152a:b35d] (2001:871:222:b6a0:16ca:c15f:152a:b35d) by mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 11 May 2021 11:50:27 +0200
To: <ntp@ietf.org>
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>
From: Joachim Fabini <Joachim.Fabini@tuwien.ac.at>
Message-ID: <ef126c62-16c5-1a00-f977-395c11b804de@tuwien.ac.at>
Date: Tue, 11 May 2021 11:50:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <YJpConUHNVvB/K45@roeckx.be>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: mbx13b.intern.tuwien.ac.at (2001:629:1005:30::62) To mbx13c.intern.tuwien.ac.at (2001:629:1005:30::63)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jlL0bO_LpqR_24X_B3KqcB_0SFo>
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:50:37 -0000

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.

br Joachim

> 
> 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
> 
> _______________________________________________
> 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
---------------------------------------