Method for providing secure connectivity to an internal network for a mobile node and related entity

0001The present invention relates to secure connectivity to an internal network for a mobile node.

0002While being inside its internal network, a mobile node can communicate securely, because the internal network is generally a trusted network. As an example, if the internal network is a corporate network, an employee using a mobile node can easily access an Intranet.

0003The same secure connectivity to the internal network would be appreciated when the mobile node is roaming in an external network which may be an untrusted network such as the Internet, for example for an employee who is outside of the enterprise premises.

0004Several solutions have been proposed to reach this goal. These solutions are based on the use of the Mobile IPv4 protocol as defined in the Request for Comments RFC 3344, "<nplcit id="ncit0001" npl-type="s"><text>IP Mobility Support for IPv4", published in August 2002 by the Internet Engineering Task Force (IETF).</text></nplcit>

0005According to a first solution in co-located mode illustrated in FIG.1, a Mobile IP (MIP) tunnel is set up between a mobile node (MN) and its home agent (i-HA for internal home agent) through an external network. This solution has been described in the Internet draft "<nplcit id="ncit0002" npl-type="s"><text>Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE ; draft-ietf-mip4-mobike-connectivity-03.txt", by V. Devarapalli and P. Eronen, published in March 2007</text></nplcit>.

0006To do so, preliminary actions for the establishment of a VPN tunnel, typically an IPsec tunnel, between the MN and a VPN gateway (VPN GW) are first performed. For instance, it is performed security exchanges of the IKE (Internet Key Exchange) protocol defined in the Request for Comments RFC 4306 "<nplcit id="ncit0003" npl-type="s"><text>Internet Key Exchange (IKEv2) Protocol" published in December 2005 by the IETF</text></nplcit>.

0007As shown with references 1 and 2 in FIG.1 and in accordance with the above mentioned RFC 4306, an IKE_SA_INIT exchange may first be performed in particular to negotiate security parameters for the IKE security association, followed by an IKE_AUTH request/response in particular to transmit identities and to prove knowledge of the secrets corresponding to the identities.

0008At the end of these preliminary actions, a VPN tunnel, e.g. an IPsec tunnel 5, is set up. The MN uses this secured tunnel to register with its i-HA (step 3). In the registration response sent back to the MN, the i-HA includes the MN's home address (HoA) which is the MN's long-term IP address on its home internal network.

0009A MIP tunnel 6 is further set up between the MN and the i-HA. As it appears in step 4 of FIG.1, the IP traffic 7 sent between the MN and a correspondent node CN is conveyed through this MIP tunnel 6. In addition, the corresponding tunneled datagrams are protected between the VPN GW and the MN by the IPsec tunnel 5.

0010FIG.2 schematically illustrates the format of traffic exchanged on the different portions in this co-located mode solution.

0011For a downlink packet sent by the CN for the attention of the MN, an encapsulating MIP header is first added by the i-HA. In this MIP header, the destination address is the tunnel inner address (TIA), which is the address that the VPN GW allocates to the MN. Then the VPN GW further adds an outer header to the packet in a classical way.

0012It comes clearly from FIG.2 that the MIP encapsulation in the VPN tunnel 5 incurs overhead. The same applies in the uplink direction.

0013To eliminate the tunneling overhead of MIPv4 in the VPN tunnel, a second solution has been proposed. This optimized solution introduces a foreign agent (FA) co-located to the VPN GW. It is described in the Internet draft "<nplcit id="ncit0004" npl-type="s"><text>Optimizations to Secure Connectivity and Mobility ; draft-meghana-mip4-mobike-optimizations-01" by M. Sahasrabudhe and V. Devarapalli, published in October 2006.</text></nplcit>

0014This second solution, which is in care-of-address mode, is illustrated in FIG.3.

0015Like in the previous solution, the MN initiates an IKE_SA_INIT exchange to create an IKE security association (step 8) and a further IKE_AUTH request/response exchange creates the IPsec security associations for the tunnel inner address TIA which is allocated to the MN by the VPN GW (step 9). At the end of these preliminary actions, a VPN tunnel, typically an IPsec tunnel 14, is set up. Then, the MN registers with its i-HA and obtains its home address HoA (step 10).

0016In step 11, a MIP tunnel 15 is created between the i-HA and the foreign agent FA.

0017The TIA is used as an address for all traffic sent through the IPsec tunnel 14. But because a foreign agent functionality exists on the VPN gateway (i.e. an FA is co-located to the VPN GW), the MN must use its HoA as an address on the data traffic and the HoA must be equal to the TIA.

0018To do so, the MN initiates a CREATE_CHILD_SA exchange to setup new tunnel mode IPsec security associations for the HoA (step 12). The CREATE_CHILD_SA request and response messages are detailed in paragraph 1.3 of the above mentioned RFC 4306 "Internet Key Exchange (IKEv2) Protocol". A new IPsec tunnel 16 is thus set up in replacement of the previous one. The security associations created earlier for the TIA may be either torn down or allowed to expire based on the configuration on the MN and the VPN GW.

0019Data traffic 17 to and from the HoA can flow protected, between the VPN GW and the MN, by the new IPsec security associations for the HoA. No MIP encapsulation occurs in the new IPsec tunnel 16 (step 13).

0020The resulting Mobile IP header reduction in the new IPsec tunnel 16, when the FA is co-located with the VPN GW, appears in FIG.4, by contrast with FIG.2.

0021FIG.4 shows a downlink flow of data with encapsulating headers from the CN to the MN. As mentioned above, the header reduction that occurs in the VPN tunnel 16 is possible when the TIA is equal to the HoA.

0022To benefit from the header reduction offered by the de-capsulation achieved by the FA, the source address of the inner header of the encapsulated packets in the VPN tunnel 16 needs to be the HoA for the uplink.

0023In addition, for the downlink, the destination address of the inner header of the encapsulated packets needs to be the TIA. The selection of the packet to be encrypted is based on the destination address of the inner packet. The IPsec security association is based on the TIA. If the TIA is different from the HoA, the incoming packet will not be protected by the VPN.

0024A problem with this second solution consisting in first establishing the IPsec security association with the TIA allocated by the VPN GW, and then running a separate CREATE_CHILD_SA exchange to setup a new tunnel mode IPsec security association for the HoA, is that it can be rather long and costly.

0025Indeed, it will take the time to establish a VPN connection and then the time to register Mobile IP. Moreover, it is only after having obtained both the TIA and the HoA that another IPsec security association (SA) is created with the HoA to be used as the TIA. The latter IPsec SA creation introduces additional delay in the form of an additional CREATE_CHILD_SA message exchange.

0026An object of the present invention is to alleviate this problem.

0027The invention proposes a method for providing secure connectivity to an internal network for a mobile node roaming in an external network, the internal network supporting Proxy MIP and comprising a home agent, the internal network and the external network being connected through a VPN (virtual private network) gateway co-located with a gateway proxy mobile agent. The method comprises the following steps: <ul id="ul0001" list-style="dash"><li>performing preliminary actions for the establishment of a VPN tunnel between the mobile node and the VPN gateway ;</li><li>obtaining at the gateway proxy mobile agent, within the framework of the preliminary actions for the establishment of the VPN tunnel, a home address of the mobile node from the home agent; and</li><li>using the home address of the mobile node as an inner address of the VPN tunnel to be established.</li></ul>

0028Because the home address of the mobile node is obtained at the gateway proxy mobile agent within the framework of the preliminary actions for the establishment of the VPN tunnel (which is made possible by virtue of the Proxy MIP technology), and thus within the same time interval as these preliminary actions, time is saved compared to the second prior art solution described above. Furthermore, there is no need for additional CREATE_CHILD_SA message exchange, which reduces the amount of signaling required.

0029Moreover, by contrast with the first prior art solution described above, no overhead is needed in the VPN tunnel between the MN and the VPN gateway.

0030Obtaining the home address of the mobile node from the home agent may result from the gateway proxy mobile agent performing a Proxy MIP registration with the home agent for the mobile node.

0031Performing preliminary actions for the establishment of the VPN tunnel can comprise performing security exchange of the IKE (Internet Key Exchange) protocol.

0032In an advantageous embodiment that will be more particularly detailed further, performing preliminary actions for the establishment of the VPN tunnel comprises receiving at the VPN gateway an IKE_AUTH request message from the mobile node and obtaining at the gateway proxy mobile agent, within the framework of the preliminary actions for the establishment of the VPN tunnel, a home address of the mobile node from the home agent results from the gateway proxy mobile agent sending a registration request message for the mobile node to the home agent on reception of the IKE_AUTH request message by the VPN gateway.

0033In this embodiment, the gateway proxy mobile agent may advantageously receive the home address of the mobile node from the home agent in a registration response message and the VPN gateway may advantageously send said home address to the mobile node in an IKE_AUTH response message on reception of the registration response message by the gateway proxy mobile agent.

0034According to another aspect, the invention can further make it possible to maintain session continuity and handle mobility for the mobile node, after said VPN tunnel has been established, by detecting that the mobile node has moved to the internal network and deleting said VPN tunnel.

0035The VPN tunnel deletion can make use of a Mobike delete message as will be described below. This message may be sent from the mobile node to the VPN gateway or from the VPN gateway to the mobile node.

0036The invention also proposes an entity consisting in a VPN (virtual private network) gateway co-located with a gateway proxy mobile agent, said entity being able to connect an internal network and an external network, the internal network supporting Proxy MIP and comprising a home agent. This entity comprises, with respect to a mobile node roaming in the external network: <ul id="ul0002" list-style="dash"><li>means for taking part in preliminary actions for the establishment of a VPN tunnel with the mobile node ;</li><li>means for obtaining, within the framework of the preliminary actions for the establishment of the VPN tunnel, a home address of the mobile node from the home agent; and</li><li>means for using the home address of the mobile node as an inner address of the VPN tunnel to be established.</li></ul>

0037This entity may further comprise means for taking part in deletion of said VPN tunnel when it has been detected that the mobile node has moved to the internal network, by exchanging a Mobike delete message with the mobile node.

0038The invention further proposes a computer program product comprising code instructions for implementing the above mentioned method, when loaded and run on computer means that may be embedded in a single device (like an entity as described above) or distributed among several devices.

0039The invention also proposes a mobile node having a VPN (virtual private network) tunnel established with a VPN gateway co-located with a gateway proxy mobile agent, the co-located VPN gateway and gateway proxy mobile agent connecting an internal network supporting Proxy MIP and comprising a home agent and an external network. The mobile node comprises means for, after moving to the internal network, deleting said VPN tunnel by sending a Mobike delete message to the VPN gateway.

0040The preferred features of the above aspects which are indicated by the dependent claims may be combined as appropriate, and may be combined with any of the above aspects of the invention, as would be apparent to a person skilled in the art. <ul id="ul0003" list-style="dash"><li>FIG.1, already discussed, shows a prior art solution in co-located mode for secure connectivity ;</li><li>FIG.2, already discussed, shows a downlink data flow according to the solution of FIG.1 ;</li><li>FIG.3, already discussed, shows a prior art solution in care of address mode for secure connectivity ;</li><li>FIG.4, already discussed, shows a downlink data flow according to the solution of FIG.1 ;</li><li>FIG.5 shows an exemplary architecture of a system capable of carrying out the invention ;</li><li>FIG.6 shows an embodiment for secure connectivity according to the invention ;</li><li>FIG.7 shows a first deletion mode of a pre-established VPN tunnel ; and</li><li>FIG.8 shows a second deletion mode of a pre-established VPN tunnel.</li></ul>

0041The present invention makes use of the Proxy MIP technology as defined in the Internet draft "<nplcit id="ncit0005" npl-type="s"><text>Mobility Management using Proxy Mobile IPv4 ; draft-leung-mip4-proxy-mode-02.txt" by K. Leung, G. Dommety, P. Yegani and K. Chowdhury, published in January 2007</text></nplcit>, rather than the MIP technology by contrast with the prior art described in the introduction.

0042It may take place in a system having an architecture as shown in FIG.5. This architecture involves an internal network and an external network.

0043The internal network is a trusted network, such as a corporate network. It supports the Proxy MIP technology. It includes an internal home agent i-HA and an AAA infrastructure to perform authentication and authorization of MNs. It also advantageously includes at least one proxy mobility agent PMA which is a network node capable of registering with the i-HA on behalf of MNs. Actually, every access point (AP) or access router (AR) in the internal network may advantageously be a PMA implementing the functionalities of Proxy MIP. Optionally, foreign agents FAs can be part of the internal network. Other nodes may take place between the i-HA and the PMAs as symbolized with the cloud on the right side of FIG.5. The PMAs and the i-HA are not directly accessible from the external network.

0044The external network can be any kind of network. It is generally an untrusted network, such as the public Internet network. It may include a DHCP (Dynamic Host Configuration Protocol) server as well as a router R. Other nodes may take place in the external network as symbolized with the cloud on the left side of FIG.5.

0045To provide secure connectivity to the internal network for a mobile node MN whose home network is the internal network, whose home agent is the i-HA and which is roaming in the external network, the internal network and the external network are connected through a VPN gateway, such as a mobile mVPN gateway, co-located with a gateway proxy mobile agent GPMA holding the functions of a PMA of the internal network.

0046As illustrated in FIG.5, a demilitarized zone DMZ, where security is limited, may be provided between the internal and external networks. These other elements shown in the exemplary architecture of FIG.5 include firewalls FWs and routers Rs between the internal and external networks.

0047An embodiment of the invention is now described with reference to FIG.6. It aims at providing secure connectivity to the internal network for a MN roaming in the external network. In this way, an employee can maintain his connection with the Intranet of his firm for instance.

0048Like in the solutions described above, preliminary actions for the establishment of a VPN tunnel between the MN and the mVPN gateway are performed. These preliminary actions comprise advantageously security exchanges of the IKE (Internet Key Exchange) protocol.

0049Then, a home address HoA of the MN is obtained from the i-HA at the GPMA co-located with the mVPN gateway. This is done within the framework of the preliminary actions for the establishment of the VPN tunnel.

0050The MN's HoA can then be used as an inner address TIA of the VPN tunnel to be established.

0051In the embodiment illustrated in FIG.6, an IKE_SA_INIT exchange is first performed (step 18). Then, an IKE_AUTH request message is sent by the MN to the mVPN gateway (step 19). The IDi (identification of initiator) payload of this request advantageously includes a unique identity of the MN (NAI). The IKE_AUTH request message may also contain a CP(CFG_REQUEST) payload, as defined in the above mentioned RFC 4306, containing 0.0.0.0 as an internal address. This indicates that the MN is requesting an IP address from the internal network.

0052Advantageously, the GPMA, co-located with the mVPN gateway, exchanges AAA messages with the AAA infrastructure of the internal network to perform authentication and authorization of the MN (step 20). As part of this step, the AAA may download MN information such as the i-HA IP address and the security association corresponding to the NAI presented in the IKE_AUTH request message.

0053The GPMA then sends a registration request message for the MN to the i-HA (step 21). This is possible due to the Proxy MIP support by the GPMA. The i-HA returns the HoA to be allocated to the MN to the GPMA in a registration response message (step 22).

0054Because the IKE_AUTH request of the VPN tunnel establishment triggers the Proxy MIP registration in this example, the GPMA can thus obtain the MN's HoA within the framework of this preliminary IKE_AUTH exchange.

0055When the GPMA receives the registration response message with the HoA, the mVPN gateway sends that HoA as an internal address in the GP(CFG_REPLY) payload of an IKE_AUTH response message, as defined in the above mentioned RFC 4306 (step 23).

0056A MIP tunnel 24 between the i-HA and the GPMA and a VPN tunnel between the MN and the mVPN gateway are finally set up. They can convey traffic between the MN and a correspondent node CN (not represented in FIG.6).

0057The HoA is used as the inner address TIA of the VPN tunnel 25.

0058The format of the downlink packets sent to the MN on the different portions are similar to the one shown in FIG.4 (except that FA is replaced by GPMA). The same applies for uplink with the source and destination reversed.

0059In terms of routing, the GPMA may be configured with the i-HA as its default router. The packets from the MN are de-capsulated by the mVPN gateway, which pass the inner packets to the GPMA. The GPMA reverse tunnel them in IP to the i-HA. Likewise, the packets from the i-HA are de-capsulated by the GPMA and then re-encapsulated in the IPsec tunnel to the MN.

0060The source address of the registration request message, which is the address of the GPMA, might be a private address. For routing simplifications, most corporate networks would not have any NAT (Network Address Translation) between the GPMA and the i-HA. Encapsulation would then be of the type IP in IP for both forward and reverse tunnels.

0061It comes from the embodiment described above that no MIPv4 overhead is present in the VPN tunnel between the MN and the mVPN gateway. This is a significant advantage compared to the first prior art solution described in the introduction.

0062Moreover, obtaining the MN's HoA within the framework of the preliminary actions for the establishment of the VPN tunnel, for example by triggering a Proxy MIP registration upon reception of an IKE_AUTH request message by the mVPN gateway makes it easy to assign the MN's HoA as the VPN TIA. It also avoids creating two successive VPN tunnels (the HoA is obtained before the VPN tunnel is established) as well as corresponding MIP signalling (CREATE_CHILD_SA exchange) between the mVPN gateway and the MN, by contrast with the second prior art solution described in the introduction. This represents a gain in terms of time and cost.

0063It will also be noted that the invention may reduce the amount of signalling that would be necessary if Dynamic Host Configuration Protocol (DHCP) was used to obtain the HoA after starting the establishment of the VPN connection.

0064According to further aspects of the invention, session continuity may be maintained and mobility may be handled.

0065The embodiment described above can be achieved to allow the MN to maintain its current session when moving from the internal network to an external network.

0066If the MN moves within the external network and its access network changes, it may use the Mobike protocol, as defined in the Internet standard "<nplcit id="ncit0006" npl-type="s"><text>IKEv2 Mobility and Multihoming Protocol (MOBIKE); draft-ietf-mobike-protocol-08.txt" by P. Eronen, published in February 2006</text></nplcit>, to update the mVPN gateway of its current address.

0067When the MN is connected to the same mVPN gateway, the GPMA still maintains a valid binding cache entry at the i-HA. The i-HA is not aware of the MN's movement as long as the MN is attached to the same mVPN gateway and the GPMA address remains the same.

0068In order to maintain session continuity of the MN as it moves, the Home Address (HoA) stays unchanged.

0069If the MN had to change mVPN gateway, the new GPMA would update the i-HA with the new care of address.

0070If the MN disconnects from the mVPN gateway or attaches a different mVPN gateway, it advantageously re-connects and obtains the same VPN TIA as the previous one. This will allow sessions to survive VPN disconnection as the mobility bindings for the MN's HoA at the i-HA have remained in spite of the VPN disconnection.

0071It also may happen that the MN roaming in an external network moves to the internal network. This may be detected for example as follows.

0072The MN performs network access authentication on the internal network which has become available. During this authentication, the MN presents its NAI to a PMA access router of the internal network (see e.g. top of FIG.7). Alternatively, if network access authentication is not required, a client Fully Qualified Domain Name (FQDN) sub-option presents the MN's FQDN to the access router as described in Request for Comments RFC 4702 "<nplcit id="ncit0007" npl-type="s"><text>The Dynamic Host Configuration Protocol (DHCP) Client ; Fully Qualified Domain Name (FQDN) Option", published in October 2006</text></nplcit>. In this case, assuming that in each PMA of the internal network, there exists a mapping between the FQDN and the NAI, the MN will be identified by that mapping. Such mapping table will be presented further.

0073The access router which is also a PMA then sends a proxy registration request message for the MN's NAI to the i-HA address.

0074Once it has been detected that the mobile node has moved to the internal network, the VPN tunnel may be torn down, i.e. deleted, because in the internal network, the MN does not use the VPN tunnel to send and receive traffic. The deletion of the VPN tunnel may be achieved as follows.

0075The security associations that were used to protect the traffic between the MN and the mVPN gateway can be deleted. To that end, the MN can send to the mVPN gateway a delete message (with address 0.0.0.0) of the Mobike protocol, as defined in the above mentioned Internet standard "IKEv2 Mobility and Multihoming Protocol (MOBIKE) ; draft-ietf-mobike-protocol-08.txt".

0076The MN may have to re-negotiate IKE security association (SA) to prevent the IKE SA from expiring. This negotiation can be done through the old network if it is still available or through the internal network if the mVPN gateway is reachable from the internal network.

0077The MN may initiate the deletion of the IPsec SA (and thus of the VPN tunnel) for the MN's HoA on the mVPN gateway by sending the Mobike delete message. This is shown in the example illustrated in FIG.7.

0078As shown in FIG.7, sending the Mobike delete message may result from the MN receiving native unprotected data to its HoA (which may be considered as an indication that the MN is in the internal network).

0079Alternatively, the deletion of the IPsec SA (and thus of the VPN tunnel), on the MN, may be initiated by the mVPN gateway. In this case, the reception of a Proxy MIP registration revocation message by the GPMA co-located with the mVPN gateway may be used as an indication to trigger the deletion of the VPN tunnel. The Mobike message may indeed be sent to the MN on reception of the registration revocation message by the GPMA. This is shown in the example illustrated in FIG.8.

0080When in the internal network, the MN can have its mobility handled and session continuity maintained by Proxy MIP with the i-HA serving as the mobility anchor. This is in accordance with what the above mentioned Internet draft "Mobility Management using Proxy Mobile IPv4 ; draft-leung-mip4-proxy-mode-02.txt" describes.

0081The relevant PMA of the internal network maintains a valid binding cache entry at all times at the i-HA, mapping the HoA to a current care of address CoA (which is the address of the PMA or of an FA). Whenever the MN attaches a new PMA, the PMA sends a registration request to update the binding cache entry for that MN

0082After having moved to the internal network, it may happen that the MN moves back to the external network. In this case, the MN may re-establish the VPN connection with possibly the old IKE SA it had before tearing down the tunnel mode IPsec SAs (VPN tunnel). The MN may not have to re-negotiate the IKE SA if it has maintained the VPN states alive in the mVPN gateway while it was receiving traffic directly from the internal network.

0083In the embodiment described above, it has been assumed that the MN presents its NAI identifier during network access to retrieve the MN's security associations that will protect the proxy registration (see e.g. 19 in FIG.6). This may not be the case however. To that end, each PMA in the internal network may contain a data structure of elements, where each element associates the Fully Qualified Domain Name (FQDN) of each user with the NAI of that user. In this way, it is possible to retrieve the NAI of a user's MN when the PMA receives a DHCP request from that user's MN containing the FQDN option as defined in the above mentioned RFC 4702. A mapping table may be used for this purpose, containing for each user a corresponding couple of values (FQDN ; NAI).

0084Although an embodiment of the invention has been particularly described, it may be varied in many ways without departing from the invention as defined in the claims.

0085All or part of the operations described above can be carried out by virtue of a computer program including appropriate code instructions. This program can be loaded and run on computer means of a single device, e.g. an entity including the co-located mVPN gateway and GPMA, or a plurality of devices in a distributed fashion.