Method and arrangement for implementing ipsec policy management using filter code

[0001] The present invention relates to the field of executing a protocol for authenticating and encrypting / decrypting packetized digital information. [0002] The IP Security Protocol (IPSEC) has been standardized by the IETF (Internet Engineering Task Force) and adds security to the well-known and widely used IP protocol. It provides cryptographic authentication and confidentiality of traffic between two communication network nodes. It can be used in end-to-end mode, i.e., both directly between communication nodes or communication hosts, or in tunnel mode between firewalls or VPN (Virtual Private Network) devices. It is also possible to have an asymmetric connection with one host and the other firewall or VPN. [0003] IPSEC specifies a set of operations that perform packet-level authentication and encryption by adding a new protocol header to each packet. IPSEC authentication of a data packet is performed by calculating an authentication code over most of the data and headers of the data packet. The authorization code also relies on the private key, which only the communicating party knows. The authorization code is then stored in the packet and appropriately wrapped in a default header or trailer. [0004] The action performed on each packet is controlled by a policy that specifies which authentication and encryption method (collectively called translation) should be applied between each pair of communication hosts. Parameters that specify cryptographic algorithms, cryptographic keys, and other data regarding the secure processing of packets between two hosts or peers are called security associations. [0005] One policy typically has a set of selectors (IP source address, IP destination address, subnet, protocol, source port number, destination port number, etc.) that force the communication or pair of communication to which each rule applies. Represented as a set of policy rules that specify. Although multiple rules may be applied to a particular packet, one rule is explicitly selected for each received and outgoing packet, usually because the rules are in mutual order. [0006] The IPSEC standard and published embodiments present a data structure called a policy database, in which an array or table resides in memory and contains rules. The rules in the policy database are examined for each packet to be processed. FIG. 1 schematizes a known IPSEC embodiment 100, includes a policy database 101, and separates a secure intranet 102 from an internet network 103. For simplicity, consider a packet (outgoing packet) that flows in only one direction. The input packet 104 of FIG. 1 is data sent by a user in the internal network 102 to another user via the Internet, and includes data that requires authentication and encryption processing. In an IPSEC embodiment, the target input packet 105 is transformed into the target output packet 106 by examining the rules in the policy database 101. The converted output packet 107 is sent to the Internet and routinely routed to its legitimate receiving user. [0007] On the other hand, mechanisms for filtering IP packets have become available and have long been well known in the literature. For example, J. Mogul, R. Rashid, and M. Accetta "The Packet Filter: An Efficient Mechanism for User-Level Network Code" In Proc. 11th Symposium on Operating Systems Principles, pp 39-51, 1987, and Jeffrey Mogul "Using screend to implement IP / TCP security policies" Digital Network Systems Laboratory, NSL Network Note NN-16, July 1991 etc. A packet filter typically has a set of rules combined by a set of explicit or implicit logical operator sets. The job of a packet filter is to either allow or deny the next processing of a packet. [0008] The logical rules used in packet filters take the form of a simple comparison of each field in a data packet. A valid one is to evaluate Boolean algebra (logical, true value) expressions for such comparisons. Methods for evaluating such expressions have been well known in the mathematical literature for centuries. The machine-readable instruction set that performs the evaluation is traditionally called a filter code. FIG. 2 shows a packet filter 200 with a stored filter code 201. In the input packet 202, one packet is inspected at a time by the packet filter 200, and only the inspected packet is passed as an output packet 203, which generate a correct Boolean value when the logical rules of the filter code are applied. [0009] Individual descriptions (comparisons) of packet filter representations are typically in individual fields of a data packet, either in the original data packet format or from an extended format that makes it easier to access each field of the packet. Contains operands for access. How to access data structure fields in fixed and variable layout data structures, and how to pack or unpack data into structures, is known in standard programming languages such as Fortran, COBOL, and Pascal, and has been programmed since the 1960s. It has been commonly used as a technique. [0010] The idea of using Boolean expressions to carry out control and their use as tests are both very fundamental parts of all modern programming languages, the technique of which has been standard in programming since the 1950s and earlier. It was a method. [0011] Representing query and search specifications as a set of rules or constraints is a standard practice in databases, pattern matching, data processing, and artificial intelligence. There are several magazines, books, and conferences that deal with the efficient evaluation of several sets of rules for data samples. These standard techniques are applicable to many types of data packets, including packets in data networks. [0012] Another well-known technique is to translate programming language expressions such as Boolean expressions and conditions into intermediate languages for faster processing (eg, A. Aho, R. Sethi, J. Ullman "Compilers-Principles, Techniques, and Tools", Addison-Wesley, See 1986). Such an intermediate code may be, for example, in the form of a tree, tuple, or interpreted bytecode instruction. Such code can be configured in a variety of ways, including register-based, memory-based, or stack-based. Such code may or may not be able to perform memory allocation, memory management may be isolated allocations and free explicit types, or the runtime system may automatically manage memory through unnecessary parts cleanup. But it may be. Such code operations may be stateless between applications, as well as the well-known UNIX program grep and other similar programs in the 1960s and earlier (programs between individual intermediate language instructions). Some state is performed, such as the need for a counter). Also, the code, like the well-known UNIX program "passwd", many database programs, and similar applications in the 1960s and earlier, can execute states during invocations. This is a lot of Apple in the early 1980s It can also be self-modifying, as in II games and many older assembly language programs. In addition, it is possible to compile such intermediate representations into directly executable machine code for further optimization. All of the above are widely known in the field and have been taught in college programming language and compiler courses for decades. Also, recent well-known studies have shown how to compile an incremental program and how to compile the program part when it is needed for the first time. [0013] Real-time filtering of large numbers of data packets required optimization in the methods used to manipulate the data. As a result, standard programming language compilation techniques have been applied to interpret the logical representation of rule sets, resulting in intermediate code that can be evaluated faster than the original rule set. BSD 4.3 Special uses of these well-known methods used in operating systems are described in university operating system materials and have been available in sample sources accessible to students at many universities since at least 1991. .. [0014] Recently, a patent was filed for well-known methods of stateless filtering and stateful filtering, granting US Pat. No. 5,606,668. "Stateless filtering" is primarily a well-known BSD 4.3 packet filter (published by the University of California, Berkeley in 1991, for example, in the release of BSD 4.3 net2 for worldwide distribution without copyright royalties). Yes, "stateful filtering" is available from A. Aho, R. Sethi, and J. Ullman (1987, ibid.) Said on page 401, "This property allows the value of the local name to be retained for the duration of the procedure's activation, that is, when control returns to the procedure, of the local name. The value is the same as the value when control was previously terminated. " The book was perhaps the most popular teaching material in college compiler courses from the late 1980s to the early 1990s. The idea itself dates back decades. [0015] A known IPSEC run requires a policy database check for each packet transmitted during the IPSEC run. Execution of a high-speed VPN (Virtual Private Network) requires, for example, processing of tens of thousands of packets per second. The processing overhead of looking up policy rules from the database for such packets immediately becomes a performance bottleneck. [0016] Packets arriving at network devices that perform the IPSEC method can be classified into regular packets and non-regular packets. The differences between the two are described in detail below. The present invention is to classify and organize the following tasks as appropriate. --Creating and maintaining a policy database, --Compile the filter code that should be applied to the packet based on the information in the policy database, --To use compiled filter code to separate non-regular packets from regular packets and potentially process the regular packets. --Consists of creating new pieces of compiled filter code as a potential response to the generation of each non-regular packet. [0017] The novel features of the present invention are specifically described in the appended claims. However, the invention itself will be best understood from the following description using the specific embodiments shown in the accompanying drawings with respect to its configuration, method of operation, additional objects and advantages. [0018] The device or process used to perform packet translation by the IPSEC method in a network device is commonly referred to as the "IPSEC packet processing engine" or "IPSEC engine" for short. According to the present invention, operations performed on incoming and / or outgoing packets are generally represented by some filter code means, whereas a request for a filter code in an IPSEC policy application is a simple packet described in the prior art. It's much more complicated than the filtering case. Known packet filters simply classify incoming packets into acceptable and unacceptable packets. The IPSEC engine needs to handle security policies, which invoke security associations to translate between incoming and outgoing packets. In addition, the IPSEC engine needs to handle the generation and termination of security associations and examine the foreign key manager. [0019] In the present invention, the compiled filter code forms the core of the control logic of the IPSEC engine. The filter code controls the processing of incoming and outgoing packets, controls the translation application applied to the data packet, and makes policy decisions about packets that should be dropped or passed without being translated. The filter code communicates with another policy manager that makes the actual policy decisions and produces new compiled filter code as needed. The need for newly compiled filter code potentially arises each time the IPSEC engine receives a packet that cannot be processed by the existing compiled filter code. The policy manager then executes the policy on the packet that caused the "trouble" and another similar packet. [0020] The compiled filter code acts as a cache for recent policy decisions, and any new decisions refer to the more general policy manager code. This reveals the difference between regular and non-regular packets. That is, a regular packet is sufficiently similar to any packet processed earlier that the IPSEC engine can apply the compiled filter code. Since non-regular packets are the first type to arrive at the IPSEC engine, the compiled filter code does not contain enough information to handle it, and as a result the Policy Manager is investigated and new policy decisions are made. Need to do. This policy decision becomes part of the compiled filter code. The present invention makes processing large amounts of data extremely efficient, yet allows sufficient flexibility of sophisticated user mode policy managers with arbitrary key management protocols, which is not feasible with known packet filters. Enables other features. The filter code also plays an important role in making the system safe and robust. That is, the filter code can often drop invalid or unacceptable packets very quickly and ignore them without looking at the policy manager. This is a countermeasure against resource exhaustion attacks. The filter code also tightly controls the conversion application, thereby preventing resource attacks due to nested encryption. [0021] [0021] An additional feature that enhances robustness is that the filter code is designed to always exit, no matter how the bad filter code is created. This feature makes the filter code particularly suitable for running in operating system kernel environments that require the highest performance. The detailed procedure for reliable termination is described in detail below. [0022] The components of the IPSEC Execution 300 according to the first embodiment of the present invention are outlined in FIG. The IPSEC engine 301 interfaces with the TCP / IP stack and / or network adapter commonly represented by block 302, where it passes IP packets to the IPSEC engine for IPSEC processing Packet interceptor 303 (as described above). Known) is used. The IPSEC engine 301 performs packet-per-packet processing, such as selecting and applying cryptographic transformations on packets as commonly described in known IPSEC literature. It also includes the filter coding mechanism 304 described in the present invention. Another policy manager 305 maintains the entire policy database 306 for acceptable communication and required authentication, and makes policy decisions on how to handle each packet. The key manager block 307 is another functional entity that communicates with the policy manager 305 and performs the actual key exchange required for the IPSEC authentication and / or encryption / decryption process. The key manager block 307 may use any protocol known per se, such as the ISAKMP / Oakley protocol, in its operation. Here, ISAKMP means the Internet Security Association Key Management Protocol. [0023] Different sections of the block diagram in Figure 3 require different performance. Packet interceptor 303 potentially monitors any packet in the network, including both IP packets and packets by other protocols. This requires that the IP packet be separated from other packets and passed to the IPSEC engine 301 at the highest packet rate it supports. The IPSEC engine 301 is typically required to monitor any IP packet and process it at the highest packet rate that supports these packets. Both the packet interceptor 303 and the IPSEC engine 301 are typically present in the operating system kernel 308 of a computerized network device in which the IPSEC execution 300 takes place. This minimizes communication costs. [0024] Policy manager 305 and key manager block 307 handle tasks that take longer to complete than the operations of blocks 303 and 301, which process at maximum speed. A typical inspection of policy database 306 by Policy Manager 305 may involve examining hundreds of individual rules and requires communication with an external host (not shown) to request the appropriate policy. There are also cases. The key exchange performed by key manager block 307 is often longer than policy database checking, in some cases longer than a few seconds. Since Policy Manager 305 and Key Manager Block 307 do not have very well defined resource requirements, it is preferable to run them as user mode processes in user mode process space 309 of the network device. [0025] Communication between a kernel-mode process and a user-mode process on a general-purpose computer is quite time consuming because it involves a data copy and substantial overhead for each message passed. Therefore, it is desired to reduce such communication volume. In the embodiment of the invention shown in FIG. 3, it means reducing the traffic between the IPSEC engine 301 and the policy manager 305. The filter coding mechanism 304 is provided for this purpose. This is because once a policy decision is saved in a filter code format compiled into a filter code mechanism, regular packets that can be processed by that filter code will no longer have messages forwarded between the IPSEC engine 301 and the policy manager 305. Because. [0026] It is possible, and sometimes desirable, to run the IPSEC engine in user mode instead of the operating system kernel. However, since response time requests differ between the IPSEC engine and the policy manager, it is also desirable to run them in separate threads or processes. The communication overhead of these is more or less the same as running the IPSEC engine in the operating system kernel. [0027] What is important for the system according to the present invention to work properly is that the division of work is clearly defined between the IPSEC engine and the policy manager. All packet processing that needs to be performed independently for each data packet is placed on the side of the IPSEC engine. When a non-regular packet is input to the IPSEC engine, the policy manager is referred to for policy decisions during its processing. The policy manager sends information to the IPSEC engine to allow the IPSEC engine to make similar decisions on subsequent regular packets on behalf of the policy manager. This continues until the policy manager sends new information to the IPSEC engine or any of the information is finished. For example, in a typical TCP / IP session, the first packet in each direction is a non-regular packet, which is passed to the policy manager. The policy manager then inspects the packet and determines its policy rules. A typical policy involves processing all packets in a TCP / IP session equally, so that the Policy Manager recognizes subsequent packets belonging to the same TCP / IP session as regular packets. It sends acceptable information to the IPSEC engine, which processes the packet. Both routine policy decisions for subsequent regular packets and their processing (eg encryption) are done by the IPSEC engine. The IPSEC engine translates packets using cryptographic keys and other data received from or through the policy manager from the key manager block. [0028] In addition to routine policy decisions, there are also actions that need to be taken on a packet-by-packet basis. For example, a security association may have a limited lifetime defined by the amount of data transmitted using that security association, which must record the amount of data already transmitted. , Transmission means that the process of establishing a new security association must be initiated after it has been dropped or the lifetime has expired. Data transmission statistics need to be updated on a packet-by-packet basis. Preferably, all these actions are performed by the IPSEC engine. [0029] There are two types of information that Policy Manager sends to the IPSEC engine. That is, the security association parameters and the compiled filter code. Security association parameters are the information needed to apply an IPSEC translation (eg, AH or ESP) to a packet. This parameter includes an encryption key, an authentication key, an initialization vector, an anti-response counter, tunnel information, and any other data needed to parameterize the transformation. Compiled filter code, on the other hand, is executable (or interpretable) information that represents some aspect of a security policy. [0030] Figure 4 shows in tabular form the key data items that should be stored in the Security Association. Cell 401 contains a selector that forces a security association. Cell 402 identifies the transformation to be applied to the packet belonging to the security association, and cell 403 contains the key material required for the transformation. Cell 404 contains anti-response data for transmission and cell 405 indicates the number of bytes transmitted. Cell 406 includes the security association expiration time and data transfer limits. [0031] Security association parameters usually need to be stored separately in the IPSEC engine for each security association, as each security association has a different encryption and authentication key. On the other hand, the filter code is usually stored separately in each network interface by attaching another code to the incoming packet and the outgoing packet. The reason is that by storing the code separately for each interface, it is unlikely that a hostile attacker will pretend that the packet came from a different interface than it really is. In addition, this shortens the code path in the filter code and speeds up execution. [0032] The information in the IPSEC engine actually acts as a cache for the information stored in Policy Manager. In other words, the policy manager has authoritative information about active security associations. It can send any of its data to the IPSEC engine and create a filter code at its discretion, in which packets for security associations are processed, and other infrequently used associations. Packets for are passed to the policy manager. As a result, the policy manager can install the filter code and association required for the packet in the IPSEC engine before reprocessing the packet. This allows fixed memory allocation in the IPSEC engine, thereby disabling resource exhaustion attacks on the operating system kernel. The filter code can also cache the fact that it rejects certain types of packets and shortcuts unacceptable packet processing. [0033] A simple embodiment of the method according to the present invention is shown in FIG. 5 as a flowchart. Blocks 501 and 502 correspond to the operation of packet interceptor 303 in FIG. That is, only IP packets can reach the IPSEC engine. Blocks 503 to 507 describe the operations performed by the IPSEC engine. At block 503, the IPSEC engine applies the previously saved filter code. Applying the filter code in block 503 may include performing packet translation, which is not claimed by the present invention. During the application of the filter code, the information stored in the IPSEC engine is also checked for validity until the expiration of the security association's lifetime. If the packet is a regular packet, the IPSEC engine knows whether it is better to drop the packet according to block 504 or accept it according to block 505. If accepted, the accepted packet is output according to block 506. If the application of the filter code involves translating the packet or otherwise processing the packet, block 506 corresponds to the output operation of the processed packet. If the answer in block 505 is no, the packet is a non-regular packet and is forwarded to the policy manager for inspection according to block 507 and further for policy rule determination according to block 508. The resulting new policy decision is stored in block 509 in the form of filter code compiled into the IPSEC engine, and its operation continues from block 503. Packets destined for blocks 508 and 509 become regular packets because the newly stored and compiled filter code contains information about how the packets should be processed. [0034] The policy manager may also process the received non-regular packet as an alternative packet responsible for compiling the new filter code and communicating with its IPSEC engine. The policy manager designer decides for himself what kind of non-regular packets are worth compiling the new filter code, what kind of packets are most advantageous for the policy manager to process, and so on. You may. In addition, the policy manager may process the non-regular packets it receives, compile new filter code, and transmit it to the IPSEC engine for similar packet processing thereafter. This is especially useful if the last alternate packet received is a key management packet. [0035] As mentioned earlier, it is most advantageous for the filter code to be stored within the operating system kernel. It consists of simple actions that can be performed quickly. For example, the filter code behavior compares one field in the packet header with a known value, branches it based on the result of the comparison, selects the best value from multiple choices, and applies the transformation to the packet. It involves dropping the packet, passing the packet in its current form, and passing it to the policy manager for further consideration. The filter code according to the present invention can therefore be said to be a generalization of the traditional idea of evaluating Boolean expressions. [0036] The filter code in the preferred embodiment of the present invention has some useful features. That is, --It is a linear bytecode, which means that it can be easily stored and cycled in a memory buffer or array. --All the jumpers in the bytecode are positive, which means that the filter code always goes to the end in any case. Making the interpreter extremely robust is easy. --There is no loop in the filter code. For example, if the conversions have to be done twice inside each other, a separate filter code is created to handle the tolerances after the first conversion. This will prevent resource exhaustion attacks due to multi-layered encryption using the same security association. [0037] There is also a situation that it is desirable to process the packet in a fragmented form. For example, if a packet must be tunneled during tunnel mode conversion (AH or ESP), instead of reassembling the packet and then performing the conversion, instead tunnel it separately for each fragment. Can be desirable. [0038] The filter code in the IPSEC engine can also be used for this purpose. The filter code can be applied to this fragment as soon as the first fragment of the packet is received. If a whole packet is needed, a special filter code instruction can be used to interrupt the process. This instruction can be used in the code path of a filter code that actually requires an entire packet. A code path that can process individual fragments (for example, by tunneling each fragment and letting it pass unmodified or dropped) does not include this instruction and is always the first fragment. It only accesses the part of the packet header that is guaranteed to fit. The information is then saved outside the filter code so that other fragments of the same packet are processed in the same way as the first fragment. [0039] The filter code described here can also be compiled into machine code that can be executed directly by the policy manager, thereby sending the actual executable processor instructions to the IPSEC engine. [0040] Many methods of optimizing executable programs are well known in the programming language and compiler literature, and apply to the filter code of the present invention as well as to other representational programs. , I didn't explain here. The method of creating intermediate code from a set of rules is also widely developed in the literature and is well known to those skilled in the art. [0041] It is well known to those skilled in the art that the present invention can be realized in a completely different form from that shown in FIG. 3 without changing its main contents. For example, it is possible to implement the IPSEC engine and policy manager in a mixed manner in the same module, or to build the policy manager on top of the key manager. [0042] Although the present invention has been described above in the context of the IPSEC protocol, it is also applicable to other cryptographic security protocols that decrypt data at the packet level. In that case, of course, all IPSEC-related definitions in the text must be changed to the corresponding definitions in the relevant security protocol. [0043] Figures 6a and 6b show a data processing system 600 and a gateway device 650 that can be used to put the invention into practice. The system 600 of FIG. 6a has a TCP / IP adapter 601 for connecting to network 602. The microprocessor 603 uses the TCP / IP adapter 601 to send and receive information over network 602. The microprocessor 603 has a core memory 604 for storing the operating system kernel in use and a separate storage device 605 for executing larger user mode processes. The memory blocks 604 and 605 may be part of a single memory circuit. Alternatively, at least a portion of one and / or the other memory block may be located on the same chip as the microprocessor 603. The non-volatile mass memory 606 is also built in to store programs and data. Given the configuration in Figure 3, the packet interceptor and IPSEC engine are in core memory 604 along with the rest of the operating system kernel, and the policy manager and key manager in Figure 3 are the storage devices needed to operate. Use 605. [0044] The gateway device 650 is similar to the data processing system 600, except that it includes two network adapters 651 and 652-one for internal network 653 connections and one for general purpose data transfer network 654 connections. .. The gateway device 650 is used to perform IPSEC security functions that protect the premises network 653 from the attack factors that occur on the general purpose data transfer network 654. [0045] The devices in FIGS. 6a and 6b are, of course, merely illustrated as examples and are not intended to limit the invention. The data processing system 600 and the gateway device 650 may include components other than those shown in FIGS. 6a and 6b. [Simple explanation of drawings] FIG. 1 shows a known IPSEC execution. FIG. 2 shows a known packet filter. FIG. 3 shows an advantageous embodiment of the present invention. FIG. 4 shows details of information stored in accordance with the present invention. FIG. 5 is a flowchart representation of the method according to the present invention. FIG. 6a shows some embodiments of the present invention. FIG. 6b shows some embodiments of the present invention.