<div dir="ltr">There are a couple of different but very similar angles of approach to explain why a network security experts will not trust a userspace daemon to control it's own defensive packet filtering.<div><br></div><div>The UNIX concept: each tool should do one thing, and do it well.   The ntpd should no more do packet filtering than the packet filers should implement the NTP protocol.</div><div><br></div><div>Separation of knowledge.  The packet filers know how the network stack is implemented, and how the local site has plumbed them.  Repeating this knowledge in the ntpd violates DRY, and are hard to keep in sync.</div><div><br></div><div>Separation of configuration.  Network configuration tools know to speak to the packet filter API and know to speak to the switch APIs.   Asking those tools to speak to every random daemon's implementation of each own control interface is asking too much. </div><div><br></div><div>Assumption of mistrust.  Admins and devops people now assume (after 40+ years of bitter experience) that all daemons are broken and insecure.  That lack of trust extends to any given daemon's own (probably half assed and poorly reviewed) implementation of packet filters.</div><div><br></div><div>Assumption of corruption.  Once a bad guy has presented a malicious packet stream to a daemon, you cannot trust that daemon's own logging, or trust any part of that daemon's execution paths. Including the execution of it's own packet filters!</div><div><br></div><div>Linus's Law, and it's weaknesses.  The packet filters are the point where Linus's Law has engaged about packet filtering.  The slightest quiver of uncertainly in the packet filter implementations will trigger CERT conference calls, corporate sev2 incidents, and personal line-by-line hand-execution code audits by technical leads.   The discovery of yet another parsing bug in a userspace daemon is called a "Tuesday".</div><div><br></div><div>The "half of common lisp" narrative.  Just like every large programmable system eventually has a poorly specified implementation of parts of Lisp, every local single process userspace implementation of packet filtering is just a poorly specified poorly performent implementation of the the packet filter.</div><div><br></div><div>..m</div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 29, 2018 at 3:13 AM Eric S. Raymond via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mark Atwood <<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a>>:<br>
> No modern sysadmin or devops shop is going to use or trust an userspace<br>
> packet filter built into the userspace daemon they are defending.<br>
<br>
Hm.  I am ignorant here.  Why is this so?<br>
<br>
> This is an ancient feature that is a fossil evidence that NTP was a known<br>
> security tarpit predating the widespread deployment of the kernel packet<br>
> filter or edge switch filters.<br>
> <br>
> We will drop this feature.<br>
> <br>
> We can explain why, and every netadmin and devops manager will agree with<br>
> the reason.<br>
<br>
I am not arguing with the decision - it is exactly yours to make - but I'd like<br>
to see an explanation in a form I can put in a doc patch.  I'll first cleanly<br>
remove it with explanation, then implement SINGLESOCK. <br>
-- <br>
                <a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br>
<br>
My work is funded by the Internet Civil Engineering Institute: <a href="https://icei.org" rel="noreferrer" target="_blank">https://icei.org</a><br>
Please visit their site and donate: the civilization you save might be your own.<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Mark Atwood<br>
<a href="http://about.me/markatwood">http://about.me/markatwood</a><br>
+1-206-604-2198</p>
</div></div>