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

[image: preview.png]

ndss2021_1A-2_24302_paper <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf> PDF Document · 1.7 MB <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>

<https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>

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 <rubensk@gmail.com> 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 <mel@beckman.org> 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 <royce@techsolvency.com> 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 <mel@beckman.org> 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.