WO2003007561A1 - Method for forming a secured network - Google Patents

Method for forming a secured network Download PDF

Info

Publication number
WO2003007561A1
WO2003007561A1 PCT/FI2002/000634 FI0200634W WO03007561A1 WO 2003007561 A1 WO2003007561 A1 WO 2003007561A1 FI 0200634 W FI0200634 W FI 0200634W WO 03007561 A1 WO03007561 A1 WO 03007561A1
Authority
WO
WIPO (PCT)
Prior art keywords
gateway node
vpn
hub
node
network
Prior art date
Application number
PCT/FI2002/000634
Other languages
French (fr)
Inventor
Tatu YLÖNEN
Original Assignee
Ssh Communications Security Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ssh Communications Security Corp filed Critical Ssh Communications Security Corp
Publication of WO2003007561A1 publication Critical patent/WO2003007561A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the invention concerns security systems in packet data networks. Especially, the invention concerns virtual private networks (VPN).
  • VPN virtual private networks
  • Virtual private networking technology uses encrypted connections over a public data network such as the Internet to form a closed internal network of an organization.
  • VPN technology is typically used to connect regional offices of an organization with each other.
  • VPN technology allows the use of the public Internet for connectivity, avoiding the use of expensive, dedicated leased lines which were the norm before the development of VPN technology.
  • VPN gateways are used to connect internal local area networks of a site to a public network.
  • the VPN gateways of different sites of the organization are configured to form encrypted tunnels between each other.
  • the VPN gateways are arranged to encrypt any data packets from the internal local area network directed to any of the other VPN sites, and direct the encrypted packets to the VPN gateway of the desired site, which in turn decrypts the packets and delivers the packets into the local area network at the destination site.
  • the VPN network When the VPN network is properly configured, it is transparent to the users, all local area networks of the organization appearing as a single network.
  • the VPN gateways typically also act as firewall devices, blocking unauthorized access to the internal network.
  • IPSEC The IPSec protocol suite
  • ISP internet service providers
  • DHCP DHCP
  • RARP RARP
  • Dial-up lines are very cost effective, but they usually provide dynamic connections with dynamic addresses (using the PPP protocol [PPP], [IPCP]).
  • Wireless technology is also gaining popularity, but many low-cost wireless solutions such as WLAN technology based on the IEEE 802.11 group of standards also provide dynamic addresses only.
  • NAT network address translation
  • IPv6 The IPv6 technology is strongly oriented towards autoconfiguration (see e.g. [RFC2462]) and dynamic address allocation, which makes the ability to operate without a static address even more important. Automatic configuration with dynamic address allocation is becoming even more important, as the increasing deployment of wireless local area networking technology increases the use of secure networks within corporations.
  • An object of the invention is to avoid the problems of the prior art solutions.
  • a further object of the invention is to allow any type of internet connection to be used for connecting VPN gateways to the internet, bringing considerable cost benefits.
  • a still further object of the invention is to allow automatic configuration for VPN gateways in corporate networks.
  • a first VPN gateway node with a dynamic address is arranged to establish a tunnel to a hub gateway node having a static address.
  • Other network nodes who wish to connect to said first VPN gateway node connect to the hub gateway node, which forwards the traffic to said first VPN gateway node.
  • This allows the actual address of said first VPN gateway node to be unknown to other nodes, since the gateway node is accessible via the static address of the hub gateway node. Therefore, the actual address of said first VPN gateway node can also change without hindering communication with other nodes.
  • the inventive principle allows building of complicated and large VPN networks easily, allows the use of cheap dial-up links for connecting VPN gateways to the Internet, and allows automatic configuration for VPN gateways.
  • a company can set up one or more hub gateway nodes at the headquarters, and have all smaller regional offices use any mode of connecting to the Internet for their VPN gateways. Further, the inventive functionality allows a site to change the Internet connection provider easily, without the need for changing the VPN configuration.
  • the VPN gateway node is not connected to the public internet.
  • the first VPN gateway node connects to the internet using the services of an Internet Service Provider (ISP).
  • ISP Internet Service Provider
  • the computer system of the ISP assigns and IP address for the first gateway node.
  • the first gateway node opens and IPSec tunnel to the hub gateway node assigned to it.
  • the identification of the hub gateway node i.e.
  • the hub gateway node is able to receive any communications intended to the first VPN gateway node, and forward the communications through the tunnel to the first VPN gateway node.
  • a third node performs an IKE negotiation with the hub node to set up an IPSec tunnel to the hub node.
  • the hub node consequently receives any traffic received via the negotiated tunnel from said third node directed to the first VPN gateway node, decapsulates and decrypts the received data, then encapsulates and encrypts the data for transmission to the first VPN gateway node, and finally sends the data to the first VPN gateway node.
  • the return traffic from the first VPN gateway can advantageously be arranged in the reverse way, i.e. by having the first VPN gateway send the data to the hub gateway, which decrypts and decapsulates the data, encrypts and encapsulates the data again for sending to the third node, and then sends the data to the third node.
  • the third node can be for example a VPN gateway with a static address, or a hub node serving another VPN gateway behind a dynamic IP address.
  • the first VPN gateway negotiates a tunnel directly to the other corresponding node, such as the third node in the previous example, for any return traffic to the other node.
  • a tunnel directly to the other corresponding node, such as the third node in the previous example.
  • the VPN gateway node needs to have preconfigured identity information for example in the form of a certificate or for example a shared secret key in order to be able to negotiate a tunnel with the hub gateway node, since the hub gateway node needs to recognize the VPN gateway node to be a part of the particular VPN network.
  • NAT network address translation
  • the third node does not need to negotiate a tunnel to the hub node, if a tunnel between the third node and the hub node already exists. This may be the case if the third node is itself a another VPN gateway or a hub node for another VPN gateway.
  • the first VPN gateway can also negotiate an IPSec tunnel directly with the third node, bypassing the hub node for the return path.
  • the third node in the previous example may be a second hub node acting for a second VPN gateway node.
  • a VPN gateway needs to know the hub gateway addresses corresponding to the other VPN gateways. This information can be included in the same piece of configuration information of the VPN gateway that includes the address of its hub gateway.
  • a VPN gateway node is arranged to query information about the rest of the VPN network from its hub gateway node.
  • the hub network node address needs to be previously configured in the VPN gateway node, and other aspects of the network can be automatically requested from the hub gateway node.
  • the configuration information can also be supplied by another node than the hub gateway node, such as a node of the VPN network management system.
  • one hub node may serve more than one VPN gateway node.
  • the hub node functions as a kind of a router, directing traffic between the tunnels between the hub node and the VPN gateway nodes.
  • one hub node can serve all VPN gateway nodes of a VPN network.
  • the inventive functionality can be used in addition to such configurations in which the IP address of a VPN gateway may change, but also in order to facilitate automatic configuration of a VPN gateway even in cases, in which the IP address of a VPN gateway, once assigned, is not expected to change.
  • a VPN gateway associated with a wireless LAN (WLAN) access point.
  • WLAN wireless LAN
  • a WLAN access can be arranged with VPN gateway functionality.
  • the inventive functionality can be used, whereby the access point needs only a hub gateway address and identity information as configuration information.
  • Figure 2 illustrates a method according to an advantageous embodiment of the invention.
  • Figure 1 illustrates an example of a network structure, in which the invention can be employed.
  • Figure 1 illustrates a first local area network 110, a second local area network 111, and a third local area network 120.
  • the first and second local area networks are LANs of smaller offices of a company
  • the third local area network 120 is the LAN of the corporate headquarters.
  • the first and second LANs are connected to the a public network such as the internet 150 via VPN gateways 130, 132. These gateways 130, 132 have connections with dynamic IP addresses of the public network 150.
  • the LAN 120 of the corporate headquarters is connected to the internet via a gateway 140, which has a static address of the public network 150.
  • the corporate VPN is formed by having the VPN gateways 130, 132 of the side offices contact the headquarters gateway 140 with a static address, and having the headquarters gateway 140 forward to the second LAN traffic from the first LAN (and any other eventual LANs) destined to the second LAN, and forward to the first LAN any traffic destined to the first LAN.
  • the gateway 140 acts as a hub gateway. Since the gateway 140 has a static address, side office gateways 130, 132 are always able to contact the gateway 140 when setting up the connections.
  • Figure 2 illustrates a method for setting up a network according to an advantageous embodiment of the invention between a first network having a first VPN gateway node having a dynamic IP address of a public network and a second network having a second VPN gateway node having a dynamic IP address of the public network.
  • the method comprises at least the steps of
  • said hub gateway node to decrypt and examine packets received from said first and second VPN gateway nodes, and to send any packets destined to said first network to said first encrypted communication channel and any packets destined to said second network to said second encrypted communication channel.
  • the method further comprises the step of negotiating at least one third encrypted communication channel between said first VPN gateway node and the hub gateway node.
  • This at least one third encrypted communication channel can carry traffic destined to a different subnetwork or different subnetworks than the first encrypted communication channel.
  • the method further comprises the step of negotiating at least one fourth encrypted communication channel between said second VPN gateway node and the hub gateway node.
  • This at least one fourth encrypted communication channel can carry traffic destined to a different subnetwork or different subnetworks than the second encrypted communication channel.
  • a VPN gateway node needs to be preconfigured at least with an IP address of a hub gateway, and information required to set up a secured tunnel to that address such as identity information of the VPN gateway node and keys for encryption and decryption.
  • an inventive VPN gateway node is arranged to renegotiate a tunnel to the hub gateway node, if an old tunnel has been lost.
  • an inventive VPN gateway node has a keepalive mechanism to detect if the hub gateway node has been rebooted and the tunnel needs to be re-established.
  • An inventive VPN gateway node can also include NAT traversal functionality discussed previously.
  • a separate security association (i.e. a tunnel) may be created for each subnet.
  • SA security association
  • different subnets correspond to different local area networks or parts of local area networks at different geographical sites.
  • Negotiating a very large prefix (for example, 0/0) for a single SA between a dynamic gateway node and the hub node would allow carrying traffic from a remote LAN via the hub gateway to any of the subnetworks of the combined VPN, but such a large prefix could also cause internal traffic of the remote LAN to be passed via the connection to the hub gateway, which is undesirable. Therefore, depending on the structure of the address spaces and subnets used, it may be advantageous to negotiate a plurality of SAs for communication between a dynamic gateway and the hub gateway, one SA for each distinct subnet.
  • a modified IKE negotiation is used in order to allow the negotiation of multiple subnets for the same tunnel.
  • a VPN gateway can use more than one hub gateway node, in which case the VPN gateway is accessible through any one of these hub gateway nodes. Such a configuration provides better fault tolerance than the use of a single hub gateway node.
  • a hub gateway node is arranged to report to a network monitoring system whether a dynamic gateway assigned to the hub gateway node is connected or not.
  • a hub gateway node is arranged to obtain information about VPN gateways assigned to it from a centralized management system.
  • inventive solution can be employed in both IPv4 and IPv6 networks.
  • inventive solution can employ any method for obtaining the IP address of a VPN gateway, such as by using DHCP, PPP, IPCP, or RARP protocols.
  • IKE as an example for use for security negotiation parameters. The invention is not limited only to IKE, since other key management protocols can also be used.
  • IPCP IPCP RFC 1661, The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994.

Abstract

According to the invention, a first VPN gateway node with a dynamic address is arranged to establish a tunnel to a hub gateway node having a static address. Other network nodes who wish to connect to said first VPN gateway node connect to the hub gateway node, which forwards the traffic to said first VPN gateway node. This allows the actual address of said first VPN gateway node to be unknown to other nodes, since the gateway node is accessible via the static address of the hub gateway node. Therefore, the actual address of said first VPN gateway node can also change without hindering communication with other nodes.

Description

Method for forming a secured network
Field of the invention
The invention concerns security systems in packet data networks. Especially, the invention concerns virtual private networks (VPN).
Background of the invention
Virtual private networking technology uses encrypted connections over a public data network such as the Internet to form a closed internal network of an organization. VPN technology is typically used to connect regional offices of an organization with each other. VPN technology allows the use of the public Internet for connectivity, avoiding the use of expensive, dedicated leased lines which were the norm before the development of VPN technology.
To form a VPN network, VPN gateways are used to connect internal local area networks of a site to a public network. The VPN gateways of different sites of the organization are configured to form encrypted tunnels between each other. The VPN gateways are arranged to encrypt any data packets from the internal local area network directed to any of the other VPN sites, and direct the encrypted packets to the VPN gateway of the desired site, which in turn decrypts the packets and delivers the packets into the local area network at the destination site. When the VPN network is properly configured, it is transparent to the users, all local area networks of the organization appearing as a single network. The VPN gateways typically also act as firewall devices, blocking unauthorized access to the internal network.
The IPSec protocol suite [IPSEC], which is at the time of writing of this patent application the most widely employed security protocol in VPN use, requires that the address of the gateway must be known in advance in order to negotiate a tunnel with the gateway. This limits the choices for the method used for connecting the VPN gateway and the local site to the Internet. Low-cost internet connections from internet service providers (ISP) usually only provide dynamic addresses automatically assigned by the use of DHCP [DHCP] or RARP [RARP] protocols. Dial-up lines are very cost effective, but they usually provide dynamic connections with dynamic addresses (using the PPP protocol [PPP], [IPCP]). Wireless technology is also gaining popularity, but many low-cost wireless solutions such as WLAN technology based on the IEEE 802.11 group of standards also provide dynamic addresses only. Further, many internet connections are provided via a network address translation (NAT) function [NAT], in which case whatever address the gateway might have from the ISP may not be accessible from the outside. Network connections with static IP addresses are usually much more expensive to obtain than those with a dynamic address.
The IPv6 technology is strongly oriented towards autoconfiguration (see e.g. [RFC2462]) and dynamic address allocation, which makes the ability to operate without a static address even more important. Automatic configuration with dynamic address allocation is becoming even more important, as the increasing deployment of wireless local area networking technology increases the use of secure networks within corporations.
SUMMARY OF THE INVENTION
An object of the invention is to avoid the problems of the prior art solutions. A further object of the invention is to allow any type of internet connection to be used for connecting VPN gateways to the internet, bringing considerable cost benefits. A still further object of the invention is to allow automatic configuration for VPN gateways in corporate networks.
According to the invention, a first VPN gateway node with a dynamic address is arranged to establish a tunnel to a hub gateway node having a static address. Other network nodes who wish to connect to said first VPN gateway node connect to the hub gateway node, which forwards the traffic to said first VPN gateway node. This allows the actual address of said first VPN gateway node to be unknown to other nodes, since the gateway node is accessible via the static address of the hub gateway node. Therefore, the actual address of said first VPN gateway node can also change without hindering communication with other nodes. The inventive principle allows building of complicated and large VPN networks easily, allows the use of cheap dial-up links for connecting VPN gateways to the Internet, and allows automatic configuration for VPN gateways. Using the inventive functionality, a company can set up one or more hub gateway nodes at the headquarters, and have all smaller regional offices use any mode of connecting to the Internet for their VPN gateways. Further, the inventive functionality allows a site to change the Internet connection provider easily, without the need for changing the VPN configuration.
Let us consider an example according to an advantageous embodiment of the invention. In this example, security of the communication is obtained through use of the IPSec protocol suite [IPSEC], and key material and other parameters for IPSec connections are obtained with negotiations according to the IKE protocol [IKE]. This example describes one example of starting communications at a first VPN gateway site. In this example, the VPN gateway node is not connected to the public internet. First, the first VPN gateway node connects to the internet using the services of an Internet Service Provider (ISP). During the connection procedure, the computer system of the ISP assigns and IP address for the first gateway node. When the connection is established, the first gateway node opens and IPSec tunnel to the hub gateway node assigned to it. The identification of the hub gateway node, i.e. information such as the IP address of the hub gateway node is a part of the configuration information of the first VPN gateway node. Thereafter, the hub gateway node is able to receive any communications intended to the first VPN gateway node, and forward the communications through the tunnel to the first VPN gateway node. To obtain secure communications, a third node performs an IKE negotiation with the hub node to set up an IPSec tunnel to the hub node. The hub node consequently receives any traffic received via the negotiated tunnel from said third node directed to the first VPN gateway node, decapsulates and decrypts the received data, then encapsulates and encrypts the data for transmission to the first VPN gateway node, and finally sends the data to the first VPN gateway node. The return traffic from the first VPN gateway can advantageously be arranged in the reverse way, i.e. by having the first VPN gateway send the data to the hub gateway, which decrypts and decapsulates the data, encrypts and encapsulates the data again for sending to the third node, and then sends the data to the third node. The third node can be for example a VPN gateway with a static address, or a hub node serving another VPN gateway behind a dynamic IP address.
In an advantageous embodiment of the invention, the first VPN gateway negotiates a tunnel directly to the other corresponding node, such as the third node in the previous example, for any return traffic to the other node. Such a configuration has the advantage, that as the return traffic does not pass through the hub gateway node, the load on the hub gateway node is reduced.
The VPN gateway node needs to have preconfigured identity information for example in the form of a certificate or for example a shared secret key in order to be able to negotiate a tunnel with the hub gateway node, since the hub gateway node needs to recognize the VPN gateway node to be a part of the particular VPN network.
In some network configurations, it is possible that a network address translation (NAT) function exists between the hub gateway and the VPN gateway. In such a case, functionality for traversing such a NAT function is necessary for implementing an IPSec tunnel between the hub gateway and the VPN gateway. Such functionality is described in patent applications EP 98963576.8 and WO 0078008, which are hereby incorporated by reference. At the time of writing of this patent application, such functionality is being discussed at the Internet Engineering Task Force (IETF) for standardization purposes, and is described in documents draft-ietf-ipsec-nat-t-ike-00.txt and draft-ietf-ipsec-udp-encaps-00.txt available from the IETF internet site www.ietf.org.
In an advantageous embodiment of the invention, the third node does not need to negotiate a tunnel to the hub node, if a tunnel between the third node and the hub node already exists. This may be the case if the third node is itself a another VPN gateway or a hub node for another VPN gateway.
In an advantageous embodiment of the invention, the first VPN gateway can also negotiate an IPSec tunnel directly with the third node, bypassing the hub node for the return path. In the case that there are more than one network having a VPN gateway node with a dynamic address, the third node in the previous example may be a second hub node acting for a second VPN gateway node. For connecting with other VPN gateways of the same VPN network, a VPN gateway needs to know the hub gateway addresses corresponding to the other VPN gateways. This information can be included in the same piece of configuration information of the VPN gateway that includes the address of its hub gateway. In another advantageous embodiment of the invention, a VPN gateway node is arranged to query information about the rest of the VPN network from its hub gateway node. In such an embodiment, only the hub network node address needs to be previously configured in the VPN gateway node, and other aspects of the network can be automatically requested from the hub gateway node. The configuration information can also be supplied by another node than the hub gateway node, such as a node of the VPN network management system.
In an advantageous embodiment of the invention, one hub node may serve more than one VPN gateway node. In such a case, the hub node functions as a kind of a router, directing traffic between the tunnels between the hub node and the VPN gateway nodes. At one extreme, one hub node can serve all VPN gateway nodes of a VPN network.
The inventive functionality can be used in addition to such configurations in which the IP address of a VPN gateway may change, but also in order to facilitate automatic configuration of a VPN gateway even in cases, in which the IP address of a VPN gateway, once assigned, is not expected to change. As an example of such a case is a VPN gateway associated with a wireless LAN (WLAN) access point. For security, a WLAN access can be arranged with VPN gateway functionality. In order to streamline installation of such an access point, the inventive functionality can be used, whereby the access point needs only a hub gateway address and identity information as configuration information.
BRIEF DESCRIPTION OF THE DRAWINGS
Various embodiments of the invention will be described in detail below, by way of example only, with reference to the accompanying drawings, of which Figure 1 illustrates an example of a structure of a VPN network according to the invention, and
Figure 2 illustrates a method according to an advantageous embodiment of the invention.
The exemplary embodiments of the invention presented in this description are not to be interpreted to pose limitations to the applicability of the appended claims. The verb "to comprise" is used as an open limitation that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.
DETAILED DESCRIPTION
Figure 1 illustrates an example of a network structure, in which the invention can be employed. Figure 1 illustrates a first local area network 110, a second local area network 111, and a third local area network 120. In this example we can assume that the first and second local area networks (LAN) are LANs of smaller offices of a company, while the third local area network 120 is the LAN of the corporate headquarters. The first and second LANs are connected to the a public network such as the internet 150 via VPN gateways 130, 132. These gateways 130, 132 have connections with dynamic IP addresses of the public network 150. The LAN 120 of the corporate headquarters is connected to the internet via a gateway 140, which has a static address of the public network 150. According to the invention, the corporate VPN is formed by having the VPN gateways 130, 132 of the side offices contact the headquarters gateway 140 with a static address, and having the headquarters gateway 140 forward to the second LAN traffic from the first LAN (and any other eventual LANs) destined to the second LAN, and forward to the first LAN any traffic destined to the first LAN. The gateway 140 acts as a hub gateway. Since the gateway 140 has a static address, side office gateways 130, 132 are always able to contact the gateway 140 when setting up the connections.
Figure 2 illustrates a method for setting up a network according to an advantageous embodiment of the invention between a first network having a first VPN gateway node having a dynamic IP address of a public network and a second network having a second VPN gateway node having a dynamic IP address of the public network. According to this embodiment, the method comprises at least the steps of
- negotiating 210 a first encrypted communication channel between said first VPN gateway node and a hub gateway node having a static IP address of the public network,
- negotiating 220 a second encrypted communication channel between said second VPN gateway node and said hub gateway node,
- arranging 230 said first VPN gateway node to transmit all packets destined to said second network via said first encrypted communication channel,
- arranging 240 said second VPN gateway node to transmit all packets destined to said first network via said second encrypted communication channel,
- arranging 250 said hub gateway node to decrypt and examine packets received from said first and second VPN gateway nodes, and to send any packets destined to said first network to said first encrypted communication channel and any packets destined to said second network to said second encrypted communication channel.
According to a further advantageous embodiment of the invention, the method further comprises the step of negotiating at least one third encrypted communication channel between said first VPN gateway node and the hub gateway node. This at least one third encrypted communication channel can carry traffic destined to a different subnetwork or different subnetworks than the first encrypted communication channel.
According to a further advantageous embodiment of the invention, the method further comprises the step of negotiating at least one fourth encrypted communication channel between said second VPN gateway node and the hub gateway node. This at least one fourth encrypted communication channel can carry traffic destined to a different subnetwork or different subnetworks than the second encrypted communication channel.
VARIOUS CONSIDERATIONS PARTICULAR TO VPN GATEWAY NODES
As described previously, a VPN gateway node needs to be preconfigured at least with an IP address of a hub gateway, and information required to set up a secured tunnel to that address such as identity information of the VPN gateway node and keys for encryption and decryption.
In an advantageous embodiment of the invention, an inventive VPN gateway node is arranged to renegotiate a tunnel to the hub gateway node, if an old tunnel has been lost. Advantageously, an inventive VPN gateway node has a keepalive mechanism to detect if the hub gateway node has been rebooted and the tunnel needs to be re-established. An inventive VPN gateway node can also include NAT traversal functionality discussed previously.
In an advantageous embodiment of the invention, if multiple internal address subnets are used in VPN network, a separate security association (SA) (i.e. a tunnel) may be created for each subnet. Typically, different subnets correspond to different local area networks or parts of local area networks at different geographical sites. Negotiating a very large prefix (for example, 0/0) for a single SA between a dynamic gateway node and the hub node would allow carrying traffic from a remote LAN via the hub gateway to any of the subnetworks of the combined VPN, but such a large prefix could also cause internal traffic of the remote LAN to be passed via the connection to the hub gateway, which is undesirable. Therefore, depending on the structure of the address spaces and subnets used, it may be advantageous to negotiate a plurality of SAs for communication between a dynamic gateway and the hub gateway, one SA for each distinct subnet.
In an a further advantageous embodiment of the invention, instead of negotiating a plurality of SAs, a modified IKE negotiation is used in order to allow the negotiation of multiple subnets for the same tunnel. In an advantageous embodiment of the invention, a VPN gateway can use more than one hub gateway node, in which case the VPN gateway is accessible through any one of these hub gateway nodes. Such a configuration provides better fault tolerance than the use of a single hub gateway node.
VARIOUS CONSIDERATIONS PARTICULAR TO HUB GATEWAY NODES
According to an advantageous embodiment of the invention, a hub gateway node is arranged to report to a network monitoring system whether a dynamic gateway assigned to the hub gateway node is connected or not.
According to a further advantageous embodiment of the invention, a hub gateway node is arranged to obtain information about VPN gateways assigned to it from a centralized management system.
FURTHER CONSIDERATIONS
The invention has been described using some particular advantageous embodiments as examples. However, various implementations of the invention are not limited to the described examples, and the invention can be realized in many different ways within the scope of the attached patent claims. For example, the inventive solution can be employed in both IPv4 and IPv6 networks. Further, the inventive solution can employ any method for obtaining the IP address of a VPN gateway, such as by using DHCP, PPP, IPCP, or RARP protocols. Further, this application discusses IKE as an example for use for security negotiation parameters. The invention is not limited only to IKE, since other key management protocols can also be used.
REFERENCES
[DHCP] RFC 2131, Dynamic Host Configuration Protocol. R. Droms. March [IKE] RFC 2409, The Internet Key Exchange (IKE), D. Harkins, D. Carrel, November 1998.
[IPCP] RFC 1661, The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994.
[IPSEC] RFC 2401, Security Architecture for the Internet Protocol, S. Kent, R. Atkinson, November 1998.
[NAT] RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999.
[PPP] RFC 1661, The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994.
[RARP] RFC 903, Reverse Address Resolution Protocol. R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. Jun-01-1984.
[RFC2462] RFC 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998.

Claims

Claims
1. Method for setting up a network between a first network having a first VPN gateway node having a dynamic IP address of a public network and a second network having a second VPN gateway node having a dynamic IP address of the public network,
characterized in that the method comprises at least the steps of
- negotiating (210) a first encrypted communication channel between said first VPN gateway node and a hub gateway node having a static IP address of the public network,
- negotiating (220) a second encrypted communication channel between said second VPN gateway node and said hub gateway node,
- arranging (230) said first VPN gateway node to transmit all packets destined to said second network via said first encrypted communication channel,
- arranging (240) said second VPN gateway node to transmit all packets destined to said first network via said second encrypted communication channel,
- arranging (250) said hub gateway node to decrypt and examine packets received from said first and second VPN gateway nodes, and to send any packets destined to said first network to said first encrypted communication channel and any packets destined to said second network to said second encrypted communication channel.
2. A method according to claim 1, characterized in that the method further comprises the step of negotiating at least one third encrypted communication channel between said first VPN gateway node and the hub gateway node.
3. A method according to claim 1, characterized in that the method further comprises the step of negotiating at least one fourth encrypted communication channel between said second VPN gateway node and the hub gateway node.
PCT/FI2002/000634 2001-07-13 2002-07-15 Method for forming a secured network WO2003007561A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20011547 2001-07-13
FI20011547A FI20011547A0 (en) 2001-07-13 2001-07-13 Security systems and procedures

Publications (1)

Publication Number Publication Date
WO2003007561A1 true WO2003007561A1 (en) 2003-01-23

Family

ID=8561662

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2002/000634 WO2003007561A1 (en) 2001-07-13 2002-07-15 Method for forming a secured network

Country Status (2)

Country Link
FI (1) FI20011547A0 (en)
WO (1) WO2003007561A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005117392A1 (en) * 2004-05-17 2005-12-08 Thomson Licensing Methods and apparatus managing access to virtual private network for portable devices without vpn client
WO2008099062A1 (en) * 2007-02-16 2008-08-21 Nokia Corporation Method for the routing and control of packet data traffic in a communication system
CN100421379C (en) * 2003-09-10 2008-09-24 华为技术有限公司 A multi-point reachable tunnel communication method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
WO2000078008A1 (en) * 1999-06-15 2000-12-21 Ssh Communications Security Ltd A method and arrangement for providing security through network address translations using tunneling and compensations
EP1071252A2 (en) * 1999-07-21 2001-01-24 International Computers Ltd. Migration from in-clear to encrypted working over a communications link
WO2002017558A2 (en) * 2000-08-18 2002-02-28 Etunnels Inc. Method and apparatus for data communication between a plurality of parties

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061346A (en) * 1997-01-17 2000-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Secure access method, and associated apparatus, for accessing a private IP network
WO2000078008A1 (en) * 1999-06-15 2000-12-21 Ssh Communications Security Ltd A method and arrangement for providing security through network address translations using tunneling and compensations
EP1071252A2 (en) * 1999-07-21 2001-01-24 International Computers Ltd. Migration from in-clear to encrypted working over a communications link
WO2002017558A2 (en) * 2000-08-18 2002-02-28 Etunnels Inc. Method and apparatus for data communication between a plurality of parties

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100421379C (en) * 2003-09-10 2008-09-24 华为技术有限公司 A multi-point reachable tunnel communication method
WO2005117392A1 (en) * 2004-05-17 2005-12-08 Thomson Licensing Methods and apparatus managing access to virtual private network for portable devices without vpn client
WO2008099062A1 (en) * 2007-02-16 2008-08-21 Nokia Corporation Method for the routing and control of packet data traffic in a communication system
US7809003B2 (en) 2007-02-16 2010-10-05 Nokia Corporation Method for the routing and control of packet data traffic in a communication system

Also Published As

Publication number Publication date
FI20011547A0 (en) 2001-07-13

Similar Documents

Publication Publication Date Title
EP1709547B1 (en) Serving network selection and multihoming using ip access network
Durand et al. Dual-stack lite broadband deployments following IPv4 exhaustion
US7941548B2 (en) Wireless network security mechanism including reverse network address translation
US6970459B1 (en) Mobile virtual network system and method
CA2521505C (en) Mobile ethernet
US7444415B1 (en) Method and apparatus providing virtual private network access
JP5281644B2 (en) Method and apparatus for enabling a nomadic terminal to access a home network on a layer 2 level
Govil et al. An examination of IPv4 and IPv6 networks: Constraints and various transition mechanisms
US20050114490A1 (en) Distributed virtual network access system and method
US20070086382A1 (en) Methods of network access configuration in an IP network
JP2007518349A (en) Equipment that facilitates deployment to medium / large enterprise networks of mobile virtual private networks
JP2007521741A (en) Apparatus and method for improving remote LAN connectivity using tunneling
JP2004357292A (en) System for converting data transferred on ip switched network from ipv4 base into ipv6 base
Smith et al. Network security using NAT and NAPT
US20090106831A1 (en) IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO
US8400990B1 (en) Global service set identifiers
WO2003007561A1 (en) Method for forming a secured network
Durand et al. RFC 6333: Dual-stack lite broadband deployments following IPv4 exhaustion
Anderson et al. Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode
Jarvinen Comparing IPv4 and IPv6 mobility and autoconfiguration for residential networks
Vijay et al. A Secure Gateway Solution for Wireless Ad-Hoc Networks.
Brustoloni et al. Application-independent end-to-end security in shared-link access networks
Vinayakray-Jani et al. An applicability of transition mechanisms for IPv6/IPv4 within the scope of GPRS with an Internet communication
Mun et al. Interconnection between IPv4 and IPv6
Buvaneswari et al. A Comprehensive Study on Next Generation Internet Protocol (Ipv6) and Security Vulnerabilities

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP