From nobody Thu Jun 3 00:07:59 2021 Return-Path: X-Original-To: ntp@ietfa.amsl.com Delivered-To: ntp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6643A2D79 for ; Thu, 3 Jun 2021 00:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.719 X-Spam-Level: X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43DCF4UqpyYR for ; Thu, 3 Jun 2021 00:07:52 -0700 (PDT) Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9073A2D77 for ; Thu, 3 Jun 2021 00:07:51 -0700 (PDT) Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 15377mVs015886-15377mVu015886 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 3 Jun 2021 09:07:48 +0200 Received: from lotus.bs.ptb.de (lotus.bs.ptb.de [141.25.85.200]) by smtp-hub.bs.ptb.de (Postfix) with ESMTPS id AFEC0B77520 for ; Thu, 3 Jun 2021 09:07:48 +0200 (CEST) MIME-Version: 1.0 Sensitivity: Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: kristof.teichel@ptb.de To: "NTP WG" Date: Thu, 3 Jun 2021 09:07:45 +0200 Message-ID: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption [FORMAL RESPONSES?] X-BeenThere: ntp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2021 07:07:58 -0000
So, we've had lots o= f discussion about the general topic that is associated with the draft.
What I feel we as a group are losing sight of is the= core of the question that Heiko asked: are we as a WG in favor of adopting= the NTS4UPTP draft?

Maybe at this point it is time = to take a tally, because I definitely see how a lot of the discussion could= be read as criticism/rejection of the draft when it isn't necessarily that= .
So far, we've had responses on this overall thread from 14 peop= le, as far as I can see.
On an arbitrarily chosen scale of "s= trong reject / weak reject / undecided / weak support / strong support", we= 've heard exactly one voice that I would call a strong reject, one strong s= upport, and at least my own weak support (arguably, a number of comments co= uld be read to represent weak support, but it would really be better to not= have to do much interpretation there).
Mostly, people have forgo= ne giving a clear statement on the core question (although we have a number= of statements that some draft in this vein should be adopted).
<= br>
From the NTS drafts times, I remember that I occasionally wis= hed the WG had a more formal approach to these inherently formal matters.
To anyone who feels hasn't given an explicit statement: could you = please make an effort to do so - or try to describe what you still require = to form an opinion?


Best regards,
Kristof



-----"ntp" <ntp-bounces@ietf.org> sch= rieb: -----
An: "Miroslav Lichvar" <mlichvar@redhat.com>= ;
Von: "Heiko Gerstung"
Gesendet von: "ntp"
Datum: 02.06.2021 18:13
Kopie: "ntp@ietf.org>
Betreff: Re: [Ntp] NTS= 4UPTP Rev 03 - Formal request for WG adoption

>
> Am 02.06.21, 15:21 sch= rieb "Miroslav Lichvar" <mlichvar@redhat.com>:
&= gt;
> On Wed, Jun 02, 2021 at 01:00:27PM +0200, Heiko Gerstung wrote= :
>> Yes, it needs to be fleshed out in more detail in a draft. My= point is tha
> t you could use a different approach than what we cho= se in our proposal, but you
> then have to put this down in writing a= nd submit a draft if you are convinced i
> t has enought benefits whe= n compared to our approach. If you believe it would be
> a lot shorte= r, more compact document with less complexity and provides the same
>= or a higher level of protection/efficiency, then please write it down so w= e can
> compare it in its entirety.
>
> I'm not interest= ed in writing a new NTS4UPTP draft, at least not at
> this time. I'm = asking you to reconsider your design or at least
> describe how it co= mpares to possible alternatives.

Well, I tried to describe how it co= mpares to all the alternatives that you and others brought up. Please excus= e my confusion, but I am not sure how to proceed from here. I was told nume= rous times in the past that if I wanted other people to discuss a proposal = of mine, then I should come up with a draft. This is exactly what I did wit= h NTS4UPTP. But instead of discussing my proposal, people start to propose = alternative approaches (by mentioning them in a sentence or two, most of th= e time claim that this alternative is either already available or requires = only a very short and compact document to describe it and matches or exceed= s the security gain of our proposal).

It is pretty hard to try and = compare our proposal against a bunch of ideas that are thrown into the disc= ussion. Most of the proposed alternatives seem simple and easy to describe = with two or three sentences, but when we drafted our proposal, we found out= (once again) that when you try to describe something in written form, a lo= t of details and corner cases come up that you have to deal with. In the en= d, you often end up with at least 10-20 pages, no matter how simple the ide= a sounds in the beginning.

Your last proposed alternative is to use = NTP4NTS instead of securing PTP. This is not a request for reconsideration = of my design, it is basically a rejection of the entire design. It is not d= oing the job of securing unicast PTP, instead it introduces a way to increa= se the accuracy of NTP (and/or NTS4NTP). Users already using or planning to= use unicast PTP in their networks would have to completely redesign their = sync architecture and infrastructure. They cannot use the security mechanis= m that is a part of the PTP standard, instead you suggest they should switc= h to a different protocol.

The first question was why not using MAC= sec or IPsec. I explained that it will not work because of the loss of the = hardware timestamping capabilities.

After that, you proposed to use= DTLS instead of NTS-KE. I do not know enough details to be able to compare= it. From the few sentences you wrote, I would guess that it will work and = would offer a way to secure PTP synchronization as well, but when I compare= this idea with our draft, I see these following points:

* DTLS: Asy= mmetric cryptography would have to be required to be carried out by every P= TP server separately for each client (even if this happens only once at the= beginning to initialize the DTLS communication). This requires a major mod= ification to the PTP software on the server side and is also requiring more= processing power on each PTP instance
* NTS4UPTP: Asymmetric cryptograp= hy can be handled on a separate NTS-KE server and is not required by the PT= P server to handle the clients.

* DTLS: would require to protect de= lay responses and announce messages from the server (in the packet transmis= sion phase)
* NTS4UPTP: only requires to use the integrated PTP security= mechanism in phase 3 for all message types

* DTLS: would require to= write a completely new draft, no volunteers yet
* NTS4UPTP: draft is al= ready there and could be discussed right away, three authors committed to w= ork on it

Not sure if this is more like what you would like to see = from me in regards to a comparison.

At this point I would be open t= o change the name of the draft so that it does not contain "NTS" anymore, i= f that helps. It seems that quite a number of the authors do not like that = we based our proposal on their work and would rather like unicast PTP to us= e something else as a key exchange protocol. I do not think that this is re= asonable, it has been mentioned numerous times now that there are quite a n= umber of users operating both NTP and PTP sync infrastructure in parallel a= nd I am still convinced they appreciate to be able to set up one NTS-KE ser= ver infrastructure that handles both NTS4NTP and our proposal. And: ee want= ed to use the latest and greatest key exchange protocol that has been desig= ned by security experts and time sync specialists.
 
>> &= gt; If you used only NTP4NTS over PTP, you would still have only one sync>> > protocol. Just the transport is different. That's a couple = lines of
>> > code.
>>
>> A couple lines of c= ode? OK, if you volunteer to modify chrony, I would vol
> unteer to t= est this with our hardware time stamping engine. Just add a comment w
&g= t; here you want to get the hw timestamp from our engine and we will add th= e necess
> ary function call to actually get it from the hardware. Pl= ease ensure that you n
> eed to read out at least the sequenceId and = MessageType from the PTP header as t
> hat is required to find the co= rrect timestamp in the queue. See my comments to K
> ristof earlier t= oday regarding the requirement to add support for different time
> st= amping hardware, but a first test if this actually works would certainly be= in
> teresting, so why not give it a shot if it's only a couple line= s of code!
>
> It is 7 lines for a quick hack that hardcodes a= PTP prefix for all NTP
> messages [1]. Both server and client ports = need to be configured to
> the PTP port. If your timestamper doesn't = use the Linux timestamping
> API, it will probably require significan= t changes. I'll leave that up
> to you if you think it's worth the tr= ouble.

Thanks, I do not think it is worth the trouble. There would s= till be code missing to use the obtained hardware timestamps and replace/ad= just the timestamps of NTS4NTP with it. But you brought it up and I believe= it could fly and improve the accuracy of NTP/NTS4NTP. Still not sure how t= o get the time into the hardware timestamper for a server that supports thi= s, but it might be worth working on it.

> I tested it on two NICs= : Intel XL710 (40Gb) and Broadcom BCM5720
> (1Gb). Both seem to work = as expected. It seems their filter only
> checks the message type and= version, ignoring the length and other
> fields. If all HW worked li= ke that and it was acceptable to generate
> invalid PTP messages, the= messages could be only two octets longer.
Yes, the good thing about PTP= messages is that they are not fixed length due to the TLV concept.
>> The NTS=5FTLV is not used for the actual sync / delay / announce = messages in
>> our draft, that means you have the authentication= =5FTLV as an overhead compared t
>> o standard unicast PTP. This T= LV has a size of 42 octets (if I assume a ICV size
>> of 256 bit).= The Common PTP message header is 34 octets in size, the size of th
>= > e Sync and Delay=5FReq messages is another 10 octets, resulting in 44 = octets in to
>> tal, which proves your point.
 
> An= other thing to consider is that PTP exchanges more messages per
> mea= surement than NTP. In NTP it's 2 messages to get all 4 timestamps.
> = In PTP it's 4 or 5 to get the timestamps and there are also announce
>= ; messages and unicast-specific messages. NTP4NTS over PTP might
> ac= tually save some network bandwidth.

Yes, maybe 300kbit/s per client = (~300 bytes less, 128 pkt/s).

> [1] https://fedorapeople.org/= ~mlichvar/chrony/chrony-ntpoverptp.patch
Thanks a lot.

Best R= egards,
   Heiko



--
Heiko Gerstung
Mana= ging Director
 
MEINBERG=C2=AE Funkuhren GmbH & Co. KG
= Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone: +49 (0)5281 9309-4= 04
Fax: +49 (0)5281 9309-9404
 
Amtsgericht Hannover 17HRA = 100322
Gesch=C3=A4ftsf=C3=BChrer/Management: G=C3=BCnter Meinberg, Wern= er Meinberg, Andre Hartmann, Heiko Gerstung
 
Email:
heiko.gerstung@meinberg.de
Web:
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 = ;
Do not miss our Time Synchronization Blog:
https://blog.meinbergglobal.com
 
Conne= ct via LinkedIn:
= https://www.linkedin.com/in/heikogerstung
 
 

=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ntp mail= ing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp
<= /div>