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

[Heiko Gerstung <[e-mail]>]

> Am 01.06.21, 15:35 schrieb "Miroslav Lichvar" <[e-mail]>:
> 
> On Tue, Jun 01, 2021 at 02:48:32PM +0200, Heiko Gerstung wrote:
>> > Am 01.06.21, 14:01 schrieb "Miroslav Lichvar" <[e-mail]>:
>> > Can you please elaborate? My (limited) understanding of DTLS is that
>> > it would address the attacks. It has a 48-bit sequence number to
>> > protect against replays and client authentication comes from TLS.
>>
>> I understood that you want to use DTLS to exchange the symmetric keys used
>> to calculate the ICV of the unencrypted event messages. This unfortunately does
>> not address the replay/amplification vulnerability of the unicast negotiation p
>> rotocol itself, it just protects against replaying the DTLS messages.
> 
> The idea is that DTLS protects everything except the sync and delay
> request messages. The unicast negotiation would be protected, of
> course.

OK, that is something you have to describe in detail. 

>> I most probably know much less about DTLS than you, Miroslav. For example,
>> I do not know whether this requires asymmetric cryptography in every message or
>> just at the beginning in the handshake. However, I am pretty sure that DTLS can
>> be used to securely exchange the symmetric keys instead of using TLS in the NTS
>> -KE phase.
> 
> DTLS is just a datagram-based version of TLS. Asymmetric crypto is
> needed only on start. Performance would certainly not be an issue. I
> suspect you are already reinventing some of its wheels, like the
> replay protection.

OK, thanks for the explanation, I expected this to be the case but was not sure. And yes, we had to come up with solutions for replay protection etc. which most probably have been describe in a similar format. 

>> As I tried to explain earlier, our intention with this draft was to stay c
>> lose to NTS4NTP to enable implementors to re-use code and allow users to combine
>> the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other
>> protocols and security mechanisms would do the trick as well, but I believe that
>> the name "Network Time Security" indicates that it has a good chance of being a
>> better fit for securing a network time sync protocol. And, according to our res
>> earch and our experience regarding network time synchronization, we came to the
>> conclusion that this is the case for unicast PTP.
> 
> 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?

Yes, because unicast PTP does not work in the same way as NTP. NTP is based on a request/response exchange while unicast PTP is not. I would certainly be possible to put NTP4NTS messages into PTP, but that would have the same drawback that I see with Daniel's proposal to use NTP4NTS to secure the time error of PTP: you need to setup an NTS4NTP infrastructure and basically run two sync protocols plus one security/key exchange protocol in parallel. NTS4UPTP only requires you to run one sync protocol and a key exchange protocol. 

I would also not be happy with the efficiency, because an NTS4NTP packet probably has some redundant or unnecessary information in it that is not required when I run unicast PTP. And, the other way around, adding a full "dummy" PTP packet header to enable using the hw timestamping engine to hardware timestamp my NTS4NTP packets is a waste of bandwidth and CPU cycles. 

Such a NTS4NTP protocol also does not address the other advantage that unicast PTP has over NTP: higher packet rates. You can change that too, of course. In the end you created a third time sync protocol which to me looks more like a Frankenstein monster version of NTP/PTP and is a completely different beast. It will be neither compliant to NTP, nor PTP. It may work and add more accuracy to NTP4NTS, but has nothing to do with PTP. And yes, you can argue that nobody needs PTP anymore in that case, but I am not sure it will be a pleasant discussion.

> This would be a very short draft and it would be useful even for
> plain NTP without NTS. I think I'll give it a shot.

Why not. But again, this is not solving the problem of securing unicast PTP and therefore can be a nice addition to NTP/NTS4NTP, but addresses a different topic than what we proposed. 

Regards,
   Heiko



-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: [phone] 
Fax: [phone] 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[e-mail]
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung