Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
RFC 5266
Document | Type |
RFC - Best Current Practice
(June 2008; No errata)
Also known as BCP 136
|
|
---|---|---|---|
Authors | Pasi Eronen , Vijay Devarapalli | ||
Last updated | 2015-10-14 | ||
Replaces | draft-devarapalli-mip4-mobike-connectivity | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5266 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Jari Arkko | ||
Send notices to | (None) |
Network Working Group V. Devarapalli Request for Comments: 5266 Wichorus BCP: 136 P. Eronen Category: Best Current Practice Nokia June 2008 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6 3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6 3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6 3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7 3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7 3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7 3.4.1. Operation When Moving from an Untrusted Network . . . 8 3.4.2. Operation When Moving from a Trusted Network . . . . . 9 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Applicability to a Mobile Operator Network . . . . . 13 Devarapalli & Eronen Best Current Practice [Page 1] RFC 5266 MIPv4 and MOBIKE interworking June 2008 1. Introduction A typical enterprise network consists of users connecting to the services from a trusted network (intranet), and from an untrusted network (Internet). The trusted and untrusted networks are typically separated by a demilitarized zone (DMZ). Access to the intranet is controlled by a firewall and a Virtual Private Network (VPN) gateway in the DMZ. Enterprise users, when roaming on untrusted networks, most often have to authenticate themselves to the VPN gateway and set up a secure tunnel in order to access the intranet. The use of IPsec VPNs is very common to enable such secure connectivity to the intranet. When the user is on the trusted network, VPNs are not used. However, the users benefit tremendously when session mobility between subnets, through the use of Mobile IPv4, is available. There has been some work done on using Mobile IPv4 and IPsec VPNs to provide roaming and secure connectivity to an enterprise [RFC5265] [RFC4093]. The solution described in [RFC5265] was designed with certain restrictions, including requiring no modifications to the VPN gateways, and involves the use of two layers of MIPv4, with one home agent inside the intranet and one in the Internet or in the DMZ before the VPN gateway. The per-packet overhead is very high in this solution. It is also challenging to implement and have two instances of MIPv4 active at the same time on a mobile node. However, the solution described here is only applicable when Internet Key Exchange Protocol version 2 (IKEv2) IPsec VPNs are used. This document describes an alternate solution that does not require two layers of MIPv4. The solution described in this document uses Mobile IPv4 when the mobile node is on the trusted network and MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted network. The mobile node uses the tunnel inner address (TIA) given out by the IPsec VPN gateway as the co-located care-of address (CoA) for MIPv4 registration. This eliminates the need for using an external MIPv4 home agent and the need for encapsulating the VPN tunnel inside a MIPv4 tunnel.Show full document text