BACKGROUND OF THE INVENTION
The invention relates in general to Virtual Private Networks (VPN). In particular the invention relates to managing VPNs.
Public networks are presently being used more and more for sensitive and mission critical communications and the internal networks of various organisations and enterprises are nowadays connected to the public networks, Internet being one of them. Since the basic mechanisms of the public networks were originally not designed with secrecy and confidentiality in mind, public networks are untrusted networks.
Virtual Private Networks (VPN) are commonly used for connecting trusted parties to each other over untrusted public network through a secure tunnel. All traffic from a first party to a second party is encrypted in a security gateway of the first party, sent in encrypted form over the public network to the second party, where the transmitted data is decrypted in a security gateway and the decrypted data is forwarded to the recipient. The VPN is typically transparent to the processes that are communicating between each other and the encryption and decryption depend on the configuration of the VPN between the parties. However, the security gateways need to have information about the configuration of the other end of the VPN in order to be able to encrypt and decrypt the traffic correctly. The configuration includes things like addressing, encryption algorithm and key information of the other end security gateway. The configuration information is usually conveyed between the administrators of different sites by means of phone or some other traditional communication system. The administrators then input the configuration to the security gateways of their sites in order to enable VPN connections between the sites. The actual encryption keys are exchanged in VPN communication, but the configuration that is needed for initiating VPN connection needs to be conveyed by some other means.
Large VPNs are complicated and tedious to manage. Keeping the information about the structure of the VPN up to date at each site (network or group of networks connected to the VPN) is problematic but mandatory. Every site must have the correct configuration for all the other sites in order to communicate with them. In large VPNs there may be dozens or hundreds of sites and the configuration may vary in time rather frequently, and if the configuration of one VPN site changes all sites need to be updated. That is, the administrator of the sites changing its configuration needs to contact administrators of all other sites and communicate the changes to them, whereby they need to re-configure their security gateways.
FIG. 1 illustrates an example network topology with four sites 101-104, who are able to communicate with each other by means of VPNs. The sites 101-104 are connected to the Internet 100 via security gateways 105-108. Each security gateway is managed via a site-specific management server 109-112, which usually resides inside respective site and to each site there is configured VPN configuration information of all other sites as well as the configuration of the site itself. In case the security gateway functions as a firewall; the firewall configuration (access rules) of the security gateways is naturally not duplicated to the other sites.
One proposal for managing large VPNs is a star like VPN, where a central “hub” acts as a VPN router. Each site connects to the hub, which decrypts the packets and then re-encrypts them for the connection from the hub to the target site. This way, the VPN sites do not need to have up-to-date VPN information of all other sites; instead it is enough to be able to connect to the central hub.
FIG. 2 illustrates the network topology of FIG. 1 in connection with the star like VPN. The sites include now only VPN configuration of the site itself and of a central hub 200. The central hub includes VPN configuration of all the sites in the configuration, and the sites connect to each other via the central hub.
The disadvantage of the star like VPN is that vast amounts of processing power are required at the hub. The security gateway at each site still has the same amount of encryption load as in a standard distributed VPN, but the hub's load is in fact equal to the sum of the loads of all the sites. In large-scale VPNs this may be difficult or impossible to achieve and in any case very expensive. Furthermore, the data transmitted in the VPNs is in cleartext form within the hub, which is clearly a security risk.
If all the sites belonging to a VPN belong to the same organization, it is possible to administer them centrally by means of existing tools. In this case, all aspects of the security gateways, including access control configuration, are managed from one central point. However, the sites joining a VPN are not always sites of one party, but many different organizations may wish to establish a VPN between them. Clearly, such central management of all aspects of security gateways is not suitable, if different organizations are involved. Therefore a new way to manage VPNs of more than one organisation and especially large VPNs is required.
SUMMARY OF THE INVENTION
An object of the invention is to provide a method for managing VPN devices, which avoids or alleviates the problems mentioned above. The object is achieved according to the invention as disclosed in the attached independent claims. Preferred embodiments of the invention are disclosed in the dependent claims. The features described in one dependent claim may be further combined with features described in another dependent claim to produce further embodiments of the invention.
The idea of the invention is to provide a centralized VPN management of a plurality of VPN sites by means of a VPN Information Provider (VIP). The security gateway (or other VPN device) management is distributed so that at least part of the VPN configuration (especially the part consisting of site addressing, used encryption algorithms and key management) is centrally managed without giving away control of the firewall rulebase or other critical local configuration used in the security gateway. There may be several VPNs handled by different VIPs, so that an organization using the invention can flexibly join several independent VPNs.
The VIP according to the invention is a mutually trusted party, from which the parties joining a VPN are willing to accept configuration information.
According to a first aspect of the invention a method for managing VPN devices comprises
maintaining in a VPN Information Provider (VIP) VPN configurations of VPN devices belonging to a first VPN,
providing from the VIP to a first VPN device belonging to the first VPN, VPN configuration of at least one other VPN device belonging to the first VPN, and
managing certain aspects of said first VPN device belonging to the first VPN from at least one other management system.
According to a second aspect of the invention a method for managing VPN device comprises
maintaining in a first VPN Information Provider (VIP) VPN configurations of VPN device belonging to a first VPN,
maintaining in a second VPN Information Provider (VIP) VPN configurations of VPN device belonging to a second VPN, and
providing to a first VPN device belonging to the first and second VPNs, VPN configuration of at least one other VPN device belonging to the first VPN from the first VIP and VPN configuration of at least one other VPN device belonging to the second VPN from the second VIP.
The configuration of at least one other VPN device may be provided directly to said first VPN device or via at least one other management system.
Own VPN configuration of a given VPN device may be defined in the VIP or in some other management system, from where the configuration is provided to the VIP for maintenance.
Providing the configuration(s) of other VPN devices to a VPN device may be done by sending to a first VPN device belonging to the first VPN, information about the VPN configurations maintained in the VIP, and by requesting from the first VIP VPN configuration of another security gateway belonging to the first VPN when needed. Said information about the VPN configurations maintained in the VIP may be for example a set of addresses included in the first VPN. (The set of addresses may be a single address range or plurality of address ranges related to different sites included in the VPN.) In that case, the request from the first VPN device comprises an address included in the first VPN, and said other VPN device is identified in the VIP by finding a VPN device related to said address. Said information about the configurations—that is, the set of addresses—may be sent to the VPN devices after a change in the set of addresses included in the first VPN, or after a predefined time has elapsed since the information was sent the last time.
Alternatively the VIP may send, to VPN devices belonging to the first VPN, VPN configurations maintained in the VIP, so that the configurations are readily available in the VPN devices when needed. The VPN configurations maintained in the VIP may be sent for example after a new VPN configuration has been added to the VIP, after an old VPN configuration has been removed from the VIP, after a VPN configuration of at least one VPN device has been changed in the VIP, or after a predefined time has elapsed since the configurations were sent the last time. That is, all changes need to be instantly conveyed to the VPN devices.
In either of the above cases, the VIP may send only changes or additions to the information or configurations previously sent (an incremental update) or all available information or configurations (a full update).
According to a third aspect of the invention a method for handling VPN configuration in a VPN device comprises
receiving a packet directed to a destination address in a first VPN,
requesting and receiving VPN configuration for a VPN device related to said destination address from a VPN Information Provider (VIP) administering the first VPN, and
using said VPN configuration for establishing a VPN tunnel to said VPN device related to said destination address for reaching said destination address.
In this context, a VPN device related to a destination address refers to the VPN device, which is securing the site, to which the destination address belongs. In order to communicate to the destination address, a VPN tunnel needs to be created to this VPN device.
According to a fourth aspect of the invention a method for handling VPN configuration in a VPN Information Provider (VIP) comprises
maintaining VPN configurations of VPN devices belonging to a first VPN,
providing to VPN devices belonging to the first VPN, information about the VPN configurations maintained in the VIP,
receiving from a first VPN device belonging to the first VPN, a request for VPN configuration of another VPN device belonging to the first VPN, and
sending to said first VPN device belonging to the first VPN, the VPN configuration of the other VPN device as a response to the request.
According to the invention all entire encryption/decryption load is addressed to the firewalls or security gateways protecting the sites, while the VPN administration is centralized by means of VIPs to achieve consistent configuration at every site. Also there is no centralized location where all the traffic is in cleartext form as in the central hub arrangement, so the communication is more secure than in a star like structure.
The method of the invention enables flexible management of a VPN between several autonomous organizations. Additionally, providing VPN management as a service is enabled. That is, the invention offers MSPs (Managed Service Providers) a possibility to provide a new type of service by means of VIPs. VPN configuration is managed separately from other configuration information and therefore management of VPN configuration can be securely outsourced and an organization can easily join different VPNs, which may be administered by a plurality of different VIPs.
These and other features of the invention, as well as the advantages offered thereby, are described hereinafter with reference to embodiments illustrated in the accompanying drawings.