Subject: [Ntp] NTS implementation / IANA port registration

From: Heiko Gerstung <[email-masked]>
Date: Thu, 13 Dec 2018 17:38:00 +0100

Hi all,

just a short heads-up that Meinberg teamed up with the Ostfalia University to create an open sourced NTS implementation based on the current state of the document (we will of course update the code if required due to last changes). We are already well into the development process and will implement nts client and server daemons (Meinberg) as well as a library (Ostfalia) that implements the core NTS algorithms and is used by the daemons for all crypto related stuff. Both the library and the daemon code will be available for others to speed up adoption, we are planning to release this under a BSD style license and are very confident we have a working solution within the next 10-12 weeks. 

What I would like to see added to the draft is a request to IANA to assign a dedicated port number for NTS as our approach foresees that NTS can run alongside NTP and other time sync mechanisms on one machine and we cannot use port 123 for this. The implementation will be capable of using any configured port but it is important to have a default port IMHO.

Our current architecture works well with ntpd, we only need to patch a single line of code to allow ntpd to use ntsclientd as a "relay" for getting secure time from a number of NTS servers. I believe that this makes it easy to add NTS to an already existing setup and should work with other implementations as well (we will test chrony and maybe openntpd but I am open for suggestions). This is to speed up adoption by users, the preferred way of utilizing NTS will be to use the Ostfalia library to directly integrate NTS with your NTP implementation. 

I strongly support going forward, publishing the NTS standard and work on a revision/follow up later to add any missing features. Our customers (tens of thousands of NTP users in all kinds of industries and segments) will be happy with a unicast only solution and my educated guess is that 95+% of NTP setups are unicast-only. No doubt that we all would love to cover 100% right from the start, but the additional effort required to accommodate the last 5% is not justified if that means the 95% of users - who would benefit from publishing the draft in its current state - will have to wait another couple of months.

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
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

---

From: Dieter Sibold <[email-masked]>
Date: Mon, 17 Dec 2018 08:47:37 +0000

Dear Heiko,
we very much appreciate your strong support to go forward with NTS in its current form. We also acknowledge your plans in implementing NTS. Many thanks!

Regarding the port assignment request:

1) For the key exchange phase NTS needs an assigned TCP port. A request for a port assignment is already included in the current draft (Section 7.1).

2) For the time exchange messages: The security information of these message are encapsulated in NTP extension fields. The assumption is, that a NTP daemon - capable of NTS and listening on port udp/123 - does also process these extension fields. Consequently, no addition port is needed and therefore no port assignment request is necessary for those messages. It is not our opinion that this document should assign a new port for NTS protected NTP messages. By design, the NTS draft also allows an NTP daemon capable of NTS to respond to NTS protected time queries as well as plain NTP queries.

Regards
- Dieter

Am 13.12.18, 17:38 schrieb "ntp im Auftrag von Heiko Gerstung" <[email-masked] im Auftrag von [email-masked]>:

    Hi all,

    

    Best Regards,
       Heiko

    -- 
    Heiko Gerstung 
    Managing Director

    
    Email:

    Connect via LinkedIn: 

    
    _______________________________________________
    ntp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 17 Dec 2018 01:06:42 -0800

Heiko,

> just a short heads-up that Meinberg teamed up with the Ostfalia University to create an open sourced NTS implementation based on the current state of the document (we will of course update the code…

Where can this code be found?

> What I would like to see added to the draft is a request to IANA to assign a dedicated port number for NTS as our approach foresees that NTS can run alongside NTP and other time sync mechanisms on…

Curious - why do you believe this cannot be done over port TCP/123 ?

> Our current architecture works well with ntpd, we only need to patch a single line of code to allow ntpd to use ntsclientd as a "relay" for getting secure time from a number of NTS servers. I belie…

I'm astonished.  I would think ntpd would need to interface with this
code in 3 places, not just one.

H
--

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Heiko Gerstung <[email-masked]>
Date: Mon, 17 Dec 2018 11:46:07 +0100

Hi Dieter and everyone,

I received some questions regarding my request to assign a dedicated port to NTS for the time exchange part, therefore I believe it is required to explain this a little bit more. 

My intention is that I want it to be possible to run a dedicated NTS daemon in parallel to any NTP implementation which does exist on a user machine (or our appliances). In my opinion, this has some advantages over re-using the well known NTP port for both NTP and NTS time exchanges. 

Here is my list:

1. I will be able to install my NTS daemon on a machine that runs ntpd, chrony or whatever implementation there might be - without having to wait until that NTP implementation is implementing NTS. In my opinion, this will speed up adoption of NTS. I can use ntpd for example with its extensive list of supported refclocks and add NTS to it without having to wait until it is implemented. I assume that most of the implementations will aim for supporting NTS as fast as possible, but it may still take time before each and every NTP client/server implementation releases a stable NTS version. 

2. Decoupling NTS from the NTP server process will allow to use other means of synchronizing the clock used by the NTS server process, for example a PTP client software can be used to synchronize the system time to a PTP Grandmaster and by installing my NTS server daemon, I provide secure and accurate time to NTS clients.

3. By having a distinguished port for NTS, my customers can use their firewalls to limit time synchronization for a specific network segment to NTS without having to make sure that each and every client in that network is configured correctly to use NTS. 

As it is for most protocols, I would certainly want NTS to be configurable and tolerant in regards to the used server ports. It should be possible for a user to not have to use the default NTS port (or NTP port) and instead freely select a port on which its NTS servers listen for incoming NTS requests. This is possible with all kinds of other protocols/services including ssh and https and gives the user more flexibility in specific network environments. 

I do not oppose the possibility that an NTP/NTS implementation chooses to offer the possibility to handle both NTP and NTS requests on UDP/123. I also do not have a problem with an NTS implementation that chooses to allow to respond to standard NTP requests on the port it listens on for NTS requests. But in my opinion an isolation of the secure NTS protocol from the standard NTP protocol is a cleaner way to handle both NTS-only and NTP/NTS combined modes of operation. 

In our implementation, we will definitely allow the user to configure a NTS port for a server and the NTS client config will have the possibility to define a list of NTS servers where each server with IP/Hostname and Port. I strongly prefer having a well known standardized NTS port for the time exchange, alternatively we would pick one as the default port for our implementation. 

These points are based on my experience selling and deploying tens of thousands of professional NTP appliances in all kinds of different environments. Your mileage may vary.

Regards,
    Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 17.12.18, 09:48 "ntp im Auftrag von Dieter Sibold" <[email-masked] im Auftrag von [email-masked]> wrote:

    Dear Heiko,

    
    
    Regards
    - Dieter

    
    
        Hi all,

        

        Best Regards,
           Heiko

        -- 
        Heiko Gerstung 
        Managing Director

        
        Email:

        Connect via LinkedIn: