Mel Beckman wrote:- >Its a problem that has received a lot of attention in both NTP and >aviation navigation circles. What is hard to defend against is total signal >suppression via high powered jamming. But that you can do with a >geographically diverse GPS NTP network.
Whilst looking forward to being corrected, GPS (even across multiple locations) seems to be a SINGLE source of time. You seem (have I misunderstood?) to be a proponent of using GPS exclusively as the external clock source. Might it be preferable to have a mixture of GPS (perhaps with another GNSS) together with carefully selected Internet-based NTP servers? I recall an incident over here in Jersey (the one they named New Jersey after!) where our primary telco had a substantial time shift on one of their two GPS synced servers. This managed to adjust the clock on enough of their routers that the certificate-based OSPF authentication considered the certificates invalid, and caused a failure of almost their whole network. This is, of course, not to say that GPS is not a very good clock source, but rather to wonder whether more diversity would be preferable than using it as a single source. -- Best wishes, Matthew ------ >From: Mel Beckman <m...@beckman.org> >To: "Forrest Christian (List Account)" <li...@packetflux.com> >Cc: Nanog <nanog@nanog.org> >Date: Mon, 7 Aug 2023 14:03:30 +0000 >Subject: Re: NTP Sync Issue Across Tata (Europe) >Forrest, > >GPS spoofing may work with a primitive Raspberry Pi-based NTP server, but >commercial industrial NTP servers have specific anti-spoofing mitigations. >There are also antenna diversity strategies that vendors support to ensure the >signal being relied upon is coming from the right direction. Its a problem >that has received a lot of attention in both NTP and aviation navigation >circles. What is hard to defend against is total signal suppression via high >powered jamming. But that you can do with a geographically diverse GPS NTP >network. > > -mel > >On Aug 7, 2023, at 1:39 AM, Forrest Christian (List Account) ><li...@packetflux.com> wrote: > >? >The problem with relying exclusively on GPS to do time distribution is the >ease with which one can spoof the GPS signals. > >With a budget of around $1K, not including a laptop, anyone with decent >technical skills could convince a typical GPS receiver it was at any position >and was at any time in the world. All it takes is a decent directional >antenna, some SDR hardware, and depending on the location and directivity of >your antenna maybe a smallish amplifier. There is much discussion right now >in the PNT (Position, Navigation and Timing) community as to how best to >secure the GNSS network, but right now one should consider the data from GPS >to be no more trustworthy than some random NTP server on the internet. > >In order to build a resilient NTP server infrastructure you need multiple >sources of time distributed by multiple methods - typically both via satellite >(GPS) and by terrestrial (NTP) methods. NTP does a pretty good job of >sorting out multiple time servers and discarding sources that are lying. But >to do this you need multiple time sources. A common recommendation is to run >a couple/few NTP servers which only get time from a GPS receiver and only >serve time to a second tier of servers that pull from both those in-house >GPS-timed-NTP servers and other trusted NTP servers. I'd recommend selecting >the time servers to gain geographic diversity, i.e. poll NIST servers in >Maryland and Colorado, and possibly both. > >Note that NIST will exchange (via mail) a set of keys with you to talk >encrypted NTP with you. See >https://www.nist.gov/pml/time-and-frequency-division/time-services/nist-authenticated-ntp-service > . > > > >On Sun, Aug 6, 2023 at 8:36?PM Mel Beckman ><m...@beckman.org<mailto:m...@beckman.org>> wrote: >GPS Selective Availability did not disrupt the timing chain of GPS, only the >ephemeris (position information). But a government-disrupted timebase >scenario has never occurred, while hackers are a documented threat. > >DNS has DNSSec, which while not deployed as broadly as we might like, at least >lets us know which servers we can trust. > >Your own atomic clocks still have to be synced to a common standard to be >useful. To what are they syncd? GPS, Ill wager. > >I sense hand-waving :) > >-mel via cell > >On Aug 6, 2023, at 7:04 PM, Rubens Kuhl ><rube...@gmail.com<mailto:rube...@gmail.com>> wrote: > >? > > >On Sun, Aug 6, 2023 at 8:20?PM Mel Beckman ><m...@beckman.org<mailto:m...@beckman.org>> wrote: >Or one can read recent research papers that thoroughly document the incredible >fragility of the existing NTP hierarchy and soberly consider their >recommendations for remediation: > >The paper suggests the compromise of critical infrastructure. So, besides not >using NTP, why not stop using DNS ? Just populate a hosts file with all you >need. > >BTW, the stratum-0 source you suggested is known to have been manipulated in >the past (https://www.gps.gov/systems/gps/modernization/sa/), so you need to >bet on that specific state actor not returning to old habits. > >OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you can >keep using GPS as well. If GPS goes bananas on timing, that source will just >be disregarded (one of the features of the NTP architecture that has been >pointed out over and over in this thread and you keep ignoring it). > >Rubens
