CA2266086A1 - Method of gateway redundancy for use in secure network communication - Google Patents

Method of gateway redundancy for use in secure network communication Download PDF

Info

Publication number
CA2266086A1
CA2266086A1 CA002266086A CA2266086A CA2266086A1 CA 2266086 A1 CA2266086 A1 CA 2266086A1 CA 002266086 A CA002266086 A CA 002266086A CA 2266086 A CA2266086 A CA 2266086A CA 2266086 A1 CA2266086 A1 CA 2266086A1
Authority
CA
Canada
Prior art keywords
gateway
network
initiator
address
status
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
CA002266086A
Other languages
French (fr)
Inventor
Brett Howard
Roy Pereira
Timothy John Jenkins
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Canada Inc
Original Assignee
TimeStep 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 TimeStep Corp filed Critical TimeStep Corp
Priority to CA002266086A priority Critical patent/CA2266086A1/en
Publication of CA2266086A1 publication Critical patent/CA2266086A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Abstract

In accordance with the invention a method for robust secure network communication is provided. A workstation is connected to a private network via a public network. The private network has access to the public network through a plurality of gateways. To ensure robust secure network communications the initiator of a secure communication session polls the gateway periodically during the course of the communication session to determine a status of the gateway. When the status of the gateway is indeterminate or failed, a new secure communication session between the initiator and a second other gateway is established and the resource is provided with a second destination address for the initiator. In another embodiment according to the invention two private networks, each having a plurality of gateways, are connected to each other via a public network.

Description

Doc. No. 79-3 CA Patent METHOD OF GATEWAY REDUNDANCY FOR USE IN SECURE NETWORK
COMMUNICATION
Field of the Invention The invention relates generally to secure network communications and more particularly to robust secure network communications using two or more gateways.
Background of the Invention In general form, computer networks are composed of a set of resource entities such as servers, workstations, printers, gateways, modems, etc.; a set of requestor entities such as users, user groups, and programs that access resources to retrieve data or manage resources; and means of communicating between the two sets of entities including for example the network itself, routers, protocols, etc. Network nodes often belong to more than one of the above sets.
Connecting geographically separate computer systems or networks together is a common business need. Often the best interface for such a connection is for the remote system or network to appear as if it were on the local network. In many cases the most cost-effective medium for connecting remote systems is a public network such as the Internet, public switched telephone networks or other common carrier data networks. A
common method for providing a network-like connection using a public network is known as Virtual Private Network (VPN). Basically, a VPN provides a means of transparent communication through a public network. This results in remote workstations and/or remote sections of the network appearing physically connected to the network through dedicated communication cables. Users using workstations at different physical locations separated by the public network are often provided with little indication of the public network - to them, the public network is merely another "cable."
In many cases VPNs compromise data security and integrity by exposing network communications and networks involved to unauthorized intrusion. In order to increase security the Internet Engineering Task Force (IETF) has developed the IPSEC
standard.

Doc. No. 79-3 CA Patent IPSEC is an extension to TCP/IP that utilizes data encryption methods and digital certificates mechanisms to positively verify an identity of a user or a workstation. While the IPSEC is specific to the TCP/IP protocol suite, the certificates, encryption mechanisms and general principles stipulated in IPSEC are also applicable to other computer communication networks. Implementation of IPSEC results in a Secured Virtual Private Network or SVPN.
The common implementation of a secured VPN calls for a security gateway to be placed at the interface point between the secured network and the public, unsecured network. Data and access rights on the secured side of the security gateway are controlled using conventional network access control methods while data flow to and from the unsecured network is encrypted and controlled by the security gateway, commonly referred to as a gateway.
One method of rendering the public network transparent is known as tunneling.
When tunneling is employed, a user directs information to a recipient and resources within the network transparently route the information to the recipient. One method of accomplishing tunneling begins with information for transmission to a destination being determined and packaged. The package is sent to an appropriate gateway from which it is sent to its destination. The destination is necessarily a system in direct communication with the network. When the destination is not in direct communication with the network, the sent information is sent to a gateway first and from there directed toward the correct destination. Thus far, for a network to network communication, we have three communications - source-gateway, gateway-gateway, gateway-destination.
Another concern in designing systems supporting tunneling is that each network likely supports an internal addressing scheme that is different from another.
For example, even when each network supports IP addresses, each network is separated from the public network by a gateway so address distribution is not limited by address distribution in the connected public network. A node in a private network can easily have a same IP address as a node on the public network and further, the same address as numerous nodes on Doc. No. 79-3 CA Patent other private networks. This presents an interesting challenge in designing a tunneling system that is transparent and robust.
For example, in order to support the address duplication, which is inherently possible with private networks, a destination is assigned an address by a gateway.
Messages sent from that "destination" address are assigned an address relating to a gateway.
When two or more gateways are used concurrently, there is potential for both load sharing and/or redundancy. Unfortunately, true redundancy results in a significant increase in expense. For example, to maintain two gateways per gateway node address requires two gateways and a system for controlling which gateway is functioning at any given time. The incremental cost is significant. Also in order to maintain security of encryption keys, the two gateways would likely be housed together for any such an implementation. This allows each gateway to access encryption key data. This allows for improved communication between the gateways but also makes it difficult to gain some of the benefits of redundancy. These benefits are gained through connection of the redundant gateways to different networks and locating the gateways in different locals;
this protects against fire, network failure, and catastrophic power failure.
Alternatively, when a single redundant gateway exists, it is difficult if not impossible for it to assume the role of a failed gateway transparently and properly. Firstly, establishing network address and setting up accurate communications absent foreknowledge of which gateway will fail, is near impossible. Further, having a gateway on standby at all times adds to the cost of a gateway to any existing communication system.
Statement of the Invention In accordance with the invention a method of maintaining robust secure network communications is provided. A workstation is connected to a private network via a public network. The private network has access to the public network by a plurality of gateways.
The workstation establishes a secure communication session to a resource within the private network by contacting a gateway and determining encryption and authentication Doc. No. 79-3 CA Patent algorithms, keys, and protocols for communicating securely. After establishing the secure communication, the gateway receives a request and subsequently forwards the request to the resource within the private network. The gateway, in forwarding the request, decrypts and retransmits the request providing it with a correct destination address and a source address indicative of the gateway and of the workstation. The resource, in order to communicate with the workstation transmits information to the reply address provided by the gateway. This information is routed to the gateway. The gateway translates the address to the address for the workstation - the actual reply address.
According to the invention, the workstation polls the gateway periodically during the communication session in order to determine its status. As long as all is well, the communication session continues. When the gateway fails to respond the workstation initiates a similar communication session with the network using a different gateway. This then allows for continued communication. In another embodiment according to the invention two private networks, each having a plurality of gateways, are connected to each other via a public network.
Brief Description of the Drawings Exemplary embodiments of the invention will now be described in conjunction with the drawings in which:
Fig. 1 illustrates a workstation connected via a public network to a private network, the private network having a plurality of gateways;
Fig. 2 illustrates two private networks, each having a plurality of gateways, connected via a public network;
Fig. 3 is a simplified diagram relating to communication for a network topography shown in Fig. 1;
Fig. 4 is a simplified diagram relating to communication for a network topography shown in Fig. 2;
Fig. 5 illustrates a workstation connected via a public network to a private network, the private network having a key contact gateway and a plurality of gateways;

Doc. No. 79-3 CA Patent Fig. 6a illustrates two private networks, each having a plurality of gateways, connected via a public network, Fig. 6b is a table of extranet addresses for a gateway in LAN A in Fig. 6a;
and, Fig. 6c is a topography description table.
Detailed Description of the Invention Referring to Figs. 1 and 2, simplified block diagrams of computer networks are shown. In Fig. l, the computer network comprises a private network 1 in communication with a public network 3 via a plurality of gateways 4a, 4b, 4c, and 4d. Though in the diagram, the gateways appear geographically proximate to each other, this need not to be so. Gateways are often located in different buildings and connected to the public network differently to enhance robustness of private/public network connections. A
workstation in communication with the public network 3 and for accessing the private network 1 is also shown. In Fig. 2, the computer network comprises two private networks 1 and 2 connected by a public network 3. Each private network 1, 2 has one or more gateways 4, 5, respectively, in communication with the public network 3. The gateways 4, 5 act to secure communications between the private networks 1 and 2 and to direct communications received from the public network 3 to an appropriate address within the private network.
Referring to Fig. 3, a simplified diagram relating to communication for a network topography such as that shown in Fig. I is shown. A communication session is initiated by the workstation 10. Initiation of a communication session commonly comprises a step of establishing a security association between two end-points The security association is between one of the gateways 4a, 4b, 4c, and 4d of the private network 1 and a workstation. The workstation 10 may select a specific gateway. Alternatively another method for the determination of a gateway with which to associate is used. One such method includes determination of the gateway by the private network 1 on the basis of load sharing and transmission of results of the determination to the workstation 10.

Doc. No. 79-3 CA Patent For example, to establish a secure communication session with a resource 20, the workstation 10 sends a request to establish a security association between two end-points to a gateway 4a. During establishment of a security association between the two end-points, the workstation 10 and the gateway 4a determine encryption and authentication algorithms, keys, and protocols for communicating securely. This information is used to establish a secure communication between the workstation 10 and the gateway 4a. After establishing the secure communication, the gateway 4a receives a request and subsequently forwards the request to the resource 20 within the private network 1. The gateway 4a, in forwarding the request, decrypts and retransmits the request providing it with a correct destination address - interpreted for the private network - and a source address indicative of the gateway 4a and of the workstation 10. Correct source information is essential for several reasons. First, the gateway 4a with which the workstation 10 is communicating has already established a secure communication link including, for example, exchange of asymmetric encryption keys. Switching gateways would prevent the secure communication from proceeding correctly. Second, the gateway is prepared to redirect return messages from the resource 20 to the workstation 10 whereas other gateways may not be capable due to a lack of information regarding the workstation 10. Third, directing a message to other than the appropriate gateway - for example directing the message back to its actual source "reply" address - may lead to address conflicts within the private network since, as is well known, the private network address scheme need not follow strict addressing requirements of a public network.
The resource 20, in order to communicate with the workstation 10 transmits information to the reply address provided by the gateway 4a. This information is routed to the gateway 4a. The gateway 4a translates the address to the address for the workstation 10 - the actual reply address. This is accomplished, for example, using a lookup table. The message is then secured and transmitted. It is evident that should gateway 4a fail during a communication session, problems will occur. These problems result from the following: workstation 10 has no information relating to the gateway failure; when communication ceases, from a perspective of workstation 10, the entire Doc. No. 79-3 CA Patent private network appears to have failed; no other gateway on the network can decode secured communication from the workstation 10 absent the session key of gateway 4a;
and, resources on the private network 1 have no information relating to the gateway failure. Further, to the resource 20, the gateway 4a appears as a plurality of different destination/source addresses - one address per source.
Therefore it is essential that a method of recovering from gateway failure exist. To this end, the present invention provides a method of detecting a gateway failure and of minimizing interruptions in communication caused thereby.
Of course, a resource cannot correct the problem when it arises because the resource does not know that a workstation 10 exists. In fact, the address the resource is using points to the gateway 4a, which in turn secures the data within the communication and translates the address to that of the source - the reply address.
Unfortunately, with gateway 4a malfunctioning, translation by gateway 4a is now impossible;
however, the workstation 10 initiated the session and therefore, it can recommence such a session when interrupted. According to the invention, the workstation 10 automatically polls the gateway 4a periodically during the communication session in order to determine its status. As long as all is well, the communication session continues. When the gateway 4a fails to respond - the communication session is not functioning - the workstation 10 initiates a similar communication session with the network using a different gateway.
Preferably in a new communication session once started, the last sent request that is incomplete is first sent in order to ensure that no data was lost during the breakdown of gateway 4a. This then allows for continued communication. The previous communication session with the resource 20 is terminated upon a time out. Time outs and their use for cleaning up open communication sessions are well known in the art.
Methods of tracking communications in progress such as file downloads etc. are known and may be employed with the present invention. Alternatively, all communication requests that are pending are automatically restarted once the new Doc. No. 79-3 CA Patent communication session is initiated. Further alternatively, communication requests are restarted manually by a user of the workstation 10.
The benefits of such a system where the initiator of a communication - the source - verifies the status of gateways within the communication path is even more evident when two private networks or two portions of a private network are connected via a public network. Referring to Fig. 4, a simplified diagram relating to communication for a network topography such as that shown in Fig. 2 is shown. A communication session is initiated by the workstation 10, here being part of a private network 2. The workstation selects a gateway Sc of the private network 2 to connect to the public network 3.
Alternatively, other methods to determine the gateway are used. The request for establishment of a security association between two end-points is transmitted via the gateway Sc to one of the gateways 4a to 4d of the private network 1.
For example, to establish a secure communication session with a resource 20, the workstation 10 sends via gateway Sc a request to establish a security association between two end-points to a gateway 4a. During establishment of a security association between two end-points the gateway Sc and the gateway 4a determine, as necessary, encryption and authentication algorithms, keys, and protocols for communicating securely.
This information is used to establish a secure communication via the public network 3 between the two gateways Sc and 4a. The workstation 10, in order to communicate with the resource 20 transmits a request to the destination address provided by the gateway Sc.
This request is routed to the gateway Sc. The gateway Sc translates the address to the address for the resource 20 - the actual destination address for a communication originating at the public network 3. This is accomplished, for example, using a look up table. The request is then secured and transmitted to the gateway 4a. The gateway 4a receives the request and subsequently forwards the request to the resource 20 within the private network 1. The gateway 4a, in forwarding the request, decrypts and retransmits the request providing it with a correct destination address and a source "reply" address indicative of the gateway 4a and of the workstation 10. The resource 20, in order to Doc. No. 79-3 CA Patent communicate with the workstation 10 transmits information to the reply address provided by the gateway 4a. This information is routed to the gateway 4a. The gateway 4a translates the address to the address for the gateway Sc and workstation 10 -the actual reply address. This is accomplished, for example, using a lookup table. The message is then secured and transmitted. The gateway Sc receives the message, decrypts and retransmits the message to the workstation 10.
It is evident that should one of the gateways Sc or 4a fail during a communication session, problems would occur. Should gateway 4a fail, problems result from the following; workstation 10 has no information relating to the gateway failure;
when communication ceases, the entire private network 1 appears to have failed from a perspective of workstation 10; no other gateway 4 on the network 1 can decode secured communication from the workstation 10 absent the private key of gateway 4a;
and, resources on the private network 1 have no information relating to the gateway failure. In case of a failure of gateway Sc the problems result from the following;
workstation 10 has no information relating to the gateway failure; when communication ceases, the entire private network 1 as well as the public network 3 appear to have failed from a perspective of workstation 10; no other gateway 5 on the network 2 can encode secured communication from the workstation 10 or decode secured communication from the resource 20 absent the private key of gateway 5c; and, resources on the private network 1 have no information relating to the gateway failure.
According to the invention, the workstation 10 polls the gateways Sc and 4a periodically during a communication session in order to determine their status. When all is well, the communication session continues. When the gateway Sc fails to respond the workstation 10 selects another gateway 5 to initiate a similar communication session with a gateway from the gateways 4. This may be gateway 4a or any other gateway since the secure communication session is lost. In case gateway 4a fails gateway 5c or another gateway 5 initiates a similar communication session with another gateway 4.
This is initiated by the workstation 10. The new secure communication session allows for continued communication between the workstation 10 and the resource 20.
Preferably Doc. No. 79-3 CA Patent during a new communication session once started, the last sent request that is incomplete is first sent in order to ensure that no data is lost during the breakdown of one of the gateways. This then allows for continued communication. The previous communication session with the resource 20 is terminated upon a time out or some other method of clearing interrupted communication sessions.
In another embodiment according to the invention shown in Fig. 5, the workstation 10 contacts a key contact gateway 400. The key contact gateway 400 then refers the workstation 10 to a gateway 4a on the basis of load sharing. Here, the initiator of a secure communication session polls periodically the key contact gateway 400, for a status of gateway 4a. The key contact gateway 400 maintains information relating to gateway status of gateways within the network. Optionally, the key contact gateway also controls gateway allocation and some other gateway functions. Alternatively, the key contact gateway 400 notifies the workstation 10 when a malfunctioning of the gateway 4a is detected. If the status of gateway 4a indicates a malfunction, the initiator of the secure communication session contacts the key contact gateway 400 again in order to establish another similar communication session. The key contact gateway 400 then refers the workstation 10 to another gateway.
Advantageously, in this embodiment the gateways are polled periodically only by the key contact gateway instead of all their clients thus reducing their workload reporting status information. For example, when a gateway supports 256 simultaneous communication sessions and polling is performed every 6 seconds, over 2,500 status queries occur each minute. This is significant in terms of load on the network and on the gateway. Alternatively, when the key gateway 400is used, the gateway is polled only 10 times in each minute and the key gateway handles the requests for status information.
Alternatively, when the key gateway notifies the workstations of gateway failure, network communication is also reduced.
In yet another embodiment according to the invention the workstation 10 contacts a key contact gateway 400 which maintains all the information necessary for secure Doc. No. 79-3 CA Patent communication such as addresses, encryption and authentication algorithms, keys, and protocols. The key contact gateway 400 then refers the workstation 10 to a gateway 4a on the basis of load sharing. Here, the key contact gateway 400 monitors the status of the other gateways. If the gateway 4a is malfunctioning the key contact gateway then redirects the secure communication session to another gateway and provides the information necessary for secure communication to the other gateway. The resulting system is highly flexible but, because of communication via the private network of private keys from the key contact gateway to other gateways, security is greatly reduced.
In a further embodiment according to the invention the gateways send a time signal to all their clients. An initiator of a secure communication session receives the time signal and the communication session continues. In the absence of the time signal, indicating a malfunctioning of the gateway, the initiator establishes a similar communication session with another gateway. Such an embodiment is useful where network resources are reliable and sufficient to transport the time signal as necessary.
Generally, such a system is a good method of polling for status information without having to first transmit a request relating to status. This reduces gateway load considerably and also reduces overall network traffic.
The method of the present invention is simple, effective, and low cost. It is therefore advantageous over prior art attempts at solving the above noted problems.
Though the above disclosure discusses gateway failure and redundancy, a similar method is also applicable to load sharing. However, as will be evident to those of skill in the art, because load sharing involves substantially planned activities, it is preferable that communications are terminated upon completion of current communications so as to prevent interruption and restarting of communications in progress. Of course, where load balancing of gateways is more important than performance of individual sessions, this is not necessary.
An application of an exemplary embodiment of the invention is discussed with reference to Figs. 6a, 6b, and 6c. Two enterprise networks local area network (LAN) A

Doc. No. 79-3 CA Patent and LAN B are linked using a VPN in a redundant manner. As noted above, overlapping addresses may exist since, within a LAN illegal IP addresses are supported. As shown in Fig. 6a, the client is in LAN A while the server is in LAN B. As shown, the client and server share the same IP address ( 10.1.1.1 ). It is clear that the client is not able to address the server directly. Instead, the server's address is mapped to one that is routed within LAN A to a gateway, for example gateway 10.4.1.3. Preferably, the mapped IP
address is contained within a DNS. The gateway 10.4.1.3 knows about the mapped IP address and its correspondence to 10.1.1.1 in LAN B.
The client begins a session with a server, such as b.srv by issuing a DNS
query, which returns a mapped address of 10.4.1.3. Packets are routed to the gateway with (src,dst) as (10.1.1.1,10.4.1.3). The gateway then uses the Extranet table to decode the received mapped destination.
The dst address matches a third line within the table - "LAN B, 10.1.1.1 ".
Then, the informaiton is routed to its correct destination. This is done, for example, using a static map or a topography description table such as that shown in Fig. 6c.
There is not a unique path to LAN B within the topography description table.
Therefore, the gateway selects a destination gateway at random or using a known algorithm. It performs PAR to obtain an address representative of the client on the LAN
B. For example, when 127.9.4.19 is the selected gateway, 10.5.7.7 may be returned. The gateway 10.4.1.3 has enough information to remap and then encapsulate the packet. The packet is first converted from ( 10.1.1.1,10.4.1.3) to ( 10.5.7.7,10.1.1.1 ).
The destination IP
address is the IP address of b.srv, which happens to be identical in this example to the client IP address on LAN A. Sometimes when the IP addresses have changed, the packet data contents are NATed, network address translation is performed. The packet is then encapsulated gateway to gateway, as in: ( 124.12.113 .3,127.9.4.19) [ 10.5 .7.7,10.1.1.1 ] .
The packet is sent over a public network in the form of a wide area network (WAN) to the destination gateway where it is decapsulated to (10.5.7.7,10.1.1.1). No Doc. No. 79-3 CA Patent further Network address translation (NAT) is required. The packet is then routed to the server.
A return packet reverses the addressing and therefore reaches the client system.
The packet is addressed (10.1.1.1,10.5.7.7). The destination address, 10.5.7.7, results in routing of the packet to the same gateway that received the incoming packet.
The gateway, having noted the correspondence between the address it assigned ( 10.5.7.7) and the requesting gateway (124.12.113.3) encapsulates the packet as:
(127.9.4.19,124.12.113.3)[10.1.1.1,10.5.7.7].
The packet is routed back through the WAN to the originating gateway which decapsulates the packet. The packet is then NATed, undergoes network address translation, with the source converted back to 10.4.1.3 and the destination converted to 10.1.1.1. The packet is then placed on LAN A as ( 10.4.1.3, 10.1.1.1 ) where it will be routed as usual to the client.
Of course, the encapsulation itself is useful in delivering the packets, but more useful because it allows the virtual private network (VPN) to support gateway redundancy and load sharing. When a gateway selected from the Extranet table fails to respond, other gateways are selected, when avaialble. Those gateways that fail to respond are noted. For example, they are erased from the Extranet table.
Alternatively, they are flagged to prevent use thereof and polled periodically until they respond;
when they respond, the flag is removed.
Because of the use of illegal and repeated IP addresses within local area networks the issue of encapsulation is significant. Of course, where addressing is unique and correct, some of the above noted steps may be omitted. For example, a network accessible Extranet table will allow for storage of which client is connected to which server through which gateway.
Numerous other embodiments of the invention may be envisaged without departing from the spirit or scope of the invention.

Claims (16)

Claims What is claimed is:
1. A method of providing robust secure network communications comprising the steps of:
a) establishing a secure communication session between an initiator and a resource via a gateway, the resource receiving from the gateway a reply address for the initiator;
b) at intervals, the initiator automatically polling to determine a status of the gateway; and c) when the status of the gateway is one of indeterminate and failed, establishing a new secure communication session between the initiator and a second other gateway including the step of providing the resource with a second reply address for the initiator.
2. The method of claim 1 wherein the second reply address is a second other reply address for directing the communication to the second other gateway and wherein the second reply address is indicative of the initiator.
3. A method of providing robust secure network communications as defined in claim 1 wherein the network communications comprise communications between a workstation and a private network via a public network, the private network being connected to the public network by a plurality of gateways.
4. A method of providing robust secure network communications as defined in claim 1 wherein the network communications comprise communications between a workstation within a private network and a second other portion of the private network via a public network, each portion of the private network being connected to the public network by a plurality of gateways.
5. A method of providing robust secure network communications as defined in claim 1 wherein the network communications comprise communications between two private networks via one or more public networks, the private networks each being connected to a public network of the one or more public networks by a plurality of gateways.
6. A method of providing robust secure network communications comprising the steps of:
a) establishing a secure communication session between an initiator and a resource via a gateway, the resource receiving from the gateway a reply address for the initiator;
b) at intervals, receiving a status signal indicative of gateway status, the status signal received by the initiator; and c) when the status of the gateway is indeterminate or failed, establishing a new secure communication session between the initiator and a second other gateway including the step of providing the resource with a second reply address for the initiator.
7. The method of claim 6 wherein the second reply address is different from the reply address and wherein the second reply address is indicative of the initiator.
8. A method as defined in claim 6 wherein the step of at intervals, providing a status signal comprises the step of: the initiator polling the gateway to determine a status thereof.
9. A method as defined in claim 6 wherein the step of at intervals, providing a status signal is performed by a system polling the gateway to determine a status thereof and the system communicating a signal based on the determined status to the initiator.
10. A method of providing robust secure network communications comprising the steps of:
a) contacting a key contact gateway in order to establish a communication session between an initiator and a resource;
b) establishing a secure communication session between the initiator and the resource via a gateway, the gateway determined by the key contact gateway;
c) the resource receiving from the gateway a reply address for the initiator;

d) at intervals, receiving from the key contact gateway status information relating to the gateway;
e) when the gateway is failed, repeating steps (a) through (e).
11. A method as defined in claim 10 wherein the step of at intervals, receiving from the key contact gateway status information relating to the gateway is performed by the initiator polling the key contact gateway for the information and the key contact gateway providing the status information in response to being polled.
12. A method of providing robust secure network communications as defined in claim 10 wherein the step of at intervals, receiving from the key contact gateway status information relating to the gateway comprises the key contact gateway notifying the initiator of a secure communication session in case of a malfunctioning of the gateway.
13. A method of providing robust secure network communications comprising the steps of:
a) providing a client computer within a first network;
b) requesting a destination address for a destination system, with the client computer;
c) receiving a destination address, the destination address indicative of a gateway within the network for accessing an insecure network; when more than one gateway is connected to a network, the destination address determined in order to balance load between the more than one gateway;
d) transmitting data from the client to the destination address;
e) receiving the transmitted data at the gateway;
f) establishing a secure communication session between the gateway and the destination;
g) re-encapsualting the data having a source address indicative of the gateway and a destination address indicative of the destination system; and, h) transmitting the re-encapsulated data from the gateway via the insecure network to the destination system.
14. A method as defined in claim 13 wherein the destination system is another gateway.
15. A method as defined in claim 13 wherein in the step (c) the destination address is determined through a random selection between available gateway addresses.
16. A method as defined in claim 13 comprising the step of:
when the gateway has substantially more traffic than other gateways on a same network, terminating some secure communication sessions.
CA002266086A 1999-03-17 1999-03-17 Method of gateway redundancy for use in secure network communication Abandoned CA2266086A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA002266086A CA2266086A1 (en) 1999-03-17 1999-03-17 Method of gateway redundancy for use in secure network communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CA002266086A CA2266086A1 (en) 1999-03-17 1999-03-17 Method of gateway redundancy for use in secure network communication

Publications (1)

Publication Number Publication Date
CA2266086A1 true CA2266086A1 (en) 2000-09-17

Family

ID=29588569

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002266086A Abandoned CA2266086A1 (en) 1999-03-17 1999-03-17 Method of gateway redundancy for use in secure network communication

Country Status (1)

Country Link
CA (1) CA2266086A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113422844A (en) * 2021-06-21 2021-09-21 浪潮云信息技术股份公司 Method for realizing double-living network address conversion gateway

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113422844A (en) * 2021-06-21 2021-09-21 浪潮云信息技术股份公司 Method for realizing double-living network address conversion gateway

Similar Documents

Publication Publication Date Title
US7366894B1 (en) Method and apparatus for dynamically securing voice and other delay-sensitive network traffic
KR100261379B1 (en) Lightweight secure communication tunnelling over the internet
US7155740B2 (en) Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode
US6529513B1 (en) Method of using static maps in a virtual private network
US6591306B1 (en) IP network access for portable devices
EP1413094B1 (en) Distributed server functionality for emulated lan
EP1304830B1 (en) Virtual private network management
US7447901B1 (en) Method and apparatus for establishing a dynamic multipoint encrypted virtual private network
US7376743B1 (en) Method and apparatus for load balancing in a virtual private network
US7480794B2 (en) System and methods for transparent encryption
US7251824B2 (en) Accessing a private network
US20020124090A1 (en) Method and apparatus for data communication between a plurality of parties
US20020016926A1 (en) Method and apparatus for integrating tunneling protocols with standard routing protocols
US8117273B1 (en) System, device and method for dynamically securing instant messages
McPherson et al. Architectural considerations of IP anycast
JP2004507169A (en) Clustering VPN Devices Using Network Flow Switch
US11831607B2 (en) Secure private traffic exchange in a unified network service
WO2021082803A1 (en) Routing information transmission method and apparatus, and data center interconnection network
US7953070B1 (en) Client configuration download for VPN voice gateways
WO2002017558A2 (en) Method and apparatus for data communication between a plurality of parties
Cisco Configuring PPP for Wide-Area Networking
Cisco Configuring PPP for Wide-Area Networking
Cisco Configuring PPP for Wide-Area Networking
Cisco Configuring PPP for Wide-Area Networking
Cisco Configuring PPP for Wide-Area Networking

Legal Events

Date Code Title Description
FZDE Discontinued
FZDE Discontinued

Effective date: 20030317