MXPA98000356A - Cache of session and method of storage of rules in high speed memory, for a dinam filter - Google Patents

Abstract

The present invention relates to a cache for use with a network filter that receives, stores and ejects local rule bases dynamically. The cache stores a rule that is derived from a rule base in the filter. The cache rule is associated in the cache with a rule base flag that shows which rule base the cache rule is derived from, and the rule base version number that indicates the version of the rule base from which the cache rule derives . When the filter receives a received packet. If that rule is not found, the filter rule base is found, and an applicable rule is carried out and copied to the cache together with a rule base indicator and version number. If a cache rule is found, it is implemented if its version number corresponds to the version number of the rule base from which it is derived. Otherwise, the cache rule eliminates. The cache provides an efficient way to accurately implement the rules of a dynamic rule base without having to search the entire rule base for each packet

Description

jf ^ SESSION CACHE AND METHOD OF STORAGE OF RULES IN HIGH-SPEED MEMORY, FOR TJN DYNAMIC FILTER Field of the Invention This invention relates to security in information systems, particularly to a dynamic filter whose bases of local rules change frequently and more particularly to a fast storage memory or session rules cache, which effectively eliminates redundant search of rule bases in f said dynamic filter. Background of the Invention A security measure in common information systems that regulates the flow of information between two automated information systems (AIS = Automated Information System), is a filter. Here, the term "AIS" refers to a computer, computer network, computer network, or any sub-set thereof. A computer with a network address is known as a "guest". A guest can be a computer with either a fixed or temporary network address. A host with its own rules (known as local rule base) to regulate the flow of information is called a "pair" information in a certain AIS flows in discrete quantum numbers called "packets". Each package in certain AIS has a head and a load. The head includes package identification data. An example of packet identification data is a REF identification number: 26414 circuit that occurs in packets that circulate in a circuit switched network. Another example of packet identification data is a 5-tupia consisting of a source network address and destination address, a source port and a destination port, and a protocol identifier. The 5-tuple occurs in packets that circulate in a switched network of packets without connection. According to the invention in the co-pending patent application of the US. Serial No., with J title "System and Method for Providing Peer Level Access Control 0 on a Network" (System and method to provide access control at the peer level in a network) filed on the same date as this request, a dynamic filter loads and stores a Local peer rule base, when the peer is authenticated, and eliminates (or "expels") the rule base, when the peer loses authentication. 5 The filter is placed between the pair and another AIS, so that packets circulating between the pair and the AIS pass through the filter. The filter receives a packet and then looks for rules (usually in bases of global and local rules) that correspond to the package. A rule includes a key and an action. The key identifies which packages the rule applies to, based on the package identification data of each package.

The action is usually either PASS or REMOVE (DROP) meaning that the packet is either sent to its intended destination or otherwise removed. If a corresponding rule 5 is found, the action predetermined by the corresponding rule applies to the packet. One of the novel features of the dynamic filter is the ability to allow frequent changes in its local rules bases. A filter in a typical configuration is illustrated in Figure 1. A corporate network 10 may wish to provide access for peers A 11, B 12 and C 13 to Internet 14, but may wish to limit the access that Internet guests have to G 15 , H 16 ^ and I 17 have the corporate network, which may contain trade secrets and property information. The corporate network 10 places a filter 18 at the interface between the corporate network 10 and the Internet 14. A filter operates in a packet, upon receiving a packet and searching for a rule whose key corresponds to the identification data of the packet. If the received packet identification data corresponds to the key of a rule, then the action of the rule is carried out in the packet. In one mode, the filter stores rules that take the form of a 5-tupia, similar in structure to a packet header and an action that is either PASS (Pass) or RETIRE (DROP). The 5-tuple is advantageous to use because it allows the filter to distinguish packets not only based on source and destination but in the particular process with which the packet is involved. This is because several well-known processes (file transfer protocol, email, etc.) use standard port numbers that are recognizable by the filter. In this way, according to this mode, a filter can advantageously enforce a security policy which, for example allows files to be transferred from guest A to guest B, but prevents exchange email between the same two guests. An example of a rule base for the corporate network 10 having pairs A 11, B 12 and C 13 connected through the filter 18 to Internet 14, with hosts G 15, H 16 and I «17 is as follows: 0 DESTINATION SOURCE PROTOCOL ACTION Address, Port, Address, Port A, 21 G, 32 4 PASS A, 22 H, 19 3 RETIRE G, 11 A, 64 4 RETIRE 5 C, 9 I, 23 4 PASS This rule base is defined by the network system administrator according to the security requirements of the guests in the network. When a packet arrives at the filter, the filter determines 0 if the 5-packet tupia corresponds to any 5-tupia of rules. Here, the 5-tuple of rules is the key to rules. If there is a correspondence, the filter carries out the corresponding rule action, either PASS (PASS) or REMOVE (DROP). A filter generally has a predefined rule for 5 transactions that are not explicitly specified in the base of M rules. In this way, if there are no corresponding rules in the rule base, the packet is compared with the predefined rule.

If there is correspondence, then the predefined action takes place, which is usually to REMOVE (DROP) the package. If there is not correspondence with the predefined rule, then an error message is generated. In a modality, the predefined rule can be structured in such a way that all the packets correspond to the predefined rule, so that no error message is ever generated. By passing and selectively withdrawing packages between pairs and guests, the filter regulates the flow of information to and from AIS, which is said to be "behind" or "protected by" the filter. In Figure 1, the corporate network 10 is behind the filter 18. A traditional filter is only able to load and store rules through the intervention of an administrator system, a slow and problematic process. Undoubtedly, the system administrator in general must code by hand rules ^ P in a specific format for the filter platform. These rules are based on a security policy promulgated by the AIS protected. Therefore, an additional rule base is inflexible and can not easily adjust the changing security needs of the protected AIS. This inflexibility often requires bases of rules that are too broad for a given application. Without the possibility of easy updates, it is simpler to manage global rules that apply to all AIS after a filter in "3-ja" time to load rules that apply to specific guests In this case, all the AIS after the filter must adapt to the strictest security requirements of any AIS , resulting in excessively respective filtering.Even when formulating rules to apply to individual guests behind a wall of fire, this level of access control must be insufficient.An example of this situation occurs for Internet service providers (ISP = Internet Service Provider.) An ISP has subscribers that are generally self-supporting personal computers that have a modem.The ISP has one or more guests, each guest connected to the Internet has a set of Internet Protocol (IP = Internet Protocol) addresses. a subscriber dials an ISP guest (called a point-of-presence or POP), the POP assigns the subscriber a temporary IP address from your set of IP addresses. This temporary address generally corresponds to the subscriber who calls only for a simple connectivity session. A future session will likely result in another IP address that is assigned to the subscriber. This is problematic because rules are based on parts about the destination addresses and network source. In this way, known filters can not effectively control access to subscribers because their IP addresses change on a per-session basis. wm The dynamic filter described in the co-pending patent application of the U.S.A. Do not . serial, with the title "System and Method for Providing Peer Level Access Control on a? etwork" (System and method for providing access control at the peer level in a network) and filed on the same date as this request, remedies this deficiency by providing a system and method by which the rules of a subscriber can be loaded dynamically in the filter, when the guest is authenticated and expelled when the guest is no longer authenticated. While the rules are stored in the dynamic filter, the rules correspond to the temporary IP address of the subscriber and can thus be made. The dynamic filter has even more application because it can easily and dynamically change the rules in the filter for any pair, including a pair with a fixed IP address, not just for an ISP subscriber. Therefore, the dynamic filter provides better access control that can be tailored to the security needs of a specific pair and easily adjusts changes to those security needs. In this way, the novel utility of a dynamic filter derives from its ability to adjust and implement frequently changing local rule bases. An example modality of a dynamic filter operates upon receiving a packet and searching a pre-global rule base for corresponding rules. If no corresponding global rules r Am are found, a local rule base is searched using hash tables or arbitrary choice keys for corresponding local rules. If no corresponding local rules are found, then a global post-rules base is searched for corresponding rules. If no corresponding global parameters are found, then a pre-defined rule applies if it corresponds to the package. If the pre-defined rule does not correspond to the packet, then an error condition is generated. When any corresponding rule is found, and the action of the rule is REMOVE (DROP), the packet is removed and no more rules are searched. Searching the rules bases for corresponding rules, consumes both time and processor power. The hash tables for the local rule base in the dynamic filter improve the efficiency of the search process substantially. However, the dynamic filter must perform a hash function and perform a search of the rule bases for each packet that receives the filter. This involves substantial and unnecessary redundancy because all packets in a particular message usually have the same 5- tuple. For example, suppose data file 5 is decomposed into 320 packets for transmission from host A to host port A 20, through host port A 20 to host B through host port B 21 using the f protocol X. The head for each of the 320 packets will include the 5-tuple: A, 20, B, 21, X When the first of these packets arrives at the dynamic filter, the filter searches for the rules bases for the corresponding rules and apply them When the next package arrives, it carries out the same search again, finds the corresponding rules and applies them. A known solution to this problem is to keep a short list (known as a "cache") of rules for recently processed packets that have been derived from the filter rule base. Each rule in the cache stores a cache entry comprising a key (such as a 5-tuple) and action derived from a full-scale search of filter rule bases, for the first packet received in a given message.

When a packet is received, the cache is first searched for a corresponding entry (ie for an entry whose key corresponds to the received packet identification data).

This is more efficient than looking up the rule bases for subsequent packages in the same message that has the same key. If a cache entry corresponds, the action of the entry is carried out on the package without having to search for the rule bases. In other words, subsequent packets essentially benefit from the search performed for the first packet in the message. This saves processor time and increases filter performance. It should be noted that this known high-speed memory storage technique is designed for traditional static filters, with rule bases that are fixed and do not change. This technique can not be used effectively with a cache for a dynamic filter whose local rule bases change frequently. This is because this known ß technique does not provide a means to track and ensure the validity or currency of a cache entry. In other words, a rule from which an entry in a dynamic filter is derived can change frequently. Known high-speed memory (cache) storage techniques can not ensure that out-of-date or out-of-date entries do not apply to packages. Traditionally, filter caches are completely emptied each time there is a rare change in the underlying rule base, and it is subsequently rebuilt according to the new rule bases, as packets are received and filtered. This is inefficient because the cache is downloaded even if the vast majority of cache rules not affected by the rule change and are still valid, and it is only acceptable because these rule changes occur so infrequently in traditional static filters. Emptying a cache for a dynamic filter every time the rule bases change would be unacceptably inefficient J | because they change the bases of local rules so frequently. A known cache implemented in a dynamic filter would have to be reconstructed so often that it would achieve few, if any, advantages in filter efficiency. SUMMARY OF THE INVENTION The present invention referred to as a "session cache" tracks the versions of cache rules and versions of dynamic filter rules in such a way that updated non-Wß cache rules are detected, deleted from memory ("eject"). ") and 0 replace when requested and before being applied to a package, while rules not affected by a cache in a local rule base are left intact in the cache. Each rule in the session cache called a session entry is derived from the results of a search of the base 5 of dynamic filter rules used to determine the action to be taken with respect to a given packet. For example, the results of a rule base search may indicate that for a packet with a certain key (for example 5-tupia) the RETIRE action (DROP) is going to be carried out. The 5-tupia then 0 is added to the cache as part of a session entry called a "session key". The RETIRE action (DROP) is stored as the action corresponding to the session key. The local rule base in a dynamic filter changes as local rules are added from the pairs to and expel from the filter. When the local rule base from which a session entry has been derived is changed, the session entry derived from the rule base of the expelled filter is not updated. The present invention advantageously provides a version tracking system that verifies the topicality of each session entry corresponding to the identification data of a package (for example a 5-packet tupia) against the current version of the rules base of the package. which is derived before it is applied to the package. If the session entry is to update, the rule applies. If the session entry is not up to date, it is ejected and the filter rule bases are searched for corresponding rules. The result of the search is stored in the session cache, replacing the outdated rule. In accordance with the present invention, each local filter rule base has a version number that is incremented each time it is loaded. Each session entry has a session entry version number, which is copied from the local filter rule base version number each time the session entry is derived. According to the present invention, when the 5-tupia of a packet corresponds to the session key of a session entry, the session entry version number is checked against the version number of the local rule base of the session. which rules are derived. If they are the same, the session entry is current, and its action is applied 9- to the package. If they do not correspond, the session entry is not updated and is expelled from the session cache. The rules bases are then searched for rules that correspond to the package. The present invention is further provided with a rule flag for each session entry, which identifies the filter rule bases from which the session entry is derived. The rule flag may indicate that the entry of mf session was derived from a global pre-rule base or a base from 0 global post-rules filter. Similarly, to the local rule base version number, each global rule base has a version number, preferably a date stamp or date stamp-stopwatch derived when the global rule base is loaded. When the version number of a session entry does not correspond to the global rule base from which the entry was derived, the entire session cache is deleted ("dragged"). Because global rule bases are so static, a session cache is rarely downloaded due to a change in a global rule base. 0 If the rule flag indicates that the session entry is derived from a local rule base, each of which comprises a base of pair and pair output rules, then the session version number is checked against the appropriate local rule base version number. If the 5 relevant version numbers correspond, the session entry is applied. If a session version number does not correspond to the local rule base version number, the session entry is ejected and a new search is performed. According to the present invention, they are ejected and advantageously and efficiently replace session cache rules not updated, only when they are requested (that is, when they are found to correspond to a 5-pack tupia) and they are found to be outdated. This is much more efficient than the known process of downloading the entire cache, 0 each time any change in the rule bases is made.

In accordance with the present invention, a change in the local rule base effects only the corresponding rules in the session cache. Session tickets not affected by a change based on local rules are still valid and are advantageously withdrawn. Therefore, they do not require derivation as with known caches, thus saving processor time and filter resources. This is critical for a dynamic filter whose local rule bases change frequently. In summary, each session entry comprises a session key 0, an action, session version number for each local rule base from which a session entry is derived and a rule flag. According to the present invention, the session cache is searched when the filter receives a packet for a session entry whose 5-tuple corresponds to that of the packet.

If a corresponding session entry is found, the rule flag identifies the rule bases from which the session entry is derived. If the flag identifies local rule bases, the appropriate local rule base version number 5 is checked against the session entry version number. If the session version number corresponds to the relevant rule base version number, then the session entry action is performed. If the session version number does not correspond to the relevant rule base version number, then the session entry is ejected from the session cache and the filter rule bases are searched for corresponding rules. Likewise, if no corresponding session key is found, then the rules bases are searched for corresponding rules. The default action for the packet resulting from the rule base search is then added to the session cache together with the session key (equal to the 5-pack tupia), rule base version numbers and a flag of updated rule. Together, these elements comprise a session entry. Finally, the default action takes place in the package. In this way, valid cache rules are not downloaded in accordance with the present invention, saving processor time and improving filter efficiency. Brief Description of the Drawings Figure 1 shows a prior art modality of a filter between two networks. Figure 2 shows a session cache according to the present invention. Figure 3 shows a session entry according to the present invention. Figure 4 shows a version table for base filter rules according to the present invention. Detailed Description As illustrated in Figure 2, the session cache 21 according to the present invention contains at least one session entry 22. Each session entry 22 comprises a session key 23, a session action 24, and a session entry version number 25 that corresponds to the local rule base version number from which the session entry is derived. Another embodiment of the present invention may include a session entry version number corresponding to the global rule base from which the entry is derived. Each session entry also has a rule flag 26 indicating which filter rule bases the session entry was derived from. For example, the rules flag indicates whether the session entry is derived from the global pre-rule base, a particular local rule base, or a global post-rule base.

A modality of the structure The data of the rules flag is as follows: pf_from-rulebase_flags. { 5 flag from_global_pre_rulebase flag from_global_post_rulebase flag from-source_peer_rulebase flag from-destination_j? Eer_rulebase 10 One mode of a session key data structure is illustrated as follows: pf_session_key. { ip_address source_address 15 ip_address dest_address. ¡Ip_port sourcejport ^ ip_port destjport ip__protocol protocol} 20 One modality of the data structure for a session entry is as follows: pf_session. { pf_sesslon_key // this is the 5-tupia 25 pf-session action // PASS (PASS) or RETIRE (DROP) f pf_from_rulebase_flag_rulebase_flags // whose rule base entry is derived integer global_pre_rulebase- ersion // input version numbers session 0 integer global_jpost_rulebase-integer version arc_peer_rulebase_version integer dst_peer_rulebase-version} Here, the local rule base version numbers are logically divided according to the present invention into torque input and pair output version numbers. The pf_session structure describes a single entry in the session cache. A session cache consists of a set of pf_session structures depending on the number of active sessions 0 at that particular time. A session entry mode according to the present invention is illustrated in Figure 3. The session entry 311, has a session key 312, which is a 5-tupia comprising a network source address 313, a port of source 5 314, a network destination address 315, a destination port? 316, and a protocol identifier 317. The session entry 311 also has a RETIRE session action (DROP) 318, a session entry version number 319. The session entry rule flag 325 has a single bit for a base of pre-global rules 321, one bit for a base of access rules of parts 22, one bit for a base of rules of output of pair 323 and one bit for a base of global post-rules 324. A "0"indicates that a session entry is not derived from the rule base Relevant H, while a "1" indicates that it is derived from that 0 basis of rules. According to the present invention, when a packet is received, the session cache is searched for a session entry whose 5-tupia corresponds to that of the packet. If a corresponding rule is found, then the rule flag 5 is used to identify which filter rule bases the corresponding session entry was derived from. A pseudo-code mode of this process is illustrated as follows: stagel_processing () 0. { Extract the IP header information from the package as described by the pf_session_key structure. Obtain the index in the pf_session_hash_table by arbitrary choice key calculation. ? ß Search for a match for the content of pf_session_key with any of the pf_session_key entries. located in this particular sector of hash storage or particular arbitrary choice. 5 if (version numbers & corresponding in the corresponding rule bases match those in pf_session) * 0 pf_session. _., _ _ _ «__ return} yes (version numbers & & corresponding are not equal) 5. { deletes the session entry from the session_cache. } Proceed to stage 2} 0 Here, stagel_processing () refers to the method used when there is a session entry whose session key corresponds to the package 5-tupia. Stage 2 is carried out when said corresponding session entry is not found. ? ß In the present embodiment illustrated in Figure 3, a package with the 5-tupia A, 20, B, 21, 3 is found to correspond. to the session entry. Rule flag 325 (0100) indicates that the rule was derived from a base of pair entry rules. In accordance with the present invention, rule base version tables are maintained in the filter. A modality of a data structure for this table is as follows: Index-Hash Session Pointer # l pf_session * 0 2 pf_session * 3 pf_session * 4 pf_session * The pf_session: hash_table describes all active sessions in the session cache. A hash function is evaluated in structure 5 pf_session to produce an index value for the table. A pointer to the pf_session structure is then placed in the pf_session_hash_table set in the index location. A modality of this version table for a local rule base is illustrated in Figure 4 as 41. When a local 0 rule base is loaded into the filter, a h hash function is performed in the network address of torque. In Figure 4, h (A) 42 represents the result of the hash function h that is carried out in a pair with the network address A. Then, a version number is associated with the network address of pair of 5 key calculation by arbitrary choice. One modality | preferred version number is a date stamp with time, generated when the local rule base was loaded. In this way, in Figure 4, the version number 0991532 (43) which means that the rule base is loaded on September 9 at 3:32 P.M. it is associated with h (A). Each time a rule base for a given pair is loaded, the version number in the version table is updated with a new date-time stamp. This way when pair A is not authenticated anymore, version 0991532 of its local rule base will be expelled from the filter. When it is subsequently authenticated again, and its local rule base is loaded, a new version number corresponding to the time and date in which it was loaded will be associated with h (A) 42. If the corresponding session entry is derived of the global pre-rule base or the global post-rule base, then the session entry version number is compared with the rule base version number in the version table. If the two are different, the session cache is downloaded. This does not significantly impair the efficiency of the present invention, because the bases of global rules are relatively static, they are changed infrequently, especially in comparison with the local rules bases, that is to say, the rules of torque entry and pair exit rules. If the flag indicates that the corresponding session entry either, is derived from the rule bases of W? Torque entry or torque output, then the corresponding session entry version numbers are checked against the relevant local rule base version number that is stored in the version table. In accordance with the present invention, it is possible to determine from which basis of rules the session entry is derived, simply by knowing the rule flag and the 5-tupia of the corresponding package. This is illustrated in the case of this ^ modality as follows. 0 The rule flag 322 indicates that the session entry of the present mode is derived for a base of pair access rules. This indicates that the applicable filter rule regulates the flow of information directed to the protected pair. From the corresponding 5-packet tuple, it can be seen that the corresponding packet 5 is addressed to a pair with a network address B. In this way, the session entry is derived from a pair access or pair entry rule. , from the local rule base of the pair B. A hash function is carried out in the network destination address of the packet, giving h (B). The version number at 0 which h (B) points to in the version table is 2. This corresponds to the stored pair input version number as the access pair entry version number 319 (Figure 3). Therefore, the REMOVE (DROP) action of the session entry illustrated in Figure 3 is carried out in the packet.

If any session entry version number does not correspond to its corresponding local filter rule version number, then the session entry is out of date and is expelled from the cache and the filter rule bases are searched. For example, suppose that the rule flag in the mode illustrated in Figure 3 was 0010, indicating that the session entry is derived from the peer output rule base, which regulates the flow of packets from a protected pair. Therefore, the packet network source address indicates the pair whose local rule base is used to derive the session entry. The hash function h is carried out in the network source address of package A and the version table is verified for the version number to which h (A) signal. As illustrated in Figure 3, h (A) corresponds to version number 3. Assuming that the local rule base version number stored in the session entry illustrated in Figure 3 was 1. This indicates that the base of A pair rules has been updated twice since the session entry in Figure 3 was derived from the rule base. Therefore, the rule is not up to date and is expelled. Then, the bases of filter rules are searched. The filter rule bases are searched if a packet is received and no corresponding session entry is found in the session cache, or if a corresponding rule is found to be out of date and thrown out. In a filter mode, you first search for a global pre-rule base. If a corresponding rule is found, the packet session key and the rule action are added to the session cache, the session entry flag is adjusted, the version number is updated, and the rule action 5 is brought to cape. If no corresponding rule is found, the rules for torque and torque output are searched. If at least one corresponding torque and / or torque output rule is found whose action is REMOVE (DROP), ^ the package session key and the REMOVE (DROP) action stored as a session entry along with the rule base version numbers in the session cache. The rule flag is also updated. If all the corresponding torque and torque output input rules are PASA (PASS), then the session key of packet and PASA action (PASS) are stored as a session entry along with the version number of rule bases in the session cache. The rule flag is also updated. If no corresponding pair torque and torque output rules are found, then the global post-rule base 20 is searched. If a corresponding rule is found, then the packet session key and the corresponding rule action are stored and a session entry in the session cache together with the rule base version number. The rule flag is also updated.

A predefined rule is part of the global post-rule base. If other rules do not correspond to the package, then the package is checked against the pre-defined rule. If they correspond, the predefined rule action takes place in the package. If they do not correspond, an error condition is generated. A pseudo code mode to find the rule base is illustrated as follows: stage2_processing (pf_session key * pkt). { g l or b a l _ p r e _ r u l e = search - rulebase (pf_global_pre_rulebase, pkt) if (global_pre_rule). { update_session_entry (pkt) perform_action (global_pre_rule- >; action) return} source_has_indx = hash (pkt-> source_address) dest_hash_indx = hash (pkt-> dest_address) source_jpeer = find_peer (source_hash_indx) dest_peer = find_peer (dest_hash-indx) if (source_peer). { source_peer_rule = search_rulebase (source_peer- Y > out_rulebase, pkt). { if (dest_peer). { 5 dest_peer_rule = search_rulebase (dest_peer-> in_rulebase, pkt). { if (source_peer_rule & source_peer_rule-> action ==? DROP) 0. { update-session_entry (pkt) perform_action (source_peer_rule -> action) return} 5 if (dest_peer_rule &&dest_peer_rule - &action == DROP). { update_session_entry (pkt) perform_action (dest _peer_rule -> action) return 0} if (source_peer rule && dest_peer_rule && source_peer_rule - > action PASS &&dest_peer_rule - &action == PASS) 5. { update_session_entry (pkt) perf orm_action (source_jpeer_rule -> action) return} if (source_peer. rule && dest_peer_rule && source_peer_rule - > action == PASS) update-session_entry (pkt) perform_action (source_peer_rule -> action) return} if (source_peer_rule && dest_peer_rule & dest_ peer_rule - > action == PASS) < update_session_entry (pkt) perform action (dest_peer_rule -> action) return} g l or b a l _ p or s _ r u l e search_rulebase (pf_global_jpre_rulebase, pkt) if (global_post_rule). { update_session_entry (pkt) perform_action (global_post_rule-> action) T return} else { 5 / * ERROR * / The session cache with version tracking according to the present invention, advantageously retains rules * Valid in the session cache that are not affected by changes in the r local rule bases stored in the dynamic filter. This reduces the load on the filter processor, increases performance and improves efficiency. It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention. Having described the invention as above, property is claimed as contained in the following:

Claims (4)

1. AND CLAIMS 1.- A cache for a dynamic filter, the dynamic filter includes a rule base that has at least one associated rule base version number, the cache comprises a storage medium that has a cache entry saved. has a cache key, a cache action, and a cache version number, the cache entry is derived from a rule in a rule base of the dynamic filter.
2. 2. The cache according to claim 1, characterized in that the cache is a network source address, a network destination address, a source port, a destination port and a protocol identifier.
3. 3. The cache according to claim 1, characterized in that the cache key is a circuit identifier.
4. 4. The cache according to claim 1, characterized in that the cache action is either PASS (PASS) or RETIRE (DROP). 5. - The cache according to claim 1, characterized in that the cache entry also includes a rule base indicator, which indicates which rule base the session entry is derived from. 6. - A method for providing pair level access control in a network carrying information packets 5 having packet identification data, the method uses, «> 31? ^ a dynamic filter that has a cache that stores a cache entry that has a cache key, a cache version number, a cache action, and a rule base flag, the cache entry is derived from at least one rule that it has a rule key 5 and a rule action, at least in a rule base, the method is characterized in that it comprises: a) receiving a packet; (b) searching the cache to identify a cache entry gr having a cache key corresponding to the identification data of the received packet; (c) if a corresponding 0 cache entry is identified and if the rule base indicator of the cache entry indicates that the cache entry is derived from a rule base that has a rule base version number associated with it: (i) determine whether the cache entry version number corresponds to the version number of the rule base from which the cache entry is derived. 7. The method according to claim 6, characterized in that step (c) further comprises the step of: (ii) carrying out the cache action of the corresponding cache entry if the cache entry number 0 corresponds to the version number of the rule base from which the cache entry was derived. 8. The method according to claim 6, characterized in that step (c) further comprises the step of: (ii) if the version number of the cache entry does not correspond to the version number of the rule base of which is derived from the 'f 32 j ^^ cache entry, search at least one filter rule base to identify a corresponding rule, which corresponds to the identification data of the received packet; (iii) if a corresponding rule is identified, carry out the action of 5 the corresponding rule; (iv) storing a cache entry derived from the corresponding rule, the cache entry comprises the identification data of the received packet, the action predetermined by the corresponding rule and which is carried out in the packet in stage (iii), and a rule base indicator 10 which indicates the rule base of the corresponding rule from which the cache entry was derived. 9. The method according to claim 8, characterized in that it also comprises the step of: (v) if a rule base version number is associated with the base of 15 rules of the corresponding rule, store the base version number of rules, as the cache entry version number of the cache entry of stage (iv). 10. The method according to claim 6, characterized in that it also comprises the step of: (ii) expelling 0 the corresponding cache entry from the cache, if the version number of the cache entry does not correspond to the base version number of rules from the rule base of the rule from which the cache entry was derived, as shown by the rule base indicator. i,. > 33 j ^^ 11. The method according to claim 6, characterized in that if a corresponding cache entry is identified and if the rule base indicator shows that the cache entry is derived from a rule of a global rule base 5 , further comprising the steps of: (i) determining whether the cache entry version number corresponds to the version number of the global rule base of the global rule base, ^ from which rule the cache entry is derived; (ii) delete all the ^ cache entries from the cache if the input version number 0 cache does not correspond to the global rule base version number. 12. The method according to claim 11, characterized in that it further comprises the step of: (iii) carrying out the cache action of the cache entry if the number of 5 cache entry version corresponds to the base version number rules global 13.- A cache for a dynamic filter, the dynamic filter includes a rule in a rule base, the cache has a cache entry, the cache is characterized in that it comprises: a) 0 means to receive a packet having identification data; (b) means for searching the cache to identify a cache entry corresponding to the identification data of the received packet; (c) means for carrying out an action in the received packet as prescribed by a corresponding cache entry 5 of step b, whose version number corresponds to the number of $ > version of the rule base from which the cache entry is derived; (d) means to carry out an action on the received packet as prescribed by a rule corresponding to the identification data of the received packet, if there is no corresponding cache entry or if the version number of the cache entry does not correspond to the version number of the rule base from which the rule was derived. 14. - The cache according to claim 13, characterized in that it also comprises: (e) means for ejecting 10 a cache entry whose version number does not correspond to the version number of the rule base from which the entry is derived. 15. The cache according to claim 13, characterized in that it also comprises: (e) means to store a cache entry, the cache entry comprises the data of 15 identification of the received packet, the action is carried out in the packet in step (d), and a rule base indicator that * w indicates which rule base the cache entry is derived from. 16. The cache according to claim 15, characterized in that it also comprises: (f) means for storing 20 a rule base version number as the cache entry version number of the cache entry of stage (e), if the rule base version number is associated with the rule base of the rule of which the entry cache is derived. 17. - Computer-readable medium that has a Computer program therein encoded, characterized in that # comprises: (a) a first portion of the medium has a first program segment for receiving a packet having identification data on a computer network; (b) a second portion of the medium and has a second program segment for searching a cache to identify a cache entry having a cache key corresponding to the identification data of the received packet; (c) a third portion of the medium having a third program segment, to determine whether the cache entry version number of a corresponding cache entry 0 identified by the second portion corresponds to the version number of the rule base of which the cache entry is derived. 18. The cache according to claim 17, characterized in that it further comprises: a fourth portion of the medium that has a fourth program segment to carry out the action of a corresponding cache entry, whose cache key corresponds to the data of identification of the received packet and whose cache entry version number corresponds to the version number of the rule base from which the 0 cache entry is derived. 19. The cache according to claim 17, characterized in that it also comprises: (e) a fifth portion of the medium having a fifth program segment, for searching a filter rule base to identify a rule having a rule key corresponding to the identification data of the packet received if no corresponding cache entry is identified or if the cache entry version number of a corresponding cache entry does not correspond to the version number of the rule base from which the cache entry is derived. 20. The cache according to claim 19, characterized in that it further comprises: (f) a sixth portion of the medium having a sixth program segment to carry out the action of a corresponding rule identified by the fifth segment of the medium. 21. The cache according to claim 20, characterized in that it further comprises: (g) a seventh portion of the medium has a seventh program segment for storing a cache entry comprising the identification data of the received packet, the action prescribed by a corresponding rule that is carried out by a sixth portion of the medium, and a rule base indicator that indicates that the rule base of the corresponding rule from which the cache entry is derived. 22. The cache according to claim 21, characterized in that it further comprises: (g) an eighth portion of the medium that has an eighth program segment to eliminate a cache entry from the cache, when the cache entry version number does not corresponds to the version number of the rule base from which the cache entry is derived. i. '' '- > SUMMARY OF THE INVENTION The present invention relates to a cache for use with a network filter that receives, stores and expels local rule bases, dynamically. the cache stores a rule that is derived from a rule base in the filter. The cache rule is associated in the cache with a rule base indicator that shows which rule base the cache rule is derived from, and the base version number rules that indicate the version of the rule base from which it is derived the cache rule. When the filter receives a packet, the cache is searched for by a rule applicable to a received packet. If that rule is not found, the filter rule base is found, and an applicable rule is carried out and copied to the cache together with a rule base flag and version number. If a cache rule is found, it is implemented if its version number corresponds to the version number of the rule base from which it is derived. Otherwise, the cache rule is deleted. The cache provides an efficient way to accurately implement the rules of a dynamic rule base without having to search the entire rule base for each packet.