Debate arose recently from a Systems [Windows] engineer over the more logical application in his opionion of File System ACLs vs how Network ACLs work.

Network ACLs generally work by applying ACEs in order (top-down) and stop on the first match. File System ACLs (NTFS in particular) work by considering all ACEs and granting the most privileges unless a deny-ACE is encountered.

Why do Network ACLs work the way they do and why shouldn't they be compared to File System ACLs as I intuitively understand?

Network ACLs work as follow per my understanding:

  • Need to process at the packet-level
  • Need to punt to CPU for first encounter of flow
  • Stops at first match for the sake of speed
  • Considering all ACEs is counter-productive since we're not building up a list of allowable permissions
  • 2
    In general, this is for the sake of speed. Just consider the amount of packets traversing a network devices versus the amount of file accesses in the same environment. The numbers will be several orders of magnitude in difference. I don't believe nowadays the first packet is punted the CPU's nowadays.
    – JelmerS
    Aug 12, 2014 at 19:50
  • It's worth noting that each Network ACL (i.e. standard, extended, etc) is specifically tailored to match based on known bit-positions. This makes dissection extremely efficient. @JelmerS hit the nail right on the head, the amount of filesystem ACLs a device will perform is trivial in comparison to how many a network device will handle.
    – Ryan Foley
    Aug 12, 2014 at 20:08
  • @RyanFoley: Good point on the bit-position matching for efficiency. Aug 12, 2014 at 20:11
  • 1
    @JelmerS: Perhaps more important is the need to not be forced to queue packets while an ACL is being check which could negatively impact other packets needing to transit even if they have already been flow and ACL checked and are in a fastpath. Aug 12, 2014 at 20:14
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 8, 2017 at 21:48

2 Answers 2


Without saying it, you have the right notion, it all comes down to speed and flexibility. This is directly related to the amount of runtime operations and parameters you must check against. I’m not an expert on Windows file system ACLs, but conceptually the facts remain the same.

One look at the extensibility of Windows file system ACLs and can you can see that you have a lot of different options for a wide array of attributes and security levels. Each of these options comes with a level of memory and CPU penalties. The goal is to provide a flexible, seamless permissions structure that still offers granular control. This includes capabilities on different file systems, account types and environments. It was built to serve a specific purpose, file control, which doesn’t necessarily need to operate at over 100 million events per second, like a 6509 would.

At the opposite end of the spectrum, you have network ACLs that were designed with speed in mind. When you create an ACL you not only have a hardware-optimized platform performing these comparisons, but you also have a strict set of bit-wise operations that are happening1. With standard ACLs, you only look at source and destination addresses; indiscriminate of any other TCP/IP variable.

Take the below test results from the European Advanced Network Test Center (EANTC). They stress test a 6500 with 32, 10Gb ports at 90% line rate with a packet size of 64 bytes (most stressful) from totally unique addresses and then compare it with a 10,000 line ACL that matches at the 10,001th entry. It yields a minimal drop in line rate and zero loss.

European Advanced Network Test Center: Test Results
EANTC: Cisco Catalyst 6500 with Supervisor720 — 10 Gigabit Ethernet Performance Test

Although this doesn’t show latency, which would be the real testament to the speed of these platforms, they do say go on to say “Catalyst performance unaffected by the addition of value-added services such as ACLs, QoS traffic classification and NetFlow Statistics gathering.”

Once you look to add additional flexibility, such as extended ACLs, you require additional checks against the data. This adds latency. The key is that you choose which is most appropriate for the application for your business requirements. Not everyone needs an extended ACL when a standard ACL will do.

As most indicated in the comments, the amount of routines a router will need to go through every moment dwarfs a file system ACL in pretty much every way. Does this mean they’re better? Not necessarily. But they are certainly faster at what they do, just limited.

1This is assuming no logging is happening, which relies on CPU processing to log the message.


As noted in the comments, it's for the sake of speed.

Having been a file server dude in another life, and gone through an internal compliance audit that makes the worst PCI inspection look like a picnic, let me also add this:

Network ACLs working top-down first-match-wins forces you to really put a lot more thought into organizing your access lists when implementing/updating them, and later read far more cleanly and readily than File system ACLs.

File system ACLs have the advantage of convenience, and afford far greater unintended consequences.

Of course, if your environment doesn't bother with security, then that's not a problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.