Re: NTP Sync Issue Across Tata (Europe)

[Mike Hammett <nanog () ics-il net>]

" 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" <mohta () necom830 hpcl titech ac jp> 
To: nanog () nanog org 
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