Patent Application
20050283604
The present invention relates to the field of computer network security. More specifically, the present invention relates to the configuration of security associations in a computer network.
A virtual private network (VPN) is a wide area network that connects private subscribers (such as employees of the same company) together using the public Internet as a transport medium, while ensuring that their traffic is not readable by the Internet at large. All of the data is encrypted to prevent others from reading it, and authentication measures ensure that only messages from authorized VPN users can be received.
Internet Protocol Security (IPsec) is a standard for security on the Internet that is commonly used to implement VPNs. IPsec (and other VPN standards) utilizes security associations in creating VPNs. These security associations, also known as tunnels, are typically negotiated by the end nodes before traffic is secured.
A security policy in a VPN is typically implemented using a series of rules. Each rule corresponds to a particular security policy. Table 1 below illustrates examples of VPN policies. In this table, rule 1 is a simple single source single designation rule, rule 2 is an application specific rule, rule 3 is a subnet rule, and rule 4 is a remote user specific rule.
In all the above cases, a single tunnel would be established for each rule according to the selectors specified. The tunnel is used to secure all traffic which satisfies the configured rule specification and thus multiple traffic streams are protected using the same encryption/decryption keys and algorithm negotiated during security association establishment. In the context of this document, the term “traffic stream” refers to similar traffic traveling between any particular source-destination pair.
There are many situations, however, where each traffic stream between two tunnel termination points (VPN gateway nodes) requires separate keys for protection. In a complex network system, a separate VPN tunnel between two VPN gateway nodes may be needed for each combination of <source IP, remote IP, upper layer protocol, source port, destination port/application>, also called a tuple. Having unshared security associations for each combination of tuple would provide enhanced security between two tunnel termination points.
Typically, there are two ways by which every traffic stream between two tunnel terminating nodes can be protected by its own security association with a distinct encryption/decryption key. One method is to configure a different rule for each traffic stream, which then requires the negotiation of a security association with unique encryption/decryption keys. Another method is to configure a single rule such that security associations are automatically negotiated for each of the unique traffic streams. Both of these solutions, however, create scalability problems in large networks. The number of tunnels required is equal to the number of traffic streams, which can be quite plentiful in full-fledged networks. In addition to the increased memory and processing requirements on the gateways, this also ties up network bandwidth with unneeded negotiation packets for multiple tunnels.
What is needed is a solution that provides granularity in the configuration of security associations, thus allowing for better control of the number of security associations established.
A solution is provided which eliminates the limitation of a single rule for multiple security associations by providing granularity in the configuration of selector fields for better control of the number of security associations established. This may be accomplished by using a selector field added to each rule if one wants to utilize multiple security associations for the rule. The selector field may include a mask which can be used to determine which threads require a new security association and which can utilize an existing security association. This solution provides significant flexibility in configuring Virtual Private Network rules by enabling the administrator to select appropriate selector fields for clustering of traffic streams through a single security association.
The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate one or more embodiments of the present invention and, together with the detailed description, serve to explain the principles and implementations of the invention.
In the drawings:
Embodiments of the present invention are described herein in the context of a system of computers, servers, and software. Those of ordinary skill in the art will realize that the following detailed description of the present invention is illustrative only and is not intended to be in any way limiting. Other embodiments of the present invention will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the present invention as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts.
In the interest of clarity, not all of the routine features of the implementations described herein are shown and described. It will, of course, be appreciated that in the development of any such actual implementation, numerous implementation-specific decisions must be made in order to achieve the developer's specific goals, such as compliance with application- and business-related constraints, and that these specific goals will vary from one implementation to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming, but would nevertheless be a routine undertaking of engineering for those of ordinary skill in the art having the benefit of this disclosure.
In accordance with the present invention, the components, process steps, and/or data structures may be implemented using various types of operating systems, computing platforms, computer programs, and/or general purpose machines. In addition, those of ordinary skill in the art will recognize that devices of a less general purpose nature, such as hardwired devices, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herein.
The present invention eliminates the limitation of a single rule for multiple security associations by providing granularity in the configuration of selector fields for better control of the number of security associations established. This solution provides significant flexibility in configuring VPN rules by enabling the administrator to select appropriate selector fields for clustering of traffic streams through a single security association.
In an embodiment of the present invention, an additional attribute is added to each rule. This may be known as the selector attribute. Table 2 is an example of rules having this additional field.
The selector field may contain a mask, the mask defining clusters of tunnels. Table 3 below is an example of a selector field in accordance with an embodiment of the present invention. In this embodiment, selectors for source IP, destination IP, source port, Upper Layer Protocol, and Destination Port/Application may be toggled. Referring back to Table 2, in Rule 1, if Upper Layer Protocol is selected as Yes in the selector field (see Table 3), then different tunnels may be established between 192.168.1.1 and 208.206.2.2 for TCP traffic and UDP traffic. In Rule 2, if none of the selectors are set, then the rule will simply behave as it would have originally. In Rule 3, if both the source IP and destination IP selectors are set as Yes, then different tunnels may be established for each IP address combination. In Rule 4, if the source IP selector is set as Yes, then each user in the user group may establish a unique tunnel. Thus, by adding the selector field to the rule, the user can configure the VPN gateway to create either a single tunnel for the rule subnet or a separate tunnel for each selector field.
Since multiple security associations are established per single rule, there is a need to store the information for all the possible tunnels, and an efficient mechanism to search the entries of the information in such a way that the performance is not significantly affected and the ability for control of the number of security associations is not compromised. In an embodiment of the present invention, the data structures defined and the hashing method used contribute to these goals. A global hash table may be utilized and the hashing may be done based on all of the selector fields. The matching of the exact entry may be based on the actual selector mask, which is configured by the administrator.
Returning to
If, however, at 110 it was determined that a linked list does exist for the hash value in a hash value table, then at 122 the linked list may be traversed, looking for a linked list entry matching the information fields of the packet. Then, at 124, it may be determined if a match is found. If so, then the security association has already been set up for this stream, and the process may simply end. If not, however, then the process may proceed to 114, where an entry may be created at the end of the linked list and the process then continues on to 116 as before.
Returning to
If, however, it was determined that a linked list does exist for the hash value in a hash value table, then a linked list traverser 322 coupled to the hash value table hash value linked list determiner 310 and to the end linked list entry creator 314 may traverse the linked list, looking for a linked list entry matching the information fields of the packet. Then it may be determined if a match is found. If so, then the security association has already been set up for this stream, and the process may simply end. If not, however, then the process may proceed to using the end linked list entry creator 314 to create an entry at the end of the linked list and the process then continues with the subsequent components described earlier.
While the above discusses the invention in terms of linked lists and hash tables, one of ordinary skill in the art will recognize that alternative data structures could be used.
Normally, any hash table has a fixed set of keys on which the hash is calculated. The limitation in this approach is that if the keys change, then the hash table needs to be different. Thus, the present scenario would have required a hash table per rule. This would ordinarily increase the total memory requirement and additionally require that different methods be implemented to hash in each type of hash table. In an embodiment of the present invention, there is a global hash table for all the rules. Thus, the total memory requirement is fixed, which is more logical in terms of managing the resources in terms of total capacity of the system. Having a common hash for any type of selectors makes this possible. Thus, there is just one hash function and it selects the hash key depending on the selector mask.
This solution provides more granularity in the configuration of security associations, as the user has control over the selection of individual selectors.
While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art having the benefit of this disclosure that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.
