Re: NTP Sync Issue Across Tata (Europe)

: 4249 > > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > > > ;; QUESTION SECTION: > > ;gov.je. IN NS > > > ;; ANSWER SECTION: > > gov.je.3600INNSns2.gov.je. > > gov.je.3600IN

Re: NTP Sync Issue Across Tata (Europe)

Best wishes, Matthew -- From: Mel Beckman To: Matthew Richardson Cc: Nanog Date: Tue, 8 Aug 2023 15:12:29 + Subject: Re: NTP Sync Issue Across Tata (Europe) Until the Internet NTP network can be made secure, no. Do you have a citation for your Jersey event? I doubt GPS caused the

Re: NTP Sync Issue Across Tata (Europe)

IN NS > > > >;; ANSWER SECTION: > >gov.je. 3600 IN NS ns2.gov.je. > >gov.je.3600IN NS ns1.gov.je. > > > >;; ADDITIONAL SECTION: > >ns2.gov.je.

Re: NTP Sync Issue Across Tata (Europe)

3600INNSns1.gov.je. ;; ADDITIONAL SECTION: ns2.gov.je.3600INA212.9.21.137 ns1.gov.je.3600INA212.9.21.9 -- Best wishes, Matthew -- From: Mel Beckman To: Matthew Richardson Cc: Nanog Date: Tue, 8 Aug 2023 15:12:29 + Subject: Re: NTP Sy

Re: NTP Sync Issue Across Tata (Europe)

Throw  PTP in the mix for the greater accuracy required for some wireless (5G) configurations, and the situation becomes even more complicated.On Aug 14, 2023, at 6:55 AM, Forrest Christian (List Account) wrote:We're going to have to somewhat disagree here...I may not have been 100% clear about

Re: NTP Sync Issue Across Tata (Europe)

NS ns1.gov.je. > >;; ADDITIONAL SECTION: >ns2.gov.je.3600IN A 212.9.21.137 >ns1.gov.je. 3600IN A 212.9.21.9 -- Best wishes, Matthew -- >From: Mel Beckman >To: Matthew Richardson >Cc: Nanog >Date: Tue, 8 Au

Re: NTP Sync Issue Across Tata (Europe)

Forrest Christian (List Account) wrote: There are lots of ways to improve a GPS-based NTP server. Better antenna positioning. Better GPS chipset. Paying attention to antenna patterns. Adding notch filters to the GPS feed. And so on. They are not a very meaningful improvement. But, in

Re: NTP Sync Issue Across Tata (Europe)

ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Forrest Christian (List Account)" To: "nanog list" Sent: Monday, August 14, 2023 2:07:14 AM Subject: Re: NTP Sync Issue Across Tata (Europe) I've responded in bits and pieces to this thread

Re: NTP Sync Issue Across Tata (Europe)

> On Aug 14, 2023, at 3:07 AM, Forrest Christian (List Account) > wrote: > > I've responded in bits and pieces to this thread and haven't done an > excellent job expressing my overall opinion. This is probably because my > initial goal was to point out that GPS-transmitted time is no less

Re: NTP Sync Issue Across Tata (Europe)

Replying to two posts at once... One can definitely get inexpensive and high-quality rubidiums for dirt cheap on the second-hand market. I've specifically ignored those when discussing price as options as one can never be sure about their accuracy or long-term reliability, and I try to filter

Re: NTP Sync Issue Across Tata (Europe)

We're going to have to somewhat disagree here... I may not have been 100% clear about what I see as the most common risks for GPS. The reason I suggest that NTP risks and GPS risks are similar is not primarily due to intentional time injection hacks (although that is a risk). Instead, it's

Re: NTP Sync Issue Across Tata (Europe)

On Mon, 14 Aug 2023, Masataka Ohta wrote: Mike Hammett wrote: " 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. For most data centers with time sensitive transactions, at

Re: NTP Sync Issue Across Tata (Europe)

Forrest, I think you’re gilding the lilly. My original recommendation was to use GPS as primary, for its superior accuracy and resistance to attack, and have anti-GPS back up. If you want automatic fail over, do that in an intermediate server on your site that makes a conscious test and

Re: NTP Sync Issue Across Tata (Europe)

Mike Hammett wrote: " 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. For most data centers with time sensitive transactions, at least. *sigh*

Re: NTP Sync Issue Across Tata (Europe)

I've responded in bits and pieces to this thread and haven't done an excellent job expressing my overall opinion. This is probably because my initial goal was to point out that GPS-transmitted time is no less subject to being attacked than your garden variety NTP-transmitted time. Since this

Re: NTP Sync Issue Across Tata (Europe)

est-ix.com - Original Message - From: "Masataka Ohta" 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 yo

Re: NTP Sync Issue Across Tata (Europe)

Gotcha. The Bad Guys are smarter than me. :-) Cheers, -- jra - Original Message - > From: "Forrest Christian (List Account)" > To: "jra" > Cc: "nanog list" > Sent: Sunday, August 13, 2023 8:06:30 PM > Subject: Re: NTP Sync Issue Acro

Re: NTP Sync Issue Across Tata (Europe)

If I'm spoofing time, I'm going to produce an entire constellation of satellites. That is, I'm going to provide a signal which looks like all of the satellites in view providing their timing signals on whatever time I want your GPS receiver to think it is. All I have to do is ensure that your

Re: NTP Sync Issue Across Tata (Europe)

- Original Message - > From: "Forrest Christian (List Account)" > Let me address your points: [ ... ] > Let's assume you have a typical GPS-derived NTP server using a typical > commercially available timing GNSS module. To convince that receiver that > it was a different time, I'd need

Re: NTP Sync Issue Across Tata (Europe)

- Original Message - > From: "John Gilmore" > Am I confused? Getting the time over a multi-gigabit Internet from a > national time standard agency such as NIST (or your local country's > equivalent) should produce far better accuracy and stability than > relying on locally received GPS

Re: NTP Sync Issue Across Tata (Europe)

John Gilmore wrote: Subsequent conversation has shown that you are both right here. Yes, many public NTP servers ARE using GPS-derived time. Yes, some public NTP servers ARE NOT using GPS-derived time. The point is whether : 2) Run a set of internal NTPd servers, and configure them to pull

Re: NTP Sync Issue Across Tata (Europe)

Forrest Christian (List Account) wrote: > > > 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. On Fri, Aug 11, 2023, 3:33 AM Masataka Ohta wrote: > > Your assumption that public NTP

Re: NTP Sync Issue Across Tata (Europe)

Forrest Christian (List Account) wrote: The NIST time servers do NOT get their time from GPS. No, of course. I know it very well. However, as I wrote: > But, additionally relying on remote servers (including those > provided by NIST) is subject to DOS attacks. the (mostly wired) Internet

Re: NTP Sync Issue Across Tata (Europe)

The NIST time servers do NOT get their time from GPS. NIST, like several government standards agencies and other research labs around the globe, run an ensemble of high precision atomic clocks. In the case of NIST, they use the ensemble to produce the timescale UTC(NIST) at their Boulder,

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

globally. > >-mel > -- > *From:* NANOG on behalf of Jay > Hennigan > *Sent:* Wednesday, August 9, 2023 10:58 AM > *To:* nanog@nanog.org > *Subject:* Re: NTP Sync Issue Across Tata (Europe) > > On 8/9/23 09:29, Seth Mattinen via NANOG wrote:

Re: NTP Sync Issue Across Tata (Europe)

Seth, My point exactly. Use GPS as primary, and have anti-PS back up, and if you want automatic fail over, do that in an intermediate server on your site that makes a conscious test and decision to fail over to regular NTP -mel via cell > On Aug 9, 2023, at 5:01 PM, Seth Mattinen via NANOG

Re: NTP Sync Issue Across Tata (Europe)

On 8/9/23 3:25 PM, Forrest Christian (List Account) wrote: Note that NIST operates a pool of 24 time servers for public use.  These are spread across four different locations in two different states.  My understanding is that they all get their time directly from the official NIST clocks

Re: NTP Sync Issue Across Tata (Europe)

Note that NIST operates a pool of 24 time servers for public use. These are spread across four different locations in two different states. My understanding is that they all get their time directly from the official NIST clocks without GPS or NTP being involved. You can also request a

Re: NTP Sync Issue Across Tata (Europe)

speak, lying in wait until an opportunity to disrupt Internet NTP globally. -mel From: NANOG on behalf of Jay Hennigan Sent: Wednesday, August 9, 2023 10:58 AM To: nanog@nanog.org Subject: Re: NTP Sync Issue Across Tata (Europe) On 8/9/23 09:29, Seth Mattinen

Re: NTP Sync Issue Across Tata (Europe)

Once upon a time, Jay Hennigan said: > Both GPS and WWVB are over-the-air. There has been concern expressed > of a bad actor spoofing or jamming GPS. Comparatively speaking, > jamming or spoofing WWVB is a trivial joke. WWVB is not generally useful for precision timing applications, due to the

Re: NTP Sync Issue Across Tata (Europe)

On 8/9/23 09:29, Seth Mattinen via NANOG wrote: I liked having a WWVB receiver in my mix, but all the hardware appliances (at least those offering OCXO or Rubidium oscillator options) seem to have rejected it in favor of GPS only. I can only conclude that either vendors think options like

Re: NTP Sync Issue Across Tata (Europe)

On 8/9/23 2:39 AM, Forrest Christian (List Account) wrote: When GPS is working, time transmission with accuracies of under 1 microsecond is common.   This is especially true if the GPS integrates some sort of disciplined oscillator.  Note that this is in excess of what NTPd running on a

Re: NTP Sync Issue Across Tata (Europe)

John Gilmore wrote: I was also speaking specifically about installing GPS antennas in viable places, not using a facility-provided GPS or NTP service. Am I confused? Getting the time over a multi-gigabit Internet from a national time standard agency such as NIST (or your local

Re: NTP Sync Issue Across Tata (Europe)

When GPS is working, time transmission with accuracies of under 1 microsecond is common. This is especially true if the GPS integrates some sort of disciplined oscillator. Note that this is in excess of what NTPd running on a typical OS can reliably retransmit. BUT.. if I was to choose only

Re: NTP Sync Issue Across Tata (Europe)

an Cc: nanog@nanog.org Subject: Re: NTP Sync Issue Across Tata (Europe) > I was also speaking specifically about installing GPS antennas in > viable places, not using a facility-provided GPS or NTP service. Am I confused? Getting the time over a multi-gigabit Internet from a n

Re: NTP Sync Issue Across Tata (Europe)

> I was also speaking specifically about installing GPS antennas in > viable places, not using a facility-provided GPS or NTP service. Am I confused? Getting the time over a multi-gigabit Internet from a national time standard agency such as NIST (or your local country's equivalent)

Re: NTP Sync Issue Across Tata (Europe)

Go for it. I’m sure NTS’ complexity clocks lots of hours for expensive consultants :) Me, I’m sticking with GPS.) -mel via cell On Aug 8, 2023, at 11:34 AM, Rubens Kuhl wrote:  So little deployment that has 3500 occurrences according to shodan.io. With such few choices,

Re: NTP Sync Issue Across Tata (Europe)

t; Cc: nanog@nanog.org, "Mark Tinka" Sent: Tuesday, August 8, 2023 10:36:46 AM Subject: Re: NTP Sync Issue Across Tata (Europe) I’d be interested in an example of a Colo that does NOT provide GPS-based NTP even if they don’t let tenants install their own. I’ve never, ever seen one. -

Re: NTP Sync Issue Across Tata (Europe)

So little deployment that has 3500 occurrences according to shodan.io. With such few choices, It should be hard to find suitable options. Rubens Em ter., 8 de ago. de 2023 13:02, Mel Beckman escreveu: > I’m familiar with NTS, which is pointedly not NTP. That’s like saying > “TCP port 80

Re: NTP Sync Issue Across Tata (Europe)

Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Mel Beckman" To: "Mike Hammett" Cc: nanog@nanog.org, "Mark Tinka" Sent: Tuesday, August 8, 2023 10:36:46 AM Subject: Re: NTP Sync Issue Across Tata (Europe) I

Re: NTP Sync Issue Across Tata (Europe)

I’m familiar with NTS, which is pointedly not NTP. That’s like saying “TCP port 80 can be made secure,: just use a VPN!” Perhaps when NTS is widely deployed it will be an option. As the RFC was only approved in 2020, that will probably take a decade. Or more. (I’m talking about you, IPv6 :)

Re: NTP Sync Issue Across Tata (Europe)

icon.png]<https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> From: "Mel Beckman" To: "Mike Hammett" Cc: nanog@nanog.org, "Mark Tinka" Sent: Tuesday, August 8, 2023 10:05:55 AM Subject: Re: NTP Sync Issue Across Tata (Europe)

Re: NTP Sync Issue Across Tata (Europe)

On Tue, Aug 8, 2023 at 12:12 PM Mel Beckman wrote: > > Until the Internet NTP network can be made secure, no. Internet NTP can be made secure, it's called NTS. https://developers.cloudflare.com/time-services/nts/ describes it with links to the RFC, and describes one of the many NTP servers that

Re: NTP Sync Issue Across Tata (Europe)

Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Mel Beckman" To: "Mike Hammett" Cc: nanog@nanog.org, "Mark Tinka" Sent: Tuesday, August 8, 2023 10:05:55 AM Subject: Re: NTP Sync Issue A

Re: NTP Sync Issue Across Tata (Europe)

; Matthew > > -- >> From: Mel Beckman >> To: "Forrest Christian (List Account)" >> Cc: Nanog >> Date: Mon, 7 Aug 2023 14:03:30 + >> Subject: Re: NTP Sync Issue Across Tata (Europe) > >> Forrest, >> >> GPS spoofing m

Re: NTP Sync Issue Across Tata (Europe)

From: "Mel Beckman" To: "Mark Tinka" Cc: nanog@nanog.org Sent: Saturday, August 5, 2023 2:26:37 PM Subject: Re: NTP Sync Issue Across Tata (Europe) Mark, You might consider setting up your own GPS-based NTP network. Commercial Ethernet GPS-sourced NTP servers, suc

Re: NTP Sync Issue Across Tata (Europe)

t; Cc: nanog@nanog.org Sent: Saturday, August 5, 2023 2:26:37 PM Subject: Re: NTP Sync Issue Across Tata (Europe) 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.

Re: NTP Sync Issue Across Tata (Europe)

Best wishes, Matthew -- >From: Mel Beckman >To: "Forrest Christian (List Account)" >Cc: Nanog >Date: Mon, 7 Aug 2023 14:03:30 + >Subject: Re: NTP Sync Issue Across Tata (Europe) >Forrest, > >GPS spoofing may work with a primitive Raspberry Pi-based NTP s

Re: NTP Sync Issue Across Tata (Europe)

Forrest Christian (List Account) wrote: Depends on how synchronized you need to be. Sure. But, we should be assuming NTP is mostly enough. A rubidium oscillator or Chip Scale Atomic Clock is in the price range you quote. However, these can drift enough that you should occasionally

Re: NTP Sync Issue Across Tata (Europe)

Mel Beckman wrote: > To be useful, any atomic clocks you operate must be synchronized > to a Stratum Zero time source, such as GPS. Only initially. Precise time is crucial to a variety of economic activities around the world. Communication systems, electrical power grids, and financial

Re: NTP Sync Issue Across Tata (Europe)

Depends on how synchronized you need to be. In the context of running airgapped: A rubidium oscillator or Chip Scale Atomic Clock is in the price range you quote. However, these can drift enough that you should occasionally synchronize with a reference time source. This is to ensure continued

Re: NTP Sync Issue Across Tata (Europe)

Masataka, To be useful, any atomic clocks you operate must be synchronized to a Stratum Zero time source, such as GPS. Such clocks are useful when you need exceptional accuracy, such as for Building Integrated Timing Service (BITS), but unless they’re synchronized you can’t coordinate

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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,

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

> On 7 Aug 2023, at 12:02, 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:

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

Bill, You’re mistaking targeted NTP attacks with global ones. Yes, to attack your specific NTP client, the attacker has to know which NTP servers you’re using. But to simply succeed at random attacks, the attacker need only spoof popular servers. This is how time-shifting attacks work. Once an

Fwd: NTP Sync Issue Across Tata (Europe)

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: https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf Or simply use non-Internet NTP

Re: NTP Sync Issue Across Tata (Europe)

On Sun, Aug 6, 2023 at 1:19 PM Royce Williams wrote: > Wouldn't a robust implementation of peering - say, seven peers, with the NTP > algorithm handily selecting a subset to peer with for each cycle - require an > attacker to know and overwhelm not just one, but a majority of the peer IPs? Hi

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

This entirely discounts the fact that bcp-38 and bcp-84 which, more or less, eliminate this "problem space" entirely. I find it hard to believe ntp reflection is actually a problem in the year 2023, assuming you're not running a ridiculously old ntp client and have taken really simple steps to

Re: NTP Sync Issue Across Tata (Europe)

Respectfully, that Wikipedia article (which is mostly about legit but unauthorized clients overwhelming a given peer) and your cites don't seem to cover what I was responding to - the "don't peer with public NTP because someone can flood your firewall and spoof the responses" problem. I just want

Re: NTP Sync Issue Across Tata (Europe)

In a nutshell, no. Refer to my prior cites for detailed explanations. For a list of real-world attack incidents, see

Re: NTP Sync Issue Across Tata (Europe)

A carefully selected set of stratum 0 sources for a set of stratum 1 servers is the heart of good NTP source design. With at least four “local” stratum 1 servers, Dr. Mills algorithm is excellent at distinguishing truechimers from falsetickers and providing a reliable source of monotonic time.

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

On Sat, Aug 5, 2023 at 7:24 PM Mel Beckman wrote: > That still leaves you open to NTP attacks. The USNO accuracy and monitoring > is worthless if you suffer, for example, an NTP DDoS attack. Hi Mel, >From what I can tell, a fairly simple firewall policy of allow UDP 123 from known NTP clients

Re: NTP Sync Issue Across Tata (Europe)

Niels, You’re the first person to mention neutral collocation facilities as a requirement. The OP only talked about servers generally. Obviously, building your own GPS-based NTP network requires you have visibility to the sky. However, that need not be rooftop access. We routinely locate GPS

Re: NTP Sync Issue Across Tata (Europe)

* m...@beckman.org (Mel Beckman) [Sun 06 Aug 2023, 04:26 CEST]: if you can eliminate such security problems for $400, I say it’s cheap at twice the price. You must be unfamiliar with the prices neutral colocation facilities charge for roof access. -- Niels.

Re: NTP Sync Issue Across Tata (Europe)

Bill, That still leaves you open to NTP attacks. The USNO accuracy and monitoring is worthless if you suffer, for example, an NTP DDoS attack. [ddos-lc.png] NTP amplification DDoS

Re: NTP Sync Issue Across Tata (Europe)

On Sat, Aug 5, 2023 at 12:26 PM Mel Beckman wrote: > You might consider setting up your own GPS-based NTP network. GPS time is monitored (and when necessary, adjusted) from the U.S. Naval Observatory Master Clock, which is -the- authoritative time source for the United States. The USNO also

Re: NTP Sync Issue Across Tata (Europe)

If the path has simmetric one way latencies you don't have to pick a lower latency faulty one. Perhaps creating a selection at startup and then using that collection ? Rubens Em sáb., 5 de ago. de 2023 12:42, Mark Tinka escreveu: > Hi all. > > I have NTP servers in Europe that are choosing

Re: NTP Sync Issue Across Tata (Europe)

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

Re: NTP Sync Issue Across Tata (Europe)

On 8/5/23 20:17, Chris Adams wrote: It's the NTP pool people you need to talk to - the .freebsd. bit is just a vendored entry into the pool (more for load tracking and management). Yes, Andreas clarified in unicast. Will do. Thanks. Mark.

Re: NTP Sync Issue Across Tata (Europe)

Once upon a time, Mark Tinka said: > On 8/5/23 19:51, Andreas Ott wrote: > >See for yourself how his pool server scores at > >https://www.ntppool.org/scores/197.224.66.40 > > > >I am not sure why it would be inserted into DNS answers for a > >worldwide pool like 0.freebsd as it clearly does have

Re: NTP Sync Issue Across Tata (Europe)

On 8/5/23 19:51, Andreas Ott wrote: See for yourself how his pool server scores at https://www.ntppool.org/scores/197.224.66.40 I am not sure why it would be inserted into DNS answers for a worldwide pool like 0.freebsd as it clearly does have connectivity issues from some of the pool

Re: NTP Sync Issue Across Tata (Europe)

See for yourself how his pool server scores at https://www.ntppool.org/scores/197.224.66.40 I am not sure why it would be inserted into DNS answers for a worldwide pool like 0.freebsd as it clearly does have connectivity issues from some of the pool project's own sensors. -andreas On Sat, Aug 5,

Re: NTP Sync Issue Across Tata (Europe)

On 8/5/23 18:30, Matthew McGehrin wrote: Hi Mark. Wouldn't a local server be more optimal? IE: server 0.nl.pool.ntp.org server 1.nl.pool.ntp.org server 2.nl.pool.ntp.org server 3.nl.pool.ntp.org I have a bunch of servers all over Europe I'd

Re: NTP Sync Issue Across Tata (Europe)

Hi Mark. Wouldn't a local server be more optimal? IE: server 0.nl.pool.ntp.org server 1.nl.pool.ntp.org server 2.nl.pool.ntp.org server 3.nl.pool.ntp.org Or for Africa server 0.za.pool.ntp.org server 1.za.pool.ntp.org server

NTP Sync Issue Across Tata (Europe)

Hi all. 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: traceroute -I 0.freebsd.pool.ntp.org traceroute to 0.freebsd.pool.ntp.org (197.224.66.40), 64 hops max, 48 byte packets  1  ae-2-24.er-01-ams.nl.seacomnet.com