The present invention relates to a method and equipment for mobile networking in general, and more particularly, to arranging IP mobility for mobile nodes.
Internet Protocols (IP) are the backbone of modern networking and interoperability with these standards is supported in most of the current telecommunications devices. IP is adaptable and has been extended to provide additional functionality.
IP protocols are regularly used to create private networks. A typical secure network connects to outside resources, such as the public Internet. The secure network represents a localized LAN or WAN that operates apart from the publicly accessible Internet. A classic example would be an internal corporate network. The secure network uses a firewall to maintain its security while also allowing access to external resources. The firewall screens traffic passing between the secure network and the Internet to prevent unauthorized access or security breaches.
It is also advantageous to allow authorized users of an intranet to access the secure network when they are not physically connected to it. However, the most efficient way for a user to establish a connection is by using the public Internet infrastructure. This would, for example, allow a user to work from home and access files residing on the secure network. This, of course, creates a security problem because it allows information from the secure network to travel over the public Internet where it is potentially accessible to others. IP security (IPsec) is one technology enabling the creation of Virtual Private Networks (VPNs) to ensure the security of transmitted information packets. A VPN gateway authenticates an external user and creates a tunnel in which the transferred packets are encrypted by keys from credentials provided by an authority entity, such as a key distributor or a public key infrastructure. Tunneling refers to a process where new “to” and “from” information is added to the front of a packet to reroute it to a given location.
Provision of IP services for mobile devices has also become an essential issue. IP mobility provides a protocol for maintaining an IP session with a mobile device whose actual network connection and IP address may change among different physical networks as the mobile device moves. The Mobile IP protocol defined in IETF specifications RFC2002 to RFC2004 and RFC2290 allows mobile nodes to change their access point to the Internet without changing their IP address. The protocol defines a system for routing data of a mobile device to the current location of the device. This is accomplished through the use of a Home Agent that monitors the permanent IP address and current location of the mobile device. The Home Agent allows the mobile device to have a permanent address that is translated by the Home Agent into the mobile device's current address. This is accomplished through tunneling. Of course, the implementation of IP mobility requires additional overhead. This includes extra data attached to the packets and a need to keep a record of the mobile device's current location.
The IPsec VPN's reliance on the external user's IP address, however, makes it unsuitable for direct use in a mobile environment. Mobile devices using IP mobility change their IP address as they move from one access point to another. Potentially, this could happen many times during a relatively short time period. Using a traditional VPN, the terminal would have to re-authenticate and re-establish its secure connection after each of these transitions.
Most IPsec implementations support IP address configuration from a private network. In the example of
However, this kind of configuration fails to provide mobility as soon as the mobile node may connect to the private network without using the insecure network. For instance, the secure private network could be accessed over a direct Ethernet access device or a wireless local area network. This problem can be avoided by arranging all traffic to the secure network via the VPN gateway, whereby all connectivity types for which mobility is to be offered provide connectivity to an insecure network. The mobile node never connects directly to the secure network behind the VPN gateway but rather it only connects to the insecure side. In this scenario, a VPN connection is always needed if the mobile node wishes to communicate with a host on the Intranet. A drawback in this arrangement is that VPN tunneling and Mobile IP needs to be used all the time, even when accessing a corporate network from corporate premises. Corporations may be unwilling to change their intranet architecture to always require VPN and Mobile IP protocols.
An object of the invention is to provide a new kind of arrangement for enabling mobility for secure network connections. The object of the invention is achieved with a method, a system, a network element, a terminal, a network element and a computer program product which are characterized by what is disclosed in the independent claims. Some preferred embodiments of the invention are set forth in the dependent claims.
A connection to a secure network for a mobile node may be arranged by a home agent if the mobile node is accessing the secure network directly or via a third network other than the insecure network, or a connection to the secure network may be arranged by a VPN node if the mobile node is accessing the secure network via the insecure network. According to a first aspect of the invention, the VPN node and the home agent are configured to allocate the same IP address as an internal IP address and as a home address. According to a second aspect of the invention, a terminal at least receiving data from a first node is configured to change at least data reception such that protocol layer functions for communicating with the first node are omitted and the protocol layer functions for communicating with the second node are applied using the same IP address as was used for communicating with a correspondent host with the first node.
Advantages of the invention include that mobility can be provided for secure network (e.g. company intranet) connections, where intranet access may be provided by VPN connections and some other access methods with which Mobile IP can be utilized. As both the security node, e.g. an IPsec gateway, and the home agent are configured to allocate the same IP address as the tunneling end-point address and as the home address for the mobile node, Mobile IP and VPN layers can be used alternatively for the application layer connection even when the mobile node moves to/from the secure network. Thus, no additional Mobile IP layer underneath the VPN layer as illustrated in
In the following, the invention will be described in further detail by means of some embodiments and with reference to the accompanying drawings, in which
a and 3b illustrate protocol layers according to an embodiment of the invention;
An embodiment of the invention will be illustrated in the following with reference to the telecommunications system in
A mobile node MN is embodied by hardware devices that can move about while being used. Examples of these devices include PDAs, mobile stations, tablet computers, etc. The mobile node MN is configured to implement a client-side VPN protocol layer and Mobile IP protocol layer functions. A home agent HA is arranged in the secure network SN and provides mobility services for the mobile node MN. When the MN is accessing the secure network SN via the insecure network PN, e.g. the Internet, the connection has to be arranged by a secure tunnel provided by a VPN gateway VPNGW and VPN functionality in the mobile node MN. Only the payload of packets may be encrypted over the Internet, or tunneling encrypting the whole packet can be used. Tunneling technologies that may be used include GRE, IPsec, L2F, PPTP, L2TP.
A Correspondent host CH represents an arbitrary network member that the mobile node MN is communicating with. The CH may be an intermediary network member and coupled to any network. For example, the CH may be coupled to the Internet, a corporate network, or a home network. In the present example, the CH is connected to the secure network and there is a need to establish data transfer between the CH and the MN. For instance, the CH may be an email server in the secure network SN.
a and 3b illustrate protocol layers according to an embodiment. The protocol layers in
The protocol layers in
In step 401, the mobile node MN determines whether or not an association with a 2nd node can be established. Depending on which the 1st node is, the 2nd node is either the VPN gateway VPNGW or the home agent HA. The mobile node MN may be configured to enter this step based on at least one of the following reasons: handover is or needs to be performed to another network, the current connection or association with the 1st node is lost, based on user initiation, based on a received message from the 2nd node (e.g. a Mobile IP foreign agent or home agent advertisement message), or based on predetermined time intervals. As to lower layer (L2/L1) changes due to movement of the MN, typical inter-system and/or intra-system handover procedures can be used. As one example, the 3GPP specification TS 23.009 “Handover Procedures”, v. 5.6.0, September 2003, describes inter-access network and intra-access network handover procedures for the 3GPP system. Referring to
If, based on the check 401, 402, no association to the 2nd node can be made, the mobile node MN is configured to continue communication (at least reception of packages) with the correspondent host CH using the current association with the 1st node. Otherwise, the mobile node MN is configured to establish 404 the association with the 2nd node. After the association has been established, the mobile node MN is configured to change 405 an upper layer connection to use a protocol layer for communicating with the 2nd node. In practice this means that one or more data flows associated earlier with the protocol layer for communicating with the 1st node are re-associated with the protocol layer with communicating for the 2nd node. Typically, a network application has a socket bound at a TCP/IP stack to a physical network interface or a logical network interface (i.e. a tunnel). Thus, Mobile IP and VPN may exist as separate logical network interfaces and the mobile node MN is configured to change the binding of the socket from the logical network interface of the 1st node to the logical network interface of the 2nd node such that the socket does not change. Consequently, the upper layer application does not detect the change. The mobile node MN is configured to use the same source IP address in communication with the correspondent host CH as was used earlier.
If the 2nd node is the home agent HA, in one embodiment the mobile node MN is configured, in step 401, to transmit a registration request to the home agent HA in the secure network SN. If a registration reply is received, the MN is accessing the secure network SN directly or via some third network, i.e. the MN can determine that the association can be made. In this embodiment, the MN does not have to send any further messages to the HA in step 404 but it may arrange the Mobile IP association internally. It is to be noted that it is not necessary to release the association with the VPNGW, whereby the already existing association can be used to establish the tunnel with the VPNGW quickly if the insecure network PN is re-entered. However, if the HA and the VPNGW are on the same link, the mobile node MN or the home agent HA may need to tell the VPNGW to stop intercepting and tunneling packets that are destined to the mobile node MN, since the home agent HA will intercept and tunnel packets to the mobile node MN. If no response is received, the mobile node MN determines that no association can be made with the home agent, i.e. it is communicating with the CH via the insecure network PN. Thus, the mobile node MN is configured to continue communication via the VPNGW.
If the 2nd node is the VPN gateway VPNGW, in one embodiment the mobile node MN is configured, in step 401, to transmit an IKE (Internet Key Exchange) message to the VPNGW. If a response is received, the MN determines that the association with the VPNGW can be made, i.e. the MN is connected to the insecure network PN, whereby a VPN tunnel is required in order to continue communication with the CH. If no response is received, no association with the VPNGW can be made, and the MN continues, in step 403, to use Mobile IP services of the home agent HA, if possible and applicable. An IETF Internet-Draft “Mobile IPv4 Traversal Across IPsec-based VPN Gateways draft-ieff-mobileip-vpn-problem-solution-03”, S. Vaarala (Ed.), Sep. 29, 2003, discloses some mechanisms for detecting an entry in a secure or insecure network, and these mechanisms may be utilized in steps 401, 402. However, it is important to note that the arrangement in said IETF Internet-Draft is otherwise totally different from the present embodiment, i.e. said arrangement requires a combination of Mobile IP and IPsec layers to be used, thereby increasing packet overhead considerably.
Some further examples of as to how to arrange the above illustrated functionality in the mobile node MN are given in the following. The mobile node MN may send both IKE (Internet Key Exchange) and Mobile IP signaling messages and check which one is ready first. Based on this information, the MN may detect whether the secure or insecure network is available and continue with step 403 or 404. Further, out of band and/or history information on network connections may be utilized. For instance, if a network has previously been insecure, IKE negotiation may be first started. It is also possible that connection settings of a secure network (e.g. a company intranet) have been pre-stored in a mobile node MN, and the configuration indicates that the connection setting in question relates to the secure network. As an example, Symbian Network ID may indicate this information such that “Office” is determined to represent a secure network and “Internet” an insecure network.
Thus, also referring to step 304 in
If the mobile node MN moves such that it accesses the secure network SN directly, the mobile node MN is at home as regards Mobile IP and thus receives an agent advertisement from the home agent. In this case, the mobile node MN may communicate directly without any mobility related headers using the same IP address as used as the VPN internal IP address.
Referring to
In an alternative embodiment differing from those of
Use of the above described embodiments does not preclude use of an outer Mobile IP layer (i.e. IP mobility in the insecure network PN), or another VPN mobility solution, to provide mobility between access networks that are connected to the insecure side of the VPN gateway VPNGW. The above-described embodiments may still be used to provide VPN mobility. Even if two mobility layers (an outer layer for VPN mobility and an inner layer for intranet mobility) were used, an advantage obtained by the above-illustrated embodiment in the mobile node MN is that only one of the layers is active at a time, so double overhead is avoided.
In an embodiment not shown in
When the mobile node MN connects the secure network SN via the insecure network PN, it establishes a VPN tunnel to the VPN gateway VPNGW. After establishing the VPN tunnel, the mobile node MN registers with the foreign agent, co-located in the VPN gateway VPNGW. The mobile IP address registration is transported over the VPN tunnel. Foreign agent advertisements may also be delivered over the VPN tunnel prior to registration. As is usual in mobile IP, the foreign agent forwards the registration request to the internal home agent HA. From the viewpoint of the home agent HA, the registration looks similar to any other registration with an internal foreign agent. No non-standard functionality is required in the home agent HA. The VPN internal IP address is not used by the mobile node MN in this case, so it is not necessary to allocate one; however, it does not matter if such an address was allocated. In the packets that are tunnelled over the VPN tunnel, the home IP address is used as the IP address of the mobile node MN, such as usually in Mobile IP between the mobile node MN and the foreign agent FA. The foreign IP address (care-of-address, COA) is an address of the VPNGW. Applications in the mobile node MN are arranged to use the mobile IP home address. The network element(s) implementing the VPN gateway and foreign agent functionalities has to be capable of using the Mobile IP home address in the VPN tunnel as the IP address of the mobile node MN. This embodiment also avoids double tunneling from the mobile node MN, which is especially advantageous for wireless terminals operating over an air interface.
When the mobile node MN is registering via the VPN gateway VPNGW, a foreign agent-home agent tunnel can be arranged between the VPN gateway VPNGW and the home agent HA. As an example, a datagram destined to the mobile node's MN home address can be considered in a situation where the mobile node MN has registered to the home agent HA via the VPN gateway VPNGW: When the datagram reaches the secure network SN, the home agent HA intercepts it and tunnels it to the foreign agent, according to standard mobile IP procedures. The foreign agent co-located in the VPN gateway VPNGW decapsulates the datagram and the datagram is encapsulated again in the VPN tunnel to be delivered to the mobile node MN. In an alternative embodiment, the foreign agent transmits the decapsulated datagram to the VPNGW which intercepts it and encapsulates the datagram. The encapsulated datagram is then sent to the MN by the VPN tunnel. Thus, the mobile IP home address is used as the IP address of the mobile node MN in the packets that are tunneled over the VPN tunnel, in other words the same IP address is used as the internal VPN address and as the home address. The mobile node MN decapsulates the IPsec-tunneled datagram and delivers it to the application layer.
In a reverse direction, the mobile node MN is arranged to add IPSec headers to the packet being transmitted and transmit it to the VPNGW address. The VPNGW strips off the IPSec headers and the packet may be transmitted to the correspondent node CN in the secure network SN. The present invention can be implemented in the existing network elements and terminals. They all have processors and memory with which the inventive functionality described above may be implemented. The functions described above may be located in one network element or some of them may be in one element and the others in other elements regardless of how they are located in the examples that were used to illustrate the invention. Computer program codes executed in the central processing unit comprising one or more processors may be used for causing a terminal to function as the mobile node MN to implement the VPN protocol and Mobile IP protocol functions and the functionality related to arranging data transmission with the CH in the secure network SN, some embodiments of which were illustrated above in association with
The accompanying drawings and the related description are only intended to illustrate the present invention. Different variations of and modifications to the invention will be apparent to those skilled in the art without departing from the scope of the invention defined in the appended claims.
This application claims the benefit of U.S. Provisional Application No. 60/551,207, filed 8 Mar. 2004, the content of which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60551207 | Mar 2004 | US |