Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

[Miroslav Lichvar <[e-mail]>]

On Wed, May 26, 2021 at 10:31:22AM +0200, Heiko Gerstung wrote:
> I just submitted the latest revision of our NTS for Unicast PTP draft (-02) which you can find here:
> 
> https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/

Here are my thoughts.

I'm missing some background of the draft. What is the issue of the
solutions described in IEEE1588, like authentication with manually
distributed symmetric keys and security mechanisms implemented at
lower layers like MACsec and IPsec, that this draft is supposed to
address?

In NTP, NTS is mainly about scaling to large numbers of clients and
privacy. None of that applies to the PTP unicast mode. Due to the
infinite amplification factor and susceptibility to DoS attacks
clients have to be authorized, so I think even the need of public-key
crypto should be explained. Is it supposed to make management of PTP
in a network easier or more secure by distributing certificates
instead of symmetric keys?

I'm missing some description on whether/how this is supposed to work
with transparent clocks. In the IEEE1588 terms, is the correction
field considered mutable?

As you already have to keep a client-specific state, I'd say an
obvious question is why not use an existing application payload
security protocol like DTLS? The draft would basically turn into
"Exchange PTP messages over DTLS on ports X and Y".

If you needed to support transparent clocks and/or keep compatibility
with some existing hardware than can timestamp only specific messages
on the standard PTP event port, you could use DTLS only for general
messages and add a single TLV to get the key needed for authentication
of event messages. I think that would still be easier to implement
(using an existing DTLS implementation) and have a much simpler
specification than what you are currently proposing.

As for that issue with detecting delay attacks that Daniel brought up,
I think that might be better to have its own draft as it applies to
all PTP modes and all security mechanisms, even those at lower layers,
if the existing documents (e.g. IEEE1588 and RFC 7384) are not
sufficient.

-- 
Miroslav Lichvar