1. Field of Invention
The present invention relates generally to routing messages over a network, and more particularly, to routing messages in a nested virtual private network.
2. Background of the Invention
A virtual private network (VPN) establishes a private or secure network connection within a public network, such as the Internet. The data sent across the public network is encrypted. A typical example of a use of the VPN is a company network with two offices in different cities. Using the public Internet, the two offices can merge their networks into one network and encrypt the traffic transported over the encrypted cloud across the public network. A nested VPN is a network that has a variety of enclaves that communicate across the encrypted cloud, which is invisible to them and to which they are invisible. An enclave includes an arbitrary number of hosts connected to a local area network (LAN), wide area network (WAN), or the like.
In VPNs supporting Internet Protocol, Version 6 (IPv6 protocol), a VPN router that routes IP packets between any two enclaves has two components, either logical or physical—a cyphertext component and a plaintext component. A cyphertext component is connected to a cyphertext (CTX) domain, such as public Internet. In the CTX domain messages are sent with additional encryption. A plaintext component is connected to a plaintext (PTX) domain, for example, a Local Area Network (LAN). In the PTX domain messages are sent without additional encryption. For purposes of this description, the words “enclave” and “PTX domain” will be used interchangeably. A CTX component of the VPN router has a CTX Internet Protocol (IP) address. Similarly, a PTX component has a PTX IP address.
When messages are routed between any two PTX domains, a VPN router connected to the sending PTX domain needs to know which VPN routing peer to use to send messages to the receiving PTX domain. In addition, the VPN router of the sending domain needs to know an address of the CTX component of that VPN routing peer so that the VPN router can set up a security association with that VPN routing peer. Routing in a nested VPN, however, requires that a PTX domain has no knowledge about IP addressing in a CTX domain and vice versa. More specifically, the information regarding the CTX domain, such as a CTX IP address of a VPN router, preferably is unknown to the PTX domain and vice versa.
One known solution that avoids leaking such information across domains involves sending a broadcast request to all routers and waiting for a response from the appropriate router. This solution, however, is not scaleable in networks having more than several hundreds of enclaves. In addition, it presents a bandwidth problem if there are many VPN Routers in the network, as each time a new request is sent to a new router all other routers receive the message.
Another solution to this problem is configuring a VPN router so that it has a security association with any possible router in the system. Again, this solution has a scalability problem as the number of routers increases.
Another approach requires creating a directory that stores the information regarding each authorized security association between VPN routers. The drawback of this approach is that maintaining a single directory introduces a single point of failure and that the directory knows the association between PTX and CTX domains.
Accordingly, it is desirable to have a mechanism that solves the problem of maintaining a zero-information between PTX domain and CTX domain and overcomes the limitations of the prior art solutions.
USPTO Backgrounds
USPTO Backgrounds