Compliance exists in many forms, with tenancy, traffic isolation and access restriction. Compliance is mostly due to regulatory needs, which really comes down to security needs. Compliance applies to networking, fundamentally ensuring that resources can only be accessed from allowed locations. The actual media and content normally isn’t pertinent, as they merely just influence the scope of access for the data.

As a result, this post doesn’t delve into more complex compliance requirements such as deep packet inspection or encryption. Rather, this is to discuss how networking engineers use their existing toolset to enforce compliance requirements.

The most fundamental of these requests is networking access permissions. Most customers will allocate subnets for functional sections of their network.

ACLs are some of the most classic and undemanding forms of permission. The greatest part of ACLs is that they can be applied on nearly every networking device, and provide somewhat of a base level of security. But there are hidden complexities with ACLs that may not make it the ideal choice for most compliance solutions:

1. Connection State Tracking

ACLs are unidirectional elements, examining packets one at a time and only blocking traffic in a single direction. This can create some logical challenges with whether the compliance requires hosts to be protected from inbound connections or to restrict their outbound communication. Trying to solve this stateful tracking component can lead to bloating ACL configurations and result in the need to apply them on them on disparate interfaces to enforce the full policies required.

A simple example of this, setting up a webserver that is protected by ingress ACLs. The ingress ACLs would allow packets destined to TCP port 80 and 443. Now assume that a sysadmin wants to use a package manager (ie. apt or yum) to install packages on this webserver. The traffic initiated from the webserver would be from a random high end port, being the ingress ACL would drop any return traffic, preventing any traffic initiated from the webserver from working.

2. Application Awareness

ACLs are not application-aware, as such protocols that negotiate a different data connection than the control connection are easily stymied with the use of solely ACLs. For example, ACLs that enforce active vs passive FTP. In Active FTP, an ingress ACL allowing TCP/21 and an egress ACL allowing TCP/20 is normally enough to statelessly permit traffic. But in passive FTP, the ACLs applied need to allow in all high end ports because the port is dynamically negotiated. Passive FTP uses port 21 for its control connection and a randomly negotiated port for its data connection. As such, in order to enforce Passive FTP using ACLs, the network operator would need to proactively open up access to all of the available Passive FTP ports on the server. In some instances, this defeats the purpose of the ACL restriction all together.

3. Hardware Limitations

ACLs aren’t infinite. When applying ACLs to network devices you’ll be limited by one of two technologies: i) RAM ii) Hardware limits
On network switches and switch hardware, the limit is normally driven by the ASIC’s capability of installing the ACLs. This is not just a total number of ACLs, but it normally depends on the subdivision of the type of ACL, for example:

  •  IPv4 vs IPv6 ACLs
  • Ingress vs egress ACLs
  • 802.1x vs QOS ACLs

The ACL design now becomes more complicated, and therefore more difficult to manage. Beyond just managing the ACL configurations and counting the number of elements, the user would have to track the resource utilization of the ACLs, and adjust the limits according to each type of ACLs.

For these very reasons, many times the network architects will start to position a dedicated security appliance to handle these compliance requirements. That security appliance is normally a firewall. Without getting bogged down with the differences between a distributed vs centralized firewall, this post will only discuss a centralized firewall as an alternative to ACLs.

A centralized firewall solves many of the ACL limitations listed above. But it poses a fundamental challenge: How can I force any compliance required traffic to go through my firewall? This is not an easy fix if ACLs were selected as the only solution used for compliance. If you’re using using ACLs in conjunction with VRFs, this is a more straight forward solution as each VRF routing table can receive a default route from the firewall. This then forces only inter-tenant VRF to be sent through the firewall. Which starts to lead to the main reasons why firewalls look unappetizing. Most commercially available firewalls on the market currently cost more than $400,000 for a single firewall capable of 100G. Whereas a 100G network switch has a total throughput capability of 3.2Tb. Again, in order to use a centralized firewall, it also requires VRFs to be able to properly segment the sections of your network.

So, where exactly is all this going? Well, there isn’t a single solution that is one size fits all. In my opinion, having a centralized firewall is one of the easier and more manageable options as it creates operational simplicity that is easy to digest. Yes, in the case that the budget or inter-tenant requirements don’t allow for a centralized firewall, ACLs are also a reasonable choice.

Remember, it’s important to be wary of network engineers that choose firewalls and then expect them to behave with all the features of a datacenter switch. There are fundamental roles that each type of network device provides, and there still exist network engineers in the industry that expect data center switches to be the “everything” box. They are drawn by the allure of a network device that can provide 100G line rate per port, and expect that same device to deliver all the features of their slower appliances. Just be critical when trying to implement security features on devices known for speed, most of the time the two requirements are incongruent.

If this blog was interesting to you, be sure to check out some of our other blogs addressing security and similar issues here. To learn how Cumulus Linux provides network protection to our customers, check out our product page.