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

[Doug Arnold <[e-mail]>]

I think that it is clumsy to bring in another protocol to add security to the one of interest.  Why not just add the same functionality to PTP?

Doug

From: ntp <[e-mail]> on behalf of Daniel Franke <[e-mail]>
Date: Tuesday, June 1, 2021 at 3:27 PM
To: Miroslav Lichvar <[e-mail]>
Cc: [e-mail] <[e-mail]>, Heiko Gerstung <[e-mail]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
On Tue, Jun 1, 2021 at 9:35 AM Miroslav Lichvar <[e-mail]> wrote:
> Ok, if you need as much of NTS4NTP as possible and at the same time
> keep accuracy provided by hardware timestamping as is supported in
> current hardware, I think the solution is simple: NTS4NTP over PTP.
>
> You can wrap NTP messages in a PTP event message to get hardware
> timestamps and keep all the benefits of NTS4NTP. It seems your plan is
> to provide NTS4NTP in any case. Do you see any disadvantages?

All these long and similar initialisms for the various PTP security
proposals are getting unmanageable, so I'm going to create some new
ones:

* I'm going to start calling my proposal NSCoPE, for NTP Securely
Constraining PTP Errors.

* I'm going to call Miroslav's proposal PEN, for PTP-Encapsulated NTP.

* I'll keep using NTS4NTP for RFC 8915, NTS4UPTP for the
Gerstung-Rohde-Arnold draft, and NTS4PTP for the Langer-Bermbach
draft.

I agree with Miroslav that PEN likely requires a lot less development
effort than NTS4UPTP does, but it still requires changes to both the
server and the client, unlike NSCoPE which can be implemented
unilaterally on the client. There's a tremendous gulf between changing
one line of code on the server and changing zero. A one-line change
requires a full-blown standards-track effort involving multiple
standards bodies, interop testing between vendors, and lots of network
infrastructure that needs upgrading, even if the upgrade is just a
firmware patch. If only client-side changes are needed, none of this
coordination is required.

Maybe a better way to think of PEN is not as a security layer for PTP,
but rather as a way to improve the typical-case precision of NTP by
adding hardware timestamps. It strikes me as a better alternative to
interleaved mode, one which avoids the need for server state or for
sending follow-up packets. It's hardly PTP at all; the fact that
responses come back framed as PTP event messages is just a hack to get
existing hardware to cooperate. The fact that the NTP messages can use
NTS is pretty much incidental. You can do PEN with unauthenticated NTP
messages too and (as long as you're not under attack) get all the same
benefit to precision.

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp