Introduction:

Access-Control-Lists (ACLs) are commonly implemented in Cisco Systems routers with the use of the "access-list" command. Access-lists are packet-classifying mechanisms. These access-lists define actual network traffic that will be permitted or denied when it is applied to a particular router network interface. Therefore, these access-lists can create network devices that are configured to implement the network security policies for an organization.

Access-lists come in different forms. There are standard and extended access-lists. Standard access-lists are defined to permit or deny an IP address or range of IP addresses. Extended access-lists define both a source and a destination IP address or IP address range. Extended access-lists can also be defined to permit or deny packets based on TCP, UDP, or ICMP protocol types and the packet’s destination port number.

Access-lists are separate from the routing functions of the router. The routing decisions are made for the packet, and only when the packet makes its way into or out of a router interface, the packet is processed and then the access-list is checked.

For inbound access lists, after receiving a packet, the router checks the source address of the packet against the access list. If the access list permits the address, the router continues to process the packet. If the access list rejects the address, the router discards the packet and returns an ICMP Host Unreachable message.

For outbound access lists, after receiving and routing a packet to a controlled interface, the router checks the source address of the packet against the access list. If the access list permits the address, the router transmits the packet. If the access list rejects the address, the router discards the packet and returns an ICMP Host Unreachable message.

When you apply an access list (standard or extended) that has not yet been defined to an interface, the router will act as if the access list has not been applied to the interface and will accept all packets. Remember this behavior if you use undefined access lists as a means of security in your network.

Because access-lists are complex and are filled with subtleties and nuances, it is important to have a detailed understanding of them. To this end, this document details many of the considerations needed for access-lists and methods to improve the ways they are used.

 Considerations:

Performance:

There are performance considerations when using access-lists. Because ACLs are sequential collections of permit and deny conditions, the router stops testing the conditions after the first match occurs when checking the rules one-by-one. If no conditions are matched, then the implicit deny "end-rule" action is performed. The sooner the packet matches a rule, the higher the performance of that connection. Therefore, the order of the conditions is critical. Because the checking of these conditions requires some processing to be performed, there are techniques to reduce the amount of CPU required for these tasks. Below is a table that details the different switching techniques used in Cisco routers and the types of access-lists that are supported under those methods. The first packet of every communication exchange is always process switched. The route table (DRAM) is consulted and the result is cached in the system memory cache. If the protocol can only be process switched, then it will continue this way and interrupt the CPU for a route table lookup for each packet. Packets that are capable of being fast-switched will consult only the route-cache on the second and subsequent packets. This still involves a memory lookup on the board, but the packet can be transferred from the source card directly to the destination card without requiring full storage on the CSC. Autonomous switching goes one step further by caching the result on the Cbus controller. True autonomous switching only occurs between Cbus boards. The Silicon Switch Processor is a specially designed switch processor that improves multilayer switching decisions by improving caching of packet forwarding rules.

Switching Path	Preference	Access-list Type
Silicon Switch Processor	1	Standard and extended outbound access-lists are supported. Completely disabled for any inbound access-lists.
Autonomous-Switching	2	Disabled per interface for outbound access-lists. Completely disabled for any inbound (cbus/cxbus) access-list. Extended access-lists are not supported.
Fast-Switching	3	All types supported. (After IOS version 10.3)
Process-Switching	4	All types supported.

However, regardless of the switching type, there are still per-packet performance costs associated with access-lists. It is a difficult to quantify these exact performance costs. None-the-less, it is important to try to maximize the use of fast-switching, and other switching techniques and steer away from process-switching as much as possible.

Logging:

It is important to realize that Cisco access-lists do not typically create an audit log of their activities. Cisco routers do not have the capability to store logs internally. However, routers are starting to get the ability to use other computers to help with logging. Later IOS 11.2 versions have the ability to log to a syslogd server packets that match a rule in an access-list. However, the log entry will not contain information on whether the packet was accepted or denied or even by which rule. Regardless, these new features should be taken advantage of to their fullest extent as soon as it is feasible.

Network Layer Security:

ACLs are said to only provide packet filtering capabilities. What is meant by this is the router inspects packets one-by-one and does not look at what the packet contains or where the packet is located in relation to the entire stream/session. ACLs are only concerned with the source and destination IP address, TCP/UDP/ICMP type, and destination port number. Therefore, the router does not maintain state information of the network conversation the router is in the middle of. Furthermore, because ACLs do not inspect application commands, the router would forward packets of a data-driven attack unknowingly. In addition, access-lists must use the keyword "established" to allow the return of packets in TCP sessions that have the ACK or RST bits set. This can be considered a security hole. This technique is only done for TCP packets of established sessions, leaving UDP packets unprotected. These are important considerations when defining the access-lists to be used on a router.

Directionality:

As mentioned earlier, access-lists can either be applied in the inbound or outbound directions. The access-list rules should be defined in both inbound/outbound directions to provide the maximum security benefit. This provides for better control of the network traffic permitted to pass through the router, therefore helping to tightly define the security policy. However, for simplicity, some companies only define what comes into their networks and not what leaves their networks. Regardless, access-lists must be defined on every interface requiring security. The use of inbound lists are important to being able to block out IP spoofed packets coming into the border router’s external interface. It is critical to define all of the networks that an organization owns for the anti-spoofing rules, even though this list may be difficult to maintain. Also, it is also important to use the "no ip source-route" command on all the interfaces of the router to further protect it from spoofing attacks.

Configuration:

Access-lists are typically defined with the command-line interface on the Cisco router. Therefore, ACLs are sensitive to typing errors. This is related in part to the fact that access-lists tend to be large, complicated, busy, and generally hard to read. It is important to mention that with the use of two windows and a cut and paste function, these administration burdens can be improved. It would be better if they had the ability to be commented within the router. This may be a feature that appears in newer versions of the IOS. In fact, in newer versions of 11.2 IOS, there is the ability to have named standard and extended access-lists as opposed to numbered. One method of commenting would be to comment the list in a file on a computer using the "!" start of line comment identifier and then have these disappear during the cut and paste at configuration. If ACLs could be defined with an object-oriented approach, their size would be reduced, their readability could increase, and the security policies could be more precisely defined. Unfortunately, this is not an option for their configuration. There is also a limitation of extended access-lists to be defined using unique numbers in the range of 100 to 199, however, this may be resolved in future IOS versions. The use of ACLs also require detailed knowledge of the security policy to be implemented and of the TCP/IP protocol. The ACL is said to only be as good as its implementer. This statement refers to the human error factors involved in ACL creation and maintenance. It should be noted that ACLs have an implicit deny all statement at their ends. In order to highlight this, these statements should be explicitly defined so that this fact is not forgotten. That way if any rule is added to the list, it comes after the deny all. However, any edit to the rules then require the entire access-list to be removed and reapplied. It would also be nice if the router had the ability to inspect the rules being entered. There is no context checking of access-lists prior to being installed in the running configuration. Currently, there is no way to automate checking for errors. Because the order of ACLs matter, it is possible to have two rules that negate each other and therefore end up not acting as intended. It is important to be understand these issues and to use care and a methodical approach when dealing with access-lists.

Maintenance:

Making changes to access-lists can also have its challenges. With an access-list that is associated with an interface, you should disable the list before a change is made to the access-list. Once you disable the access-list from the interface, changes can be made to the access-list without any impact on users. However, the router is then operating wide open without any security. This may last for a few seconds to several minutes, depending on how long the cut/paste or edit takes. If the change to the access-list is made with it still being applied to the interface, there could be disruptions to the streams that are flowing through the interface. Sessions may be forced to transmit packets or sessions could have more serious problems. In the future, you may be able to edit lines in the middle of the access-list without the considerations listed above. Therefore, at this time, it is best to disable the access-list from the interface and make the change quickly to reduce the risk of attacks during the period when the router is unprotected.

Packet Discard:

Routers send back ICMP host unreachable messages when packets are dropped with access-lists. In some cases it might be more desirable to just silently drop the packet. There is not a concern that many ICMP packets will choke the router because ICMP packets have a lower processing priority for the router. However, it is suggested to use "ip spd enable" for selective packet discard. This is just a matter of what the security policy wants the external network to see when communicating with the filtering router.

Configuration Failure:

It is also important to mention that ACLs fail in the open direction. This is to say that if the ACL is disabled, then no security policy is implemented. Because the removal of the ACL leaves the network unprotected, it may be difficult to detect the ACL’s failure during normal operation. Therefore, it is important to test the ACL set regularly and to augment the security provided by the filtering routers in other ways.

 Conclusions:

With these considerations in mind, router access-lists can be improved. However, there are some significant issues related with ACLs that are important to consider and act upon. Therefore, it is common practice to partner filtering routers with other security systems that look at upper layer network information in order to increase security, manageability, and visibility of the enterprise security policy.