Changing Campus Concepts
High-speed switches, such as the Catalyst 6000 series, have become mainstream in the modern campus network. As these switches increase in their capability to move data at increasing speeds, their functionality also increases. Many of the functions that belonged to routes only a few short years ago are now becoming the responsibility of the switches. As these functions are built into the architecture of the switch, it changes some of the concepts that we've been taught about how to implement and design campus networks. One of the functions that is becoming the responsibility of the switch is policy enforcement by packet filtering or access control. This article discusses the use of VLAN access control lists in the Catalyst 6000 series switches and how to configure and manage these lists.
Overview of Policy Enforcement
Campus networks have transitioned from simple, shared segments interconnected by bridges and routers into a series of complex and interdependent switches (Layer 2 and Layer3). Many things have changed in campus network design in recent years, such as the introduction of individual segments for users and intelligent wire speed Layer 2 switches in the wiring closets. Overall, these changes have improved the performance and throughput of networks; however, many things have remained the same in campus networking, such as the enforcement of security at the L3 device beyond the wiring closet (see Figure 1).
Figure 1 Distribution Switch: InterVLAN Routing & Policy Enforcement
The problem with this form of security is twofold. First, all packets must travel across the connection between the wiring closet and the distribution switch to be checked and, if they are denied an administratively prohibited (ICMP) message, must be sent back across the same link. This results in lost resources for that link because it could have been sending user traffic, but it was dealing with packets that were doing nothing to transport production traffic. The second problem is the cost of doing a security check on individual packets. Depending on the L3 device in question here (assume it's a router, RSFC, or RSM and that the L3 device is not performing multilayer switching), it will have to perform a lookup for each packet that passes through the router. Now, if the distribution switch is running MLS, the security process is improved, but only for packets that have established a flow in the cache, which is temporary and would have to be periodically re-established. Also, it is important to mention that these flow-cache resources are limited.
VLAN Access Control Lists Operation
Imagine the advantages of having the ACL lookup performed at the same time as the L2 or L3 switching lookup, and imagine that the ACL is not a software list but one that has been committed to hardware, and that this entire process all occurs at wire speed. Seems too good to be true? Well, the fact is that all this is possible with the latest generation of L2 and L3 switching engines. The Catalyst 6000 series of switches has this switching engine known as a Policy Feature Card (PFC) that can be purchased as an option when you select the supervisor engine. The PFC contains specialized Application Specific Integrated Circuits (ASICs) that have a direct connection to the switching bus or fabric of the switch. These ASICs are responsible for Layer 2, Layer 3, and security/QoS control within the switch. Each of these ASICs performs its function simultaneously and reports the results internally about the control information that is to be sent to the intended forwarding port (such as forward or drop). From a security perspective, this process results in wire speed ACLs on the switch.
Beyond the fact that the ACLs are checked in hardware, it is also important to note that the security function does not require interaction with any type of route processor. This means that a switch with a PFC only can enforce a security policy without having to send packets to the distribution device. This means that you have not only eliminated the cost issue, but you have also eliminated the wasted bandwidth. (You just have to convince accounting to let you replace your old L2 switch with 6000+PFC.) In any event, these ACLs can vastly improve the design and performance of a switched network.
These ACLs are configured in memory committed to a ternary CAM (TCAM) table in hardware and applied to VLANs on the Catalyst 6000 series products. They are referred to as VLAN access control lists (VACLs) and work just like the extended ACLs on a router. That is, they have the following characteristics:
VACLs are a list of permit or deny statements.
VACL statements are processed from top down until a match is made.
Every VACL has an implicit deny at the end of the list.
Only one VACL can be mapped to a VLAN.
IP VACLs can specify both source and destination addresses and ports.
Also, other features make VACLs unlike extended access lists:
VACLs are not applied to an individual port, but are applied to a VLAN; therefore, all ports are in the VLAN.
These lists are not applied in any direction (in or out). The packets are checked as they cross the bus.
Because VACLs check all packets traveling through the VLAN, they can filter traffic flowing between devices in the same VLAN (i.e., the same subnet).
VACLs can be edited without affecting traffic flow.
Entries can be added in any part of the list (not just the end) and individual list entries can be modified.
The changes can be reviewed and modified before they are applied to the switch.
Configuring VACLs
All in all, VACLs offer all the advantages of extended ACLs on a router with none of the penalties. To get a better understanding of VACLs and VACL configuration, take a look at the following scenario:
Company ILB has determined that the new security policy for all access devices is to be implemented at the access level using Catalyst 6006s with PFCs in the wiring closets. The new policy dictates that access devices in the closet should only be able to ping the router but not communicate directly with the router using IP packets in any other way (for example, telnet, TFTP). Also, no user should be able to communicate directly with any other user in the subnet. Furthermore, management decided that no device should be allowed to issue and ICMP echo request to any other devices in any network.
In an effort to accomplish this policy, a VACL named accesspolicy has been created as a test policy for VLAN 101. The router for VLAN 1 is 172.16.101.1 and the subnet is 172.16.101.0/24. The following set of commands define this policy:
Cat6K (enable) set security acl ip accesspolicy permit icmp any host 172.16.101.1 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy deny icmp any any echo accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit ip any any accesspolicy editbuffer modified. Use 'commit' command to apply changes.
By showing the security ACL information, we note at this point in time, no ACLs have been defined:
Cat6K (enable) show sec acl info all No ACLs have been defined yet.
Currently, the list exists only in what is known as the editbuffer, a portion of volatile memory, in the switch. We must commit these changes in the editbuffer to the VACL ASIC with the commit command, but before we do this, we might want to review the contents of the editbuffer with the following commands:
Cat6K (enable) show sec acl editbuffer info all ACL Type Status -------------------------------- ---- ------------------- accesspolicy IP Not Committed Cat6K (enable) show security acl info accesspolicy editbuffer set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any ACL accesspolicy Status: Not Committed
Now that we are satisfied with the VACL, it needs to be committed to the TCAM:
Cat6K (enable) commit security acl accesspolicy ACL commit in progress. ACL 'accesspolicy' successfully committed.
Finally, the policy needs to be mapped to the VLAN for which it will be applied:
Cat6K (enable) set security acl map accesspolicy 101 Mapping in progress. ACL accesspolicy successfully mapped to VLAN 101.
To verify the list or the mappings, use the following show commands:
Cat6K (enable) show security acl info accesspolicy set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any Cat6K (enable) show security acl ACL Type VLANS -------------------------------- ---- ----- accesspolicy IP 101 or Cat6K (enable) show security acl map accesspolicy ACL accesspolicy is mapped to VLANs: 101
Modifying VACLs
After implementing the policy and having it run in our network, some problems come to our attention that need modification. Note that our second statement that was supposed to deny IP traffic within the 172.16.101.0 subnet has an invalid destination network address (172.16.1.0). This must be corrected. Also, it happens that there is another router on this VLAN and our configured gateway keeps sending ICMP redirects to the clients to use this router for certain networks, but due to the entry in the list that stops all other ICMP traffic, these redirects are being blocked. After applying the list, we learn that one of the minor applications running on server 172.16.101.44 regularly sends out broadcasts on UDP port 6108 to determine whether or not clients are active. If these clients don't respond back on UDP port 18888, their sessions with the server times out. It is determined that the following adjustments need to be made to the access policy:
Cat6K (enable) set security acl ip accesspolicy deny ip 172.16.101.0 0.0.0.255 172.16.101.0 0.0.0.255 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit icmp host 172.16.101.1 any host-redirect accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit udp host 172.16.101.44 host 255.255.255.255 eq 6108 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit udp any host 172.16.101.44 eq 18888 accesspolicy editbuffer modified. Use 'commit' command to apply changes.
At this point, the changes have been written to the editbuffer, but not committed to the TCAM. If we view the VACL, we note no changes. However, if we view the editbuffer, the changes are clear:
Cat6K (enable) show security acl info accesspolicy set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any Cat6K (enable) show security acl info accesspolicy editbuffer set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any 5. deny ip 172.16.101.0 0.0.0.255 172.16.101.0 0.0.0.255 6. permit icmp host 172.16.101.1 any host-redirect 7. permit udp host 172.16.101.44 host 255.255.255.255 eq 6108 8. permit udp any host 172.16.101.44 eq 18888 ACL accesspolicy Status: Not Committed
The problem is that we can't add these to the bottom of the list because they would have no effect after the permit ip any any statement. So when we make these changes, a keyword before will be used at the end of the set command followed by the index number in the editbuffer of the item that we want to place them before. For the statement that changes the address for entry number 2, we will use the keyword modify to change that entry. Before we can add the statements correctly, however, we need to remove all the changes to the editbuffer. Because the editbuffer has not been committed, we can use the rollback command to change the editbuffer back to the most recent committed state.
Cat6K (enable) rollback security acl accesspolicy Editbuffer for 'accesspolicy' rolled back to last commit state. Cat6K (enable) show security acl info accesspolicy editbuffer set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any ACL accesspolicy Status: Committed
Now we need to re-enter the commands with the appropriate keywords. But we also need to know where to place the entries in respect with the current list, so we will view the current list with the show security acl info command:
Cat6K (enable) show security acl info accesspolicy set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any
Note that we need to modify entry number 2. Place the ICMP permit statement in before entry number 3 and the remaining two statements need to be placed in before entry number 2. As the first one is placed in before number 2, it will become entry 2. This means that all the original statements will move down one in the index; what was entry 2 is now entry 3. The next statement will now be placed in the list before what is now entry number 3:
Cat6K (enable) set sec acl ip accesspolicy deny ip 172.16.101.0 0.0.0.255 172.16.101.0 0.0.0.255 modify 2 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit icmp host 172.16.101.1 any host-redirect before 3 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit udp host 172.16.101.44 host 255.255.255.255 eq 6108 before 2 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) set security acl ip accesspolicy permit udp any host 172.16.101.44 eq 18888 before 3 accesspolicy editbuffer modified. Use 'commit' command to apply changes. Cat6K (enable) show security acl info accesspolicy editbuffer set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. permit udp host 172.16.101.44 host 255.255.255.255 eq 6108 3. permit udp any host 172.16.101.44 eq 18888 4. deny ip 172.16.101.0 0.0.0.255 172.16.101.0 0.0.0.255 5. permit icmp host 172.16.101.1 any host-redirect 6. deny icmp any any echo 7. permit ip any any ACL accesspolicy Status: Not Committed
Now one of the advanced features of the VACL is that these changes are not being applied to the active list. If you check the active ACL, none of these changes are in effect.
Cat6K (enable) show security acl info accesspolicy set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. deny ip 172.16.101.0 0.0.0.255 172.16.1.0 0.0.0.255 3. deny icmp any any echo 4. permit ip any any
You would have to commit the changes before it affected the traffic flow. At this point, you would use the show security acl info accesspolicy editbuffer to verify the changes. If you want to eliminate all the changes, you could issue a rollback security acl accesspolicy command and clear all the changes in the editbuffer, or you could clear individual entries by using the clear security acl accesspolicy <edditbuffer_index> command. After you are satisfied with the changes, commit them by using the commit security acl accesspolicy command. This adds the entries to the active list and changes the flow of traffic accordingly. Verify these changes with the show security acl info accesspolicy command:
Cat6K (enable) commit security acl accesspolicy ACL commit in progress. ACL 'accesspolicy' successfully committed. Cat6K (enable) show security acl info accesspolicy set security acl ip accesspolicy --------------------------------------------------- 1. permit icmp any host 172.16.101.1 2. permit udp host 172.16.101.44 host 255.255.255.255 eq 6108 3. permit udp any host 172.16.101.44 eq 18888 4. deny ip 172.16.101.0 0.0.0.255 172.16.101.0 0.0.0.255 5. permit icmp host 172.16.101.1 any host-redirect 6. deny icmp any any echo 7. permit ip any any
Removing VACLs
Finally, if you decide to remove the list alltogether, use the command clear security acl accesspolicy followed by a commit security acl accesspolicy command. This eliminates the entire list and traffic will again flow normally through the VLAN. This command also removes all mappings associated with the list. If you want to remove the mapping without destroying the list, you would use the command clear security acl map accesspolicy.
Conclusion
VLAN access control lists are a function of the Catalyst 6000 series switch that enable network professionals to add functionality and speed to network designs. These lists work in hardware and have the look and feel of traditional router ACLs. The VACL is applied to the VLAN and can filter traffic based on Layer 3 and above information in the packet for any traffic that passes through the given VLAN on the switch that's configured with the list. The lists are easy to manage and offer some significant editing functions that are superior to traditional router ACLs.
The addition of VACLs to the architecture of the switch has given us pause for contemplation on just how to implement security policies in the switched environment. As more and more functions move to hardware, the switch is rapidly becoming the workhorse of the campus environment. Security is just one of many functions that switching is beginning to take a more active role in for campus networks. Switches are also beginning to take on other functions, such as QoS classification, scheduling, policing, and packet rewrites. As switches continue to become more robust, many traditional concepts of campus internetworking will be challenged and, overall, the performance of the campus network will greatly improve.
Copyright © 2000-2002 by Publications & Communications Inc. (PCI). All rights reserved.