<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<blockquote type="cite"><span style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">So, probably not a failure "caused by GPS", rather one caused by poor</span><br style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
<span style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">design (only two clock sources) combined with unsupported and buggy</span><br style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">
<span style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">devices.</span></blockquote>
<div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;"><br>
</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">Interesting software bug, but not really germane to this discussion, other than as a cautionary tale about time distribution architectures. </span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;"><br>
</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;"><br>
</span></font>
<div dir="ltr"> -mel beckman</div>
<div dir="ltr"><br>
<blockquote type="cite">On Aug 16, 2023, at 3:51 AM, Matthew Richardson <matthew-l@itconsult.co.uk> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"><span>Mel Beckman wrote:-</span><br>
<span></span><br>
<blockquote type="cite"><span>Do you have a citation for your Jersey event? I doubt GPS caused the problem, but I'd like to see the documentation.</span><br>
</blockquote>
<span></span><br>
<span>The event took place on the evening of Sunday 12 July 2020, and seems NOT</span><br>
<span>to have been due to an issue caused directly by GPS, but rather to</span><br>
<span>misbehaviour of a GPS NTP server relating to week numbers. Our regulator</span><br>
<span>subsequently issued the following comprehensive document:-</span><br>
<span></span><br>
<span>https://www.jcra.je/media/598397/t-027-jt-july-2020-outage-decision-directions.pdf</span><br>
<span></span><br>
<span>By way of summary, JT operated two GPS derived NTP servers, with all of</span><br>
<span>their routers were pointing to both. On the evening in question, one of</span><br>
<span>the two reset its clock back to 27 November 2000.</span><br>
<span></span><br>
<span>Their interior routing protocol used amongst their mesh of routers was</span><br>
<span>IS-IS which was using authentication. The authentication [section 4.19]</span><br>
<span>was described having a "password validity start date" of 01 July 2012.</span><br>
<span>Thus, any routers which had picked up the time from the faulty source no</span><br>
<span>longer had valid IS-IS authentication and were thus isolated.</span><br>
<span></span><br>
<span>Whilst only 15% of their routers were affected, this was enough to cause an</span><br>
<span>almost total failure in their network, affecting telephony (fixed & mobile)</span><br>
<span>and Internet. For foreign readers (this is NANOG!) "999" calls refer to</span><br>
<span>the emergency services in these parts, where any failures attract the</span><br>
<span>attention of our regulator.</span><br>
<span></span><br>
<span>The details of why the clock "failed" start at section 4.23, and seem to</span><br>
<span>relate a GPS week number rollover.</span><br>
<span></span><br>
<span>So, probably not a failure "caused by GPS", rather one caused by poor</span><br>
<span>design (only two clock sources) combined with unsupported and buggy</span><br>
<span>devices.</span><br>
<span></span><br>
<span>One curious aspect is that some routers followed the "bad" time, which is</span><br>
<span>alluded to in section 4.31.</span><br>
<span></span><br>
<span>Something not discussed in that report is that JT's email failed during the</span><br>
<span>incident despite its being hosted on Office365. The reason was that the</span><br>
<span>two authoritative DNS servers for jtglobal.com were hosted in Jersey inside</span><br>
<span>their network. As that network was wholly disconnected, there was no DNS</span><br>
<span>and hence no email. Despite my having raised this since with their senior</span><br>
<span>management, their DNS remains hosted in this way:-</span><br>
<span></span><br>
<blockquote type="cite"><span>matthew@m88:~$ dig +norec +noedns +nocmd +nostats -t ns jtglobal.com @ns1.jtibs.net</span><br>
</blockquote>
<blockquote type="cite"><span>;; Got answer:</span><br>
</blockquote>
<blockquote type="cite"><span>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20462</span><br>
</blockquote>
<blockquote type="cite"><span>;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 4</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; QUESTION SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>;jtglobal.com. IN NS</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; ANSWER SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>jtglobal.com. 60 IN NS ns2.jtibs.net.</span><br>
</blockquote>
<blockquote type="cite"><span>jtglobal.com. 60 IN NS ns1.jtibs.net.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; ADDITIONAL SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>ns1.jtibs.net. 60 IN A 212.9.0.135</span><br>
</blockquote>
<blockquote type="cite"><span>ns2.jtibs.net. 60 IN A 212.9.0.136</span><br>
</blockquote>
<blockquote type="cite"><span>ns1.jtibs.net. 60 IN AAAA 2a02:c28::d1</span><br>
</blockquote>
<blockquote type="cite"><span>ns2.jtibs.net. 60 IN AAAA 2a02:c28::d2</span><br>
</blockquote>
<span></span><br>
<span>Rediculously (and again despite my agitation to their management) our</span><br>
<span>government domain gov.je has similar DNS fragility:-</span><br>
<span></span><br>
<blockquote type="cite"><span>matthew@m88:~$ dig +norec +noedns +nocmd +nostats -t ns gov.je @ns1.gov.je</span><br>
</blockquote>
<blockquote type="cite"><span>;; Got answer:</span><br>
</blockquote>
<blockquote type="cite"><span>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4249</span><br>
</blockquote>
<blockquote type="cite"><span>;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; QUESTION SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>;gov.je. IN NS</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; ANSWER SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>gov.je. 3600 IN NS ns2.gov.je.</span><br>
</blockquote>
<blockquote type="cite"><span>gov.je. 3600 IN NS ns1.gov.je.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>;; ADDITIONAL SECTION:</span><br>
</blockquote>
<blockquote type="cite"><span>ns2.gov.je. 3600 IN A 212.9.21.137</span><br>
</blockquote>
<blockquote type="cite"><span>ns1.gov.je. 3600 IN A 212.9.21.9</span><br>
</blockquote>
<span></span><br>
<span>--</span><br>
<span>Best wishes,</span><br>
<span>Matthew</span><br>
<span></span><br>
<span>------</span><br>
<blockquote type="cite"><span>From: Mel Beckman <mel@beckman.org></span><br>
</blockquote>
<blockquote type="cite"><span>To: Matthew Richardson <matthew-l@itconsult.co.uk></span><br>
</blockquote>
<blockquote type="cite"><span>Cc: Nanog <nanog@nanog.org></span><br>
</blockquote>
<blockquote type="cite"><span>Date: Tue, 8 Aug 2023 15:12:29 +0000</span><br>
</blockquote>
<blockquote type="cite"><span>Subject: Re: NTP Sync Issue Across Tata (Europe)</span><br>
</blockquote>
<span></span><br>
<blockquote type="cite"><span>Until the Internet NTP network can be made secure, no. Do you have a citation for your Jersey event? I doubt GPS caused the problem, but I'd like to see the documentation.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Using GPS for time sync is simple risk management: the risk of Internet NTP with known, well documented vulnerabilities and many security incidents, versus the risk of some theoretical GPS-based vulnerability, for which mitigations
such as geographic diversity are readily available. Sure, you could use Internet NTP as a last resort should GPS fail globally (perhaps due to a theoretical - but conceivable - meteor storm). But that would be a fall-back. I would not mix the systems.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>-mel</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>On Aug 8, 2023, at 1:36 AM, Matthew Richardson <matthew-l@itconsult.co.uk> wrote:</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>?Mel Beckman wrote:-</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>It's a problem that has received a lot of attention in both NTP and</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>aviation navigation circles. What is hard to defend against is total signal</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>suppression via high powered jamming. But that you can do with a</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>geographically diverse GPS NTP network.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Whilst looking forward to being corrected, GPS (even across multiple</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>locations) seems to be a SINGLE source of time. You seem (have I</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>misunderstood?) to be a proponent of using GPS exclusively as the external</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>clock source.</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Might it be preferable to have a mixture of GPS (perhaps with another GNSS)</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>together with carefully selected Internet-based NTP servers?</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>I recall an incident over here in Jersey (the one they named New Jersey</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>after!) where our primary telco had a substantial time shift on one of</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>their two GPS synced servers. This managed to adjust the clock on enough</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>of their routers that the certificate-based OSPF authentication considered</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>the certificates invalid, and caused a failure of almost their whole</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>network.</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>This is, of course, not to say that GPS is not a very good clock source,</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>but rather to wonder whether more diversity would be preferable than using</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>it as a single source.</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>--</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Best wishes,</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Matthew</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>------</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>From: Mel Beckman <mel@beckman.org></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>To: "Forrest Christian (List Account)" <lists@packetflux.com></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Cc: Nanog <nanog@nanog.org></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Date: Mon, 7 Aug 2023 14:03:30 +0000</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Subject: Re: NTP Sync Issue Across Tata (Europe)</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Forrest,</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>-mel</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>On Aug 7, 2023, at 1:39 AM, Forrest Christian (List Account) <lists@packetflux.com> wrote:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>?</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>The problem with relying exclusively on GPS to do time distribution is the ease with which one can spoof the GPS signals.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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 .</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>On Sun, Aug 6, 2023 at 8:36?PM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>DNS has DNSSec, which while not deployed as broadly as we might like, at least lets us know which servers we can trust.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>I sense hand-waving :)</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>-mel via cell</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>On Aug 6, 2023, at 7:04 PM, Rubens Kuhl <rubensk@gmail.com<mailto:rubensk@gmail.com>> wrote:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>?</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>On Sun, Aug 6, 2023 at 8:20?PM Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>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).</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Rubens</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<span></span><br>
</div>
</blockquote>
</div>
</body>
</html>