Re: [Ntp] A simpler way to secure PTP

["Langer, Martin" <[e-mail]>]

Hello Daniel,

That's an interesting thought and reminds me of a similar approach that Kristof and I had
for securing TESLA for NTP. But I think the problem goes a bit deeper. ...at least for PTP
unicast. As far as I know, connections could be "reactivated" or cancelled by replay attacks.
Possibly other attacks could also be carried out by packet manipulation. ...but I need to
think this through further. ;)

have a nice day

-martin-

-------------------
Martin Langer, M.Eng.
Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
University of Applied Sciences

Labor Datentechnik, Labor Design Digitaler Systeme
Fakultät Elektrotechnik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
Germany

Tel.: [phone]
Web: https://www.ostfalia.de/cms/de/pws/bermbach/mitarbeiter/martin-langer


________________________________
Von: ntp <[e-mail]> im Auftrag von Daniel Franke <[e-mail]>
Gesendet: Samstag, 8. Mai 2021 22:53:06
An: NTP WG
Betreff: [Ntp] A simpler way to secure PTP

As an alternative to Martin's and Heiko's drafts, I'd like to propose a simpler approach to securing PTP. It is compatible with all PTP features, supports the same threat model as NTS-secured NTP, introduces zero jitter, and can be implemented entirely on the client side without the knowledge or cooperation of the rest of the PTP infrastructure.

The trick is: run NTS-secured NTP and regular, unauthenticated PTP side-by-side. Do not use the NTP responses to set the clock; instead, use them only to establish maximum error bounds on the current time, and then clamp all PTP messages to within those bounds.

The client's on-wire interaction with the NTP server is the same as it is in normal NTS-secured NTP, but the way it processes the server's responses is different. The client maintains an estimate `theta` of the offset between a local, unadjusted monotonic clock `t_raw` (implemented e.g. by CLOCK_MONOTONIC_RAW on linux) and the server's realtime clock, along with a continuously-changing error term `lamdba`.

Upon receiving an authentic response from an NTP server, let:

  t_1 = origin timestamp captured from t_raw.
  t_2 = packet receive timestamp
  t_3 = packet transmit timestamp
  t_4 = destination timestamp captured from t_raw.
  theta = ((t_2 - t_1) + (t_3 - t_4))/2
  DTAI = TAI - UTC offset

giving a current estimated TAI time of

  t_raw + theta + DTAI

For computing error bounds, let

  hrtt = (t_4 - t_1)/2
  rdel = packet root delay
  r_1 = local clock precision
  r_2 = packet clock precision
  PHI = some appropriate upper bound on our local clock's drift rate

and then our error term is plus-or-minus

  hrtt + rdel/2 + r_1 + r_2 + PHI*(t_raw - t_1)

Only the single best clock sample, from a given NTP server, i.e. the one that gives the tightest error bounds, need be retained. Other things being equal, newer samples will be preferable to older ones because the PHI*(t_raw - t_1) term will be smaller, but sometimes this may be negated by other terms such as hrtt being larger.

A client may gain resiliency by using multiple NTS-secured NTP servers. In this case for N servers it lets f=floor((N-1)/2), then discards the f lowest lower bounds and the f highest upper bounds, and then treats anything inside any of the remaining bounds as plausible.

Any PTP message whose time (after applying the usual link-delay correction) is plausible according to these bounds is processed as usual. Any PTP message whose time is not plausible is first clamped to the nearest bound and then processed as usual.

And that's all there is to it!