"It seems your position is 'i don't know how ACL works on my platforms and i don't trust myself to write ACL, so i should not do them',"
That is not my position at all, but thanks. On Mon, Mar 25, 2019 at 12:43 PM Saku Ytti <s...@ytti.fi> wrote: > Hey Tom, > > > 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. > > You may at some cases have hard to troubleshoot issues, which is true > for everything, even when perfectly configured, because software is > not perfect. However choosing to do iACL is still something many > networks choose to do, because the upside is worth the complexity to > them. > > > 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. > > Depends on implementation, on some implementations it is zero-cost on > some it is not. On most implementations it's very cheap, particularly > compared to say uRPF. It seems your position is 'i don't know how ACL > works on my platforms and i don't trust myself to write ACL, so i > should not do them', which is perfectly valid position under those > constrains, but other networks have other constrains under which it is > no longer valid proposal to omit doing iACL. > > I would encourage networks to continue deploying iACL and consider it > BCP. iACL removes attack surface and protects you from host of known > and unknown SIRT issues. > > -- > ++ytti >
