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

[[e-mail]]

Yeah, your point about max error versus (un)certainty interval makes total sense.

Thanks for clearing it up.

 

-----"Joachim Fabini" <[e-mail]> schrieb: -----

An: <[e-mail]>
Von: "Joachim Fabini" <[e-mail]>
Datum: 11.05.2021 12:56
Kopie: "Doug Arnold" <doug.arnold=[e-mail]>, "Miroslav Lichvar" <[e-mail]>, "NTP WG" <[e-mail]>, "Daniel Franke" <[e-mail]>
Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: A simpler way to secure PTP

On 5/11/21 10:48 AM, [e-mail] wrote:
> I don't think I expressed this clearly enough:
> Your 100%* guarantee (the 100% kinda still needs an asterisk there) with
> a two-way exchange is going to be that the measurement you make of your
> time offset is wrong by at most half of your RTT (where RTT = the sum of
> the two messages' flight times).
> It's about an upper bound to the error you make in your calculation.
> The maximum of half of RTT would be taken if one message was delivered
> instantaneously and the other accounted for all of your RTT, so in
> reality, you at least know that it's really less than that (and, as
> Daniel said, you can do a few things more if you account for not
> exceeding lightspeed and a known lower bound to your physical distance).

My earlier posting to the ntp group (reply to Kurt's email) seems to be
delayed. It's about how we define "error" (I read the discussion after
having a discussion on uncertainty intervals, so was to some extent
biased...)
If it is about "the maximum deviation of my guessed offset from a
reference clock" then I'm with you, it's (+-)1/2 RTT. If it is about the
uncertainty interval it's a RTT. Apologies for the confusion.

Btw, perhaps it's worth to include a dedicated definition of error or
define an alternative unique name in one of the future docs. I briefly
skimmed over NTPv4 and NTS and error is used (in the meaning used by
you) but (imo - did not do an exhaustive search) not defined.
> With a one-way exchange, the issue is that your possible error is
> unbounded in one direction (basically because you have no way of
> asserting that the message is fresh).

Full agree.

best regards
Joachim

> See also https://ieeexplore.ieee.org/document/8357814" rel="nofollow">https://ieeexplore.ieee.org/document/8357814,
> <https://ieeexplore.ieee.org/document/8357814" rel="nofollow">https://ieeexplore.ieee.org/document/8357814,> or my dissertation.
>
>
> Best regards!
>
> * The asterisk would account for frequency differences in addition to
> time offsets.
>
>
> -----"ntp" <[e-mail] <mailto:[e-mail]>> schrieb:
> -----
> An: <[e-mail] <mailto:[e-mail]>>, "Doug
> Arnold" <doug.arnold=[e-mail]
> <mailto:doug.arnold=[e-mail]>>
> Von: "Joachim Fabini"
> Gesendet von: "ntp"
> Datum: 11.05.2021 09:59
> Kopie: "Miroslav Lichvar" <[e-mail]
> <mailto:[e-mail]>>, "NTP WG" <[e-mail]
> <mailto:[e-mail]>>, "Daniel Franke" <[e-mail]
> <mailto:[e-mail]>>
> Betreff: Re: [Ntp] Antwort: Re: A simpler way to secure PTP
>
> On 5/10/21 7:05 PM, [e-mail]
> <mailto:[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.
>
> By knowing physical link properties (delay, capacity) one can restrict
> the RTT bound and decrease the limits. However, attackers could - in
> theory and practice - exploit this assumption, too (for instance by
> inserting new (faster-than)-light-speed paths).
>
> If anyone is interested: theoretical aspects (and practical
> consequences) of securing time sync protocols against malicious actors
> can be found in an older paper (https://arxiv.org/pdf/1705.10669.pdf" rel="nofollow">https://arxiv.org/pdf/1705.10669.pdf 
> <https://arxiv.org/pdf/1705.10669.pdf" rel="nofollow">https://arxiv.org/pdf/1705.10669.pdf>)
> and in parts of the subsequent PhD thesis
> (https://www.annessi.net/data/2019-Annessi_thesis.pdf" rel="nofollow">https://www.annessi.net/data/2019-Annessi_thesis.pdf 
> <https://www.annessi.net/data/2019-Annessi_thesis.pdf" rel="nofollow">https://www.annessi.net/data/2019-Annessi_thesis.pdf>).
>
> regards
> Joachim
>
>
>  >
>  > -----"ntp" <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] <mailto:[e-mail]>>> schrieb:
>  > -----
>  > An: "Daniel Franke" <[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>  > Von: "Doug Arnold"
>  > Gesendet von: "ntp"
>  > Datum: 10.05.2021 18:19
>  > Kopie: "Miroslav Lichvar" <[e-mail]
> <mailto:[e-mail]>
>  > <mailto:[e-mail] <mailto:[e-mail]>>>, "NTP WG"
> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>  > Betreff: Re: [Ntp] A simpler way to secure PTP
>  >
>  > Many of the applications of PTP I know of require time transfer accuracy
>  > better than half the RTT.  This is achieved using a variety of
>  > mechanisms, including:
>  >
>  >   * On-path support
>  >
>  >   * High message rates + lucky packet filters
>  >
>  >   * Synchronous Ethernet
>  >
>  >   * Networks with lightly loaded switches
>  >
>  >   * Preemptive switches
>  >
>  >   * Asymmetry calibration
>  >
>  >   * Multiple PTP domains with different paths to devices needing time
>  >
>  >   * Multiple sources of time, that is PTP, plus other non-PTP time
>  >     transfer mechanisms in a redundant system
>  >
>  > A switch in the middle could mount a delay attack, which is of course
>  > immune to cryptography, but the risk could be reduced by
>  > non-cryptographic defenses such as time source, or network path
> redundancy.
>  >
>  > NTS4PTP could help against malicious agents which have gained access to
>  > the network and start sending bogus PTP messages, for example
>  > impersonating the Grandmaster.
>  >
>  > Doug
>  >
>  > *From: *Daniel Franke <[e-mail]
> <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>  > *Date: *Monday, May 10, 2021 at 11:21 AM
>  > *To: *Doug Arnold <[e-mail]
> <mailto:[e-mail]>
>  > <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>  > *Cc: *Miroslav Lichvar <[e-mail] <mailto:[e-mail]>
>  > <mailto:[e-mail] <mailto:[e-mail]>>>, NTP WG
> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>  > *Subject: *Re: [Ntp] A simpler way to secure PTP
>  >
>  > On Mon, May 10, 2021 at 10:43 AM Doug Arnold
>  > <[e-mail] <mailto:[e-mail]>
> <mailto:[e-mail] 
> <mailto:[e-mail]>>> wrote:
>  >
>  >     I have heard of people actually doing this in the field as a sanity
>  >     check.
>  >
>  >     However, some applications that use PTP can be broken by introducing
>  >     timing errors that are less than the expected difference between PTP
>  >     and NTP.
>  >
>  > You cannot solve this with cryptography. An adversarial network is, by
>  > definition, one where you can't rely on statistical behavior and can't
>  > neglect the probability of worst-case outcomes. The worst-case outcome
>  > for any unicast protocol is going to be at least half the measured RTT,
>  > and for a broadcast protocol the worst case is unbounded. As I've
>  > mentioned before, you can improve this a little bit if you know a lower
>  > bound on the physical distance `d` between the client and server, in
>  > which case you can shrink each of your bounds by `d/c` where `c` is the
>  > speed of light, but this still won't get you anywhere near the kind of
>  > precision you have in mind. If worst-case, let alone typical-case,
>  > NTS4NTP behavior is going to break your application in critical ways,
>  > then you MUST have a physically-secure link to your time source. If you
>  > have an adversary on your communication path, you're just screwed and
>  > cryptography can't save you.
>  >
>  > _______________________________________________
>  > ntp mailing list
>  > [e-mail] <mailto:[e-mail]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>  > https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp>
>  > <https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp>>
>  >
>  > _______________________________________________
>  > ntp mailing list
>  > [e-mail] <mailto:[e-mail]>
>  > https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">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] <mailto:[e-mail]>
> ---------------------------------------
>
> _______________________________________________
> ntp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp 
> <https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">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]
---------------------------------------