<div dir="ltr">"It seems your position is 'i don't know how ACL<br>works on my platforms and i don't trust myself to write ACL, so i<br>should not do them',"<div><br></div><div>That is not my position at all, but thanks. </div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 12:43 PM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Tom,<br>
<br>
> If your edge ingress ACLs are not 100% in sync all the time, you will inevitably have Really Weird Stuff happen that will end up taking forever to diagnose.<br>
<br>
You may at some cases have hard to troubleshoot issues, which is true<br>
for everything, even when perfectly configured, because software is<br>
not perfect. However choosing to do iACL is still something many<br>
networks choose to do, because the upside is worth the complexity to<br>
them.<br>
<br>
> Packet filtering is more computationally taxing than just routing is. Your edge equipment is likely going to be built for maximum routing efficiency. Trying to bite off too much filtering there increases your risk of legit traffic being tossed on the floor.<br>
<br>
Depends on implementation, on some implementations it is zero-cost on<br>
some it is not. On most implementations it's very cheap, particularly<br>
compared to say uRPF. It seems your position is 'i don't know how ACL<br>
works on my platforms and i don't trust myself to write ACL, so i<br>
should not do them', which is perfectly valid position under those<br>
constrains, but other networks have other constrains under which it is<br>
no longer valid proposal to omit doing iACL.<br>
<br>
I would encourage networks to continue deploying iACL and consider it<br>
BCP. iACL removes attack surface and protects you from host of known<br>
and unknown SIRT issues.<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div>