Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd)
-
I don’t doubt hardware optimised for time keeping will do better than hardware optimised for firewall functionality.
I don’t think that’s relevant though. The issue is chrony provides better functionality on whatever hardware it runs on. It’s simply better at it’s job, so given the choice, it is the preferred option.
But then again both of the above are answer to the the wrong question. A more relevant question is: is improving the time functionality of high enough priority to actually be done by a company who sells expertises in firewalls. I suspect the answer to this question is no, it will be upgraded when added upstream.
So unless someone outside of Netgate is willing and able to implement and test a chrony port, I can’t see it happening.
-
@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Doing NTP well is not easy, because, say, one temperature dependency of crystal can throw the whole thing in the trash.
If you're relying on a crystal, you're doing it wrong. NTP servers are supposed to be traceable back to something called International Atomic Time, which is the average of several atomic clocks around the world. The NTP software averages out the variations and if you have multiple sources (you should have at least 3), your time will actually be better than a single source. That said, however, hardware quality may affect jitter.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@patch said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
I don’t doubt hardware optimised for time keeping will do better than hardware optimised for firewall functionality.
Totally agree. In previous replies I just note that most of the modern devices are just “PPS signal source (GPS, RF) + embedded SoC that realize NTP server”
I don’t think that’s relevant though. The issue is chrony provides better functionality on whatever hardware it runs on. It’s simply better at it’s job, so given the choice, it is the preferred option.
But then again both of the above are answer to the the wrong question. A more relevant question is: is improving the time functionality of high enough priority to actually be done by a company who sells expertises in firewalls. I suspect the answer to this question is no, it will be upgraded when added upstream.
Thank You for most relevant reply here ;)
So unless someone outside of Netgate is willing and able to implement and test a chrony port, I can’t see it happening.
May be I have time in this wintertime ;)
P.S. Chrony able to using NTS/NTPsec.
P.P.S.
From Netgate Official docs:
Time and clock issues are relatively common on hardware, but on firewalls they are critical, especially if the firewall is performing tasks involving validating certificates as part of a PKI infrastructure.
...
Not only will getting this all in line help with critical system tasks, but it also ensures that the log files on the firewall are properly timestamped, which aids with troubleshooting, record keeping, and general system management.
-
@jknott said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
If you're relying on a crystal, you're doing it wrong.
Yup,
I did not mean that I produce the time source itself with a crystal, say a VCO
unless I was referring to the fact that all computing devices follow some basic clock, e.g. CPU, BUS, RAM cycles, etc.
So there are a thousand points where time can be lost...
Of course, what you describe is the right approach, but it is also pointed out wherever time is involved, for example here:
(this is one of the behaviors of the NTPd and what would be good) + so this should not be news
++++edit:
BTW:
https://www.microsemi.com/product-directory/3425-timing-synchronizationHSO with Rubidium, OCXO, TCXO, Quartz = crystal :)
https://timetoolsltd.com/atomic-clocks/high-stability-oscillators/Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
I have 5 sources, 3 stratum 1 and 2 stratum 2. One thing some people don't realize is the math that goes on to calculate the transit delay and then the error from the source. They're described in this article. I had to show that to a co-worker a couple of years ago. He thought each hop was delay from the one it connected to.
GPS is an excellent source as it traces back to IAT, through atomic clocks on the satellite. There's also WWVB. There were a couple of other methods that are pretty much gone now. One was the old 2G CDMA cell network, which used extremely precise time on the phones and the NTSC analog TV signal, where the colour burst frequency was tied to an atomic clock and some stations (PBS) provided the time of day in the vertical blanking interval. Even short wave radio broadcasts from WWV or CHU can be used, though their short term stability is not as good as WWVB. An NTP server that's not traceable back to IAT is supposed to be stratum 15.
BTW, here's a free book from the NIST about time.
From Sundials To Atomic Clocks -
@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
HSO with Rubidium, OCXO, TCXO, Quartz = crystal :)
Yep, the crystal will be synced to the source and provide the correct time should you lose the connection to the source.
-
Forgot to mention, my background is in the telecom industry. Prior to IP becoming so popular, the phone network was based on time division multiplexing, which required precise synchronization. The way this was done was to include the timing in the signalling. At the company I worked for, LORAN C was used as the primary source. However, that provided a time base only and not time of day. Some of the people I worked with didn't understand the difference.
-
@jknott said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Forgot to mention, my background is in the telecom industry.
In a way, I am also a telecom professional, I used to build telecommunication microwave networks and antenna systems
(I got a degree in RF engineering, huhu many many years ago :-))Now I am the chief engineer of a URH-FM network of several radio stations.
(yeah, but we currently have several satellite broadcasting cars, where timing is also important)BTW:
Thanks for the technical guide (NIST) I have not come across this before -
In a "Big Enterprise" where timestamping is critical , nobody would use the firewall as their NTP Master.
They would use dedicated hardware , as the Mentioned Meinberg above, or Ie.
Symmetricom.
https://prostudioconnection.com/products/symmetricom-syncserver-s300-gps-ntp-network-time-server-atomic-clock-receiver-refurbished-1They would have 2..4 of these boxes , spread over multiple sites ,and all in a "Peer setup", they might even use a couple of "selected" external NTP servers, for extra reduncancy. But their primary trust would be their internal dedicated NTP servers.
You can even get some of the bxes doing both NTP & "SYSPLEX" ... @JKnott
Dealing with timestamping firewall loglines and/or Certificate validation would easily be fulfilled, by letting the firewall be a Client to the "Inside coproprate NTP setup".
Your normal PC/server Xtal is NOT "Time-nut" worthy , and it will drift quite a lot depending on environment temperature.
The Interrupt Latency would also be variable , especially with the CPU ability to scale frequency up & down , and will contribute to the Jitter.A dedicated NTP server would often have 1-PPS timestamping in hardware , and if the buyer isn't going "Cheap" , there will be an OCXO or even a Rubidium clock source inside.
The need for the OCXO/Rubi is typically for improving the Holdover period (aka if the GPS signal is lost). A TCXO would be enough for keeping the "Specs" if one would trust that the GPS signal was always present.PHK did a "Super precise NTP server implementation" using the Soekris
https://www.febo.com/time-freq/ntp/soekris/index.htmlAnd the "Magic" was HW-timer 1-PPS timestamping , in the ELAN CPU used in the Soekris. Helped
Ohh his work on the BSD Kernel timestamping, didn't hurt either.
But that would be available for any BSD HW.Edit:
This is the drift on my Atom270 based NTP Server, using a "simple" Xtal$ cat /var/lib/ntp/ntp.drift 26.975/Bingo
-
Dear pfSense friends! (May is call You like that ? ;)
Personally I thankful to all here and each of You about suggestions and professional-grade level of discussion! A lot of interesting info for others and some - may be interesting for Pro-grade SysAdmins.
Only a few users here on forum have dedicated stand-alone Time-source device, like You refer to in several replies ago.
So, let me propose to change our direction back to the Chrony with NTS/NTPsec as replace of old/unsecured NTP. (In form of additional package with GUI for pfSense).Cheers
-
@sergei_shablovsky said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
So, let me propose to change our direction back to the Chrony
Uhum
as someone wrote above this needs to be ported, I don't think it will be included otherwise, may need a persistent and dedicated programmer with a lot of time,....hihihi
You wrote you may have time in the winter, we would welcome such an initiative
(note: as a system administrator say, it's COVID time again, ergo more work, not to mention Ransomware + APTs
-
@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
as someone wrote above this needs to be ported
I think 3.5 is available since freebsd 12? Just in the normal freebsd packages.. So it should be possible without having to build or port, etc. Latest is 4.1?
-
@johnpoz said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
I think 3.5 is available since freebsd 12?
Ah, right it's already 4.1 currently...
https://www.freebsd.org/cgi/ports.cgi?query=Chrony&stype=all++++edit:
Then all we need is PHP, Netgate and you're done :-)Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Then all we need is PHP, Netgate and you're done
Easy peasy ;) @Sergei_Shablovsky can you knock that out this afternoon ;) hehehe
-
@daddygo said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
@johnpoz said in Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
I think 3.5 is available since freebsd 12?
Ah, right it's already 4.1 currently...
https://www.freebsd.org/cgi/ports.cgi?query=Chrony&stype=all++++edit:
Then all we need is PHP, Netgate and you're done :-)As You may see both for ntpd (FreeBSD) and Chrony (FreeBSD, offsite) a lot of settings are common, so most users that need NTP service on pfSense would have short adoption time and not to be disappointed by a lot of new options in NTP GUI.
The main question is still “because of ntpd was outdated is replacement to Chrony in pfSense NTP service needed, or better to keep both ntpd and Chrony as additional pfSense package”.
Anyway time of ntpd gone away (like most of old protocols) and one day this question pop up again. Why need to be so sticky to old protocol? Chrony able to keep old-fashioned ntpd clients well without any issues, Chrony already exist in FreeBSD 12 and 13...
—
CLOSE SKY FOR UKRAINE https://youtu.be/_tU1i8VAdCo !
Help Ukraine to resist, save civilians people’s lives !
(Take an active part in public protests, push on Your country’s politics, congressmans, mass media, leaders of opinion.) -
@sergei_shablovsky said in Chrony, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
The main question is still “because of ntpd was outdated is replacement to Chrony in pfSense NTP service needed, or better to keep both ntpd and Chrony as additional pfSense package”.
NTP should not be removed from pfSense , it is still the industry standard, for timekeeping.
Anyway time of ntpd gone away (like most of old protocols) and one day this question pop up again. Why need to be so sticky to old protocol? Chrony able to keep old-fashioned ntpd clients well without any issues, Chrony already exist in FreeBSD 12 and 13...
How do you come to that conclusion : That "time of ntpd gone away" ?
It is my impression that: Before this thread you didn't even know Chrony existed .....If you can convince Netgate to or implement your self: A Chrony integration then by all means go do it. An additional pfSense Chrony package wouldn't hurt.
But don't "slaugther" the NTP package (implementation), just because you got an idea.
/Bingo
-
@bingo600 said in Chrony, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
@sergei_shablovsky said in Chrony, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
The main question is still “because of ntpd was outdated is replacement to Chrony in pfSense NTP service needed, or better to keep both ntpd and Chrony as additional pfSense package”.
NTP should not be removed from pfSense , it is still the industry standard, for timekeeping.
Anyway time of ntpd gone away (like most of old protocols) and one day this question pop up again. Why need to be so sticky to old protocol? Chrony able to keep old-fashioned ntpd clients well without any issues, Chrony already exist in FreeBSD 12 and 13...
How do you come to that conclusion : That "time of ntpd gone away" ?
It is my impression that: Before this thread you didn't even know Chrony existed .....I just try to make things better. (“better” means in technical term;)
I hands up on Your solution, because it’s better than only implementing NTS/NTPsec.
If you can convince Netgate to or implement your self: A Chrony integration then by all means go do it. An additional pfSense Chrony package wouldn't hurt.
But don't "slaugther" the NTP package (implementation), just because you got an idea.
;) Ok, let’s start with Chrony in addition to pfSense's ;)
-
@sergei_shablovsky said in Chrony, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
“because of ntpd was outdated
hmmmm,
This is a very tough and I think premature statement, the whole world cannot be so foolish as to trust its life to an outdated protocol, yes its life, because we depend on it at the moment
-not to mention the fact that this money-modulated world of ours is also run by this protocol in terms of money
we think it is not so important, but it is and it still works well in the background
Ok, I see that you registered at the end of 2019, ergo you can see that introducing a new thing to pfSense is not a "torch marching"
at the moment there are other more important things to be improved, which I think is a priority
https://redmine.pfsense.org/projects/pfsense/roadmapDon't get me wrong, we would love to see your work, if you take on this challenge, have here a couple of "well versed in the ways of time" colleague, you know :) and we could certainly help...
BTW:
There were some attempts that I was interested in at one time (ntpv3 vs. ntpv4), but I stayed with the multi-source (3-5) NTP
https://blog.cloudflare.com/roughtime/And for important workloads, as I mentioned above, PTP IEEE 1588-2002 / IEEE 1588-2008 for audio remains the target hardware Meinberg
-
@daddygo
What switches are you using to distribute your PTP, around on the site(s) ?
That's imho the biggest PTP Killer, that you's need all your switches to be PTP enabled.Especially if you already have an existing (working) switch infrastructure.
I for one doesn't have a single PTP enabled switch at home.
And would prob. not be paying extras for one.Then again if i needed any of my home devices to "Really" be in "sync" i would prob. just distribute my GPSDO (or PRS-10 Rubidium) 1-PPS around using balanced mode and RJ-45 cables. Not an optimal method in a large corp building.
/Bingo
-
@bingo600 said in Chrony, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
What switches are you using to distribute your PTP, around on the site(s) ?
Let's see.....
Enterprise level:
One that has worked for us for a long time (and since we also do video processing) is the Arista 7500 series family:
https://www.arista.com/assets/data/pdf/Whitepapers/ME-PTP-White-Paper.pdf
https://www.arista.com/assets/data/pdf/Datasheets/7500RDataSheet.pdf
My experience so far is that this cannot be done well and cost-effectively in a SOHO environment.
In our smaller studios we use the following devices, synchronized from an external clock source:
https://studio-tech.com/products/m5401a/
(with GPS module opc.)
+++ Cisco Catalyst 3800 series + 10G optic network (in-house facilities)
https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9300-series-switches/q-and-a-c67-744007.pdf@bingo600 "Especially if you already have an existing (working) switch infrastructure."
When we changed to DANTE AoIP and AES67 we changed the complete L1 - L2 infrastructure...
This is the only reasonable way to do it, as good PTP is the rule of thumb for real-time audio deliveryWe implemented this DANTE stuff almost 7 years ago, as the first radio network in Central Europe,
It has a lot of pitfalls, but once I get it right it's very convenient, I can route the sound exactly like TCP, hahahaha...Our mixing tables are also software based, no more FADER replacement because the mechanics components are tired
We represent America in Europe
https://www.arrakis-systems.com/arrakis---darc-virtual-console.html
(My company is the representative of Arrakis)
So here I encountered the concept of time in more depth, and here as well Hawking - The Time :)
