Resuming the great cleanup

[Mark Atwood]

On Sun, May 27, 2018 at 11:56 AM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> Eric said:
> > SINGLESOCK:  While messy and somewhat difficult, this is mostly a SMOP
> > (Simple Matter of Programming). There is one potential technical risk,
> > relatively minor I think.
>
> > The reason for iterating over interfaces is that ntpd has the capability
> to
> > block incoming packets by interface of origin. In order to go to a single
> > epoll we either need to (a) abandon this feature, or (b) find a way to
> query
> > the device a packet came through from the packet.
>
> Could that feature be moved to a packet filter?  I think most OSes support
> some form of kernel level packet filtering.  I'm not familiar with any
> details.
>
> Does anybody use interface filtering?
>

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.

We can explain why, and every netadmin and devops manager will agree with
the reason.

..m

-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20180528/2360ae86/attachment.html>