marco conceptual

This section describes the problems in deploying MIPv4 when working with IPSec-based VPN. There are several ways in which a VPN gateway (GW) and MIP HA can be deployed. Scenarios where IPSec is encapsulated by MIP do not face problems; the issue in such a case is multivendor support. Scenarios where MIP is encapsulated by IPSec have serious problems; this issue will be discussed here.

6.6.6.1 Scenarios

To start with we will briefly look at different scenarios of deploying MIP and VPN and after that we will discuss in depth the scenario of concern.

Possible ways of deploying MIP and IPSec are listed as follows [19]:

1. MIPv4 HA(s) inside the intranet behind an IPSec-based VPN gateway:

Requires MIP inside IPSec; this means that traffic between the MN and the VPN server is encrypted. Thus if a FA is being used it cannot inspect and relay the packet. A CCoA might work but it means that the VPN tunnel should be renegotiated every time the MN changes its point of attachment.

2. VPN Gateway and MIPv4 HA(s) in parallel at the network border (i.e., VPN and HA are separate): This scenario can work with MIP in IPSec or IPSec in MIP. MIP in IPSec will have the same problem as in 1. IPSec inside MIP will have no problem though there will be routing logic modification needed at the VPN gateway or the HA.

3. Combined VPN gateway and MIPv4 HA: This way IPSec in MIP can be easily used but it does not support multi-vendor interoperability.

4. MIPv4 HA(s) outside the VPN domain: Same as 3 except that the HA is separate and placed away from the VPN gateway outside the home network.

5. Combined VPN gateway and MIPv4 HA(s) on the local link, (i.e., using NAT at the firewall and VPN/HA inside the intranet). It can be possible to

MN

Care of Address (CoA) Home Agent (HA)

HA address IPSec based VPN GW

VPN address IPSec

MIP inside IPSec

 Figure 6.14 MIP with collocated address.

give the user IPSec connectivity using solutions; now this scenario is similar to 3. In the case of MIP inside IPSec, the problem is the same as in 1.

As scenario 1 is the one supposed to be most practical [19], its issues are further discussed below.

6.6.6.2 MN Registers with its MIPv4 HA Using CCoA

Figure 6.14 shows the MIPv4 and the IPSec tunnel endpoints in co-located mode.

MN’s CoA (most likely obtained through DHCP) is used as both the IPSec and MIP tunnel outer addresses at the MN end.

The MN obtains a CoA at its point of attachment (via DHCP or some other means), and then first sets up an IPSec tunnel to the VPN gateway, after which it can successfully register with its HA through the IPSec tunnel. The problem is that in an end-to-end security model, an IPSec tunnel that terminates at the VPN gateway must protect the IP traffic originating at the MN. If the IPSec tunnel outer address is associated with the CoA, the tunnel SA must be refreshed after each IP subnet handoff, which could have noticeable performance implications on real-time applications. As MIPv6 uses CCoA, the issues discussed above are also valid for IPSec usage with MIPv6.

Foreign Agent (FA) MN-CoA MN

Home Agent (HA) HA address IPSec based VPN GW

VPN address IPSec

MIP

 Figure 6.15 MIP with FA.

6.6.6.3 MN registers with its HA Through a FA

Figure 6.15 shows the MIPv4 and the IPSec tunnel endpoints in a hypothetical (but impossible) noncollocated mode. MN’s home address and CoA (i.e., a FA address) are used as the IPSec and the MIP tunnel outer addresses, respectively. Please note that the MN does not have a CoA assigned to its physical interface in non-co-located mode.

There are a number of problems with this. Simply put, you could say that the FA needs to see the MIP tunnel outermost, while the VPN-GW needs to see the IPSec tunnel outermost. A more detailed explanation follows.

First, the MN must have an IPSec tunnel established with the VPN-GW in order to reach the HA, which places the IPSec tunnel outside the MIP traffic between MN and HA. The FA (which is likely in a different administrative domain) cannot decrypt MIPv4 packets between the MN and the VPN gateway, and will consequently not be able to relay the MIPv4 packets. This is because the MIPv4 headers (which the FA should be able to interpret) will be encrypted and protected by IPSec.

Second, when the MN is communicating with the VPN-GW, an explicit bypass policy for MIP packets is required, so that the MN can hear FA advertisements and send and receive MIP registration packets. Although not a problem in principle, there may be practical problems when VPN and MIP clients from different vendors are used.

6.6.6.4 Solutions

Reference [20] discusses pros and cons of the solutions available in the open literature. Details will not be given in this document. Solutions discussed in [4] are listed as follows:

1. Dual HA: This solution says that two HAs should be used, for internal and external, respectively. This leads to three layers of tunnels: external HA, IPSec and internal HA.

2. Optimized dual HA: The motivation of this solution is to eliminate use of double MIP encapsulation discussed in 1.

3. Use of Mobile IP signaling to VPN gateway (route optimization).

4. MIP proxy: This solutions aims at introducing a MIP proxy for seamless traversal across VPN.

5. Making VPN GW accept outer IP changes.

6. Use IPSec instead of GRE/IP-IP for MIP tunneling.

7. Host routing and end-to-end security.

8. Explicit signaling to update IPSec endpoint.

9. Use FA to route ESP.