There currently is an effort going to experiment with pool constructions for NTS. For this purpose, we are running an experimental pool using one of the implementation techniques currently suggested to the IETF at https://experimental.ntspooltest.org.
If you are interested in this sort of effort, it would help us immensely if you experiment with it and provide feedback to us, either trying to use the pool as an NTS time source, or by trying to add one of your servers to the pool. The pool is functional at this time, and we could greatly use feedback to learn what is needed to give this, and NTS adoption, the best chance of success in the long term.
Sure! The nts pool experiment is being run by the Trifecta Tech Foundation, which is a dutch not-for-profit focussing on developing open source software and running digital commons. You might know us as the people developing ntpd-rs or sudo-rs.
I (David) am one of the developers active on the time synchronization front, being one of the driving forces behind ntpd-rs, and one of the author of the draft specification for nts pools the experiment is build on (draft-venhoek-nts-pool-04 - NTS extensions for enabling pools). Within the experimental pool project, I am one of 4 people responsible for building and running the experiment, with my focus being mostly on the protocol and backend side of things.
If you have further questions on who we are or what we do, feel free to ask
Sounds interesting! Unfortunately i don’t operate NTS timeservers.
I’ve looked into it some time ago, but it complicated to setup on the appliances i run.
I’ll sit this one out…
But your remark makes me wonder; what if I’m on an IPv6-only client, connecting to 0.ke.experimental.ntspooltest.org; is there a change it will make an attempt to redirect me to an IPv4-only server? Because according to the RFC this should not happen.
Hi, Having had a look at the monitoring logs for your server, the problem is that your NTS server currently doesn’t support the protocol extensions needed to join the pool.
When designing a pool for NTS there is an unfortunate reality that needs to be faced that is not present for NTP pools, namely that a pool requires either changes on the client or on the servers that participate in it. For the design we are currently testing, we decided on the tradeoff to require modifications on servers, allowing clients to be unchanged.
Also taken a look at your logs, it seems occasionally your server requires more than 1 second to react to the NTP messages when approached over ipv4. Not sure why that would be.
We are still considering this timeout, but given that only a single rtt is needed I am not sure we will be in a hurry to change this particular one. We are working on a better interface that surfaces the interesting part of the logs better, that will hopefully be deployed later this week.
On the ipv4 vs ipv6 front, the pool is smart enough to never give you an ipv4 only server when you contact it over ipv6. This is why there are separate scores for ipv4 and ipv6 on servers.
Hi, thanks for the reply. I’m using chrony latest version on Linux and NTS works just fine here and for my clients. Can you elaborate more on the “protocol extensions” that your pool requires? Thanks
Same for me. I tried it too, but found it needlessly complicated for something that is universal the same and easy to check.
Why do a complicated man-in-the-middle-attack on timeservers when it’s far easier to do phishing or simply call people to ask for their bank-details?
Crooks already changed their ways into something that is far more simple to do and brings easy large profits.
You can not secure anything against stupidity of the human in front of the screen or at the phone
That’s because I looked at the modified source code of Chrony 4.8 and could not find the extensions defined in draft-venhoek-nts-pool, so I may have overlooked a couple of things. Pretty funny indeed. I did find a new configuration option ntsauthtokenfile, but the adapted Chrony version I currently run doesn’t have it, because it is rather new. So apparently is also works without, albeit perhaps less efficient?
Hence, I figured to raise the question here, although meanwhile I have already found a few more clues in the adapted source code of Chrony 4.8.
What did you do to try and understand it? Perhaps we can help.
I did find a lot of NTS keys being stored when it’s enabled as client.
It does connect via NTS to NTS-servers.
But I could not get it to work itself as NTS-server.
Just wanted to test it, to see how it’s done. But never got it working.
Also tried NTPD-RS (forgot the exact name), but I find NTPD too hard to work with, as well to monitor it. So I gave up.
I’m not particular interested to use NTS, just wanted to know how it’s done.
As I have been trying IPv6 on my local network again….yes IPv6 runs, but the firewall fights me and I can’t figure out what I’m doing wrong…but different discussion.
I have plenty time to test stuff as with long-covid, since 22-2-2020 (got it on my birthday), I can not work anymore or do intensive work, but playing with computers and hardware is no problem.
So I try and test a lot….or do translations for hosting-panel-software, not much else I can do.
@microchip8@marco.davids Essentially, the current design of the NTS pool we are testing has the pool itself act as the key exchange server. To do this, it needs to be able to
a) know which algorithms/protocols the time source understands, for which we have extensions that allow us to query that from the time source’s KE server.
b) get cookies for specific keys, which again we have custom extensions for.
These are the extensions that are needed to be able to be a part of the pool. On top of that we have a further custom extension to allow us to reuse connections to time sources, which if you have that reduces the load from tls handshakes both on the pool and on the time sources.
