Re: [Ntp] The trick to timestamp with authentication

Speaking as someone in broadcast, whilst the industry has standardised 
on the use of PTP in a few places (AES67, SMPTE 2110, etc) there are use 
cases where NTP is used instead, particularly where PTP is either not 
feasible or simply overkill for the application. Many of those operate 
on less-trusted networks or public internet and thus would greatly 
benefit from NTPv5 having greater security.

I don't believe on-path corrections and security are completely 
exclusive capabilities, but there's a spectrum between having on-path 
connection with either limited or more complicated security, or greater 
security with limitations on what corrections can be applied. As part of 
the requirements for NTPv5 I think the working group should decide where 
in the metaphorical spectrum we should focus on.

- J

On 04-12-2020 01:03, Doug Arnold wrote:
> I think that the enterprise networks of financial institutions, broadcast companies and power grids all want security and on path support.  Maybe large data centers as well. Broadcast and power have already adopted ptp and will probably stick with that, but my interactions with people in finance and data centers suggest that some of them would prefer a more precise version of ntp.  Some companies in finance are already doing nonstandard sub microsecond "ntp."  That is hardware timestamped ntp packets, but with higher than normal message rates and different client algorithms.
>
> The ntp working group could decide ntpv5 can support on path corrections or security, but not both.  However, I suspect a lot of people would be disappointed.
>
> Doug
>
> On 12/3/20, 6:36 PM, "Hal Murray" <hmurray@megapathdsl.net> wrote:
>
>
>      doug.arnold@meinberg-usa.com said:
>      > This could be handled using a symmetric group key that authorized nodes get
>      > periodically from a key exchange server.  See, for example GDOI.  I believe
>      > that NTS could be adapted to group key operation as well.
>
>      The whole idea of patching an authenticated packet seems wrong.
>
>      How much effort has gone into investigating alternatives?
>
>
>      > I see you were paying attention. Accuracy and security are a trade-off.  If
>      > you want on path timing support and security, then you either have to have a
>      > lot of secrets or a secret that a lot of nodes are in on.  Either way it is
>      > less secure than just NTS between a client and a server.  However, in a
>      > private network where someone wants microsecond level time transfer accuracy
>      > that might be a sensible trade-off.
>
>      That seems like a narrow market.  It's a private network.  They want
>      authentication so they don't trust their network yet they do trust it enough
>      to patch their authenticated packets.
>
>
>      --
>      These are my opinions.  I hate spam.
>
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp