Re: [Ntp] The trick to timestamp with authentication

On 4 Dec 2020, at 10:11, James wrote:

> 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
>

I agree. There seems to me that different people have different ideas on 
how NTPv5 should develop. I cannot remember that we had any real 
discussion on NTPv5’s objective in the WG. It seems to me that this is 
urgently needed.

Dieter

> 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
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp