Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption (SUPPORT)

[Heiko Gerstung <[e-mail]>]

> Von: ntp <[e-mail]> im Auftrag von <[e-mail]>

> Datum: Montag, 31. Mai 2021 um 17:28

> An: Kai Heine <[e-mail]>, NTP WG <[e-mail]>

 

 

> [...]

> As someone who is also involved in the security subcommittee of the 1588 WG, I f

> eel that it might be important to clarify the following:

> PTP has a method of transporting authentication tags in a TLV field, specified i

> n the current standard version.

> What is "missing" is a key management scheme that enables the use of those secur

> ity TLVs (there are some, but I feel that one based on NTS' methods would be rea

> lly nice to have).

 

And I would like to add that unicast PTP has no means of protection against someone sending a negotiation request (or cancel) packet with a forged IP address, as the TLV you refer to does not protect the transport header which, in turn, is used by the unicast PTP server to determine the IP address of the requesting client. 

 

> So far, AFAIK, Heiko's draft is the only document that has actually been propose

> d here.

 

Martin and Rainer also submitted a draft, well before ours, back in February. You can find it here:

https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/

 

Unlike our draft it also covers multicast PTP and is introducing more significant additions to the NTS-KE phase. It is 69 pages in sizes and a very comprehensive and detailed document, and I definitely believe it is worth discussing it in the WG as well. One motivation for creating NTS4UPTP was that we believe that it is more practical to stay closer to NTS4NTP by reusing as much of the NTS-KE phase as possible, given the differences of NTP and unicast PTP. Plus, securing a multicast protocol requires even more effort IMHO than unicast, after all there was a good reason why NTS4NTP does not cover multicast/broadcast modes of NTP. By focusing on unicast, I am confident that we can get to a standard a lot faster, and I would like to find a way to secure both multicast NTP and PTP in an additional step in the future. 

 

> I'm sorry, but I haven't read it closely enough to judge its technical merits.

I really would like to start discussing the draft on a technical basis, that is why I would like to see it being adopted by the WG.

 

> [...]

> Until then, I believe I support adoption of Heiko's draft (except if there is a

> good argument to be made that we need to look at all candidates first and then c

> hoose one?).

That is a question I would have, too. 

 

> The approach certainly seems to have enough merit for at least a WG-wide discuss

> ion.

> 

> I also feel that I would like to hear more people's opinions, especially more wh

> o don't have a candidate of their own in this race.

 

Yes please. And, tbh, I do not really consider this a race or a competition. I would prefer to put all proposals on the table and find a way to combine them and/or divide them into two or more documents which address a separate set of problems/challenges and in the end are complementing each other. 

 

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