Re: NTP Sync Issue Across Tata (Europe)

[Masataka Ohta]

Forrest Christian (List Account) wrote:


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.


Instead, just rely on atomic clocks operated by you. They are not
so expensive (several thousand dollars) and should be accurate
enough without adjustment for hundreds of years. There can be no
coordinated attacks. They may be remotely accessed through
secured NTP.

Masataka Ohta

Re: Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)

[Job Snijders via NANOG]

Dear John, ARIN, NANOG,

On Mon, Aug 07, 2023 at 06:24:09PM +, John Curran wrote:
> We have made some fairly significant changes for those customers using
> ARIN Online for routing security administration – see attached message
> for specifics.

Yes, significant changes! I very much appreciate ARIN's efforts to
streamline IRR & RPKI operations for INR holders. :-)

I too think that having to enter "sorta similar" data in 2 places of
course is more prone to error (in terms of internal discrepancies
between the two inputs of data) compared to entering routing data in
just one place. I imagine the scheduled simplification of the user
interface (intertwining IRR & RPKI) will lead to improved data accuracy
and fewer operator errors. Thank you ARIN for that!

I think the industry's transition from plain-text IRR data towards
cryptographically verifiable RPKI data really starts happening when
there are automated processes coupling the two sets of data, and indeed
also retroactively glueing the two together (within ARIN's auspices the
'ARIN Online' environment).

A few questions arose in my mind while wondering about implementation
aspects on ARIN's side:

- is the IRR state directly derived from the RPKI state?

  An example for context: should some kind of unfortunate failure happen
  in ARIN's HSMs and thusly a new Manifest + CRL pair isn't signed and
  published before the 'nextUpdate' timestamp of the previous pair,
  would the associated IRR objects be deleted via NRTM? Or is the
  creation of ROAs and IRR route:/route6: objects discoupled in the
  sense that an operator creates an abstract object which then is
  transformed into both IRR and RPKI objects?

- What is the expected delay (if any) between creating a RPKI ROA and
  the associated IRR route/route6 objects appearing via NRTM?
  Is there online documentation outlining expectations, and is there
  internal monitoring on the delivery of the RPKI-to-IRR transformation
  service?

- The documentation states "If the creation of a ROA would result in
  more than 256 IRR Route Objects, no managed IRR Route Objects will be
  created." - but, why not? Would it not be advantageous to create at
  a minimum the 256 of the 'least-specific' objects? I wonder if the
  current approach violates the principle of least astonishment in the
  sense that an operator picking an unfortunate 'maxLength' value
  results in no IRR objects at all.

Kind regards,

Job

Re: NTP Sync Issue Across Tata (Europe)

[Forrest Christian (List Account)]

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  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) <
> 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  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  wrote:
>>
>> 
>>
>>
>> On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  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 

Changes to ARIN Online - Routing Security Dashboard - RPKI & IRR integration (was: Fwd: [arin-announce] New Features Added to ARIN Online)

[John Curran]

NANOGers -

We have made some fairly significant changes for those customers using ARIN 
Online for routing security administration – see attached message for specifics.

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN 
Subject: [arin-announce] New Features Added to ARIN Online
Date: August 7, 2023 at 1:37:51 PM EDT
To: 

ARIN is pleased to present the latest version of ARIN Online, including 
improvements, new features, and updates. Full release notes are included at the 
end of this message.

All ARIN systems have been restored and are now operating normally. We thank 
you for your patience. If you have additional questions, comments, or issues, 
please submit an Ask ARIN ticket using your ARIN Online account or contact the 
Registration Services Help Desk by phone Monday through Friday, 7:00 AM to 7:00 
PM ET at +1.703.227.0660.

Regards,

Mark Kosters
Chief Technology Officer
American Registry for Internet Numbers (ARIN)

Release Notes

- Navigation and eligibility status for ARIN’s routing security services, the 
Resource Public Key Infrastructure (RPKI), and Internet Routing Registry (IRR) 
have been condensed into a single Routing Security Dashboard in ARIN Online. We 
have also made the navigation of the IRR pages consistent with the RPKI 
portions of the website.
- Abuse, Network Operation Center (NOC), and DNS Points of Contact now have 
read-only viewing privileges for RPKI details in both ARIN Online and the 
RESTful API.
- Creating a new Route Origin Authorization (ROA) in ARIN Online now 
automatically creates and manages the matching IRR Route Objects based on the 
ROA prefix and max length configuration. If the creation of a ROA would result 
in more than 256 IRR Route Objects, no managed IRR Route Objects will be 
created. Managed IRR Route Objects may not be removed independently of their 
covering ROAs. Deleting a ROA in ARIN Online will automatically delete its 
corresponding managed IRR Route Objects. In the coming weeks, ARIN will create 
managed IRR Route Objects for all preexisting ROAs that do not currently have 
matching IRR Route Objects. Preexisting IRR Route Objects that match ROAs will 
be associated with the covering ROA.
- To create feature parity with templates, we have added the capability to 
modify reassignment information within ARIN Online without any changes to the 
registration date.
- Customers can begin the application process for the Qualified Facilitator 
Program in ARIN Online. ARIN Qualified Facilitators serve as resources for the 
community by assisting organizations seeking to acquire or transfer IPv4 or 
Autonomous System Number (ASN) resources.


___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: NTP Sync Issue Across Tata (Europe)

[Mel Beckman]

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) 
 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 
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 sync’d? GPS, I’ll wager.

I sense hand-waving :)

-mel via cell

On Aug 6, 2023, at 7:04 PM, Rubens Kuhl 
mailto:rube...@gmail.com>> wrote:




On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman 
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


--
- Forrest

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

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



Rubens



On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  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:
>
> [image: preview.png]
>
> ndss2021_1A-2_24302_paper
> 
> PDF Document · 1.7 MB
> 
>
> 
>
> Or simply use non-Internet NTP servers based on a Stratum-0 GPS source for
> mission-critical network timing.
>
> Until then, we may all wake up one morning and discover massive data
> breaches traced to an unfounded reliance on insecure public NTP servers.
> Then the game truly will be over, but not in our favor.
>
>  -mel
>
> On Aug 6, 2023, at 2:35 PM, Rubens Kuhl  wrote:
>
> Or one can select NTS-capable NTP servers, like those 5:
> a.st1.ntp.br
> b.st1.ntp.br
> c.st1.ntp.br
> d.st1.ntp.br
> gps.ntp.br
>
> Or any other NTP server that has NTS deployed. Game-over for NTP
> impersonation.
>
>
> Rubens
>
> On Sun, Aug 6, 2023 at 4:41 PM Mel Beckman  wrote:
>
>
> In a nutshell, no. Refer to my prior cites for detailed explanations. For
> a list of real-world attack incidents, see
>
>
> https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse#
>
>
>
> -mel
>
>
> On Aug 6, 2023, at 12:03 PM, Royce Williams 
> wrote:
>
>
> 
>
> Naively, instead of abstaining ;) ... isn't robust diversity of NTP
> peering a reasonable mitigation for this, as designed?
>
>
> Royce
>
>
> On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman  wrote:
>
>
> William,
>
>
> Due to flaws in the NTP protocol, a simple UDP filter is not enough. These
> flaws make it trivial to spoof NTP packets, and many firewalls have no
> specific protection against this. in one attack the malefactor simply fires
> a continuous stream of NTP packets with invalid time at your firewall. When
> your NTP client queries the spoofed server, the malicious packet is the one
> you likely receive.
>
>
> That’s just one attack vector. There are several others, and all have
> complex remediation. Why should people bother being exposed to the risk at
> all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve
> already described. Having suffered through such attacks more than once, I
> can say from personal experience that you don’t want to risk it.
>
>
>

Re: NTP Sync Issue Across Tata (Europe)

[Dorn Hetzel via NANOG]

Diversity from GPS might also be obtained by setting one receiver for GPS
and another for Galileo.  I think I'd skip GLONASS for now :)


On Mon, Aug 7, 2023, 06:09 Rubens Kuhl  wrote:

> > > 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.
> >
> > Well DNS can be cryptographically secured.  There really isn’t any good
> reasons to not sign your zones today.  The majority of responses from
> authoritative servers are validated today so if you sign the responses will
> be checked.  Unfortunately most to those validations still result in
> insecure instead of secure because people are not signing their zones.
>
> So does NTP, with NTS.
>
> https://datatracker.ietf.org/doc/html/rfc8915
>
>
> Rubens
>

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

> > 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.
>
> Well DNS can be cryptographically secured.  There really isn’t any good 
> reasons to not sign your zones today.  The majority of responses from 
> authoritative servers are validated today so if you sign the responses will 
> be checked.  Unfortunately most to those validations still result in insecure 
> instead of secure because people are not signing their zones.

So does NTP, with NTS.

https://datatracker.ietf.org/doc/html/rfc8915


Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

On Sun, Aug 6, 2023 at 11:36 PM Mel Beckman  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.

NTP has NTS, which all 5 servers I mentioned have, and many more also have.

> 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.

Nope, they are synced to the reference atomic clock of National
Observatory, pretty similar to USNO but local.

Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Giovane C. M. Moura via NANOG]

So the Anycast address our devices use internally to find the closest
 NTP server is geo-mapped to MU. 


So indeed, the pool will only send you a single NTP server in this case.
GeoDNS essentially map  you to mu.pool.ntp.org.

You can verify what NTP servers you can expect from the Pool by querying 
it directly (and thus bypassing GeoDNS mappings)


$ dig mu.pool.ntp.org


mu.pool.ntp.org.62  IN  A   197.224.66.40


However, the physical server is 
geo-mapped to the specific countries in Europe, e.g., GB, NL, FR, DE,


What really matters from GeoDNS is the IP address of your client -- the 
one that goes in the NTP query. So if you are using your anycast address 
to query, it does not matter what are the unicast addresses of your servers.



Unless the geo data ntp.org are using is inconsistent, I'd imagine
the servers should be mapped to a European pool, since the physical
address from which the server queries the pool is geo-mapped locally,
for this specific reason.


They also use the latest Maxmind mappings, and I confirmed it 
experimentally. ( I think it's fully automated their update method)


/giovane

Re: NTP Sync Issue Across Tata (Europe)

[Mark Tinka]

On 8/7/23 11:04, Giovane C. M. Moura via NANOG wrote:

TL;DR: I'd guess your NTP Server IP address is geolocated to 
Mauritius. The Mauritius zone[0] on the pool has only one server, so 
you'll only see this one. To fix it, use europe.pool.ntp.org (_do not_ 
use pool.ntp.org).


So the Anycast address our devices use internally to find the closest 
NTP server is geo-mapped to MU. However, the physical server is 
geo-mapped to the specific countries in Europe, e.g., GB, NL, FR, DE, e.t.c.


Unless the geo data ntp.org are using is inconsistent, I'd imagine the 
servers should be mapped to a European pool, since the physical address 
from which the server queries the pool is geo-mapped locally, for this 
specific reason.


Mark.

Re: NTP Sync Issue Across Tata (Europe)

[Giovane C. M. Moura via NANOG]

Hi Mark,



I have NTP servers in Europe that are choosing Tata (6453) to get to
 0.freebsd.pool.ntp.org which lives on 197.224.66.40:


NTP is not sync'ing to that address, and sessions stay in an Init
state.
TL;DR: I'd guess your NTP Server IP address is geolocated to Mauritius. 
The Mauritius zone[0] on the pool has only one server, so you'll only 
see this one. To fix it, use europe.pool.ntp.org (_do not_ use 
pool.ntp.org).



Longer answer:

NTP pool folks use GeoDNS[1], which is their DNS server to map clients 
to servers.


The `0.freebsd.pool.ntp.org` name is just an alias for them -- what they 
really do is this:


 * Get geolocation_data(client_IP_address): 
 * check country subzone in NTP pool (e.g, nl.pool.ntp.org [2]):
   * If there are >=1  servers in the zone, return (up to) 4 or them
   * If there is one, then return just one (this is a _known issue_)
   * if there is none, then fall back to the continent zone (Europe[3])

I've seen the same issue before with Guernsey clients (only one server). 
We have contact the pool operators and they are working now on a new 
GeoDNS version to prevent this from happening [4]


More details in [5].

In short, change your ntp configuration; the issue you have is that 
despite having 4k servers on the Pool, this strict GeoDNS mapping 
prevents you from accessing the other servers just bc of your IP 
address. The reasoning is to prevent asymmetric routing [4], but they 
are working on a fix to prevent these scenarios.



/giovane

[0] https://www.ntppool.org/zone/mu
[1] https://github.com/abh/geodns
[2] https://www.ntppool.org/zone/nl
[3] https://www.ntppool.org/zone/europe
[4] https://community.ntppool.org/t/minor-new-features-on-the-website/2947/8
[5] 
https://www.sidnlabs.nl/downloads/5aPx86UtFmvKs6WE3LHwbU/c6acce6a012fe07256bab8caefff54af/Diving_into_the_NTP_Pool.pdf

Re: NTP Sync Issue Across Tata (Europe)

[Forrest Christian (List Account)]

I  forgot to finish my thought in the third paragraph before hitting send.

What I was going to express was that one should choose not only close,
trusted, NTP servers, but also perhaps ones from different government
agencies, or different sources.   Sourcing time from multiple sources not
likely to be affected by the same outage and/or attack is good robust
design.

On Mon, Aug 7, 2023 at 2: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  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  wrote:
>>
>> 
>>
>>
>> On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  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
>


-- 
- Forrest

Re: NTP Sync Issue Across Tata (Europe)

[Mark Tinka]

On 8/5/23 21:26, Mel Beckman wrote:


Mark,

You might consider setting up your own GPS-based NTP network. Commercial 
Ethernet GPS-sourced NTP servers, such as the Time Machines, TM1000A, are as 
little as $400. Or you can roll your own using a Raspberry Pi or similar nano 
computer with a GPS module and antenna. We use these exclusively in data 
centers now rather than depending on Internet NTP servers, primarily for 
security, because financial transactions in e-commerce can be sensitive to 
false time information. There are also a variety of NTP-based Internet attacks, 
so if you can block NTP at your border you’ve eliminated another attack surface.


To be honest, we have decent resiliency across the network to weather 
issues such as these. While going the GPS route is not a bad idea, I 
have more pressing problems to fix right now.


All that said, the issue seems to have corrected itself re: the Tata 
path (even if it's still the same path).


Appreciate all the feedback and support. Thanks.

Mark.

Re: NTP Sync Issue Across Tata (Europe)

[Forrest Christian (List Account)]

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  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  wrote:
>
> 
>
>
> On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  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