" As such, the ultimate (a little expensive) solution is to have your own Rb clocks locally."
Yeah, that's a reasonable course of action for most networks. *sigh* ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Masataka Ohta" <[email protected]> To: [email protected] Sent: Friday, August 11, 2023 4:33:20 AM Subject: Re: NTP Sync Issue Across Tata (Europe) Forrest Christian (List Account) wrote: > The recommendation tends to be the following: > > 1) Run your GPS-derived NTP appliances, but DO NOT point end-user > clients at it. 2) Run a set of internal NTPd servers, and configure > them to pull time from all of your GPS-derived NTP servers, AND > trusted public NTP servers 3) Point your clients at the internal NTPd > servers. That is not a very good recommendation. See below. > At some point, using publicly available NTP sources is redundant > unless one wants to mitigate away the risks behind failure of the GPS > system itself. Your assumption that public NTP servers were not GPS-derived NTP servers is just wrong. > What I'm advocating against is the seemingly common practice to go > buy an off-the-shelf lower-cost GPS-NTP appliance (under $1K or so), > stick an antenna in a window or maybe on the rooftop, and point all > your devices at that device. Relying on a local expensive GPS appliance does not improve security so much and is the worst thing to do. But, additionally relying on remote servers (including those provided by NIST) is subject to DOS attacks. As such, the ultimate (a little expensive) solution is to have your own Rb clocks locally. Masataka Ohta
