Cisco Blogs

Access Control: Understanding iACL vs tACL

Other than semantics, what’s the difference between the two access control list configurations presented below? They both look much the same, in fact, but the key differentiation is one of context! Take a few minutes and read ahead…


ip access-list extended Access-Control
permit tcp host eq 80
permit udp host eq 69
deny tcp any eq 23
deny ip any any
access-list 150 permit tcp host eq 80
access-list 150 permit udp host eq 69
access-list 150 deny tcp any eq 23
access-list 150 deny ip any any


Understanding ACLs (access-control lists), or moreover, the difference between standard ACLs, extended ACLs, VLAN ACLs (VACLs), and access-control entries (ACEs) — the individual lines that comprise an ACL — is a challenge in and of itself, but now you read a Cisco Applied Mitigation Bulletin (AMB) and see the terms iACL and tACL: great, another acronym and concept to grasp? You bet!

As defined in the Protecting Your Core: Infrastructure protection Access Control Lists white paper, iACLs are used to minimize the risk and effectiveness of infrastructure attacks by explicitly permitting ONLY authorized traffic to the infrastructure equipment while permitting [all legitimate transit traffic]. On the other end of the spectrum, tACLs, as defined in the Transit Access Control Lists: Filtering at Your Edge white paper, are used to increase network security by explicitly permitting only required traffic into your network or networks. The most common and simple way to put this theory into practice is to first define ingress and egress points.

Most people already know the gist or difference between iACLs and tACLs, they simply do not identify the terminology. First off, let’s clear up some points of confusion. iACL refers to an infrastructure protection access-control list, often referred to as an infrastructure access-list (yes, without the word “protection” it’s all the same concept), while a tACL indeed refers to a transit access-control list. There are two keys to note, which truly define the essence of these ACL concepts:

1) iACL vs tACL is often known as “to” the box traffic vs “through” the box traffic, respectively.

2) The construct is predicated on design/architecture (more on that shortly).

Regarding the “to” and “through” the box concepts, to the box traffic refers to traffic destined to a device. This is often management and control plane related traffic. As stated in the Cisco Guide to Harden IOS Devices white paper, there are three functional planes to a network: management, control, and data. The management plane refers to the traffic sent to the IOS device, consisting of applications and protocols such as SSH and SNMP, whereas the control plane consists of applications and protocols such as routing protocols, e.g. Border Gateway Protocol (BGP) and Enhanced Interior Gateway Routing Protocol (EIGRP). Through the box traffic refers to the data plane, which consists of application and protocol traffic that is forwarded through the device, such as email and web traffic.

One will find that Cisco Security Research & Operations often recommends ACLs for mitigation solutions, mainly due to their robust nature, flexibility, and availability across numerous platforms and software releases. Taken a bit further, one will notice that the context in which we recommend applying ACLs takes on a bit of a twist, in that we assume the firewall to be at the network edge, hence it will always consist of tACL mitigations. As for IOS, well, those devices could be anywhere, and hence the logic for both iACLs and iACLs. However, note that this is not the way it has to be, but just the frame of reference we provide for consistency in our AMBs to help translate the logic to the field. Looking at an AMB, one can see that the concept of iACLs and tACLs is often discussed. Note the following, as stated in a traditional AMB regarding iACLs and tACLs, respectively:

To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure access control lists (iACLs) to perform policy enforcement of traffic sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. For the maximum protection of infrastructure devices, deployed iACLs should be applied in the ingress direction on all interfaces to which an IP address has been configured.

To protect the network from traffic that enters the network at ingress access points, which may include Internet connection points, partner and supplier connection points, or VPN connection points, administrators are advised to deploy transit access control lists (tACLs) to perform policy enforcement. Administrators can construct a tACL by explicitly permitting only authorized traffic to enter the network at ingress access points or permitting authorized traffic to transit the network in accordance with existing security policies and configurations.

As always, an ACL (iACL or tACL) workaround cannot provide complete protection against a vulnerability when the attack originates from a trusted source address.

So, what does all of this truly mean? What’s the importance of the concept? Both statements are indeed accurate; however, it’s the context that truly defines the essence of this concept. Let’s delve into the details. The iACL and tACL concepts are predicated on design/architecture. That design must consist of clearly defined ingress and egress points in the network. Note that’s ingress and egress points in the network, not just “to” the network. The point being, these ACLs can be deployed anywhere. The defining factor is the positioning of the respective network device and the protocols in use (because, well, they define what is being filtered at the end of the day).

The end result? Access control is access control. The means of applying additional or advanced concepts such as iACLs and tACLs is one of efficiency and preference based on one’s respective environment. Moreover, it’s all about the established policies which ultimately define what concepts/options should be applied!

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Hey Lucky, for sure not. As stated in the post, it’s just terminology and more specifically context. The function of the ACL does not change based on these aspects.

  2. @lucky – no.

    Here’s a .pdf of a preso on using iACLs, CoPP, et. al. to harden one’s network infrastructure:

  3. Apart from the terminology used and the context is there any difference in the way they function (filter packets) ?

  4. Hi Andrae

    Beautiful article! Thank you.

    PS: Router has a 4th plane, the service plane 😉

    • Barry Greene and I devised the concept of the services plane several years ago. It has not yet come into general usage, but it’s gratifying to see it cited.


      That being said, the more commonly-used paradigm is that of the control, management, and data planes. The services plane is somewhat notional in nature, though as more and more services-oriented functions are added to the routing infrastructure, it becomes a more concrete concept.

  5. So are the dACLs (downloadable ACLs) we use as authorization in 802.1x deployments the same as tACLs or rather dtACLs? 🙂

    • Haha, for sure, the saga continues eh…..

    • They’re tACLs.

      iACLs deal strictly with traffic destined *for* one’s network infrastructure – routers, layer-3 switches, and so forth – not with traffic headed *through* said infrastructure to servers, clients, and so forth.