Resuming the great cleanup
Stromeko at nexgo.de
Tue May 29 18:15:09 UTC 2018
Mark Atwood via devel writes:
> No modern sysadmin or devops shop is going to use or trust an userspace
> packet filter built into the userspace daemon they are defending.
> Direct-internet-connected boxes are going to use the kernel packet policy
> filter, and drop the packet before it ever reaches the daemon.
> Site-connected boxes are going to use their edge switch filters, and then
> maybe will use the kernel packet filter as a security alarm trip.
> Cloud-connected instances are going to use their cloud provider packet
> control APIs to permit inbound NTP packets, may run a policy relay instance
> on their VPC chokepoint, and again maybe will use the kernel packet filter.
> This is an ancient feature that is a fossil evidence that NTP was a known
> security tarpit predating the widespread deployment of the kernel packet
> filter or edge switch filters.
> We will drop this feature.
As far as outright ignoring packets from certain interfaces, domains or
IP ranges goes, that seems like a good move to me (zero trust packets
should never reach the daemon).
However, there is still value in the knowledge of which interface the
packet came in so that ntpd can place different levels of trust
depending on whether it's from a private (virtual) network segement, an
internal or public network. Also, this information would potentially be
quite valuable to get a better grip on asymmetric network delays, which
are dominating the residual timing error on many types of networks these
Of course this can be done in various ways, among them tagging the
packets, running multiple threads or even a fleet of DJB style mini
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
More information about the devel