Systems and methods of handling access control violations

[0001] Network devices which implement access control policies or criteria in order to filter out or drop packets can typically be configured to log or report violations of these policies. In order to report not only the violation itself but details about the packet which caused the violation, the packet is copied to the main processor, which consumes bus and/or processor bandwidth.

[0011] The inventive techniques disclosed herein allow efficient logging of access control violations by utilizing an access control list in conjunction with a forwarding table. By using one specific entry within the forwarding table in combination with an indirect forwarding index within the access control list, reporting of access violations to a host processor can be efficiently enabled or disabled by changing this single forwarding table entry. Disabling such reporting is sometimes desirable because providing packets to host processor consumes bus bandwidth, and without this technique, disabling involves updating multiple entries in access control list.

[0012] FIG. 1 is a block diagram of a network including a network device which implements efficient logging of access control violations. A network device 110 receives packets from network nodes 120 through one or more ports 130 (also known as “network interfaces”). Using various policies and/or criteria, access control and reporting logic 140 (residing in network device 110) decides whether the packets will be forwarded through device 110, or will instead be dropped. For example, one policy might specify that all IP packets received from a specific subnet are permitted to transit, while another might specify that all Real-Time Transport (RTP) packets are to be dropped is notified when a received packet fails a policy/criteria, and may perform various logging and/or notification functions such as writing the violation to a file, displaying the violation on a screen, sending a Simple Network Management Protocol (SNMP) message that describes the violation to another device, etc.

[0013] Network device 110 is a general term intended to encompass any device which performs this access control function, which may include (but is not limited to) a firewall, a router, a switch, etc. In the example network of FIG. 1, network device 110 is coupled to a local area network (LAN) segment through LAN link 150, and to the Internet 160 through a wide area network (WAN) link 170. Other types of links are also intended to be within the scope of this disclosure.

[0014] FIG. 2 is a block diagram of selected components of network device 110, in which functionality is divided between a packet processor 210 (implementing the data plane) and a host processor 220 (implementing the control plane). In particular, packet processor 210 implements access control logic 230, which determines whether a packet is passed through or dropped. In some implementations, access control logic 230 corresponds to a packet classifier. Packet processor 210 also determines where the packet is forwarded in some implementations of network device 110 (e.g., routers).

[0015] Host processor 220 controls the behavior of packet processor 210 by configuring packet processor 210 in various ways, based on user input, and on information received in packets and passed from packet processor 210 to host processor 220. Specifically, access control violation reporting logic 240 configures an access control list (access control list 310 in FIG. 3), by issuing a configuration command 250. Packet processor 210 also notifies host processor 220 of errors or exceptions. In particular, packets which violate an access control rule are passed to access control violation reporting logic 240 through an access violation indication 260.

[0016] FIG. 3 is a diagram of various data structures used by access control logic 230 and access control violation reporting logic 240. An access control list 310 includes one or more access control entries 320, where each access control entry 320 includes a packet criteria 330 and a forwarding index 340. A packet criteria 330 specifies (either explicitly or implicitly) particular fields of a packet, along with particular values. As each packet is received, access control logic 230 compares the data values in the specified fields of the packet to the values in a packet criteria 330. Comparing packets with access control list 310 can be implemented in various ways, such as a software-based sequential search of a table stored in random access memory, a hardware-based simultaneous search of a content-addressable memory, a combination of the two, or any other implementation known to a person of ordinary skill in the art.

[0017] If a match of packet data with criteria 330 detected, packet processor 210 uses the forwarding index 340 for the matching packet criteria 330 to determine an action to be taken on the packet. The end result is either dropping the packet or passing the packet through. If the packet is dropped, this is considered an access violation and this may be reported to access control violation reporting logic 240.

[0018] In existing systems, an access control entry (ACE) directly specifies one of the following actions to be taken by packet processor 210: permit; drop and report the packet to host processor 220; and drop without reporting the packet to host processor 220. In contrast, access control list 310 as disclosed herein does not directly specify an action. Instead, the action is indirectly specified by forwarding index 340, which is an index into a separate data structure, a forwarding table 350. That is, forwarding index 340 refers to one of the forwarding table entries 360 in forwarding table 350.

[0019] When a packet matches one of the packet criteria 330 in access control list 310, packet processor 210 uses the corresponding forwarding index 340 to find a forwarding table entry 360. Each forwarding table entry 360 includes a next destination 370 field, where the next destination corresponds to an internal destination within network device 110, such as one of network interfaces 130, or host processor 220, or a null interface. Packet processor 210 then disposes of the packet according to next destination 370. As a result, the packet may be: transferred to a network interface 130, and thus be forwarded to another (remote) device; provided to host processor 220, and specifically to access control violation reporting logic 240; or provided to the null interface—which, by not forwarding to an actual interface, has the effect of dropping the packet.

[0020] In the implementation shown in FIG. 3, host processor 220 fills in and manages forwarding table 350 so that one entry is reserved for use by access control violation reporting logic 240 so that packets which violate particular ACEs are either provided to host processor 220 or dropped. Specifically, in this entry (represented in FIG. 3 by “ACL_REPORT”) next destination 370 is toggled between a value representing host processor 220 (this value is referred to herein as “HOST”) and another value representing the null interface (referred to herein as “NULL”). For example, in FIG. 3, ACL entry 320A and entry 320B each have forwarding index 340 set to the same “ACL_REPORT” entry in forwarding table 350. Thus, this “ACL_REPORT” entry determines the reporting behavior for entry 320A and for entry 320B: if a packet violates either of these two ACLs, the packet is provided to host processor 220, or not, depending on the current value of the “ACL_REPORT” entry (“HOST” or “DROP”).

[0021] By using one specific entry within forwarding table 350 in combination with an indirect forwarding index within access control list 310, access control violation reporting logic 240 can efficiently enable or disable reporting of access violations to host processor 220 by changing this single forwarding table entry. Disabling such reporting is sometimes desirable because providing packets to host processor 220 consumes bus bandwidth, and without this technique, disabling involves updating multiple entries in access control list 310. In some implementations, reporting is initially enabled but is disabled by access control violation reporting logic 240 when the first access violation is reported. In some implementations, reporting is enabled again by logic 240 after a fixed period, such that violations are reported every N minutes (or seconds, hours, etc.)

[0022] Details of enabling and disabling access violation reporting for the implementation of FIG. 3 will now be discussed in connection with FIG. 4, which is a flowchart illustrating operation of access control violation reporting logic 240 (performed by host processor 220). Logic 240 performs various functions related to reporting violations, each represented by an input arrow into FIG. 4. These different paths may be invoked as a result of corresponding function calls, messages, events, or other mechanisms which should be familiar to a person of ordinary skill in the art.

[0023] Incoming path 410 represents the EnableGlobalReporting function, which controls how reporting for any access control violation is handled. In some implementations, this path is invoked during initialization of host processor 220. When path 410 is invoked, block 420 sets the next destination field of the ACL_LOG entry in the forwarding table to the value “HOST”. Block 430 begins an iteration loop, covering all ACEs that have been configured to report violations (e.g., according to a configuration database or table). Within the loop, block 440 sets the forwarding index field for the current ACE to the value “ACL_LOG”, and the loop continues with the next iteration. When all ACEs have been handled, the loop has completed and block 450 starts an ACL reporting timer. (This timer block is optional, and may be user configurable.) As described earlier, a violation of one of those ACEs, packet processor 210 follows the forwarding index to the ACL_LOG entry. Since this entry indicates the next destination is host processor 220, the packet which caused the violation is copied to host processor 220.

[0024] This copy invokes incoming path 460. When this path is invoked, block 470 reports the violation (e.g., writing to a file, sending an SNMP message, etc.). Block 480 sets the next destination field of the ACL_LOG entry in the forwarding table to the value “NULL”. As explained above, upon an access violation packet processor 210 follows the forwarding index to the ACL_LOG entry. Since this entry indicates the next destination is the null destination, the packet which caused the violation is discarded, which means host processor 220 is not notified and does not report the violation. Therefore, before the action in block 480, access violations resulted in a copy of the packet to host processor 220—but after this action, the packets are discarded instead of copied. Without such a change, host processor 220 is likely to be flooded with packets reporting access violations.

[0025] Path 490 is invoked upon expiration of the ACL reporting timer set by path 410. When this path is invoked, block 495 sets the next destination field of the ACL_LOG entry in the forwarding table to the value “HOST”. As explained above, upon an access violation packet processor 210 follows the forwarding index to the ACL_LOG entry. Since this entry indicates the next destination is host processor 220, the packet which caused the violation is once again copied to host processor 220 (and once again invoking path 460).

[0026] The implementations described in FIGS. 3 and 4 uses a single entry within forwarding table 350 to control reporting of access violations. Another implementation, described in connection with FIGS. 5 and 6, uses multiple entries within forwarding table 350. The implementation of FIG. 5 is similar to FIG. 3 except that ACEs for which reporting of violations is desired can be grouped, where each group corresponds to a different forwarding table entry. As shown in FIG. 5, ACE group 510 includes a single ACE, which points to FTE 360A. ACE group 520 includes two ACEs, each of which point to FTE 360B. Notably, these two FTEs have two different values such that, in the state shown in FIG. 5, packets violating the ACE in group 510 are provided to host processor 220 while packets violating the either of the ACEs in group 520 are dropped. Thus, this implementation provides more flexibility than the implementation of FIGS. 3 and 4

[0027] Details of enabling and disabling access violation reporting for the implementation of FIG. 5 will now be discussed in connection with the flowchart of FIG. 6. Incoming path 610 represents the EnableGrouplReporting function, which controls reporting of access control violations for a particular group (group N). When path 610 is invoked, block 620 sets the next destination field of the ACL_LOG entry in the forwarding table to the value “HOST”. Block 630 begins an iteration loop, covering all ACEs in group N (e.g., as specified in a configuration database or table). Within the loop, block 640 sets the forwarding index field for the current ACE to a value associated with the group (“ACL_LOG_N”), and the loop continues with the next iteration. When all ACEs in the group have been handled, the loop has completed and block 650 starts an ACL group reporting timer. (This timer block is optional, and may be user configurable.) As described earlier, a violation of one of those ACEs, packet processor 210 follows the forwarding index to the ACL_LOG_N entry (an entry specific to group N). Since this entry indicates the next destination is host processor 220, the packet which caused the violation is copied to host processor 220.

[0028] This copy invokes incoming path 660. When this path is invoked, block 670 reports the violation for the ACE group (e.g., writing to a file, sending an SNMP message, etc.). Block 680 sets the next destination field of the ACL_LOG_N entry in the forwarding table to the value “NULL”. As explained above, upon an access violation packet processor 210 follows the forwarding index to the ACL_LOG_N entry. Since this entry indicates the next destination is the null destination, the packet which caused the violation is discarded, which means host processor 220 is not notified and does not report the violation. Therefore, before the action in block 680, access violations resulted in a copy of the packet to host processor 220—but after this action, the packets are discarded instead of copied. Without such a change, host processor 220 is likely to be flooded with packets reporting access violations.

[0029] Path 690 is invoked upon expiration of the ACL reporting timer set by path 610. When this path is invoked, block 695 sets the next destination field of the ACL_LOG_N entry in the forwarding table to the value “HOST”. As explained above, upon an access violation packet processor 210 follows the forwarding index to the ACL_LOG_N entry. Since this entry indicates the next destination is host processor 220, the packet which caused the violation is once again copied to host processor 220 (and once again invoking path 660).

[0030] FIG. 7 is a block diagram showing the operation and structure of packet processor 210 in more detail. In this example, packet processor 210 is illustrated as two separate components (access control logic 230 and forwarder 750), but this division of functionality is only a logical convenience. Packet processor 210 receives packet 710 at ingress port 130-I. Access control logic 230 uses one or more header fields (720) of the ingress packet as a key 730 to search access control list 310. Access control logic 230 provides search result 740 to forwarder 750 as a forwarding index 340 into forwarding table 350. Forwarder 750 obtains the corresponding next destination 370 from forwarding table 350, then disposes of packet 760 by adding it to one of the packet queue 770 that is indicated by next destination 370: one of the port-specific queues 770-1 . . . N; drop queue 770-D; or host processor queue 770-H.

[0031] FIG. 8 is a block diagram of network device 110, according to some implementations disclosed herein. Network device 110 includes packet processor 210, host processor 220 memory 810, a network interface 820, a peripheral input output (I/O) interface 830, and storage device 840 (e.g., non-volatile memory or a disk drive). These components are coupled via a bus 850. Omitted from FIG. 8 are a number of components that are unnecessary to explain the operation of network device 1100.

[0032] Access control logic 230 and access control violation reporting logic 240 can be implemented in hardware logic, software (i.e., instructions executing on a processor), or a combination thereof. Hardware embodiments includes (but are not limited to) a programmable logic device (PLD), programmable gate array (PGA), field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system on chip (SoC), and a system in package (SiP).

[0033] When implemented as software, access control logic 230 and/or access control violation reporting logic 240 can be embodied in any computer-readable medium for use by or in connection with any processor which fetches and executes instructions. In the context of this disclosure, a “computer-readable medium” can be any means that can contain or store the program for use by, or in connection with, the processor. The computer readable medium can be based on electronic, magnetic, optical, electromagnetic, or semiconductor technology.

[0034] Specific examples of a computer-readable medium using electronic technology would include (but are not limited to) the following: an electrical connection (electronic) having one or more wires; a random access memory (RAM); a read-only memory (ROM); an erasable programmable read-only memory (EPROM or Flash memory). A specific example using magnetic technology includes (but is not limited to) a portable computer diskette. Specific examples using optical technology include (but are not limited to) an optical fiber and a portable compact disk read-only memory (CD-ROM).

[0035] The software components illustrated herein are abstractions chosen to illustrate how functionality is partitioned among components in some embodiments of various systems and methods of deferred error recovery disclosed herein. Other divisions of functionality are also possible, and these other possibilities are intended to be within the scope of this disclosure. Furthermore, to the extent that software components are described in terms of specific data structures (e.g., arrays, lists, flags, pointers, collections, etc.), other data structures providing similar functionality can be used instead.

[0036] Software components are described herein in terms of code and data, rather than with reference to a particular hardware device executing that code. Furthermore, to the extent that system and methods are described in object-oriented terms, there is no requirement that the systems and methods be implemented in an object-oriented language. Rather, the systems and methods can be implemented in any programming language, and executed on any hardware platform.

[0037] Software components referred to herein include executable code that is packaged, for example, as a standalone executable file, a library, a shared library, a loadable module, a driver, or an assembly, as well as interpreted code that is packaged, for example, as a class. In general, the components used by the systems and methods for handling access violations are described herein in terms of code and data, rather than with reference to a particular hardware device executing that code. Furthermore, the systems and methods can be implemented in any programming language, and executed on any hardware platform.

[0038] The flow charts herein provide examples of the operation of various software components, according to embodiments disclosed herein. Alternatively, these diagrams may be viewed as depicting actions of an example of a method implemented by such software components. Blocks in these diagrams represent procedures, functions, modules, or portions of code which include one or more executable instructions for implementing logical functions or steps in the process. Alternate embodiments are also included within the scope of the disclosure. In these alternate embodiments, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. Not all steps are required in all embodiments.

[0039] The foregoing description, for purposes of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and describe in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.