Re: NTP Sync Issue Across Tata (Europe)

["Forrest Christian (List Account)" <lists () packetflux com>]

Those particular boxes are not cheap.   (Yes I know the units you talk
about).  Note that some of them rely on terrestrial communication of
ephermis data to validate the GPS data to further make the time more
robust.

I was hopefully trying to dispel the seemingly common thread in this
discussion that somehow a $400 GPS derived ntp clock is more robust than
using the public NTP infrastructure.  Without understanding that GPS
receivers are also subject to similar attacks as NTP, one comes to the
wrong conclusion about how to build a robust timing infrastructure.   GPS
is subject to DoS and spoofing attacks just like NTP, and as such, it's
important to mitigate those as well if you care about time stability.

In the end, it's all about risk vs cost to mitigate risk.    If you're
running a tiny network, deriving your time from the public NTP servers is
fine.

 At the other end of the scale is using exotic hardened solutions which
derive their own clock source and can hold over time for days or weeks in
the event of a failure or attack.

In the middle tends to be a more moderate solution which involves a mix of
time transmission methods from a variety of geographically and/or network
diverse sources.  Taking time from the public trusted ntp servers and
adding lower cost GPS receivers at diverse points in your network seems
like a good compromise in the middle.  That way,  only coordinated attacks
will be successful.


On Mon, Aug 7, 2023, 8:03 AM Mel Beckman <mel () beckman org> wrote:

> 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. It’s 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) <
> lists () 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 <mel () 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 sync’d? GPS, I’ll wager.
> >
> > I sense hand-waving :)
> >
> > -mel via cell
> >
> > On Aug 6, 2023, at 7:04 PM, Rubens Kuhl <rubensk () gmail com> wrote:
> >
> > 
> >
> >
> > On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman <mel () 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
>
> --
> - Forrest