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

[Joachim Fabini <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> 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: [phone]
mailto: [e-mail]
---------------------------------------