JP4262284B2 - Packet filtering system and method - Google Patents

Description

(Priority claim)
The present invention relates to US Provisional Patent Application No. 06 / 296,763 and claims priority to US Provisional Patent Application No. 06 / 296,763. This teaching is incorporated herein in its entirety.

(Copyright claim)
This application contains material that is subject to copyright protection. The copyright owner has no objection to facsimile copying by anyone with a patent disclosure if it appears in the file or record of the Patent and Trademark Office, but otherwise retains all copyrights.

(Field of Invention)
The present invention relates to packet filtering. More specifically, it uses a small, binary 5-tuple optimized sequence that displays filter rules to achieve space-efficient packet filtering, and can be dynamically and extensible when a triggering event occurs To support correct processing behavior and use of procedure tables.

(Background of the Invention)
Packet filtering is a function that provides performance for various network systems, network access control or firewall type. Packet filtering achieves the above firewall types by examining each network packet sent or received from a network device or node in a communication network and making decisions based on such examination. To do.

  Most packet filters of the prior art allow network administrators, system administrators, network device owners, etc. to define specific filtering rules via an operational graphical user interface (GUI). However, most packet filtering simply allows the user to specify whether the packet is discarded or can continue based on such a determination. These are called “deny” and “allow” actions or rules. The above approach to this technology, such as the system taught by Edward Boden et al., US Pat. No. 6,057,028 (the '228 patent issued on Jan. 30, 2001), logs specific information based on packet data. Increased the number of available actions to include actions.

Allow, deny and log filter rules are most commonly entered as an ordered list of rules, processed sequentially from top to bottom. Order is specified by the rule creator, often a system or network administrator. Each rule allows or denies certain types of network traffic. In a more secure packet filter, packet processing continues through all the rules until the packet is explicitly allowed, explicitly denied, or there are no rules when the packet is denied. In general, a fairly large and complex set of filter rules must be written for each protocol that a network device is to support.
US Pat. No. 6,182,228 B1 specification

(Summary of the Invention)
Accordingly, the present invention relates to a compact and extensible packet filtering system and method that substantially eliminates one or more of the problems due to limitations and disadvantages of the related art.

  Accordingly, it is an object of the present invention to provide an improved packet filtering system and method.

  It is a further object of the present invention to provide a space efficient packet filtering system and method.

  It is also an object of the present invention to provide a dynamic and scalable filtering system and method.

  Additional features and benefits of the present invention are set forth in the description that follows and is in part apparent from the description, and can be obtained by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and the appended drawings hereof.

  In accordance with embodiments of the present invention, systems and methods are provided for filtering packets at or above the network protocol software stack level of a network adapter (or data link). Filtering of network adapter level packets or packets above the network adapter level is accomplished by processing filter rule statements and procedural statements entered by the user in a rule file or rule database (collectively "rule files"). Is done. Such a rule file can be converted into a 5-tuple filtering rule and procedure table that can be loaded into a filter interpreter. The filter interpreter may then interpret and resolve user generated filtering rules for each packet received by the network adapter, either through this adapter or through low level network software.

  For small, networking devices, including but not limited to personal digital assistants (PDAs), cell phones, pagers, watches, cameras, etc. (collectively “network devices”), the filtering action is Space as efficiently as possible due to the limited processing power and amount of memory available, and because of the potentially large number of filter rules that must be processed for each packet It is preferable to be efficient. Unnecessarily large filter files or excessively time consuming filtering rules can interfere with other uses of the device and can cause throughput or other undesirable performance issues. Thus, unlike prior art systems where each packet flowing through the system must be processed by all filter rules, the present invention intelligently packets only the necessary rules once the packet is identified. Applies to

  While some of the prior art (such as the '228 patent) has created a system based on filtering rules having about 6 or more parameters, the present invention implements a 5-tuple definition. This reduction results in a higher level of flexibility, increased performance, and reduced storage requirements over the prior art. Such improvements can be particularly beneficial when the present invention is used on computing devices with only limited storage and processing capabilities.

Other features and advantages of the present invention will be apparent from the following detailed description of the invention in conjunction with the accompanying drawings. The foregoing general description and the following detailed description are exemplary and exemplary.

  The accompanying drawings are included to provide a further understanding of the invention, are incorporated in and constitute a part of this specification, and illustrate the principles of the invention. Embodiments of the present invention are illustrated with explanations that are useful to do so.

(Detailed description of preferred embodiments)
Reference will now be made in detail to the preferred embodiments of the invention, examples of which are illustrated in the accompanying drawings. Generation and testing of very compact packet filters that can be performed within the network software stack, separation and expansion of processing options after identifying packets without burdening all packet filters with unnecessary overhead, and packet filters Dynamic process changes when identifying specific packets without changing or adding filter rules is within the benefits of the present invention over the prior art.

  FIG. 1 illustrates the key elements of a preferred embodiment of the present invention, and the logical relationships and data flow between such elements. The embodiment shown in FIG. 1 includes filter variants, procedures and other rule statements for 5-tuple playback 122 and procedure display 124 and interpretation of 5-tuple 122 as network packets via network software 132 and 136. 100 related.

  Filters, procedures, and other rule statements 100 are processed by the filter compiler 102. The filter compiler 102 may be implemented using code similar to the pseudo code presented in Table 1 and Table 2 below. Table 1 provides sample pseudo code for processing filter statements, and Table 2 provides sample pseudo code for processing procedural statements. The filter compiler 102 outputs a rules file 106 and a procedure file 108 that contains a binary representation of the rules to be applied by the filter. The rules file 106 may take the form of Java (R) byte code, machine language, or other machine readable code. Procedure file 108 contains a binary representation of the policy applied by the filter. The procedure file 108 is preferably a combination of a table of procedure indications and a set of procedure functions compiled into Java (R) bytecode, machine language or other machine-read code. The rules file 106 and procedure file 108 can be copied over a range of network devices, for each network adapter to which the rules should be applied.

  Either the network adapter device driver 130 or the low level network protocol 132 or both are initialized and executed by the filter loader 120. Execution pseudo code for the sample filter loader 120 is provided in Table 3 and Table 4 below. Table 3 provides pseudo code for loading the procedure table, and Table 4 provides pseudo code for loading the 5-tuple.

Filter statement processing / * Process filter statement to generate 5-tuple * /
Create a 5-tuple buffer to hold the configured 5-tuple;
Set 'nexttuplepointer' at the beginning of the 5-tuple buffer;
Set 'nextpointer' at the beginning of the 5-tuple buffer;
while (more sentences exist in the file) {
if (the rule sentence is a filter sentence) {
for (each logical condition in a sentence) {
Construct a 5-tuple for the condition;
Copy to 'nexttuplepointer' in a 5-tuple buffer;
}
increment nextpointer;
for (each 5 tuple generated for this filter rule) {
Set 'rule offset' 5-tuple element =
the address of the nextpointer-5 tuple;
}
Construct the default last 5 tuples;
Copy to 'nexttuplepointer' in a 5-tuple buffer;
Increment the 5-tuple buffer 'nexttuplepointer';
}
increment nextpointer;
for (each 5 tuple generated for this filter rule) {
Set "Rule Offset" 5-tuple element =
the address of the nextpointer-5 tuple;
Increment the 5-tuple buffer nexttuplepointer ';
}
else {/ * process other sentences as usual * /}
}
Write a procedure file for each network adapter
Table 1
Filter statement processing / * Process procedure statement to generate procedure table * /
Create a procedure buffer to hold the configured procedure table;
Set 'nextprocpointer' at the beginning of the procedure buffer;
while (more procedural statements exist in the file) {
if (the rule sentence is a procedure sentence) {
Configure a procedure index entry;
Copy to the 'nextprocpointer' in the procedure buffer;
Increment the 'nextprocpointer' of the procedure buffer;
else {/ * process other sentences as usual * /}
}
Write a rules file for each network adapter
Table 2
Either the network adapter device driver 130 or the low level network protocol 132 or both are initialized and executed by the filter loader 120. Execution pseudo code for the sample filter loader 120 is provided below in Tables 3 and 4. Table 3 provides pseudo code for loading the procedure table, and Table 4 provides pseudo code for loading the 5-tuple.

Load procedure table / * Load and disassemble procedure index * /
Load procedure function library;
Read the procedure file;
Load the procedure table into the filter interpreter;
for (each procedure index entry) {
Load an index entry with a pointer to a procedure function;
}
Table 3
Load 5-tuple table / * Load 5-tuple table * /
Read the rules file;
Load the rules into the filter interpreter;
Table 4
In the preferred embodiment, execution or initialization of the filter loader 120 also allows the filter interpreter 134 to load the 5-tuple rule 122 and the procedure table 124. The 5-tuple 122, once loaded, allows a network packet to enter the system via a device driver 130 to one or more network adapters (not shown) and away from it to one or more network adapters. Can be used by the filter interpreter 134. Pseudo code that implements the process by which 5 tuples can be interpreted by the filter interpreter 134 is provided in Table 5 below.
Interpret 5 tuples / * Return code to caller to indicate code that interprets 5 tuples allow, deny, or deny actions for each packet * /
Get a 5-tuple pointer to the first 5-tuple;
while (TRUE) {
IF (Length == 0) {/ * Assume matching-last 5 tuples * /
Call procedure function based on procedure index element in policy return code = 5 tuples;
Return (procedure return code)
/ * The caller does the actual allow, deny, or deny action
Do * /
}
Extract bit offset from data offset; / * can be 0 * /
Clear bit offset in data offset;
Add a data offset to the packet pointer;
if (Extract (length, packet data in packet pointer, bit offset) == data value) {/ * data from packet and test
Extract*/
/ * Length is byte size or bit size
/ * Alignment * /
/ * Determine actions to align * /
if Next Flag == Does the SET && / * rule have more than 5 tuples? * /
Procedure index == 0 {/ * AND with the next 5 tuples? * /
Set a 5-tuple pointer to the next 5-tuple; / * continue the rule * /
} Else {/ * Call procedure * /
Call procedure function based on procedure index element with procedure return code = 5 tuples;
Return (procedure return code)
/ * The caller does the actual allow, deny, or deny action
Do * /
}
} Else {/ * No match * /
/ * Determining actions taken for inconsistencies * /
if Next Flag == SET / * Does the rule have more than 5 tuples? *
/
if procedure index == 0 {/ * logical AND * /
Add rule offset to 5-tuple pointer; / * Skip the rest of the rule * /
else / * logical OR * / with next 5 tuples
Set the 5-tuple pointer to the next 5-tuple; / * continue the rule * /
else / * end of rule * /
Add a rule offset to the 5-tuple pointer;
break; / * comes out during the loop * /
}
}
Table 5
The network adapter is typically built into the device or removably coupled to the device. Such network adapters include, but are not limited to, the Institute of Electrical and Electronics Engineers (IEEE) 802.3 or 802.5 standards, and the fiber-distributed-data interface (FDDI). Implement wireless frequency, optical, acoustic or magnetic inductive transmitters, including, but not limited to, wireless device types such as, including, but not limited to, 10Base-2, 100-Base-FX, 100Base-TX and others. It takes the form of wired devices such as 11 standards, including Bluetooth (Bluetooth) wireless communication standards and others. A network adapter typically communicates with the device in which it is installed or attached by presenting an interface data structure that the device has access to.

  A device developer or manufacturer can write the device driver code 130 so that it can typically operate with a certain set of commands, and a device with a given data structure uses a different set of commands and a different data structure. The network adapter can be effectively and efficiently communicated. The device driver code 130 always translates device commands and data structures into commands and data structures used by the network adapter (and vice versa). In most embodiments, the device driver code serves as an interface between a network adapter or other peripheral device attached to or incorporated in the device and the operating system that runs on the device. Data or commands received from or destined for the peripheral device (collectively “data”) are routed through the device driver so that the data can be converted to the required format. Although the above description details the use of explicit device driver code, it is important that the device interface with the network adapter even in such an environment where the device does not explicitly support the use of the device driver. It will be apparent to those skilled in the art that the enabling software or hardware is functionally equivalent to a device driver and can be replaced with a device driver without departing from the spirit or scope of the present invention.

  Currently, the filter interpreter 134 is preferably implemented as low as possible on the protocol stack and as close to the network adapter as possible. FIG. 1 illustrates one possible embodiment of the present invention with respect to device driver code 130 and low level network protocol software 132. In this embodiment, the filter interpreter 134 can communicate with one or more network adapters via the device driver code 130. In another embodiment shown in FIG. 2, filter interpreter 134 communicates with one or more network adapters via low-level network protocol software 132.

  As both FIG. 1 and FIG. 2 illustrate, the filter interpreter 134 routes any incoming packet to a low level network protocol 132 or higher level network such as TCP, UDP, NetBios, SPX, Bluetooth and others. Prior to passing to protocol 136, the filter rules shown as 5-tuple 122 and the procedure illustrated as procedure table and procedure function 124 are performed. Further, the embodiment illustrated in FIGS. 2 and 3 implements filter rules and procedures before the filter interpreter 134 passes any outgoing packets to the device driver code 130 or the low-level network protocol 132. Make it possible. In yet another embodiment, the filter interpreter 134 may block incoming network packets at one protocol stack level, preferably at a higher level, preferably near the network adapter, while outgoing packets. Is blocked to another protocol stack level. While the above description has focused primarily on implementing the filter interpreter 134 as close to the network adapter as possible, the filter interpreter 134 may be implemented in different ways without departing from the spirit or scope of the present invention. Can be implemented at the level.

  FIG. 3 illustrates a sample filter rule statement 100 entered by a network or system administrator and received by the filter compiler 102. Three example rules 140, 142 and 144 are shown. The first two rules 140 and 142 are rules that have been explicitly entered by the system administrator. In the preferred embodiment, the last rule 144, also called the “default negation” rule, is automatically generated by the filter compiler 102. Alternatively, a user interface that allows a system administrator, network administrator or other user to enter rules allows the user to enable or disable the inclusion of “default deny” rules. When such inclusion is disabled, the “Default Allow” rule can be replaced. When the “default negation” rule is used, the preferred approach to ordering the filter rule 146 is to write a rule that allows the desired or desired network traffic to continue. Any packet that does not match some rules that explicitly allow the packet to continue (such as rules 140 and 142) is discarded by the default negation rule 144.

The rule 140 of the filter set fs1 (Filter Set fs1) is: Procedure = Allow 150, Direction of the selector = ^* 152 ( ^* means “arbitrary”), Source address Source Addr = ^* 154, Destination address Dest Addr = ^* 156 and protocol Protocol = TCP158. The rule 142 of the filter set fs1 (Filter Set fs1) includes Procedure = Allow and Log 160, and Direction of the selector = ^* 162, source address SourceAddr = ^* 164, Dest Addr = ^* 166 and protocol Protocol = UCP168, port Port = (161, 162) 170 and destination port Dest Port = (161, 162) 172 are included. The n-rule 144 includes Procedure = Deny 180, selector Direction = ^* 182, Source Addr = ^* 184, Dest Addr = ^* 186 and protocol Protocol = TCP188. Although the example illustrated in FIG. 3 refers to specific field names, such field names are arbitrary and any or all fields or other transmitted with the packet orientation protocol supported by the device Those skilled in the art will appreciate that similar information may be included.

Rules 140, 142 and 144 are logically processed from top to bottom for each packet. Thus, if the packet satisfies all aspects described in a given rule, the appropriate procedural function is invoked as specified in the rule (block 150, 160 or 180 in FIG. 2). By way of example, without intending to limit the present invention, for rule 140, Procedure = Allow 150 may be interpreted as “call an Allow procedure function” that allows the packet to continue. If a given packet does not match the first rule 140, the packet is examined against the next rule 142. This process repeats until the last rule 144. When used, the default negation rule 144 matches any packet and calls Procedure = Deny 180 which means that the packet is processed by the negation procedure function and discarded (ie not allowed to continue). Composed.

  In the embodiment shown in FIG. 3, the first filter rule 140 allows all TCP / IP datagrams from any source to any destination. The second filter rule 142 allows UDP traffic if the source or destination port is 161 or 162. These are well-known ports for SNMP (Simple Network Management Protocol). The filter set name (“fs1”) is used at the beginning of the rule set via the NETWORK__INTERFACE statement to associate the filter rule set with a particular network adapter. For this sentence, one or more filter sets are associated with one or more network adapters. In the preferred embodiment, only the filter set associated with a network adapter is loaded into that network adapter by a filter loader. This means that each network adapter must have its own filter loader with its own separate copy of the file rules. While this increases the overall storage requirements, the implementation of a suitable binary rule produces a rule set that is small enough so as not to generally impose significant storage requirements on the device. Although the use of separate filter loaders and filter rules for each network adapter are currently preferred, the number of filter rules and filter loaders in memory at any time can be used without departing from the spirit or scope of the present invention. It will be apparent to those skilled in the art that this can be reduced through various techniques.

  Referring to FIG. 4, each 5-tuple logical structure includes a length 200, a procedure index 202, a rule offset 204, a data offset 206 and a value 208. Length 200 displays the length to be compared (eg, one octet, two octets, etc.) to be performed. The length 200 may also indicate an octet bit to be compared with the value 208, eg, a flag bit.

  Procedure index 202 is an index or pointer to a procedure table entry that points to a procedure table function that will be executed if the comparison is true. Table 6 below provides sample pseudo code that implements a procedural function.

テーブル６
テーブル６が示すように、全ての手順は、本発明の好適な実施形態において、パケットを許可し（Ａｌｌｏｗ）、否定し（Ｄｅｎｙ）、または拒絶する（Ｒｅｊｅｃｔ）ためにアクションコードを戻す。さらなるアクションコードおよび特定のパケット処理手順は、容易に、このスキームで実施される。好適な実施形態において、このようなさらなるパケット処理手順は、限定されるわけではないが、記録、サニタイジング（ｓａｎｉｔｉｚｉｎｇ）およびこれらの組み合わせを含み得る。好適な実施形態にて実施されるこのような手順の特定リストが、図５のパケット処理手順３４０〜３４８により、例示される。組み合わせ手順の例として、手順が規則の手順要素のＤＥＮＹ＿ＡＮＤ＿ＬＯＧである場合、フィルタリング処理の直接のユーザ可視性を提供するログエントリが作成され、パケットが否定される。

Table 6
As Table 6 shows, all procedures return an action code to allow (Deny) or reject (Reject) the packet in the preferred embodiment of the present invention. Further action codes and specific packet processing procedures are easily implemented in this scheme. In a preferred embodiment, such additional packet processing procedures may include, but are not limited to, recording, sanitizing, and combinations thereof. A specific list of such procedures implemented in the preferred embodiment is illustrated by the packet processing procedures 340-348 of FIG. As an example of a combination procedure, if the procedure is a rule procedure element DENY_AND_LOG, a log entry is created that provides direct user visibility of the filtering process and the packet is denied.

  Such a record may be useful if the log is used to debug, validate filter rules and detect attacks. In a preferred embodiment, the information contained in each log entry of an IP packet includes the procedure index element (ALLOW_AND_LOG, DENY_AND_LOG, etc.), packet direction (inward or outward), source and destination IP address, packet at offset Value of the source and destination ports, and information sufficient to identify the filter 5 tuple (such as the actual filter rule 5 tuple or the offset of the filter rule start position). Each logged and filtered protocol can use the extensible procedural architecture of the present invention to implement a unique log entry generator with any combination or format of fields and information available.

Rule offset 204 is a number that is a byte offset from the current 5-tuple for the next rule in the rule table. If the 5-tuple does not match the packet, the filter interpreter selects the next rule by adding the rule offset to the current 5-tuple address, except when a special flag called NEXT flag is set. If the 5-tuple does not match the packet, the NEXT flag is set, and the procedure index is valid, the filter interpreter adds the size of the current 5-tuple to the current 5-tuple address, thereby adding the next 5-tuple. Select. The filter compiler ensures that the rule offset is not zero. More specifically about the use of NEXT flag, when the NEXT flag for rule offset 204 is set, the filter interpreter steps into the next five tuples of the rule for comparison. If the NEXT flag is set and the procedure index is empty or null after the comparison is true, the result of the next comparison is ANDed with the current comparison. If the NEXT flag is set after the comparison is false and the Procedure Index is valid, the next comparison is ORed with the current comparison.

  Data offset 206 is a number that is an offset into the packet for the field in that packet that is examined by this 5-tuple. Data offsets allow the present invention to access any field or data position within a network protocol packet or other network transmission. By way of example, without intending to limit the present invention, the data offset 206 may be an octet offset or a combination of octet offsets and a bit offset within an octet. The filter compiler ensures that the most recent 5 tuple of the rule set contains a negative procedure index. Optionally, the filter compiler may generate the latest five tuples of the rule set that includes the allowed procedure index. Those skilled in the art will appreciate that data offsets can be modified directly during rule loading, or combined during processing for base packet offsets to employ rules for operating at various network stack levels. The The base packet offset changes depending on the network protocol level to which the filter rule is applied.

  The value 208 is the value that will be compared to the field in the packet accessed by the data offset 206. With respect to this 5-tuple element, the 5-tuple logical operation is expressed as "operand 1, equal ?, operand 2". Operand 1 is obtained from the packet data at data offset 206, and operand 2 is a 5-tuple element value 208. "Equal?" Says a test for equality. The 5-tuple can display expressions such as “number of source ports, equal ?, number of test ports”. Although an equality test is used as part of the preferred embodiment of the present invention, it will be apparent to those skilled in the art that other mathematical tests can be substituted without departing from the spirit or scope of the present invention.

  FIG. 5 illustrates a set of five tuples 220, 224, 226, 230, 232, 234 and 240 corresponding to the three filter rules 140, 142 and 144 of FIG. Table 7 presents another display of these five tuples. “NEXT +” refers to a set NEXT flag that is ANDed with a rule offset. Referring to FIG. 5, it corresponds to the NEXT flag in which “N” in blocks 274, 284, 294 and 304 is set.

テーブル７
全ての５タプルは、いくつかがヌル（バイナリ０）であり得るか、いくつかの他の未使用の値であり得る５つの要素を有する。

Table 7
All 5 tuples have 5 elements, some of which can be null (binary 0) or some other unused value.

  In table 7, procedure index 1 corresponds to procedure index 252 and procedure table entry 340 in FIG. 5, procedure index 2 corresponds to procedure index 312 and procedure table entry 342 in FIG. This corresponds to the procedure index 322 and the procedure table entry 342 in FIG.

Of course, the 5-tuple direct in-memory format does not include ")" or "", which is on a separate line and is a T ^* S8 bit octet of binary data. T is 5 tuples in this particular example, within 5 tuples of 8 bit octets, and S is the size. There is no efficient limit on the number of filter rules that can be defined by the user or the resulting size of 5 tuples (the total length in octets of 5 tuples 122).

  Table 72 and FIG. 5 do not show procedural decomposition. Each of the procedure values indicated by (252, 272, 282, 292, 302, 322) is actually an index or pointer to a table of address pointers to function entry points. The procedure function takes two independent variables, a pointer to the current 5-tuple containing their procedure index and a point for the packet, and returns a return code. The procedural function may cause the packet to be modified before returning.

  Referring to the example of FIG. 5, after interpretation of 5-tuple 220 for packet data matching the value 258, the independent variables for function Allow 340 are 220 (ie, a pointer to 5 tuple 220) and a pointer to the packet (not shown). including. It will be appreciated that additional independent variables or other independent variables may be provided without departing from the spirit or scope of the present invention. This architecture extends procedural function processing options, simplifies the use of the above functions 340-348 by the filter interpreter 134 of FIG. 1, and keeps the filter interpreter small.

In FIG. 5, the ellipses under the 5-tuple 234 are followed by any additional number of 5-tuples, indicating that these ellipsis correspond to the ellipsis under rule 142 of FIG. Thus, in FIG. 5, a 5-tuple display is provided for all rules shown in FIG. The correspondence between the filter statements 140, 142 and 144 and the 5-tuple of FIG. 5 is as follows. 142 corresponds to 224, 226, 230, 232, 234. 144 is 2
40.

  The values 9, 20, and 22 of the 5-tuple offset elements 256, 286, and 306, respectively, are octet data offsets into the IP datagram where the appropriate field is found. 9 corresponds (offset) to the protocol field of the IP diagram. Similarly, 20 corresponds to the IP source port, and 22 corresponds to the IP destination port. The 5-tuple value elements (blocks 258, 278, 288, 298, 308 and 318) are 6 (TCP), 20 (UDP), etc.

  In FIG. 5, box 348 also indicates that an additional optional procedural function follows. The size of the procedure table 260 or the number of procedure functions is not limited.

  While the invention has been described in detail with reference to specific embodiments thereof, those skilled in the art will recognize that various changes and modifications can be made without departing from the spirit and scope of the invention. Is clear. Thus, it is intended that the present invention include modifications and variations of this invention if they come within the scope of the following claims and their equivalents.

FIG. 1 is a flowchart illustrating a preferred data flow. FIG. 2 is a flowchart illustrating a preferred data flow. FIG. 3 is a set of sample filter rules. FIG. 4 is a block diagram illustrating a 5-tuple format according to a preferred embodiment of the present invention. FIG. 5 is a block diagram illustrating a five-tuple logical structure for the example set of FIG. 1 at the point following the loading step of FIG. 1, in accordance with a preferred embodiment of the present invention.

Claims (32)

A method of filtering packets at a network interface,
The method
(1) The length defined by the length value of the length field (200, 250, 270, 280, 290, 300, 310) of the filter document (198, 220, 224, 226, 230, 232, 234, 240) And the packet by the data offset value of the data offset field (206, 256, 276, 286, 296, 306, 316) of the filter document (198, 220, 224, 226, 230, 232, 234, 240). Using a first logic circuit to identify a portion of the packet having a starting position that is offset from the first byte of
The starting position is calculated by the first logic circuit by adding the data offset value of the data offset field of the filter document to the value of a packet pointer pointing to the packet to be filtered;
The end position is obtained by adding the data offset value of the data offset field of the filter document and the length value of the length field of the filter document to the value of the packet pointer. Calculated by the steps, and
(2) the value field (208, 258, 278, 288, 298, 308, 318) of the filter document (198, 220, 224, 226, 230, 232, 234, 240) and the identified portion of the packet And using a second logic circuit to perform a predetermined type of comparison specified by the network interface, the comparison starting at the start position and ending at the end position. Steps,
(3) If the result of the comparison is true, a predetermined procedural function (124, 340 to 348) for processing the packet is started using the third logic circuit according to a predetermined set of rules. A method comprising the steps of:   The method of claim 1, wherein the performing step occurs when the packet is being transferred between a network adapter device driver (130) and a low level network protocol (132).   The method of claim 1, wherein the performing step occurs when the packet is being transferred between a low level network protocol (132) and a high level network protocol (136).   The method of claim 1, wherein the comparison includes a comparison of whether both are equal. The filter document (100, 220-240) is one of a plurality of filter documents (100, 220-240) arranged in a sequence (146), the method comprising:
(4) If the comparison is false, the subsequent filter documents (198, 220, 224, 226, 230, 232, 234, 240) in the sequence (146) are used using the first logic circuit. The method of claim 1 further comprising the step of processing.   6. The method of claim 5, further comprising the step of automatically generating the last filter document (100, 220-240) in the sequence (146) by the first logic circuit.   The subsequent filter document (198, 220, 224, 226, 230, 232, 234, 240) is stored in the rule offset field (204) of the filter document (198, 220, 224, 226, 230, 232, 234, 240). 254, 274, 284, 294, 304, 314).   The method of claim 7, wherein the rule offset variable (204, 254, 274, 284, 294, 304, 314) is a predetermined number.   The method of claim 7, wherein the rule offset variable (204, 254, 274, 284, 294, 304, 314) is the total number of bytes in the filter document (100, 220-240).   The predetermined procedural function (124, 340-348) is associated with a corresponding procedural index field (202, 252, 272, 282, 292) of the filter document (198, 220, 224, 226, 230, 232, 234, 240). , 302, 312, 322). A system for filtering packets at a network interface, the system comprising:
The length defined by the length value in the length field (200, 250, 270, 280, 290, 300, 310) of the filter document (198, 220, 224, 226, 230, 232, 234, 240); The first of the packet by the data offset value in the data offset field (206, 256, 276, 286, 296, 306, 316) of the filter document (198, 220, 224, 226, 230, 232, 234, 240) A first logic circuit configured to identify a portion of the packet having a starting position offset from a byte;
The starting position is calculated by a first logic circuit by adding the data offset value of the data offset field of the filter document to the value of a packet pointer pointing to the packet to be filtered;
The end position is determined by the first logic circuit by adding the value of the packet pointer to the data offset value of the data offset field of the filter document and the length value of the length field of the filter document. A first logic circuit to be calculated;
For the value field (208, 258, 278, 288, 298, 308, 318) of the filter document (198, 220, 224, 226, 230, 232, 234, 240) and the identified portion of the packet A second logic circuit configured to perform a predetermined type of comparison specified by the network interface, the comparison starting at the start position and ending at the end position, The logic circuit of
If the result of the comparison is true, a third logic configured to activate a predetermined procedural function (124, 340-348) for processing the packet according to a predetermined set of rules. A system comprising a circuit and   The second logic circuit is further configured to perform the comparison when the packet is being transferred between a network adapter device driver (130) and a low level network protocol (132). The system according to claim 11.   The second logic circuit is further configured to perform the comparison when the packet is being transferred between a low level network protocol (132) and a high level network protocol (136). The system according to claim 11.   The system of claim 11, wherein the comparison includes a comparison of whether both are equal. The filter document (100, 220-240) is one of a plurality of filter documents (100, 220-240) arranged in the sequence (146);
12. If the comparison is false, the first logic circuit is further configured to process subsequent filter documents (100, 220-240) in the sequence (146). The system described. 16. The system of claim 15 , wherein the first logic circuit is further configured to generate a last filter document (100, 220-240) in the sequence (146). The subsequent filter document (100,220～240) is identified by the rule offset variable rules offset field of the filter document (204,254,274,284,294,304,314) of claim 15 system.   18. The system of claim 17, wherein the rule offset variable (204, 254, 274, 284, 294, 304, 314) is a predetermined number.   18. The system of claim 17, wherein the rule offset variable (204, 254, 274, 284, 294, 304, 314) is the total number of bytes in the filter document (100, 220-240).   The predetermined procedural function (124, 340-348) is associated with a corresponding procedural index field (202, 252, 272, 282, 292) of the filter document (198, 220, 224, 226, 230, 232, 234, 240). , 302, 312, 322).   (4) By processing a predetermined procedure document (100, 108) and the filter document (100, 140-144) during a single period when the fourth logic circuit is activated, the procedure document (100, 108) has a table format (124, 260) having a procedure index and the procedure function (124, 340-348), and the filter document (100, 140-144) has a corresponding procedure index. 8. The method of claim 7, further comprising the step of having a 5-tuple format (122, 198, 220-240) having (202, 252, 272, 282, 292, 302, 312, 322).   The method of claim 1, wherein the predetermined procedural function comprises a function configured to change a content of the packet.   The rule offset variable (204, 254, 274, 284, 294, 304, 314) is a predetermined number if the condition is false, and if the condition is true, the filter document ( 100. 220. The method of claim 7 equal to the total number of bytes in 220-240).   A fourth logic circuit, wherein the fourth logic circuit is a procedural document (100, 108) and the filter document (100) during a single period when the fourth logic circuit is activated. 140-144), the procedure document (100, 108) has a table format (124, 260) having a procedure index and the procedure function (124, 340-348), The filter document (100, 140-144) has a 5-tuple format (122, 198, 220-240) with a corresponding procedure index (202, 252, 272, 282, 292, 302, 312, 322), The system according to claim 15.   The system of claim 11, wherein the predetermined procedural function includes a function configured to change a content of the packet.   The rule offset variable (204, 254, 274, 284, 294, 304, 314) is a predetermined number if the condition is false, and if the condition is true, the filter document ( The system of claim 17, equal to the total number of bytes in 100, 220-240). The filter document further includes a rule offset field, the rule offset field including the following flags:
The performing step includes:
Obtaining a pointer to the packet;
Obtaining a tuple pointer to the filter document;
Setting the loop end flag to false;
If the length field of the filtered document pointed to by the tuple pointer is zero, executing the first procedure; and if the length field of the filtered document pointed to by the tuple pointer is non-zero The method of claim 21, further comprising: repeating the step of performing a second procedure in a loop until the loop end flag is true. The first procedure includes:
Invoking the procedure function for the procedure index of the filter document specified by the tuple pointer;
Passing the tuple pointer and packet pointer as parameters to the procedure function;
28. The method of claim 27, comprising setting the loop end flag to true. The second procedure is:
Calculating the start position by adding the data offset value of the data offset field of the filter document specified by the tuple pointer to the value of the packet pointer;
Add to the value of the packet pointer the data offset value of the data offset field of the filter document specified by the tuple pointer and the length value of the length field pointed to by the filter document specified by the tuple pointer Calculating the end position by:
Comparing the portion of the packet data with the value field of the filter document specified by the tuple pointer to start at the start position and end at the end position;
If the packet data comparison returns true,
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical AND relationship with the next filter document, the tuple pointer points to the next filter document; Or
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical OR relationship with the next filter document, it corresponds to the procedure index of the filter document specified by the tuple pointer. Calling the procedural function and passing the tuple pointer and the packet pointer as parameters to the procedural function, or
If the next flag and procedure index of the filter document specified by the tuple pointer indicates a lack of relationship with the next filter document, it corresponds to the procedure index of the filter document specified by the tuple pointer Executing the procedural function to perform and passing the tuple pointer and the packet pointer as parameters to the procedural function;
If the packet data comparison returns false,
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical AND relationship with the next filter document, the tuple pointer points to the filter document in the next rule. Or if the next flag and procedure index of the filter document specified by the tuple pointer indicates a lack of relationship with the next filter document, the tuple pointer indicates the filter document in the next rule. Or if the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical OR relationship with the next filter document, the tuple pointer 28. The method of claim 27, comprising: pointing to a filter document of: The filter document further includes a rule offset field, the rule offset field including the following flags:
The second logic circuit includes:
Obtaining a pointer to the packet;
Obtaining a tuple pointer to the filter document;
Setting the loop end flag to false;
If the length field of the filtered document pointed to by the tuple pointer is zero, executing the first procedure; and if the length field of the filtered document pointed to by the tuple pointer is non-zero 25. The system of claim 24, further comprising: performing the second procedure and repeating in a loop until the loop end flag is true. The first procedure includes:
Invoking the procedure function for the procedure index of the filter document specified by the tuple pointer;
Passing the tuple pointer and packet pointer as parameters to the procedure function;
31. The system of claim 30, comprising setting the loop end flag to true. The second procedure is:
Calculating the start position by adding the data offset value of the data offset field of the filter document specified by the tuple pointer to the value of the packet pointer;
The data offset value of the data offset field of the filter document specified by the tuple pointer and the length value of the length field pointed to by the filter document specified by the tuple pointer are added to the value of the packet pointer Calculating the end position by:
Comparing the portion of the packet data with the value field of the filter document specified by the tuple pointer to start at the start position and end at the end position;
If the packet data comparison returns true,
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical AND relationship with the next filter document, the tuple pointer points to the next filter document; Or
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical OR relationship with the next filter document, it corresponds to the procedure index of the filter document specified by the tuple pointer. Calling the procedural function and passing the tuple pointer and the packet pointer as parameters to the procedural function, or
If the next flag and procedure index of the filter document specified by the tuple pointer indicates a lack of relationship with the next filter document, it corresponds to the procedure index of the filter document specified by the tuple pointer Executing the procedural function to pass and passing the tuple pointer and the packet pointer as parameters to the procedural function;
If the packet data comparison returns false,
If the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical AND relationship with the next filter document, the tuple pointer points to the filter document in the next rule. Or if the next flag and procedure index of the filter document specified by the tuple pointer indicates a lack of relationship with the next filter document, the tuple pointer indicates the filter document in the next rule. Or if the next flag and procedure index of the filter document specified by the tuple pointer indicate a logical OR relationship with the next filter document, the tuple pointer 31. The system of claim 30, comprising: pointing to a filter document of:

Images