MIP4 Working Group M. Sahasrabudhe Internet-Draft Nokia Intended status: Standards Track V. Devarapalli Expires: October 20, 2007 Azaire Networks April 18, 2007 Optimizations to Secure Connectivity and Mobility draft-meghana-mip4-mobike-optimizations-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 October 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Users that need to connect to their enterprise network from an untrusted network require secure connectivity and mobility. Enterprise users are increasingly using mobile nodes. A user may need to connect to the enterprise network from anywhere, and in a number of scenarios, from untrusted networks. There are existing specifications developed by the Mobile IPv4 working group that describe solutions for enterprise secure connectivity and mobility. Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 1] Internet-Draft VPN Gateway and FA co-location April 2007 This document proposes optimizations to those solutions to reduce the tunneling overhead and allow for a number of new access modes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Access mode: 'fvf' . . . . . . . . . . . . . . . . . . . . 6 3.3. Access mode: 'cvf' . . . . . . . . . . . . . . . . . . . . 7 3.4. Access mode: 'mf' . . . . . . . . . . . . . . . . . . . . 7 4. Home Address as IPsec TIA . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 2] Internet-Draft VPN Gateway and FA co-location April 2007 1. Introduction It is assumed that the reader is familiar with the use of MIP4 and MOBIKE to provide security connectivity and mobility to an enterprise user [2]. This document talks about optimizations to the solution proposed in [2] and also to [6]. An enterprise user authenticates to the VPN gateway from an untrusted network to gain access to the services on the enterprise network. While inside the network, a user doesn't need to use the VPN gateway. When a user roams in and out from a trusted to an untrusted network the sessions currently active should not drop and the change in connectivity should be seamless to the user. The solution in [2] elaborates that the user uses only Mobile IPv4 [3] when inside the enterprise network and uses IPsec VPNs with MOBIKE extensions to IKEv2 when roaming outside the enterprise network to have access to the services provided by the enterprise. Point to note is that this solution does not support legacy IPsec VPNs. The VPN gateways have to implement mobility extensions to IKEv2 [4]. The solution also does not require multiple Home Agents or a Home Agent in the DMZ. The Home Agent is always located inside the enterprise network. The tunnel inner address of the IPsec tunnel is used as the MIPv4 co-located care of address (CCoA). As long as the mobile node is connected to the same VPN gateway and its TIA remains the same, there is no change in the CoA used by the mobile node. When the mobile node moves to a new VPN gateway or gets a new TIA, it updates its home agent with its new CCoA. The packet format for packets sent from the mobile node to a correspondent node, when the mobile node is outside the enterprise, looks as follows IPv4 hdr (src=IPA, dst=VPN_GW) ESP Hdr IPv4 hdr (src=TIA, dst=HA) IPv4 hdr (src=HoA, dst=CN) Payload From the VPN gateway to the correspondent node the packet looks as follows IPv4 hdr (src=TIA, dst=HA) IPv4 hdr (src=HoA, dst=CN) Payload When the mobile node is inside the enterprise the packet format looks as follows Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 3] Internet-Draft VPN Gateway and FA co-location April 2007 IPv4 hdr (src=IPA, dst=HA) IPv4 hdr (src=HoA, dst=CN) Payload There is additional tunneling overhead when the mobile node is roaming in an untrusted network. This overhead can be avoided by having the Mobile IPv4 Foreign Agent functionality on the VPN gateway. This would avoid having to encapsulate a Mobile IP tunnel inside an IPsec tunnel. The following sections describe an optimized connectivity and roaming solution that reduces the packet overhead from the solution described in [2]. 2. Terminology i-MIP: Mobile IP layer used for internal enterprise mobility. Home Agent is inside the enterprise network. x-MIP: Mobile IP layer used for access from outside the enterprise network. Home Agent resides either in the Internet or in the DMZ before the VPN gateway looking from the Internet i-HA: Home Agent inside the enterprise network x-HA: Home Agent outside the enterprise network i-FA: Mobile IPv4 foreign agent residing in the trusted enterprise network FA CoA: Foreign Agent mode care of address cCoA: co-located care of address HoA: Home address TIA: Tunnel Inner Address, the address given out to the mobile node by the VPN gateway during IKE setup The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 3. Solution Overview The optimization proposed in this document places the Foreign Agent on the VPN gateway. This reduces the tunnel overhead as the additional tunneling from the TIA to the Home Agent is not required. Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 4] Internet-Draft VPN Gateway and FA co-location April 2007 When the VPN gateway receives the packet from the mobile node, it removes the IPsec header and the FA functionality on the VPN GW encapsulates the original packet and sends it to the Home Agent inside the enterprise. The packet format from the mobile node to the VPN gateway now looks as follows IPv4 hdr (src=IPA, dst=VPN_GW/FA) ESP hdr IPv4 hdr (src=HoA, dst=CN) Payload From the VPN gateway to the correspondent node the packet looks as follows IPv4 hdr (src=VPN_GW/FA, dst=HA) IPv4 hdr (src=HoA, dst=CN) Payload Figure 6 depicts the network topology assumed for the solution. It also shows the possible mobile node locations and access modes. (MN) {mf} {home} (MN) [i-HA] ! \ / .--+---. .-+---+-. ( ) ( ) `--+---' [MVPN/FA] `--+----' \ ! ! [R/FA] .--+--. [R] \ ( DMZ ) ! .-+-------+--. `--+--' .-----+------. ( ) ! ( ) ( external net +---[R]----[FW]----[R]--+ internal net ) ( ) ( ) `--+---------' `---+---+----' / / \ [DHCP] [R] [DHCP] [R] [R] [i-FA] \ / \ / \ / .+--+---. .-+-+--. .--+--+-. ( ) ( ) ( ) `---+---' `--+---' `---+---' ! ! ! (MN) {mf} (MN) {c} (MN) {f} Figure 6: Network Topology with FA colocated on VPN gateway Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 5] Internet-Draft VPN Gateway and FA co-location April 2007 The tunnel overhead reduction is significant especially if the mobile node is connected over a wireless network. The optimization requirement of co-locating the Foreign Agent with the VPN gateway can place the FA multiple hops away from the mobile node. FA availability is hence an issue here. The FA still has to be on link for the mobile node to receive Agent Advertisement messages. There already exists a tunnel interface between the mobile node and the VPN gateway. This tunnel interface can be used so the FA can appear just one hope away and on link to the mobile node. The FA sends out Agent Advertisement messages on the tunnel interface. The mobile node too can send out MIP control messages to the FA on the tunnel interface. 3.1. Access modes The access modes possible in [1] are f: i-MIP with FA-CoA c: i-MIP with CCoA mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA The additional access modes possible with the optimizations in this document are fvf: x-MIP with FA CoA/ VPN/ i-MIP with FA CoA cvf: x-MIP with CCoA/VPN/ i-MIP with FA CoA mf: mobile enhanced VPN, i-MIP with FA CoA 3.2. Access mode: 'fvf' In this access mode there are two home agents. One Home Agent is located inside the enterprise and one outside the enterprise in the internet or the DMZ before the VPN gateway looking from the internet. In this mode the mobile node uses the external care-of address (x-FACoA) and an external home address (x-HoA). Packets are first tunneled to the external home Agent, then to the VPN gateway and eventually to the internal home Agent. Packet format from the mobile node to the VPN gateway looks as follows: IPv4 hdr (src=x-FA-CoA, dst=x-HA) IPv4 hdr (src=i-HoA, dst=VPN_GW/FA) ESP hdr IPv4 hdr (src=i-HoA, dst=CN) Payload Packet format from the VPN gateway to the correspondent node looks as follows: Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 6] Internet-Draft VPN Gateway and FA co-location April 2007 IPv4 hdr (src=VPN_GW/FA, dst=i-HA) IPv4 hdr (src=i-HoA, dst=CN) Payload 3.3. Access mode: 'cvf' There are two home agents here also. One Home Agent is located inside the enterprise and one outside the enterprise in the internet or the DMZ before the VPN gateway looking from the internet. In this mode tme mobile node uses the external co-located care-of address (x-cCoA) and an external home address ( x-HoA).Packets are first tunneled to the external home Agent, then to the VPN gateway and eventually to the internal home Agent. Packet format from the mobile node to the VPN gateway looks as follows: IPv4 hdr (src=x-cCoA, dst=x-HA) IPv4 hdr (src=i-HoA, dst=VPN_GW/FA) ESP hdr IPv4 hdr (src=i-HoA, dst=CN) Payload Packet format from the VPN gateway to the correspondent node looks as follows IPv4 hdr (src=VPN_GW/FA, dst=i-HA) IPv4 hdr (src=i-HoA, dst=CN) Payload 3.4. Access mode: 'mf' In this mode the VPN gateway is mobility aware in the sense that it also implements MOBIKE extensions in addition to being a Foreign Agent. The mobile node uses the TIA as a co-located care-of address. Packet format from mobile node to the VPN GW/FA looks as follows: IPv4 hdr (src=IPA, dst=VPN_GW/FA) ESP hdr IPv4 hdr (src=TIA, dst=HA) IPv4 hdr (src=HoA, dst=CN) Payload Packet format from the VPN gateway to the correspondent node looks as follows: Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 7] Internet-Draft VPN Gateway and FA co-location April 2007 IPv4 hdr (TIA, dst=i-HA) IPv4 hdr (src=i-HoA, dst=CN) Payload The advantage in using access modes 1 and 2 is that these can still be used with legacy IPsec VPNs. Hence these can be deployed in existing enterprise networks that may have already invested heavily in legacy VPNs and would be reluctant to upgrade the VPN gateways in the enterprise network. 4. Home Address as IPsec TIA When the mobile node sets up an IPsec tunnel with the VPN gateway it is allocated a tunnel inner address (TIA). The TIA is used as the source address for all traffic sent through the IPsec tunnel. The tunnel mode IPsec security associations are created based on TIA. But when a foreign agent functionality exists on the VPN gateway, the mobile node MUST use the home address as the source address on the data traffic. Moreover, the optimization described in Section 3.4 is possible only if the home address is equal to the TIA. In order for the home address to be equal to the TIA, there is a need for close interaction between the IKEv2 implementation and Foreign agent implementation on the VPN gateway. This may not be possible with all implementations, since the IPsec tunnel setup happens before an Foreign Agent Advertisement can be sent over the IPsec tunnel to the mobile node. One possible solution would be to allocate a TIA when the IPsec tunnel is setup and later replace the TIA with the home address. This would require updating the IPsec SAs with the new home address. But this would violate RFC 4301 [8] which says the TIA cannot be changed without rendering the tunnel mode IPsec SAs invalid. A simple solution would be for the mobile node to setup an IPsec tunnel with the TIA allocated by the VPN gateway, and then run a separate CREATE_CHILD_SA exchange [5] to setup new tunnel mode IPsec security associations for the home address. This would however introduce additional delay in the form of an additional CREATE_CHILD_SA exchange when the mobile node connects to the enterprise network from outside. The security associations created earlier for the TIA may be either torn down or allowed to expire based on the configuration on the mobile node and the VPN gateway. 5. Security Considerations The solution described in this document does not introduce any new Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 8] Internet-Draft VPN Gateway and FA co-location April 2007 security vulnerabilities on top of what is described in the security considerations sections of [2], [6] and [7]. 6. IANA Considerations This document requires no action from IANA. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", draft-ietf-mip4-mobike-connectivity-03 (work in progress), March 2007. [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 7.2. Informative References [6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across IPsec-based VPN Gateways", draft-ietf-mip4-vpn-problem-solution-02 (work in progress), November 2005. [7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005. [8] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 9] Internet-Draft VPN Gateway and FA co-location April 2007 Authors' Addresses Meghana Sahasrabudhe Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Email: meghana.saha@nokia.com Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 10] Internet-Draft VPN Gateway and FA co-location April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sahasrabudhe & Devarapalli Expires October 20, 2007 [Page 11]