Secure network connection for devices on a private network

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to the formation and use of secure network connections. More specifically, the present invention relates to forming secure network connections for devices located within a private network.

[0003] 2. Description of the Related Art

[0004] Computer networks, and in particular Wide Area Networks (WANs) such as the Internet, provide opportunities for the misuse and abuse of communications traveling thereover. For example, two users communicating via the WAN may have their communications intercepted and/or altered. Also, it is possible for one user to misrepresent his or her identity to another user. As a final example, a user may utilize network resources and communications to disrupt all or part of the network.

[0005] Thus, there is a need for both privacy and authentication between users of the WAN communicating with one another. In other words, users should be able to rely on the fact that their transmissions will not be intercepted or altered, and that transmissions from someone purporting to be a particular user do in fact originate from that user.

[0006] One type of defense against ill-intentioned uses of the WAN is a device operating at the edge of a private network, such as a Gateway, Firewall or some other dedicated network appliance. Such a device operates to filter transmissions between the private network and the WAN and/or to protect the transmissions that do go through by encrypting/decrypting (i.e., encoding/decoding) those transmissions.

[0007] Other related types of defenses function by establishing the identity of a sender and/or recipient before sending/receiving a communication. Still other defenses include establishing a secure channel between two communicating devices.

[0008] A particular conventional protocol for providing security between devices operating over an Internet Protocol (IP) network is known as IPsec. Short for IP Security, IPsec is a set of protocols supporting the secure exchange of IP packets at a network layer. Two of the protocols used are the Authentication Header protocol (AH) and the Encapsulating Security Payload protocol (ESP).

[0009] AH is designed to ensure that transmitted packets are not altered during transit over the network, but does not protect the contents of the packets from being viewed by other users of the network such as intercepting parties. ESP, on the other hand, ensures the confidentiality of the packet contents. ESP provides an optional authentication mechanism; however, this mechanism is only for authenticating the data payload of the packet (and associated ESP headers/trailers). Therefore, ESP does not authenticate an IP Header of a packet indicating an original IP address on the network from which the packet originated. It is also possible to use AH and ESP in conjunction with one another, in order to achieve the advantages of both.

[0010] Whether using AH or ESP, IPsec operates in either transport or tunnel mode. Transport mode is often used in host-to-host communications; i.e., when the peer devices are the endpoints of communication. Transport mode is most useful within an overall IPsec environment including the two endpoints. Tunnel mode is typically used in communications between an IPsec-protected system and some other endpoint, such as communications sent from a private network over the Internet. In tunnel mode, the payload of a secured IP packet carries another packet containing the actual data payload to be transmitted.

[0011] A common use of the tunnel mode is to implement a Virtual Private Network (VPN). VPNs are networks that use publicly-available network resources, such as the Internet, to construct a network accessible only by selected parties. For example, a company may create its own version of a Local Area Network (LAN) using the Internet, or a worker working from a remote location may be able to utilize company resources at a company headquarters.

[0012] In order to implement the various protocols and modes of IPsec such as those discussed above, a security association (SA) is typically formed. An IPsec SA is essentially a contract or agreement between parties defining conditions according to which the two parties will communicate. For example, an IPsec SA is typically a one-way connection that defines, for example, encryption algorithms to be used during information exchange. SAs are defined by such parameters as an IP destination address and a security protocol identifier (e.g., AH or ESP). SAs typically include a security parameter index (SPI), which is a 32 bit identification number.

[0013] If an IPsec SA is considered a contract or agreement, then the terms thereof can be considered to be negotiated by a separate protocol (or manually). In other words, both communicating parties must agree on actions that will be taken on communicated packets in order to encrypt/decrypt those packets. One such protocol is known as the Internet Security Association and Key Management Protocol (ISAKMP), and one implementation of ISAKMP is known as the Internet Key Exchange (IKE).

[0014] IKE typically operates in two phases. In a first phase, parties agree as to how to protect further negotiation traffic. For example, IKE may authenticate a sender by virtue of, for example, public key encryption, also known as Diffie-Hellman encryption. In public key encryption, each user generates a public and private key, where the public key is then sent to the other party. When each user combines his own private key with the other's public key (and perhaps additional information), they each obtain an identical secret key. This secret key serves as a basis for deriving subsequent cryptographic keys.

[0015] In this way, a first user can encrypt a message using the second user's public key, and then only the second user (using his own private key) will be able to decrypt and receive the message.

[0016] Also, a first user can use his private key to sign a message and the second user, with the first user's public key, can receive and authenticate the transmitted message. Thus, the first user is authenticated to the second user as the one who sent the transmission; i.e., a “digital signature.”

[0017] This latter methodology, however, does nothing to guard against the eventuality that a third party is merely pretending to be the sender (i.e., the first user) when the keys were generated in the first place. Therefore, independent and trusted Certification Authorities (CAs) exist which issue digital certificates verifying the association of a public key with a particular user, along with other identifying information.

[0018] There are two primary modes for phase 1 of IKE: main mode and aggressive mode. Main mode, generally speaking, is a more involved but more secure method. Aggressive mode, though faster, sacrifices identity protection; however, using the public key encryption methodology just discussed obviates the need for this feature.

[0019] In a second phase, IKE negotiates the actual IPsec SA (over which the actual application layer data exchanges will take place) by setting up the encryption/authentication keys for the AH and/or ESP protocols. In particular, “quick mode” negotiates the SAs for general purpose IPsec communications. Also, it should be noted that, typically, only one phase 1 negotiation is needed for an associated plurality of phase 2 operations by a plurality of peer devices. This allows the multiple peer devices to each take advantage of the phase 1 proceedings, thereby establishing secure connections more quickly and more easily.

[0020] As shown in the above discussion, therefore, various solutions exist for implementing private and authenticated network communications. Within these solutions, for example, a protocol such as IPsec requires that the devices between which a secure connection will be established are available over an IP environment. In other words, the devices should have their IP addresses available as a registered, routable address.

[0021] However, it is often the case that a device's IP address is not available to the entire WAN. For example, a device may be located within a private network and protected by an external Gateway or Firewall, such as might be contained within an Internet Service Provider (ISP) or corporate sponsor of the device. Although many such Gateways provide a Network Address Translation (NAT) function, which differentiates between an internal and external address of each device within the private network, this function does not provide a means for a remote device to access an actual IP address of a member device of the private network through the Gateway.

[0022] Although some current solutions to this scenario utilizing the above technologies are available, none are completely suitable. For example, as demonstrated in FIG. 1A (where no NAT is implemented), it is possible to simply disable the filtering feature of a Firewall with respect to the set of devices in question. In FIG. 1A, device <b>100</b> on WAN <b>120</b> is provided with an address of (and access to) device <b>140</b> on private network <b>130</b>.

[0023] Therefore, devices <b>100</b> and <b>140</b> can establish an SA and tunnel connection as shown; i.e., those devices are both the SA endpoints and the tunnel endpoints, and can communicate with one another in a secure manner.

[0024] However, this solution has the obvious disadvantage of creating a hole in the network security. For example, once access to device <b>140</b> is provided to users of WAN <b>120</b>, any user of WAN <b>120</b> may access that device. Such access may then lead to various problems in protecting device <b>140</b> or any device on private network <b>130</b>.

[0025] Another exemplary conventional solution is to establish a secure channel between the remote device and the Gateway (the address of which is publicly available). Then, decryption can occur at the Gateway, after which the decrypted packets can be forwarded to the recipient device within the private network. However, this solution suffers from the fact that operators of the Gateway will have access to the decrypted information intended for the recipient device. In other words, this solution can be used in conjunction with a NAT Gateway, but such a device is not a customer device; it is a service provider device, and, as such, it is not typically secure or desirable (from the customer's viewpoint) to allow access to decrypted packets there.

[0026] Therefore, what is needed is a system and method for establishing a secure, manageable connection between a private network device and a second device, even over a WAN such as the Internet.

SUMMARY OF THE INVENTION

[0027] One embodiment of the present invention relates to a method for implementing secure network communications between a first device and a second device, where at least one of the devices is communicating with a public network via a separate computer. The method comprises receiving a request for a first secure connection from the first device, masking an address of the first device with respect to the second device and initiating a second secure connection between the separate computer and the second device. According to this method, the first and second secure connections enable the secure network communications between the first and second devices.

[0028] Another embodiment of the present invention relate to a virtual peer device for implementing a secure network connection between a first and second device, where at least one of the devices is a private network device communicating with a public network via the virtual peer device. In this embodiment, the virtual peer device comprises a means for receiving a request for a first connection from the first device, a means for requesting a second connection with the second device, means for forwarding encryption parameters between the two devices, to thereby establish the first and second connections and means for establishing the secure connection based on the first and second connections.

[0029] Another embodiment of the present invention relates to an article of manufacture comprising a computer readable medium having stored therein a computer program carrying out a method for implementing a secure connection between two devices. In this embodiment, the computer program comprises a first code segment for establishing a device address associated with the article of manufacture, a second code segment for establishing a first link between a first device and the device address, a third code segment for establishing a second link between a second device and the device address, a fourth code segment for exchanging encryption parameters associated with each of the first and second device via the first and second link and a fifth code segment for establishing the secure connection based on the encryption parameters.

[0030] Another embodiment of the present invention relates to a method of transmitting data. This method comprises negotiating a first security association between a first device and a second device, negotiating a second security association between a second device and a third device that is independent of the first security association and transmitting data inaccessible to said second device between the first and third devices via the second device.

[0031] The features and advantages of the invention will become apparent from the following drawings and description.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The present invention is described with reference to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

[0033]FIG. 1A demonstrates a prior art networking environment.

[0034]FIG. 1B demonstrates a network environment in which one embodiment of the present invention might operate, including a gateway computer operating on the edge of a private network and communicating with another device via a public WAN.

[0035]FIG. 2 demonstrates a methodology for negotiating a pair of Security Associations (SAs) according to one embodiment of the invention.

[0036]FIG. 3 describes an embodiment of the invention in which various types of IPsec traffic is relayed through a gateway computer both ways between a pair of devices.

[0037] FIGS. <b>4</b>A-<b>4</b>D describe structures of exemplary IPsec packets that may be transported according to various embodiments of the invention.

[0038] FIGS. <b>5</b>A-<b>5</b>C demonstrate various simplified views of IP header packet structures for tunnel head portions such as those shown in FIGS. <b>4</b>A-D.

[0039] FIGS. <b>6</b>A-<b>6</b>D describe exemplary certificate structures for each device type when certificates are used within the SA process.

[0040]FIG. 7 demonstrates exemplary process steps run by a gateway computer during a first phase of SA establishment.

[0041]FIG. 8 demonstrates exemplary process steps run by a gateway computer during a second phase of SA establishment.

DETAILED DESCRIPTION

[0042] While the present invention is described below with respect to various exemplary embodiments, the present invention is not limited to only those embodiments that are disclosed. Other embodiments can be implemented by those skilled in the art without departing from the spirit and scope of the present invention.

[0043] In this regard, although IPsec is used herein to demonstrate an exemplary embodiment of the invention, it should be understood that the present invention can be utilized in the context of other conventional network security protocols, such as Layer 2 Tunneling Protocol (L2TP) and Point-to-point Tunneling Protocol (PPTP), as would be apparent. Similarly, other protocols/methodologies besides IKE and public key encryption exist which are useful in implementing network security protocols, and the present invention can be implemented in those environments as well.

[0044] Moreover, it should be noted that the terminology and associated definitions used herein are subject to some level of disagreement in the art, as is known. For example, some artisans will describe IKE as an instance of ISAKMP, whereas others will describe IKE as the combination of ISAKMP with certain other protocols. Such terminology and definitions are used singularly and consistently herein only for the purposes of clarity; therefore, it should be understood that such usage is designed merely to explain and not limit the present invention. Similarly, terms such as “encryption,” “encryption parameters” or any other term of art, unless otherwise specified or limited herein, are not intended to be re-defined to have a special meaning herein and should be given their broadest reasonable interpretations consistent with the conventional understanding in the art.

[0045] The present invention, in an exemplary embodiment, operates by modifying the functionality of a conventional Network Address Translation (NAT) Gateway operating on the edge of a private network and communicating with another device via a public WAN, such as the Internet. This configuration is shown in both of FIGS. 1A and 1B, where device <b>140</b> operates on a private network <b>130</b> behind Gateway or other dedicated network appliance <b>110</b>, and communicates via WAN <b>120</b> (such as the Internet) with device <b>100</b>. Note that device <b>100</b> could be a single device on WAN <b>120</b>, or could be operating on its own private network or according to any other conventional network configuration, as would be apparent. Also note that, because of its location on a private network <b>130</b>, the IP address of device <b>140</b> will not typically be available to device <b>100</b>.

[0046] Modifications of such a Gateway <b>110</b> according to one embodiment of the invention are implemented in the establishment of a security association (SA) for an IPsec session between devices <b>100</b> and <b>140</b>, as well as in a forwarding mechanism for the packets being exchanged according to these established parameters.

[0047] According to one embodiment of the present invention, a first SA is established between device <b>100</b> and Gateway <b>110</b>. A second SA is established between Gateway <b>110</b> and device <b>140</b>. In this way, Gateway <b>110</b> acts as a virtual peer for both devices <b>100</b> and <b>140</b>, and allows device <b>100</b> to establish a link with Gateway <b>110</b> while believing that the link is actually established with device <b>140</b>.

[0048] It should be understood that Gateway <b>110</b> is not merely establishing a link with device <b>100</b>, decrypting information received thereover, and then re-encrypting the information for transmission over a separate link with device <b>140</b>. This solution would still suffer from the problem mentioned above that an operator of Gateway <b>110</b> would have access to the information contained within the transmission during a time between decrypting and re-encrypting. Rather, actual encryption parameters of devices <b>100</b> and <b>140</b> are utilized by one another in negotiating a secure connection (e.g, a tunnel) therebetween; however, this negotiation takes place through the Gateway <b>110</b>.

[0049] In other words, in conventional secure connections, devices <b>100</b> and <b>140</b> would be both SA endpoints and tunnel endpoints, as shown in FIG. 1A. In contrast, according to this embodiment of the present invention, devices <b>100</b> and <b>140</b> ultimately remain tunnel endpoints, but all of devices <b>100</b>, <b>110</b> and <b>140</b> become SA endpoints for two separate SAs, as shown in FIG. 1B.

[0050] For example, as will be discussed, Gateway <b>110</b> may forward the encryption parameters from device <b>100</b> to device <b>140</b> and vice-versa, using functionality similar to conventional NAT functionality. As another example mentioned below, Gateway <b>110</b> may modify digital certificates of devices <b>100</b> and <b>140</b> in a manner such that the SA is forced through Gateway <b>110</b> even though the devices' actual encryption parameters are still used.

[0051] Moreover, once Gateway <b>110</b> has assumed such a role in negotiating an SA with a remote peer device, it may also intercept and forward packets more easily and efficiently to devices on the private network <b>130</b>. For example, device <b>100</b> may communicate with several devices on private network <b>130</b> after establishing only one SA with Gateway <b>110</b>. Gateway <b>110</b> may swap headers and possibly change the signature of each packet on the fly, as will be discussed with respect to FIG. 5. In addition, Gateway <b>110</b> may mediate direct SA negotiation between all of the end devices communicating thereover, thereby controlling all secure communications between the end devices by allowing only (relayed) secure tunnels as discussed herein.

[0052]FIG. 2 demonstrates a methodology for negotiating a pair of SAs according to one embodiment of the invention. In FIG. 2, device <b>100</b> seeks to initiate an SA with device <b>140</b>. However, device <b>100</b> does not have access to an IP address of device <b>140</b>. As discussed above, an SA describes operations that should be applied to future data packets including an authentication method, an encryption method (and associated algorithm), authentication/encryption keys and various other parameters (such as the Security Parameter Index (SPI), an effective lifetime of the key(s), etc.). IKE allows two devices to negotiate and agree on these operations, including the establishment of the keys.

[0053] As discussed above, there are typically two phases in negotiating an SA using IKE. Thus, in FIG. 2, device <b>100</b> initiates a phase 1 session (PH1) by sending message <b>210</b> to Gateway <b>110</b> at an IP address G1 of Gateway <b>110</b> that may be advertised (i.e., made public) over WAN <b>120</b>.

[0054] In one embodiment of the invention, device <b>100</b> may be preset such that it believes that address G1 is an address for device <b>140</b>. In this scenario, Gateway <b>110</b> may be aware upon reception of transmission <b>210</b> which device with which it will then establish a secondary SA, SA2, without having to inspect the details of the SA transmission <b>210</b>. This implementation may utilize “loop-back” addresses on Gateway <b>110</b>, one for each possible peer on private network <b>130</b>. In other words, there will be a different address G1 associated with each of the private network devices.

[0055] Another implementation utilizes a single G1 IP address for all IPsec flows on the WAN side. In this solution, Gateway <b>110</b> must examine the transmission <b>2</b><b>10</b> to determine which private network device will be the tunnel endpoint for communications with device <b>100</b>. This implementation has the advantage that a device <b>100</b> can communicate with a plurality of devices (tunnel endpoints) on private network <b>130</b>, while only itself needing to establish one SA (with Gateway <b>110</b>).

[0056] In the latter implementation there is a need to maintain a name and identity of device <b>100</b>, either locally at the Gateway <b>110</b> or at a Domain Name System/Server (DNS). This information can also be used to identify device <b>140</b> as the sought-after tunnel endpoint device, as will be discussed in connection with FIG. 5.

[0057] In any case, phase 1 message <b>210</b> is sent from device <b>100</b> to Gateway <b>110</b> at address G1. This message, as discussed above, is generally intended to protect further negotiation traffic by way of, for example, the Main mode. As is known, the Main mode provides protection for the identity of the involved devices. It is typically divided into three sets of messages, each set containing two messages. The first two messages are used for negotiating a security policy for the exchange, the next two messages are used for the Diffie-Hellman keying material exchange and the last two messages are used for authenticating the peers, such as with digital signatures and optional digital certificates.

[0058] It should be noticed that SA2 may start by using a similar message <b>220</b> upon reception by Gateway <b>110</b> of the first SA1 message. In the various scenarios discussed above, in cases where Gateway <b>110</b> does not know the identity of the destination device <b>140</b> by one of the above-defined methods, it will wait for a SA message from device <b>100</b> containing an identification payload. In such a case, Gateway <b>110</b> should proceed with a phase 1 negotiation with device <b>100</b> until this message is received.

[0059]FIG. 2 describes only the case when either the identity of device <b>140</b> is included in the first message <b>210</b> or is already known by Gateway <b>110</b>. One limitation when the destination identity is not known is that Gateway <b>110</b> should not start negotiating parameters which may turn out to be unsuitable for device <b>140</b>; a solution in this case is to define a common set of rules which will be accepted by all devices on private network <b>130</b>.

[0060] Assuming Gateway <b>110</b> is aware of the identity of device <b>140</b>, Gateway <b>110</b> may then start a secondary phase 1 SA message <b>220</b> for SA2, using another IP address G2 for Gateway <b>110</b> that belongs to private network <b>130</b> and to which device <b>140</b> will be able to answer. Device <b>140</b> is now the SA responder and will answer to Gateway <b>110</b> using a PH1BA type message <b>230</b>. In other words, device <b>140</b> will receive parameters associated with device <b>100</b> but having address G2, and will respond with its own parameters to that address.

[0061] Afterwards, Gateway <b>110</b> responds to the first SA message <b>210</b> and provides a similar answer PH1GA message <b>240</b> to device <b>100</b>. In other words, the same parameters are negotiated between Gateway <b>110</b> and device <b>100</b> as between Gateway <b>110</b> and device <b>140</b>. The two SAs are thus independent, but will negotiate the same rules and parameters thanks to the interleaving of the SA messages.

[0062] At this point Gateway <b>110</b> provides its own authentication parameters, such as its own authentication public key, but uses the identity of device <b>140</b>. If this checking is done via certificates, then the certificates will be defined according to FIG. 6, as will be discussed. Shared keys (i.e., previously-agreed upon keys designed to be maintained in confidence) may also be used at this point, but do not offer as high a security level as public key encryption.

[0063] It should be noted that the SA mechanisms between device <b>100</b> and Gateway <b>110</b> on one side and device <b>140</b> and Gateway <b>110</b> on the other side fully meet the IKE protocol rules and process, so that no change is required on devices <b>100</b> or <b>140</b>, which are therefore transparent to this implementation.

[0064] Once phase 1 is achieved, a fully secure authenticated channel with possible encryption is established in order to proceed with SA phase 2. Phase 2 allows the definition of parameters for the IPSec protocol itself, and generally makes use of the Quick mode discussed above. A Diffie-Hellman key exchange may be done to achieve forwarding secrecy.

[0065] As referred to above, the Diffie-Hellman methodology allows device <b>100</b> to build a symmetric secret key (same key used for encryption and decryption) thanks to its local private key, a known Diffie-Hellman (DH) key and the public key of device <b>140</b> that can either be transmitted from device <b>140</b> to device <b>100</b> via Gateway <b>110</b>, or is obtained from a certificate as described in FIG. 6. Similarly, device <b>140</b> builds the same symmetric secret key thanks to its local private key, the DH key and the public key of device <b>100</b>. As long as the SAs between device <b>100</b> and Gateway <b>110</b>, and between Gateway <b>110</b> and device <b>140</b>, are valid, the same secret key is valid. Therefore the same parameters of key lifetime should typically be negotiated both ways.

[0066] Either one of the devices <b>100</b> or <b>140</b> might initiate the quick mode exchange. In FIG. 2, device <b>140</b> is the initiator of the second phase starting with PH2BI message <b>250</b>. Gateway <b>110</b> rebuilds a similar message PH2GI <b>260</b>, where the authentication (public) key belongs to Gateway <b>110</b> and the message is sent to device <b>100</b>.

[0067] Device <b>100</b> answers with its own parameters in PH2AA message <b>270</b> to Gateway <b>110</b>, and the Gateway <b>110</b> forwards the message including the same parameter values, except for the authentication key of device <b>100</b> which is exchanged for the key of Gateway <b>110</b>, to device <b>140</b> in PH2GA message <b>280</b>. The authentication key for Gateway <b>110</b> given to both of devices <b>100</b> and <b>140</b> is mainly used when AH header is used in the IPsec flow, in order to allow Gateway <b>110</b> to modify the IP header and then rebuild the packet signature, as described with more detail in FIGS. 3 and 4.

[0068] A last message that can be viewed as a final acknowledge is also sent back which is not shown in FIG. 2. Such a message ends the SA(s) for IPsec traffic between devices <b>100</b> and <b>140</b>. As SAs are typically asymmetrical, it may be necessary to repeat the above-described process in the reverse direction. However, it may be necessary only to perform a phase 2 negotiation, as is known. Once all SAs are active, the IPsec traffic can start in both directions. Thus a tunnel has been established for future data flows having endpoints of devices <b>100</b> and <b>140</b>, even though the SA endpoints included Gateway <b>110</b>.

[0069]FIG. 3 describes IPsec traffic both ways between devices <b>100</b> and <b>140</b> through Gateway <b>110</b>. As just described, Gateway <b>110</b> essentially acts as a relay for traffic sent between devices <b>100</b> and <b>140</b>. This relaying function can occur in various ways, depending, for example, on the terms of the SAs previously negotiated. For example, the relay process(es) performed in Gateway <b>110</b> may depend on the tunnelling and IPsec protocol headers being used according to the negotiated SAs.

[0070] Two exemplary scenarios are represented in FIG. 3: a first scenario where only an ESP header is used (i.e., as explained above, encryption is involved but no fall packet authentication is necessarily provided), and a second scenario where both AH and ESP are used (i.e., when a first IPsec header is an AH header and a second is an ESP header). As already noted, AH may also by used alone without encryption; however, as its behavior is similar to the more complex case when both AH and ESP are used, it is not discussed in detail here.

[0071] In FIG. 3, a first IPsec packet is sent from device <b>100</b> to Gateway <b>110</b> in step <b>310</b>. As already described, device <b>100</b> believes that it is sending a packet to device <b>140</b>, but the destination address in an IP header of the packet is G1. When Gateway <b>110</b> recognizes a packet having G1 as destination address, it first checks a protocol field (“PROT”) field described in FIG. 5 in order to know which process to use. The PROT will indicate whether to use an IPSec ESP flow process or an IPSec AH (+ESP or not) flow. In step <b>310</b>, the protocol is ESP and therefore Gateway <b>110</b> has only to swap source and destination address fields before forwarding the frame to device <b>140</b> in step <b>315</b>. This process is detailed in FIG. 5.

[0072] A similar process is used when an IPsec ESP packet is sent by device <b>140</b> to device <b>100</b> in step <b>320</b>, requiring header swapping in Gateway <b>110</b> and subsequent forwarding of the modified packet to device <b>100</b> in step <b>325</b>.

[0073] When the protocol type is identified as AH within a first IPsec protocol header, then the process is a more complex. This scenario is described starting with step <b>350</b> by a packet with an IPSec AH header with an IP destination address G1. When Gateway <b>110</b> decodes an AH protocol by way of the PROT, the authentication of the packet using its digital signature occurs. This is described in more detail in FIG. 4, along with various other packet structures.

[0074] Once authenticated, the AH relay process within Gateway <b>110</b> proceeds with the header swapping (as in the previous case), followed by the regeneration of the packet signature using the authentication private key of Gateway <b>110</b>. Gateway <b>110</b> then sends the packet to device <b>140</b> in step <b>355</b>. Device <b>140</b> can verify the packet signature using the public key associated with address G2, and which is either certified in a G2 certificate or sent in the SA as being the device <b>100</b> authentication public key.

[0075] From device <b>140</b> to device <b>100</b>, a similar process is performed starting with the transmission of an IPSec AH packet in step <b>360</b> with a destination address of G2. Gateway <b>110</b> performs the three steps of authenticating the packet, swapping the header address fields and rebuilding the packet signature. It then forwards the modified IPSec AH packet to device <b>100</b> in step <b>365</b>.

[0076] In any of the processes described above, the encryption can be done in either device <b>100</b> or <b>140</b>, and the decryption on device <b>140</b> or <b>100</b>, respectively. Both devices use the same symmetric secret key which may be based on various well-known encryption algorithms built using a Diffie-Hellman public key value and the set of private/public encryption keys associated with device <b>100</b> and <b>140</b>. Gateway <b>110</b> doesn't share this encryption secret key, since the encryption private keys of devices <b>100</b> and <b>140</b> are never disclosed to Gateway <b>110</b>.

[0077] FIGS. <b>4</b>A-<b>4</b>D describe structures of exemplary IPsec packets that may be transported according to various embodiments of the invention.

[0078] In FIG. 4A, packet <b>410</b> represents an IPsec packet using IPsec tunnel mode with an ESP header <b>416</b>. The inner payload <b>412</b> and IP header <b>414</b> are encrypted, while the entire packet except the tunnel header <b>418</b> is authenticated (i.e. integrated in the packet signature). Therefore, a change in the tunnel header <b>418</b> may be done without an impact on the packet authentication.

[0079] In FIG. 4B, packet <b>420</b> represents an IPsec packet using IPsec transport mode with ESP header <b>428</b> and Generic Routing Encapsulation (GRE) tunneling. The inner payload <b>422</b> and IP header <b>424</b> as well as the GRE portion <b>426</b> are encrypted, while the entire packet except the tunnel header <b>429</b> is integrated in the packet signature (i.e., authenticated). Therefore, a change in the tunnel header <b>429</b> may be done without an impact on the packet authentication. This case uses the same header process swapping as a packet <b>410</b> shown in FIG. 4A.

[0080] In FIG. 4C, packet <b>430</b> represents an IPsec packet using IPsec tunnel mode with AH header <b>436</b>. No field is encrypted, while the entire packet including the tunnel header <b>438</b> is integrated in the packet signature. Therefore, a change in the tunnel header <b>438</b> cannot be done without an impact on the packet authentication. The process in Gateway <b>110</b> therefore includes the three steps described above of authenticating the packet, swapping the header address fields and rebuilding the packet signature (i.e., re-authenticating).

[0081] In FIG. 4D, packet <b>440</b> represents an IPsec packet using IPsec tunnel mode with AH and ESP headers <b>448</b> and <b>446</b>, respectively. The inner payload <b>442</b> and IP header <b>444</b> are encrypted, while the entire packet including the tunnel header <b>449</b> is integrated in the packet signature. Therefore, as in FIG. 4C, a change in the tunnel header <b>449</b> cannot be done without an impact on the packet authentication, and the three-step process of authenticating the packet, swapping the header address fields and rebuilding the packet signature must again be performed within Gateway <b>110</b>.

[0082]FIG. 5 demonstrates various simplified views of IP header packet structures for tunnel head portions such as portions <b>418</b>, <b>429</b>, <b>438</b> and <b>449</b> shown in FIGS. <b>4</b>A-<b>4</b>D.

[0083] As shown in FIG. 5A, the tunnel head is an IP header which contains different fields as shown in generic IP header <b>510</b>. The fields include IP header trailer/footer fields <b>512</b>, as well as a source address field SA (<b>514</b>), a destination address field DA (<b>516</b>) and a protocol field PROT (<b>518</b>).

[0084]FIG. 5B demonstrates a first header-swapping process as a packet is sent from device <b>100</b> through Gateway <b>110</b> to device <b>140</b>. Specifically, packet <b>520</b> demonstrates a source address A in source address field <b>524</b><i>a, </i>indicating origination at device <b>100</b>, and a destination address G1 in source address field <b>526</b><i>a, </i>indicating a destination of Gateway <b>110</b>. As packet <b>520</b> is relayed through Gateway <b>110</b>, source address field <b>524</b><i>b </i>is switched to contain a new source address of G2, while destination address <b>526</b><i>b </i>field is switched to contain a destination address B.

[0085] Similarly, FIG. 5C demonstrates a second header-swapping process as a packet is sent from device <b>140</b> through Gateway <b>110</b> to device <b>100</b>. Here, packet <b>530</b> demonstrates a source address B in source address field <b>544</b><i>a, </i>indicating origination at device <b>140</b>, and a destination address G2 in source address field <b>546</b><i>a, </i>indicating a destination of Gateway <b>110</b>. As packet <b>530</b> is relayed through Gateway <b>110</b>, source address field <b>544</b><i>b </i>is switched to contain a new source address of G1, while destination address <b>546</b><i>b </i>field is switched to contain a destination address A.

[0086] If there is a one-to-one mapping between device address A and G1 on one side, and device address B and G2 on the other side, the process is easily-implemented. However, it is also possible to share a single G1 address between several devices located on WAN <b>120</b> and/or share a single G2 address between several devices located on private network <b>130</b>. In that case, a local or remote directory table should be use to identify, based on the source address, which IPsec peer corresponds to this flow. It may be a table built during the SA phase, a static directory or a dynamic directory using either a DNS server or a digital certificate from a certification authority server. However, all of the above methods will typically have the restriction that only one destination may be linked to a particular source address.

[0087]FIG. 6 describes exemplary certificate structures for each device type when certificates are used within the SA process. The certificates <b>600</b><i>a </i>and <b>600</b><i>b </i>for devices <b>100</b> and <b>140</b> in FIGS. 6A and 6B can be standard or “true” certificates, as all the parameters included in the certificate fields really belong to those devices. A certificate <b>600</b><i>a </i>for device address A as in FIG. 6A is only given to a device located on WAN <b>120</b>, and a certificate <b>600</b><i>b </i>for device address B as in FIG. 6B is only given to a device located on private network <b>130</b>.

[0088] As shown in FIG. 6A, a portion <b>610</b><i>a </i>of certificate <b>600</b><i>a </i>may contain the certification authority (CA) identify and signature, while a portion <b>620</b><i>a </i>contains various information for device <b>100</b> having address A, including its identity on the WAN <b>120</b>, IP address, device public key, IPsec authentication public key and IPsec encryption public key.

[0089] Similarly, as shown in FIG. 6B, a portion <b>610</b><i>b </i>of certificate <b>600</b><i>b </i>may contain the CA identify and signature, while a portion <b>620</b><i>b </i>contains various information for device <b>140</b> having address B, including its identity on the private network <b>130</b>, IP address, device public key, IPsec authentication public key and IPsec encryption public key.

[0090]FIG. 6C demonstrates a type of certificate <b>600</b><i>c </i>that a device <b>140</b> having device address B (or a similarly-situated device) may receive when it requests a certificate for a device such as device <b>100</b> having device address A (or a similarly-situated device). A certificate such as <b>600</b><i>c </i>is a “false” certificate, since it is validated by the CA as valid even though it contains some fields with false information in order to work properly. That is, if certificate <b>600</b><i>c </i>is considered to belong to Gateway <b>110</b>, then Gateway <b>110</b> is impersonating device <b>100</b> having address A in purporting to possess that device's identity (as far as the private network <b>130</b> is concerned) and public encryption key.

[0091] Alternatively, if certificate <b>600</b><i>c </i>is considered to belong to device <b>100</b>, then it can be considered a “hybrid” true-false certificate since the identity and public encryption key are correct but the remaining fields (i.e., IP address, device public key and IPsec authentication public key) are incorrect. Nevertheless, it should be noted that such certificates are valid certificates that can easily be built by the network security administrator.

[0092] Similar comments apply in the inverse to certificate <b>600</b><i>d </i>in FIG. 6D; that is, it represents a type of certificate <b>600</b><i>d </i>that a device <b>100</b> having device address A may receive when it requests a certificate for a device such as device <b>140</b> having device address B.

[0093] Note that although Gateway <b>110</b> may have different device addresses G1 and G2 as discussed, which is proper inasmuch as those addresses belong to separate networks, a G2 device public key and IPsec authentication public keys may be the same as corresponding keys for the G1 address.

[0094]FIG. 7 demonstrates exemplary process steps run by Gateway <b>110</b> during SA establishment. Note that, at each step, the process may stop if an error or a wrong request is performed which leads to a rejection of the SA. However, this is not shown at each step in order to simplify the process; only steps where there is a high probability of rejection are shown as such.

[0095] In step <b>710</b>, Gateway <b>110</b> waits for a phase 1 SA message to be detected from either the WAN <b>120</b> interface or the private network <b>130</b> interface. Note that any new SA is considered a separate process, so that only one such process is detailed here. When an SA message with a new source IP address is decoded, then a source and destination address is determined in step <b>712</b>. As already mentioned, a source address of an SA initiator may be included in the message or may be searched by Gateway <b>110</b> using a DNS lookup or a Certificate request to the appropriate CA.

[0096] If the identity is recognized and allowed to establish an IPsec session with a device located on the opposite network, the process goes to step <b>714</b>. In step <b>714</b>, the IP destination of the SA message is checked, including verification that it is a valid destination for IPsec and that this destination is reachable and active.

[0097] Gateway <b>110</b> may also validate the destination according to the source, using entity certificate comparison and validation. For example, if the two entities do not belong to the same company or VPN, the SA may be rejected according to predefined rules. In case of rejection, the process stops on step <b>720</b>, which may include a rejection message to the initiator of the message or not, whereupon Gateway <b>110</b> goes back to its waiting state <b>710</b>.

[0098] If the destination <b>1</b>P address and identity is allowed as a destination with respect to the IP source address and associated identity, then the process in step <b>716</b> starts, as an SA originator, a secondary phase one Security association. The process also, in step <b>718</b>, starts a timer and then waits for an answer to this message in step <b>730</b>.

[0099] In step <b>732</b>, if no answer is received due to either a timer expiration, a bad answer or a rejection answer then the first SA is rejected in step <b>720</b>. If an acceptable answer is received, then the answer is analyzed and processed in step <b>734</b> according to the IKE (ISAKMP) standard. In this case, an affirmative answer is also provided to the first SA initiator device in step <b>734</b>.

[0100]FIG. 8 describes other SA messages as handled by Gateway <b>110</b>. These include other phase 1 messages as well as SA phase two messages according to ISAKMP/IKE. To the extent that the first and secondary Security Associations fully meet the ISAKMP and IKE standard recommendations, they are not further detailed. FIG. 8 only refers to parameters that are exchanged that are different from the standard process(es).

[0101] In step <b>810</b>, Gateway <b>110</b> awaits additional SA messages. When an SA message from an existing session arrives in step <b>812</b> (such as from device <b>100</b> having device address A), Gateway <b>110</b> analyzes the content of the message and prepares a similar request to the other SA peer device on the other network (such as device <b>140</b> having device address B) in step <b>814</b>.

[0102] Next, a timer is started in step <b>816</b> and Gateway <b>110</b> begins to wait for an answer from device <b>140</b> in step <b>820</b>. If no answer is received before the timer expires in step <b>822</b>, the session can be aborted in step <b>824</b>. When an answer is received in step <b>822</b>, the process proceeds to step <b>826</b>, where an equivalent answer is built and sent to the first message initiator (A in the described example).

[0103] Thus, as can be seen from the above description, the present invention provides a methodology for providing a private, secure connection between devices, even when one of the devices is located on a private network such that its device address is not publicly available. In one embodiment, the present invention operates by providing a first secure connection between a first device and a gateway to the private network, and thereafter providing a second secure connection between the gateway and the second device. Once various security, authentication and/or encryption parameters are exchanged via the two connections, communications between the two devices may take place. In this way, neither end point device need know an actual address of the other device. Additionally, once a first secure connection is established between the first device and the gateway, a plurality of secondary secure connections can be implemented between the gateway and a each of a plurality of devices connected to the private network. In this way, network management is improved.

[0104] While this invention has been described in various explanatory embodiments, other embodiments and variations can be effected by a person of ordinary skill in the art without departing from the scope of the invention.