ch02lev1sec5.html

Understanding ACL Processing

This section helps you to understand ACL processing by explaining inbound and outbound ACLs, packet flow rules, and guidelines for implementing ACLs.

Inbound ACL

Examine the pseudocode that follows to understand packet processing. When an inbound ACL is applied on an interface, the router checks the received packet against the ACL's statements for a match.

Code View:

if {a match is found} then
  if {the action is to permit) then
     {router continues to process the packet}
  else {the action is to deny} then
       {router discards the packet sending an ICMP Unreachable message to the
          source address in the packet - assuming this is not disabled}
  endif
else {a match is not found} then
     {with the default 'implicit deny' statement—the router discards the packet,
          sending an ICMP Unreachable message}
endif

Outbound ACL

Examine the pseudocode that follows to understand packet processing. When an outbound ACL is applied on an interface, the router first performs a route lookup for the destination address in the routing table to determine the exit (egress) interface.

Code View:

if {valid path found in routing table} then
  if {a match is found} then
   if {the action is to permit) then
        {router continues to process the packet}
   else {the action is to deny} then
     {router discards the packet sending an ICMP Unreachable message to the source
       address in the packet - assuming this is not disabled}
   endif
  else {a match is not found} then
      {with the default 'implicit deny' statement—the router discards the packet,
        sending an ICMP Unreachable message}
  endif
else {valid path not found in routing table, the router drops the packet}
endif

Figure 2-3 shows the logical flowchart for how a packet is processed against an inbound or outbound ACL.

Figure 2-3. Life of a Packet Undergoing the ACL Process

[View full size image]

Packet Flow Rules for Various Packet Types

The packet flowchart shown in Figure 2-4 demonstrates how ACL rules are applied to various packet types such as nonfragments, initial fragments, and noninitial fragments that are checked against an ACL.

Figure 2-4. ACL Flow for Non-fragments, Initial Fragments, and Non-initial Fragments

[View full size image]

RFC 1858 covers security considerations for IP fragment filtering and highlights two attacks with two defending mechanisms involving an IP fragment attack.

Note

The noninitial fragment packet contains only Layer 3 information, not Layer 4 information, although the ACL may contain both Layer 3 and Layer 4 information.

Note

Figure 2-4 is taken from the Cisco documentation URL listed here. For more details on ACLS and IP Fragments, visit http://www.cisco.com/warp/public/105/acl_wp.html.

Guidelines for Implementing ACLs

Following are some general guidelines to consider when implementing ACLs:

ACLs can be applied to multiple interfaces on a device.
Only one ACL is allowed per protocol per interface per direction. This means that you can have two ACLs per interface—one inbound and one outbound.
ACLs are processed from the top down. The order of the access-list entries needs to be planned carefully. More specific entries must appear first.
When entering the ACL, the router appends the access control entries (ACEs) at the bottom. In newer IOS versions that have sequencing function, it is possible to insert ACE entries between current entries.
There is an "implicit deny" for traffic that is not permitted. A single-entry ACL with only one deny statement has the effect of denying all traffic. An ACL must have at least one permit statement; otherwise, all traffic is blocked.
Always create an ACL before applying it to the interface. When modifying or editing an ACL, always remove the ACL from the interface, make the changes, and then reapply the ACL to the interface.
An outbound (egress) ACL applied to a router interface checks only for traffic traversing through the router—that is, traffic going through the router and not traffic originating from the router.