Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

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

yeah... guess you are right.


In this case we need a periodic unicast connection as a watchdog protocol, ...or something else.

The group-based PTP (multicast) communication is a tricky one.

It is hard to secure. Especially delay attacks.

... on the other hand... it is also a part of the security prongs C and D of PTPv2.1 (redundancy and monitoring).
We are not able to secure packets against delay attacks with cryptographic measures.


-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: Miroslav Lichvar <[e-mail]>
Gesendet: Montag, 8. März 2021 12:38:05
An: Langer, Martin
Cc: NTP WG
Betreff: Re: [Ntp] Comments on draft-langer-ntp-nts-for-ptp

On Mon, Mar 08, 2021 at 11:09:49AM +0000, Langer, Martin wrote:
> The multicast connections are not comparable to the broadcast connections in NTP.

I think they are pretty much the same if you assume the NTP client is
making periodic measurements of the delay and not just once on start.

> In NTP, TESLA-secured communication could be broken, because delay attacks are not
> detectable. However, in PTP we have two-way communication (Delay Request/Response)
> during multicast, which can be used to register runtime changes (RTT). However, a formal
> analysis is indeed not available.

The delay measurement has a request and response, but the offset
measurement (using sync messages) does not. Delay messages can be much
less frequent than sync messages. That's quite different from the NTP
client-server mode, where each request has an immediate response.

--
Miroslav Lichvar