WO2003003664A1

WO2003003664A1 - System and method for address and key distribution in virtual networks

Info

Publication number: WO2003003664A1
Application number: PCT/SE2001/001471
Authority: WO
Inventors: Leif BYSTRÖM; David Ahlard; Joachim Bergkvist; Urban Hansson
Original assignee: Hyglo Ab
Priority date: 2001-06-27
Filing date: 2001-06-27
Publication date: 2003-01-09

Abstract

A system and method for resolving endpoint addresses and security credentials in virtual private networks (VPNs) based on a combination of server based address resolution and key distribution. The virtual network comprises a first (C3) and a second client (C2), and a server (S), in which server records are stored comprising address information for said clients. The address information in a record for a certain client comprises that client's global address in a physical global network, preferably an IP network such as the Internet, on which the virtual network resides. Preferably the address information in a record for a certain client comprises a tunnel terminator address together with a VPN id/port corresponding to a physical endpoint for that client to which data is transmitted, and security credentials for accessing that client.

Description

SYSTEM AND METHOD FOR ADDRESS AND KEY DISTRIBUTION IN VIRTUAL NETWORKS

Field of invention

The invention relates in general to computer networks and more in particular to enabling mechanisms for delegation and distribution of centralised network server functions to the edge of computer networks. More specifically, then invention relates to a mechanism for resolving endpoint addresses and security credentials in virtual private networks.

Background

Most enterprises are located at multiple sites where each site has its own local area network (LAN). A site is defined as anything from a head-quarter, or an affiliation company site, to a single employee's remote office site. Some kind of communication infrastructure is then used to interconnect the different sites. The Internet evolution can roughly be categorised into two main areas: a) Internet as the global communication infrastructure. Traditionally, companies used so called leased lines, provided by telephone companies to interconnect their sites. Separated firewall solutions were used for accessing the Internet. During the last years, companies are no longer using Internet only for external communication, more and more companies are trying out new network solutions that enables them to also use Internet for company-internal communication. Internet has become their site-to-site interconnecting medium. b) Broadband Internet access. In parallel with the above, more and more broadband access solutions are rolled out by different network access providers. This enables anyone to upgrade their access to Internet from a traditional dial-up PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) access solution to a broadband solution, e.g. ADSL (Asymmetric Digital Subscriber Line), Cable or Ethernet, with direct access to Internet. Apart from the obvious broadband benefits, the network access user is also able to always be connected to the Internet.

The common name for most of the network solutions that interconnects multiple sites over Internet is "virtual private networks" (VPN). VPNs can be implemented in numerous ways, this is well explained in e.g. the IETF RFC

(Internet Engineering Task Force Request For Comments) by B. Gleeson et. al, "A Framework for IP Based Virtual private Networks", RFC 2764, February 2000. A VPN is a private network that is configured within a public network. For years, common carriers have built VPNs that appear as private national or international networks to the customer, but physically share backbone trunks with other customers. VPNs enjoy the security of a private network via access control and encryption, while taking advantage of the economies of scale and built-in management facilities of large public networks. Today, there is tremendous interest in VPNs over the Internet, especially due to the constant threat of hacker attacks. The VPN adds that extra layer of security, and a huge growth in VPN use is expected. In general, the different VPN solutions can be categorized into two main groups; customer premises equipment (CPE) based solutions or network based solutions. Internet is a public data network based on network paradigms such as equal and best effort traffic treatment. All traffic crossing the Internet is public and insecure resulting in a number of problems that need to be solved, e.g. end-to-end security communication between enterprise sites. Some problems have solutions supported by several VPN system vendors, such as encrypted IP tunnelling between end-users using the IPSec architecture described by S. Kent and R. Atkinson in "Security Architecture for the Internet Protocol", RFC 2401, November 1998, or stand-alone firewall solutions, desktop software VPN clients, e.g. Microsoft® VPN, etc. A PC that is connected to Internet can, not easily but it is possible, be used as a transit node by a hacker, e.g. the hacker could use a Trojan horse program to get inside the PC. Well inside, the Trojan horse program may be adapted to release application software that will act as some authenticated software installed by the owner of the PC. It is very difficult for layer 2 and 3 firmware/software to detect this kind of malicious applications. Therefore, it is recommendable to have VPN control and management software and firmware functions and end-user applications, such as service login software, "authenticated" software applications that in some way uses the network infrastructure provided by the VPN service, separated on different hardware platforms. What generally should be avoided, is having PC clients that are responsible for configuring the actual VPN setup, i.e. having access to the lookup-table for other VPN members public IP addresses, having access to information on how to authenticate, perform integrity check and encrypt traffic aimed for the VPN etc.

State of the art functions for virtual private networks based on dynamic tunnelhng needs an effective mechanism to translate the VPN local destination into a global address. In addition the demands for security on these dynamic tunnels requires an equally efficient mechanism for distributing security associations for authentication and encryption. An object of the present invention is thus to provide a mechanism for address resolution in VPN's, devised to operate on top of an existing layer 3 network such as an IP or IPV6 network. Summary of the invention

According to a first aspect of the invention, a system for resolving endpoint addresses and security credentials in virtual networks is provided. Said virtual network comprises a first and a second client, and a server, in which server records are stored comprising address information for said clients.

Preferably the address information in a record for a certain client comprises that client's global address in a physical global network on which the virtual network resides. In one embodiment the address information in a record for a certain client comprises a tunnel terminator address together with a VPN id/port corresponding to a physical endpoint for that client to which data is transmitted.

Preferably the address information in a record for a certain client comprises security credentials for accessing that client.

In one embodiment said server includes a timeout mechanism for said a client's record, including means for revoking said record upon timeout. Preferably the server also comprises means for receiving a server request from a first client desiring access to a second client, and means for sending the record for said second client to said first client in response to said request. Additionally or alternatively, the server may comprise means for sending a record for a second client to a first client in anticipation of the first clients use. In a preferred embodiment said physical network is an Internet Protocol network, such as the Internet.

According to a second aspect of the invention, a method is provided for taking the steps described in this application, for resolving endpoint addresses and security credentials in virtual networks.

Brief description of the drawings

These and other features, aspects and advantages of the present invention will become better understood with reference to the following description, appended claims and accompanying drawings where Fig. 1 illustrates the system overview according to an embodiment of the present invention;

Fig. 2 illustrates traffic monitoring and session overtaking according to an embodiment of the present invention; and

Fig. 3 illustrates data and ARP signalling between processes according to an embodiment of the present invention.

Fig. 4 illustrates an emulated LAN on top of a global IP network, according to an embodiment of the invention. Detailed description of preferred embodiments

According to one aspect, the system according to the present invention is based on a standard IP network like the public Internet. The system comprises multiple VPN clients and at least one server. One server can be a distributed cluster of physical boxes. The VPN clients could be implemented as drivers on the client computer but are for security reasons preferably implemented in a stand alone hardware box. A purpose of this mechanism is to establish dynamic and secure Virtual Local area Networks between some or all of the clients. A virtual network is created by establishing connection groups in a VPN server. The server has a service device for keeping track of connected machines and mapping them to IP addresses. In one embodiment this is obtained using ARP (Address Resolution Protocol), an IP protocol used to obtain a node's physical address. A client station sends an ARP request to the VPN server with the VPN internal IP address of the target node it wishes to communicate with, and the VPN server responds by sending back the external IP address so that packets can be transmitted. ARP returns the layer-2 address for a layer- 3 address. This mechanism also handles distribution of public keys to form complete security associations. For handling broadcasts an emulated broadcast service is implemented in the server, preferably using an IP multicast group or as a separate broadcast service. Data sent directly from one machine in the virtual network to another is tunnelled over IP directly to the IP address of the receiving client. The mechanism includes both the case where data packets are tunnelled directly over IP and when an layer-2 media such as Ethernet is bridged onto the IP network.

Fig. 4 illustrates an embodiment of the system according to the present mechanism, wherein a network 4 comprises five nodes; four VPN clients 31 - 34 with global addresses Cl - C4, and a server S. All of these are connected to and have a valid address in the physical network 4. These nodes are interconnected using standard Internet routing procedures, but the clients 31 - 34 are not on the same LAN. On top of this network infrastructure, clients 31, 32 and 33 form a virtual network 30 with local addresses Dl, D2 and D3. In the illustrated case the clients in this VPN appear to be on the same local area network. The reason for this is the broadcast service, i.e. the service device, which delivers all packets for the local broadcast domain to all machines on the VPN 30. Thus service discovery mechanisms or layer-2 ARP operate transparently on top of the virtual network. When client 31 on the VPN wants to transmit a packet directly to client 32 the client-software requests the physical address C2 from server S, based upon the local address D2, and possible security keys required for talking to D2 from S. Dl is then able to transmit the packet in a secure tunnel directly to D2 without passing the server S. The above provides an effective and user friendly mechanism for establishing Virtual Private Networks over generic IP connections. Broadcast services and service discovery protocols that normally require a direct layer-2 interconnection may work independently of the actual network structure. It also provides the possibilities of distributed network broadcast handling, where rules and configuration options may be cached in the end nodes of the network instead of in a centralised server. The described mechanism is unique in that it presents a complete distributed emulated LAN on top of an IP network where access and attributes such as security associations are completely controlled by a server. Most current solutions uses static tunnels. Either permanent connections are set up between the members of the VPN or tunnel servers which basically works as modem pools only you "dial" an IP number. This means that all traffic no matter it's final destination goes through this one box. In particular traffic going to sites in the VLAN (Virtual LAN) other than that of the VLAN server comes in through the server access and turns. The broadcast service allows service discovery protocols designed for local networks to function on the VPN while the ARP mechanism allows for dynamic establishment of secure tunnels directly between endpoints. The well known LANE (LAN Emulation) standard was focused entirely on ATM (Asynchronous Transfer Mode) and featured no integrated security handling. Lane introduces, inter alia, the ability to connect Ethernet and Token Ring networks together via ATM. LANE makes the process transparent, requiring no modification to Ethernet and Token Ring stations. LANE allows common protocols, such as IP, IPX, AppleTalk and DECnet, to ride over an ATM backbone. LAN emulation has been implemented and verified over ATM. However, since the system architecture itself by design avoids sending all data through the server, the bottleneck problem with overloaded server links is completely avoided.

In general, the target system relies on a decision scheme for a third-party overtaking of a client role in a two-party communication session. Turning to Fig. 1, the system processes comprises end user clients located at the end user premises equipment 1, a central VPN system server 2, and network edge located VPN system clients 3. Full lines indicate physical communication lines, whereas arrows indicate communicating ends, without specifying which route the communication takes between those communicating ends.

The end user client process preferably resides in a PC, the VPN client process preferably resides within a standalone hardware unit, and the VPN server process resides within any kind of server hardware unit, such as an IBM® server. By process is here meant the functionality for the particular client or server, as described herein. The VPN server 2 and the VPN client 3 are parts of a VPN system that provides the end user client 1 with access to required VPNs. The end user client 1 hardware is physically connected via a communication line 11 to the VPN client 3 hardware. The VPN client 3 hardware is physically connected to a layer-two termination that enables the VPN client 3 to access Internet over a communication line 12. The layer-two protocol is preferably Ethernet but could practically be any known layer-two protocol used for the encapsulation and transport of IP (Internet Protocol) packets between IP nodes. The VPN server 2 is connected to Internet via a communication line 13 in the same way as the VPN client 3.

According to an embodiment of the target system the end user client 1 initiates a communication session with the VPN server 2 in order to acquire access to a virtual private network. During the initialisation phase, the VPN server 2 authenticates and authorises the end user client 1 as a registered user of VPN services that are provided by the VPN server 2. The VPN client 3 is passive in that it does not initiate any new information elements during the initialisation phase. The VPN client 3 also monitors 22 the communication between the end user client 1 and the VPN server 2.

When the initialisation phase between the end user client 1 and the VPN server 2 is finished, and when information has been exchanged, regarding particular VPN that the end user clients request access to, then the VPN client 3 becomes active and takes over the communication session between the end user client 1 and the VPN client 3. The VPN client 3 now requests, if it is necessary because the VPN information can already be cached by the VPN client 3, VPN configuration data from the VPN server 2. The VPN client 3 uses the configuration data to configure necessary VPN access parameters such as traffic classification parameters, performance assurance parameters, or firewall parameters such as encryption, authentication, filtering parameters, etc.

The end user client 1 is allowed to use different VPN servers 2 but cannot have simultaneous access to more than one VPN server 2. The VPN client 3 detects when an end user client 1 tries to access a certain server 2. At this moment the VPN server 2 is considered insecure until the end user client 1 has authenticated the VPN server 2 and also have been authenticated by the VPN server 2.

The monitoring and session overtaking scenarios are described more in detail in Fig. 2. The VPN client 3 has one trusted domain, which is the end user client 1 side, and one distrusted domain, the Internet domain. From the VPN client's 3 point of view, the VPN server 2 is therefore located in the distrusted domain. Since all in- and outgoing IP traffic to/from the end user client passes through the VPN client 3 hardware, the VPN client 3 is able to monitor the communication between the end user client 1 and the VPN server 2. This is true if, and only if, the IP traffic not is encrypted in such a way that the VPN client 3 is unable to decrypt the IP traffic. The VPN client 3 software resides on hardware that physically interconnects the end user client 1 with Internet 4. The VPN client 3 is therefore able to monitor all traffic between the VPN client 3 and different VPN servers 2 to whom the end user client 1 are registered as user.

The VPN client 3 identifies when the end user client 1 starts to establish contact with a VPN server 2. The VPN client 3 treats the end user client 1 side as a trusted party and the VPN server 2 as a distrusted party. The session establishment phase 21 between the end user client 1 and the VPN server 2 could be done in numerous ways, e.g. by a traditional challenge/response handshaking sequence. The communication 21 is primarily meant to be done by web based clients but other client/server process environment solutions are possible. When the handshaking sequence between the end user client 1 and the VPN server 2 has finished, the VPN client 3 takes over the communication session. The handshaking is considered finished when the VPN server 2 has authenticated and authorised the end user client 1, and acknowledged the end user client 1 as a confirmed user. The VPN client 3 will from now on undertake proxy roles towards both the end user client 1 and the VPN server 2. Towards the end user client 1, the VPN client 3 will act as a VPN server proxy, and towards the VPN server 2 as an end user client proxy. The end user client 1 will continue it's session in belief that it still communicates with the VPN server 2. The VPN client 3 will, using the VPN server proxy role, continue the VPN setup session with the end user client 1.

Further on, the VPN client 3 is now considering the VPN server 2 as a secure source and starts up communication sessions 23 with the VPN server 2 that enables the end user client 1 to be included as members in the requested VPN.

In one embodiment the target system is implemented in a service provisioning system, where parts of the service functionality are distributed to system clients acting as server proxies. One technical advantages of the present system is that any hacker intrusions via an end user PC 1 are avoided by having critical software/firmware for control and management of VPN configuration data separated on standalone hardware 3. Another advantage is the automated overtaking of certified sessions. Another benefit is the plug-and-play behavior for virtual services over Internet, which is made available through the system. The teachings of the present system thus differs from prior art technology, since earlier solutions to the problem have either been centralised server solutions, such as PSTN/ISDN modem-pool solutions, server centralised IP Sec tunnelling etc, or distributed solutions, which are only valid within one network operator intra-domain or within federated network operator domains. These solutions are generally referred to as network based VPN systems. The present system will function independently of whether or not the different VPN client users access the same network operator domain or a federated network domain or have access to totally independent network operator domains.

The present invention provides a mechanism for address resolution in VPN's. It operates on top of an existing layer 3 network such as a IP or IPV6 network and uses a centralised but possibly distributed ARP (Address Resolution Protocol) service. ARP is an IP protocol used to obtain a node's physical address. A client station sends an ARP request to the VPN server with the internal IP address of the target node it wishes to communicate with, and the VPN server responds by sending back the external IP address so that packets can be transmitted. The mechanism according to the invention also includes distribution of security keys associated with each physical endpoint.

Fig. 3 illustrates an embodiment of the invention, comprising a system having a protocol for resolving endpoint addresses and security credentials for virtual private networks. The system comprises a server S, which may be distributed, and a number of clients C1-C3. According to the invention a mechanism uses records containing global address and security credential for accessing a client. In general, each record comprises the local address, the physical endpoint to which data is transmitted, i.e. tunnel terminator address and VPN id/port, and a key to use for this endpoint. Records are normally sent upon request to members C1-C3 of a VPN but the server S may decide to send one or more records to the client in anticipation of their use. Preferably, each record has a timeout mechanism for robust operation. Should a frequently used client, e.g. Cl, leave the network the server S may decide to revoke the record for that client Cl before the natural timeout to avoid unnecessary requests. For small networks this behaviour might be sufficient so that each client C1-C3 may always have a current list of which other clients are available and how to reach them. For a larger network the pre-caching is used only for frequently used machines such as servers and routers. In general the server S can distribute any type of endpoint addresses. In the special case of the clients being connected to an IP network the addresses in question are IP addresses.

Referring now to Fig. 3, the server mechanism and the method according to this embodiment of the invention works as follows. When a client C3 wants to transmit data to a client C2 of which it has no previous record, said client C3 first sends a server request to the server S, in order to get the information required to set up a security association for the client C2. In one embodiment, the server request includes the destination address for the target client C2. The server S looks up the relevant data for client C2 in a storage record. As previously described, each such record preferably comprises the local address, the physical endpoint to which data is transmitted, i.e. tunnel terminator address and VPN id/port, and a key to use for this endpoint. The server responds to the request by sending a server response to the requesting client C3, where said server response includes the record for C2, or parts of the information contained in said record. Having received the server response, client C3 has the address information needed to find client C2, and the security credentials to access client C2. The client Cl who already has a valid security association for C2 can transmit data directly to C2 for the duration of their security association.

The solution according to the present invention differs from earlier known technology in that dynamic address and key resolution is not used in existing IP VPN products. The combination of server based address resolution and key distribution is a powerful combination assuring that complete security associations are distributed on demand, which allows for dynamic establishment of secure tunnels between endpoints.

Claims

1. System for resolving endpoint addresses and security credentials in virtual networks, said virtual network comprising a first (C3) and a second client (C2), and a server (S), in which server records are stored comprising address information for said clients.

2. The system as recited in claim 1, wherein the address information in a record for a certain client comprises that client's global address in a physical global network on which the virtual network resides.

3. The system as recited in claim 2, wherein the address information in a record for a certain client comprises a tunnel terminator address together with a VPN id/port corresponding to a physical endpoint for that client to which data is transmitted

4. The system as recited in claim 3, wherein the address information in a record for a certain client comprises security credentials for accessing that client.

5. The system as recited in claim 4, wherein said server includes a timeout mechanism for said a client's record, including means for revoking said record upon timeout.

6. The system as recited in claim 5, wherein said server comprises means for receiving a server request from a first client (C3) desiring access to a second client (2), and means for sending the record for said second client to said first client in response to said request.

7. The system as recited in claim 5, wherein said server comprises means for sending a record for a second client to a first client in anticipation of the first clients use.

8. The system as recited in claim 2, wherein said physical network is an Internet Protocol network.