Network Working Group S. Vaarala (Ed.) Internet-Draft Netseal Expires: July 2, 2003 N. Baider Check Point G. Dommety E. Gelasco M. Kulkarni Cisco F. Adrangi Intel H. Levkowetz ipUnplugged Q. Zhang Liqwid D. Gellert Nokia January 2003 Mobile IPv4 Traversal Across IPsec-based VPN Gateways draft-ietf-mobileip-vpn-problem-solution-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 1] Internet-Draft MIPv4-VPN January 2003 Abstract This document outlines the proposed solutions and pro/con analysis for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The intent is to first document existing analysis, and in a later version move towards a single solution for IPv4. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Terms and abbreviations . . . . . . . . . . . . . . . . . 4 2. Proposed solutions . . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Dual HA (draft-nuopponen-vaarala-mipvpn-00) . . . . . . . 5 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 Security concerns . . . . . . . . . . . . . . . . . . . . 7 2.3 Optimized dual HA (draft-adrangi-mobileip-mipvpn-traversal-00) . . . . . . . 8 2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Use of Mobile IP signaling to VPN gateway (route optimization) . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02) . . . 12 2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6 Making VPN GW accept outer IP changes . . . . . . . . . . 14 2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . 14 2.6.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 15 2.7 Use IPsec instead of GRE/IP-IP for MIP tunnelling . . . . 16 2.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . 16 2.7.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 16 2.8 Host routing and end-to-end security . . . . . . . . . . . 17 2.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . 17 2.8.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 17 2.9 Explicit signaling to update IPsec endpoint . . . . . . . 18 2.9.1 Description . . . . . . . . . . . . . . . . . . . . . . . 18 2.9.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 18 2.10 Use Foreign Agent to route ESP . . . . . . . . . . . . . . 18 2.10.1 Description . . . . . . . . . . . . . . . . . . . . . . . 18 2.10.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Intellectual property rights . . . . . . . . . . . . . . . 20 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . 22 Vaarala (Ed.), et al. Expires July 2, 2003 [Page 2] Internet-Draft MIPv4-VPN January 2003 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . 25 Vaarala (Ed.), et al. Expires July 2, 2003 [Page 3] Internet-Draft MIPv4-VPN January 2003 1. Introduction The Mobile IP working group started a design team to explore the problem and solution spaces of IPsec and Mobile IP coexistence. The problem statement and solution requirements for Mobile IPv4 case was first documented in [1]. The design team then set out to evaluate solution candidates and ultimately arrive at a solution draft. The current version of this document outlines the solutions and the pro/con analysis of each solution done by the design team. Most of the material is from the design team mailing list and from conference calls. The intent is to first document existing analysis, and in a later version move towards a single solution for IPv4. 1.1 Related work Related work has been done on Mobile IPv6 in [2] which discusses the interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 signalling. The draft also discusses dynamic updating of the IPsec endpoint based on Mobile IP signaling packets. There has also been discussion on the IPsec mailing list about updating the IPsec endpoint when packets arrive from a new address. When NAT traversal is used, an update of the UDP port for NAT traversal is also required. The "transient pseudo-NAT" attack, described in [3] and [4], affects any approach which attempts to provide security of mobility signalling in conjunction with NAT devices. In many cases, one cannot assume any co-operation from NAT devices which thus have to be treated as "adversaries" of a sort. 1.2 Scope This document only covers a solution for IPv4. 1.3 Terms and abbreviations TBD. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 4] Internet-Draft MIPv4-VPN January 2003 2. Proposed solutions 2.1 Overview Multiple solution candidates have been identified by the design team. Some have been described in drafts while others on the mailing list or in face-to-face meetings. The sections correspond to originally identified proposals (in previous design team discussion) as follows: o Option 1.1: Section 2.2. o Option 1.2: Section 2.3. o Option 1.3: Section 2.4. o Option 2: Section 2.5. o Option 3: Section 2.6. o Option 4: Section 2.7. o Option 5: Section 2.8. o Option 6: Section 2.9. o Option 7: Section 2.10. 2.2 Dual HA (draft-nuopponen-vaarala-mipvpn-00) 2.2.1 Description The basic idea of this approach is to use three layers of tunnelling when the mobile node is outside the trusted network and has to go through a VPN to gain access. The outermost layer is "external Mobile IP", the middle layer is IPsec, and the innermost layer is "internal Mobile IP". Two home agents are required, one for the internal Mobile IP and another for the external Mobile IP. The solution has been documented in [5]. 2.2.2 Pros/cons Pros: o Does not require specification of new protocols (but an algorithm Vaarala (Ed.), et al. Expires July 2, 2003 [Page 5] Internet-Draft MIPv4-VPN January 2003 for secure detection of the trusted network is still required). o Does not require changes to VPN gateway (except to allow Mobile IP traffic to pass). o Doesn't require new functional entities. o Is a clean solution from protocol perspective. o Doesn't require removing or disabling the SA as MN moves from outside to inside the firewall (compare to optimized dual HA solution which has this requirement). o Although MN software needs to be changed, existing HA/FA elements can be used because no protocol changes are required. Cons: o Software complexity resulting from running two instances of MIP layer. For instance, the following complexities may apply to Microsoft Windows: 1. Layering and ordering of MIP layers in a standard way (i.e., using standard filterclass values) could be an issue in Windows NDIS network architecture. 2. Not using standard NDIS filterclass values to do layering and ordering of the MIP layers, could have implications in getting the driver to be signed by Microsoft. 3. Implementing the solution for Microsoft IPsec client becomes very complicated, as TCP/IP and IPsec are combined into one layer. This means that the upper MIP layer has to be placed above MS TCP/IP! Note: Corporate ITs are moving towards replacing vendor IPsec clients with MS IPsec clients to reduce overhead and cost in customer support and software distribution. VPN vendors also like the idea as it reduces their development, deployment, and support cost. o Packet Overhead - 20 bytes due to additional MIP layer, though this was not considered critical. o Routing inefficiencies - MIP traffic always traverse inside the firewall. Consider two MNs communicating outside the firewall, their traffic will have to route to the internal HA and back to outside the firewall. o MIP layer has to somehow query the VPN client for TIA (Tunnel Vaarala (Ed.), et al. Expires July 2, 2003 [Page 6] Internet-Draft MIPv4-VPN January 2003 Inner Address), which is most likely assigned by the VPN gateway. o The solution will not work where VPN gateway does NATing before it sends the decrypted packet inside. This is common in deployments where VPN client uses the care-of address as both tunnel inner and outer addresses. To get around this problem, the internal HA MUST implement MIP NAT extension. o Content scanning and filtering in the VPN or a separate firewall may block internal MIP traffic (which is IP-IP or IP-over-UDP encapsulated). o In summary, the most important concern is the software complexity which may prevent implementation and deployment of the solution for certain IPsec client architecture (e.g. Microsoft Windows). 2.2.3 Security concerns MIPv4 and IPsec have different goals and approaches for providing security services. MIPv4 typically uses a shared secret for authentication of (only) signalling traffic, while IPsec typically uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys. Thus, the overall security properties of a combined MIPv4 and IPsec system depend on both mechanisms. In a "dual HA" solution the external MIPv4 layer provides mobility for IPsec traffic. If the security of MIPv4 is broken in this context, traffic redirection attacks against the IPsec traffic are possible. However, such routing attacks do not affect other IPsec properties (confidentiality, integrity, replay protection, etc), because IPsec does not consider the network between two IPsec endpoints to be secure in any way. Because MIPv4 shared secrets are usually configured manually, they may be weak if easily memorizable secrets are chosen, thus opening up redirection attacks described above. Assuming the MIPv4 shared secrets have sufficient entropy, there are still at least the following differences and similarities between MIPv4 and IPsec worth considering: o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" attack described in [3] and [4], assuming that NAT traversal is enabled (which is typically the case). o When considering a "pseudo NAT" attack against standard IPsec and standard MIP (with NAT traversal), redirection attacks against MIP Vaarala (Ed.), et al. Expires July 2, 2003 [Page 7] Internet-Draft MIPv4-VPN January 2003 may be easier because: * MIPv4 re-registrations typically occur more frequently than IPsec SA setups (although this may not be the case for mobile hosts). * It suffices to catch and modify a single registration request, whereas attacking IKE requires that multiple IKE packets are caught and modified. o There may be concerns about mixing of algorithms. For instance, IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC- MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore, while IPsec algorithms are typically configurable, MIPv4 clients typically use only HMAC-MD5 or prefix+suffix MD5. Although this is probably not a security problem as such, it is more difficult to communicate. o When IPsec is used with a PKI, the key management properties are superior to those of basic MIPv4. Thus, adding MIPv4 to the system makes key management more complex. o In general, adding new security mechanisms increases overall complexity and makes the system more difficult to understand. 2.3 Optimized dual HA (draft-adrangi-mobileip-mipvpn-traversal-00) 2.3.1 Description The main motivation behind this solution is to eliminate the double MIP encapsulation, which in turn eliminates the extra 20 byte overhead. This is done to mainly reduce the software complexity as the dual HA solution requires dual Mobile IP layer running on the client. In a sense, the VPN incorporates some FA features, in particular detunneling of IP-IP -- consider the VPN tunnel as a "private link" between an MN and an FA, capable of exchanging packets which use the MN's home address. However, this analogy is not complete because there is no FA advertisement support and the VPN does not participate in the registration directly. The proposal is described in [6]. 2.3.2 Pros/cons Pros: Vaarala (Ed.), et al. Expires July 2, 2003 [Page 8] Internet-Draft MIPv4-VPN January 2003 o Optimizes 20 bytes of packet overhead compared to "basic dual HA" when MN is outside. o When two MNs which are outside communicate with each other, traffic does not go through the HA(s). * Comment: Is this desireable? The HA may be used as a policy enforcement point, and this mechanism bypasses the HA. * Comment: The draft could be applied without bypassing the HA, so this is just an option. o Client network stack architecture may be easier (than in basic dual HA solution) in some cases, as only one actual MIP layer (underneath IPsec) is required. * When MN outside, the inner MIP registration can be sent using a normal UDP socket. In other words, there *are* two MIP layers, but only one IP-IP encaps/decaps layer. * This advantage is pronounced when the IPsec implementation is built into the TCP/IP stack and packet interception between the IPsec and the TCP/IP is difficult. For instance, consider Windows 2000/XP IPsec implementation. o Because the VPN sees MN traffic in unencapsulated form (and is required to decapsulate encapsulated traffic), content scanning and NATing are not a problem. Cons: o The client requires a rather broad MIP/VPN "coexistence API". Since we're not specifying this API, the promise of multi-vendor solutions may not be actually realized (i.e. there will be a de facto API, or vendor specific APIs, etc). o The VPN software needs a software upgrade (both VPN client and VPN gateway). * If the vendor does not yet have a patch, or decides that it will not implement a patch, the customer has to change VPN vendor to take advantage of this solution. This goes against preserving existing investment (in some cases). * Even if a patch is available, there is a coupling between MIP and VPN vendors, as the MIP vendor needs to deal with various VPNs and their software upgrades. This goes against independence of MIP and VPN solutions; ideally MIP and VPN Vaarala (Ed.), et al. Expires July 2, 2003 [Page 9] Internet-Draft MIPv4-VPN January 2003 deployments should not interfere. * Note, however, that even the basic "dual HA" solution may require a VPN patch or at least reconfiguration. Consider for instance VPN devices that perform stateful session tracking etc. Although these are not part of the IPsec specifications, such configurations exist. o MIP and IPsec are tightly bound in the solution, which may not be architecturally wise. Layering violations often manifest as subtle problems later. o The MN needs to know the VPN private interface address when outside. * This is a piece of information that may or may not be available in a "standard IPsec implementation". There is no standard for getting this information -- hence a solution would either use a proprietary protocol or manual configuration. Neither seems appealing. * What if the VPN private interface address changes -- e.g. the admin changes network numbering? How are the MNs informed? If manual config is used, do all MNs need to be reconfigured manually? * What if multiple routes to intranet are used (i.e. there are multiple private interfaces)? Should all such addresses be given to the MN? If so, which address should the MN use? Should the MN and the VPN dynamically negotiate this somehow? o The VPN routing is quite complex. Routing decisions need to be based on existence of IPsec SAs -- a packet destined to an intranet address is either (a) sent to the intranet if there is no SA for the host (host is in intranet or does not exit), or (b) sent to the internet using an IPsec SA because an SA exists. * In other words, existence of an SA is taken to imply that the MN is outside, which may not be a sound assumption, and not rooted in the IPsec specs. As a result, the MN is required to delete all IPsec SAs (on the VPN gateway) when it returns to the intranet; otherwise packets from other MNs which are outside end up in a black hole. * IP-IP decapsulation + subsequent IPsec SA application may not be easy in all VPN architectures. * However, some VPN vendors have indicated that this change is no Vaarala (Ed.), et al. Expires July 2, 2003 [Page 10] Internet-Draft MIPv4-VPN January 2003 big deal to them. If this generalizes to a vast majority of VPN implementations, then perhaps this is not such a big concern. o The fact that IPsec SA deletion is mandatory raises a few further requirements: * IKE DELETE must be supported; not all vendors support that now. * What if the MN crashes? The MN must use INITIAL-CONTACT to flush out any SAs used before the crash; this in turn requires support from the VPN, and places more requirements on the client API. * The MN must be able to send the IKE DELETE to the VPN public address *from the intranet*. Sometimes firewalls do not allow this, which raises new firewall requirements. o IPsec SA deletion also implies that in a scenario where the MN (1) first sets up an SA, (2) goes back inside (deleting SAs), then (3) goes back outside, the MN is (unnecessarily) required to reauthenticate. This is emphasized when IPsec uses legacy authentication and requires user interaction during authentication. * Although many VPN vendors use keepalives and delete inactive SAs, there's nothing in the IPsec specs to prevent one from reusing existing SAs even after a period of inactivity. * Thus there is no IPsec reason not to pick up old SAs when the MN goes back outside (remember that the MN may be inside only for a few minutes in some cases; the proposed approach requires SA deletion in all cases). o Handling of non-unicast packets requires non-standard use of the "D"-bit in the RRQ (see Section 2.2.2.1). (Does the same apply to GRE?) o Dynamic home address allocation is complicated, as the draft assumes that the (internal) home address is known when setting up an IPsec tunnel. The draft requires a two-phase solution where an IPsec SA with "any" address is established first (in order to get the home address), and then a new IPsec SA is established. The security considerations described in Section 2.2.3 apply to this proposal as well. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 11] Internet-Draft MIPv4-VPN January 2003 2.4 Use of Mobile IP signaling to VPN gateway (route optimization) 2.4.1 Description Use of Mobile IP signaling to VPN gateway (use of Update message to update the MN binding). 2.4.2 Pros/cons Pros: o Works well even if there is a outside HA (by another party/operator). Cons: o New MIPv4 functionality on VPN gateway (but only route optimization part of MIPv4). o Need to consider the route optimization draft which has a lot of other things. 2.5 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02) 2.5.1 Description The proposed Mobile IPv4 proxy solution is described in [7]. A quote from the draft summarizes the idea: This draft introduces a logical component called the Mobile IP Proxy (MIP Proxy) to enable seamless Mobile IPv4 functionality across VPN gateways, without requiring any IPsec VPN protocol changes to VPN gateways. The solution aims specifically at extending the use of deployed IPsec-based VPN gateways, a feature that is much desired by corporate IT departments. The solution also leverages [11] to support Mobile traversal across "NAT and VPN" gateways. The "NAT and VPN" refers to a network topology where Mobile IP traffic has to traverse one or more NAT gateway(s) followed by a VPN gateway in the path to its final destination. While the discussion in this draft is limited to IPsec-based VPN gateways, it should be compatible with other IP-based VPN solutions as well. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 12] Internet-Draft MIPv4-VPN January 2003 2.5.2 Pros/cons Pros: o Uses standard (single mode) mobile IP client. * MIP client will run only one MIP layer and still enable seamless VPN traversal. * MIP layer is inserted below the VPN layer. This is an advantage given that most operating systems will allow it. Insertion above the VPN layer is in general more complicated at least in multi-vendor solutions. o Tunneling overhead: * MIP proxies will keep the Mobile IP tunneling overhead at a minimum, that is, Mobile IP tunneling for a single MIP layer. Cons: o Assumes that the VPN client and Mobile IP client use the same IP address (MN-Perm). * This is complicated in most if not all operating systems and will require close integration between the VPN client and the MIP client. VPN clients that use specific VPN adapters are one example. These adapters are usually enabled when the tunnel is established, and disabled when the tunnel goes down. Since MN- Perm is used for application binding too, the VPN adapter scheme used by numerous VPN solutions must be handled in a different way. * In addition, there is a problem on the server side since both VPN gateway and Internal HA needs control over the same IP address. There are interesting ARP issues related to this. o New Mobile IP entity, i.e. MIP Proxy: * MIP proxy will require a lengthy standardization process. * Support for new HA parameter extension is necessary to convey the IP address of the internal HA. * An additional entity will only add to the installation complexity of Mobile IP systems. * MIP Proxies must be deployed in the DMZ. In larger Vaarala (Ed.), et al. Expires July 2, 2003 [Page 13] Internet-Draft MIPv4-VPN January 2003 organization, this can be a problem due to limited scalability regarding the number of users and the overall performance. * Enterprises can not leverage public Mobile IP services. o Requires specific DMZ setup and network design: * The traffic paths for incoming and outgoing traffic are asymmetric and complicated with impact on DMZ routing. In addition, there are non-trivial L2-switching/L3-routing issues in both the VPN gateway and MIP proxy to make the scheme work. * The security depends on DMZ firewall configuration and routing. * Non-trivial firewall rules for inner and outer FW are necessary to make the scheme work properly. o Upgrade/transition path to IPv6: * There are no evident upgrade or transition paths to Mobile IPv6. It will be very hard to run different IP versions on both sides of the MIP proxy. The surrogate operation is already non-trivial and the translation will be even harder in a IPv4/IPv6 MIP proxy. o To summarize, the biggest concerns are introduction of a new entity and the use of a common MN-Perm address. At the moment, this will make it very hard to implement a multi-vendor client solution use existing VPN solutions. This can probably be handled by the VPN vendors, but it will take time and effort to do it. o Applicability in enterprises with distributed or redundant VPN gateway solutions may be an issue. 2.6 Making VPN GW accept outer IP changes 2.6.1 Description The suggestion is for the VPN GW to detect changes in the source IP address of the incoming IPsec packets coming from the MN, and send IPsec packets to the updated address. The primary IP address to be used, is the one the IKE negotiation came from. If that IP changes, it is assumed that this is because the MN IP address or care-of- address has changed. A related idea is updating the UDP source port when doing IPsec NAT traversal. This idea has also been suggested on the IPsec mailing Vaarala (Ed.), et al. Expires July 2, 2003 [Page 14] Internet-Draft MIPv4-VPN January 2003 list. 2.6.2 Pros/cons Pros: o It is the quickest way to change IP. o No registration is required. o No dual HA is required, just a single instance of MIPv4. o It is difficult to break as it is difficult to fake a legally encrypted and authenticated IPsec packet. o Even if, in some way, a bogus IPsec packet succeeds to change what the GW sees as the MN care-of-address, the next packet from the MN to the GW will reinstate the proper address. Cons: o The "Security Architecture for the Internet Protocol" RFC (2401) states: * A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. o It is probably commonly assumed that the IP Destination Address is the external IP header destination, while the current proposal suggests changing it. It is not clear, however, if the security benefit of fixing the destination IP is significant. It is also possible to consider the tunnel internal IP as the fixed destination IP, which alleviates the need to modify the RFC definition. o If the MN changes it's care-of-address, and no traffic is going from the MN to the VPN GW at that time, it may be required to send an IPsec packet to the GW just for the update. Doesn't sound so bad, but yet another design consideration. Open: o Is this implemented in majority of VPNs? o Does this break IPsec? Vaarala (Ed.), et al. Expires July 2, 2003 [Page 15] Internet-Draft MIPv4-VPN January 2003 o Is this within the purview of IPsec? o Can we make this a recommendation for VPN gateways? 2.7 Use IPsec instead of GRE/IP-IP for MIP tunnelling 2.7.1 Description The general idea is that instead of IP-IP or GRE (or minimal encapsulation) provided by Mobile IPv4 at the moment, IPsec tunneling would be used in place of IP-IP. IPsec tunneling provides the same functionality as IP-IP tunneling so this should be reasonable straightforward. MN --------- FA ------------------- HA -------- CN MN using FA CoA |======================| IPSec Tunnel MN using CCoA |====================================| IPSec Tunnel The mobility agents and their placement is as shown in the figure above. MN can use either FA CoA or Collocated COA as shown above and hence there will be two cases of IPSec tunnel. 2.7.2 Pros/cons Pros: o Mobility and security are logically at the same level of the protocol stack. This approach combines the two and hence makes the system design simple. o No extra tunneling overhead (IP-IP or GRE). Cons: o When MN uses FA CoA, the IPSec tunnel is between HA and FA. HA to FA traffic is encrypted, but the data goes in clear between MN and FA. o The above problem can be fixed if the IPSec tunnel is between MN and HA, then all the traffic is encrypted. But it creates another Vaarala (Ed.), et al. Expires July 2, 2003 [Page 16] Internet-Draft MIPv4-VPN January 2003 problem. When the MN changes CoA, the IPSec tunnel end-point changes, terminating the IPSec tunnel. IKE re-negotiation must take place between the HA and the new CoA. This will lead to sessions getting dropped, not to mention more IKE overheads due to frequent MN movements. o When the FA and HA are not in the same administrative domain, deployment issues may arise because FA and HA can not share credentials. That means IKE/IPSec between HA and FA can't work. o This is a new functionality involving all mobility agents. Hence change is required in the implementation of HA, FA and MN. 2.8 Host routing and end-to-end security 2.8.1 Description The general idea was to use some sort of "full" or "partial" (i.e. only some routers support) host routing when the mobile node is outside. (The idea is similar to the Cellular IP and HAWAII approaches for limited host routing.) 2.8.2 Pros/cons Pros: o No change to IPsec. o No extra packet overhead. Cons: o Deviation from Mobile IP. Basically we invent a modified mobility management mechanism. o Security model unknown. o Overlapping IP addresses are harder to accommodate. o Route convergence and route explosion for large number of mobiles, especially if moving between two access types. o Distributed solution, hard to manage. General feeling: too much deviation from Mobile IP, impractical. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 17] Internet-Draft MIPv4-VPN January 2003 2.9 Explicit signaling to update IPsec endpoint 2.9.1 Description This proposal is essentially the same as Section 2.6 except that explicit signalling is used to update IPsec SA endpoints. The form of signalling could be e.g. Mobile IP messages. 2.9.2 Pros/cons Open: o What are the security considerations to IPsec? o Is this within purview of IPsec? o Is it acceptable to make recommendations to VPN gateway implementations? 2.10 Use Foreign Agent to route ESP 2.10.1 Description Referring to Figure 11 of the problem statement [1], the problem is that the FA cannot understand MIP signalling because it is encapsulated inside IPsec. Thus we add some signalling to IPsec which gives the FA the information it would otherwise get through MIP signalling. A brief analysis of this is that this in effect, if not in exact implementation, would be equivalent to wrapping the IPsec inside another layer of MIP, to get the relevant signalling through to the FA. There are at least two approaches: o Add signalling to the IPsec protocol, and at the same time add functionality to the FA and VPN-GW to make them understand the signalling. This signalling would replicate equivalent MIP signalling but within IPsec. o Wrap IPsec inside a MIP tunnel which carries the signalling between FA and VPN-GW. However, this alternative is the "dual HA" solution. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 18] Internet-Draft MIPv4-VPN January 2003 2.10.2 Pros/cons Pros: o No new overhead to IPsec, but functionality similar to wrapping IPsec inside MIP. o Would allow (modified) FAs to be used, to conserve address space, etc. Cons: o Makes two currently independent protocols (MIPv4 and IPsec) dependent. o Introduces changes to FA, VPN gateway, and the IPsec protocol. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 19] Internet-Draft MIPv4-VPN January 2003 3. Intellectual property rights Design team members were still investigating possible IPR issues when this draft was submitted. More detail will be presented in later versions of the draft. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 20] Internet-Draft MIPv4-VPN January 2003 4. Acknowledgements The authors would like to thank MIP/VPN design team, especially Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their continuous feedback and helping us improve this draft. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 21] Internet-Draft MIPv4-VPN January 2003 References [1] Adrangi, F., Kulkarni, M., Dommety, G., Gelasco, E., Zhang, Q., Vaarala, S., Gellert, D., Baider, N. and H. Levkowetz, "Problem Statement and Solution Guidelines for Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-ietf-mobileip-vpn- problem-statement-guide-00e, work in progress)", January 2003. [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in progress)", October 2002. [3] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed (draft-dupont- transient-pseudonat-01, work in progress)", December 2002. [4] Levkowetz, H. and S. Vaarala, "Mobile IP NAT/NAPT Traversal using UDP Tunnelling (draft-ietf-mobileip-nat-traversal-07, work in progress)", November 2002. [5] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with IPsec remote access tunnelling (draft-nuopponen-vaarala-mipvpn- 00, work in progress)", July 2002. [6] Adrangi, F., Iyer, P., Zhang, Q. and N. Baider, "Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-adrangi- mobileip-mipvpn-traversal, work in progress)", January 2003. [7] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., Zhang, Q. and J. Lau, "Mobile IPv4 Traversal Across IPsec-based VPN Gateways (draft-adrangi-mobileip-vpn-traversal-02)", July 2002. Authors' Addresses Sami Vaarala Netseal Niittykatu 6 Espoo 02201 FINLAND Phone: +358 9 435 310 EMail: sami.vaarala@iki.fi Vaarala (Ed.), et al. Expires July 2, 2003 [Page 22] Internet-Draft MIPv4-VPN January 2003 Nitsan Baider Check Point Software Technologies, Inc. Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA EMail: gdommety@cisco.com Eli Gelasco Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA EMail: egelasco@cisco.com Milind Kulkarni Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 408-527-8382 EMail: mkulkarn@cisco.com Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR USA Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com Vaarala (Ed.), et al. Expires July 2, 2003 [Page 23] Internet-Draft MIPv4-VPN January 2003 Henrik Levkowetz ipUnplugged AB Arenavagen 33 Stockholm S-121 28 SWEDEN Phone: +46 8 725 9513 EMail: henrik@levkowetz.com Qiang Zhang Liqwid Networks, Inc. 1000 Wilson Blvd, Suite 900 Arlington, VA 22209 USA Phone: +1 703-224-1120 -x 203 EMail: qzhang@liqwidnet.com Dorothy Gellert Nokia Corporation Vaarala (Ed.), et al. Expires July 2, 2003 [Page 24] Internet-Draft MIPv4-VPN January 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vaarala (Ed.), et al. Expires July 2, 2003 [Page 25]