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 days. 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 daemons. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
