Browse Prior Art Database

A method to cache packet filters to improve filtering performance

IP.com Disclosure Number: IPCOM000013658D
Original Publication Date: 2002-Oct-28
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 55K

Publishing Venue

IBM

Abstract

The IP protocol is the network layer (OSI layer 3) in the TCP/IP protocol stack. IP packet filtering works at this layer to allow the expression and processing of IP filter rules (filter rules). These filter rules are widely used to allow certain packets to continue their normal processing and to disallow other packets. A typical set of filter rules may number in the 100s. Since every packet that enters or leaves a system must be processed by the current set of filter rules, the performance of the filtering function itself is important. Poor performance can affect all (TCP/IP) network activity for a system adversely. A given IP packet is processed by 'checking' it against each filter rule, in turn. (The filter rules are an ordered set.) The first filter rule which 'matches' the packet is used to determine the packet disposition (typically, 'permit' (allow it to continue), 'deny' (immediate discard of the packet) or 'ipsec' (handle the packet via the correct IP Security policy)). Hence, a given packet is typically checked against a subset of the all the existing filter rules. Ideally, a higher percentage of the traffic that passes through a given physical interface, with a given set of filter rules, is handled by one of the first few filters. So, the technical challenge can be stated as; how to arrange things that more frequent traffic is handled by fewer filters? Filter caching also supports caching of 'ipsec'-action filters, hence, also supports IP security-based VPN. Why not just re-order the filters, perhaps dynamically, depending on the relative frequency of various IP packets? The problem with this approach is that the order is specified by the customer, based on their ideas of relative packet frequency, and more importantly, on the relative overlap of the filters themselves. The filter order effects the result. Consider two filters; filter A denies all FTP traffic and filter B permits all traffic between node 1.2.3.4 5.6.7.8. Now consider an FTP packet between 1.2.3.4 5.6.7.8 it will be permitted or denied depending on which of these two filters it encounters first. Which is the behavior that the customer wants? Answer; its the behavior the results from the order in which the customer specified the two filters. So, the system cannot re-order the filters, based on traffic frequency (or other criteria), because it may directly contradict the effect the customer wants. (There are other basic problems with this approach, which are not elaborated here.)

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Page 1 of 3

A method to cache packet filters to improve filtering performance

   The IP protocol is the network layer (OSI layer 3) in the TCP/IP protocol stack. IP packet filtering works at this layer to allow the expression and processing of IP filter rules (filter rules). These filter rules are widely used to allow certain packets to continue their normal processing and to disallow other packets. A typical set of filter rules may number in the 100s. Since every packet that enters or leaves a system must be processed by the current set of filter rules, the performance of the filtering function itself is important. Poor performance can affect all (TCP/IP) network activity for a system adversely.

A given IP packet is processed by 'checking' it against each filter rule, in turn. (The filter rules are an ordered set.) The first filter rule which 'matches' the packet is used to determine the packet disposition (typically, 'permit' (allow it to continue), 'deny' (immediate discard of the packet) or 'ipsec' (handle the packet via the correct IP Security policy)). Hence, a given packet is typically checked against a subset of the all the existing filter rules. Ideally, a higher percentage of the traffic that passes through a given physical interface, with a given set of filter rules, is handled by one of the first few filters. So, the technical challenge can be stated as; how to arrange things that more frequent traffic is handled by fewer filters? Filter caching also supports caching of 'ipsec'-action filters, hence, also supports IP security-based VPN.

Why not just re-order the filters, perhaps dynamically, depending on the relative frequency of various IP packets? The problem with this approach is that the order is specified by the customer, based on their ideas of relative packet frequency, and more importantly, on the relative overlap of the filters themselves. The filter order effects the result. Consider two filters; filter A denies all FTP traffic and filter B permits all traffic between node 1.2.3.4 & 5.6.7.8. Now consider an FTP packet between
1.2.3.4 & 5.6.7.8 -- it will be permitted or denied depending on which of these two filters it encounters first. Which is the behavior that the customer wants? Answer; its the behavior the results from the order in which the customer specified the two filters. So, the system cannot re-order the filters, based on traffic frequency (or other criteria), because it may directly contradict the effect the customer wants. (There are other basic problems with this approach, which are not elaborated here.)

The approach disclosed has proven to be relatively simple, and effective in reducing filtering overhead, in typical networking situations. It relies on the fact that IP packets tend to occur (statistically) in groups or clusters. This is a side-effect of the way most higher level (layer 4 and up) protocol work; request-response pairs, and multiple pairs, occur in clusters within a relatively short period of t...