draft-ietf-mip4-mobike-connectivity-03.txt   rfc5266.txt 
MIP4 Working Group V. Devarapalli Network Working Group V. Devarapalli
Internet-Draft Azaire Networks Request for Comments: 5266 Wichorus
Intended status: Best Current P. Eronen BCP: 136 P. Eronen
Practice Nokia Category: Best Current Practice Nokia
Expires: September 3, 2007 March 2, 2007 Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE)
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE
draft-ietf-mip4-mobike-connectivity-03.txt
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 September 3, 2007.
Copyright Notice Status of This Memo
Copyright (C) The IETF Trust (2007). 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 Abstract
Enterprise users require mobility and secure connectivity when they Enterprise users require mobility and secure connectivity when they
roam and connect to the services offered in the enterprise. Secure roam and connect to the services offered in the enterprise. Secure
connectivity is required when the user connects to the enterprise connectivity is required when the user connects to the enterprise
from an untrusted network. Mobility is beneficial when the user from an untrusted network. Mobility is beneficial when the user
moves, either inside or outside the enterprise network, and acquires moves, either inside or outside the enterprise network, and acquires
a new IP address. This document describes a solution using Mobile a new IP address. This document describes a solution using Mobile
IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide
connectivity and mobility. secure connectivity and mobility.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access mode: 'h' . . . . . . . . . . . . . . . . . . . 7 3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 7 3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 7 3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.1.4. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.2. Mobility within the enterprise . . . . . . . . . . . . . . 8 3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.3. Mobility when outside the enterprise . . . . . . . . . . . 8 3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 8 3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.1. Operation when moving from an untrusted network . . . 9 3.4.2. Operation When Moving from a Trusted Network . . . . . 9
3.4.2. Operation when moving from a trusted network . . . . . 10
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Applicability to a Mobile Operator Network . . . . . 13 Appendix A. Applicability to a Mobile Operator Network . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
A typical enterprise network consists of users connecting to the A typical enterprise network consists of users connecting to the
services from a trusted network (intranet), and from an untrusted services from a trusted network (intranet), and from an untrusted
network (Internet). The trusted and untrusted networks are typically network (Internet). The trusted and untrusted networks are typically
separated by a demilitarized zone (DMZ). Access to the intranet is separated by a demilitarized zone (DMZ). Access to the intranet is
controlled by a firewall and a VPN gateway in the DMZ. controlled by a firewall and a Virtual Private Network (VPN) gateway
in the DMZ.
Enterprise users, when roaming on untrusted networks, most often have Enterprise users, when roaming on untrusted networks, most often have
to authenticate themselves to the VPN gateway and set up a secure 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 tunnel in order to access the intranet. The use of IPsec VPNs is
very common to enable such secure connectivity to the intranet. When very common to enable such secure connectivity to the intranet. When
the user is on the trusted network, VPNs are not used. However, the the user is on the trusted network, VPNs are not used. However, the
users benefit tremendously when session mobility between subnets, users benefit tremendously when session mobility between subnets,
through the use of Mobile IPv4, is available. through the use of Mobile IPv4, is available.
There has been some work done on using Mobile IPv4 and IPsec VPNs to There has been some work done on using Mobile IPv4 and IPsec VPNs to
provide roaming and secure connectivity to an enterprise [6] [7]. provide roaming and secure connectivity to an enterprise [RFC5265]
The solution described in [6] was designed with certain restrictions, [RFC4093]. The solution described in [RFC5265] was designed with
including requiring no modifications to the VPN gateways and involves certain restrictions, including requiring no modifications to the VPN
the use of two layers of MIPv4, with one home agent inside the gateways, and involves the use of two layers of MIPv4, with one home
intranet and one in the Internet or in the DMZ before the VPN agent inside the intranet and one in the Internet or in the DMZ
gateway. The per-packet overhead is very high in this solution. It before the VPN gateway. The per-packet overhead is very high in this
is also challenging to implement and have two instances of MIPv4 solution. It is also challenging to implement and have two instances
active at the same time on a mobile node. However, the solution of MIPv4 active at the same time on a mobile node. However, the
described here is only applicable when IKEv2 IPsec VPNs are used. 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 This document describes an alternate solution that does not require
two layers of MIPv4. The solution described in this document uses two layers of MIPv4. The solution described in this document uses
Mobile IPv4 when the mobile node is on the trusted network and MOBIKE Mobile IPv4 when the mobile node is on the trusted network and
capable IPsec VPNs when mobile node is on the untrusted network. The MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted
mobile node uses the tunnel inner address (TIA) given out by the network. The mobile node uses the tunnel inner address (TIA) given
IPsec VPN gateway as the co-located CoA for MIPv4 registration. This out by the IPsec VPN gateway as the co-located care-of address (CoA)
eliminates the need for using an external MIPv4 home agent and the for MIPv4 registration. This eliminates the need for using an
need for encapsulating the VPN tunnel inside a MIPv4 tunnel. external MIPv4 home agent and the need for encapsulating the VPN
tunnel inside a MIPv4 tunnel.
The following assumptions are made for the solution described in this The following assumptions are made for the solution described in this
document. document.
o IKEv2 [4] and IPsec [5] are used to set up the VPN tunnels between o IKEv2 [RFC4306] and IPsec [RFC4301] are used to set up the VPN
the mobile node and the VPN gateway. tunnels between the mobile node and the VPN gateway.
o The VPN gateway and the mobile node support MOBIKE extensions as o The VPN gateway and the mobile node support MOBIKE extensions as
defined in [3]. defined in [RFC4555].
o When the mobile node is on the trusted network, traffic should not o When the mobile node is on the trusted network, traffic should not
go through the DMZ. Current deployments of firewalls and DMZs go through the DMZ. Current deployments of firewalls and DMZs
consider the scenario where only a small amount of the total consider the scenario where only a small amount of the total
enterprise traffic goes through the DMZ. Routing through the DMZ enterprise traffic goes through the DMZ. Routing through the DMZ
typically involves stateful inspection of each packet by the typically involves stateful inspection of each packet by the
firewalls in the DMZ. Moreover, the DMZ architecture assumes that firewalls in the DMZ. Moreover, the DMZ architecture assumes that
the DMZ is less secure than the internal network. Therefore the the DMZ is less secure than the internal network. Therefore, the
DMZ based architecture allows the least amount of traffic to DMZ-based architecture allows the least amount of traffic to
traverse the DMZ, that is, only traffic between the trusted traverse the DMZ, that is, only traffic between the trusted
network and the external network. Requiring all normal traffic to network and the external network. Requiring all normal traffic to
the mobile nodes to traverse the DMZ would negate this the mobile nodes to traverse the DMZ would negate this
architecture. architecture.
o When the mobile node is on the trusted network and uses a wireless o When the mobile node is on the trusted network and uses a wireless
access technology, confidentiality protection of the data traffic access technology, confidentiality protection of the data traffic
is provided by the particular access technology. In some is provided by the particular access technology. In some
networks, confidentiality protection MAY be available between the networks, confidentiality protection MAY be available between the
mobile node and the first hop access router, in which case it is mobile node and the first hop access router, in which case it is
not required at layer 2. not required at layer 2.
This document also presents a solution for the mobile node to detect This document also presents a solution for the mobile node to detect
when it is on a trusted network, so that the IPsec tunnel can be when it is on a trusted network, so that the IPsec tunnel can be
dropped and the mobile node can use Mobile IP in the intranet. dropped and the mobile node can use Mobile IP in the intranet.
skipping to change at page 4, line 22 skipping to change at page 3, line 29
access technology, confidentiality protection of the data traffic access technology, confidentiality protection of the data traffic
is provided by the particular access technology. In some is provided by the particular access technology. In some
networks, confidentiality protection MAY be available between the networks, confidentiality protection MAY be available between the
mobile node and the first hop access router, in which case it is mobile node and the first hop access router, in which case it is
not required at layer 2. not required at layer 2.
This document also presents a solution for the mobile node to detect This document also presents a solution for the mobile node to detect
when it is on a trusted network, so that the IPsec tunnel can be when it is on a trusted network, so that the IPsec tunnel can be
dropped and the mobile node can use Mobile IP in the intranet. dropped and the mobile node can use Mobile IP in the intranet.
IPsec VPN gateways that use IKEv1 [13] are not addressed in this IPsec VPN gateways that use IKEv1 [RFC2409] are not addressed in this
document. document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [RFC2119].
Many of the following terms are defined in [6], but are repeated here Many of the following terms are defined in [RFC5265], but are
to make this document self-contained. repeated here to make this document self-contained.
FA: Mobile IPv4 foreign agent FA: Mobile IPv4 foreign agent.
CCoA: co-located Care-of address Co-CoA: co-located care-of address.
FA-CoA: Foreign Agent Care-of address FA-CoA: foreign agent care-of address.
FW: Firewall FW: firewall.
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet) i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet)
network network.
i-HA: Mobile IPv4 home agent residing in the trusted (intranet) i-HA: Mobile IPv4 home agent residing in the trusted (intranet)
network network.
i-MIP: The mobile node uses the home agent in the internal network
VPN TIA: VPN tunnel inner address. This address is given out by the i-MIP: The mobile node uses the home agent in the internal network.
VPN-TIA: VPN tunnel inner address. This address is given out by the
VPN gateway during IKE negotiation and is routable in the trusted VPN gateway during IKE negotiation and is routable in the trusted
network network.
mVPN: VPN with MOBIKE functionality mVPN: VPN with MOBIKE functionality.
The following access modes are used in explaining the protocol. The The following access modes are used in explaining the protocol. The
access modes are explained in more detail in [6]. access modes are explained in more detail in [RFC5265].
f: i-MIP with FA-CoA f: i-MIP with FA-CoA
c: i-MIP with CCoA
mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA c: i-MIP with Co-CoA
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
3. Solution Overview 3. Solution Overview
The mobile node is configured with a home address that remains the The mobile node is configured with a home address that remains the
same irrespective of whether the mobile node is inside or outside the same irrespective of whether the mobile node is inside or outside the
enterprise network. The mobile node is also reachable at the same enterprise network. The mobile node is also reachable at the same
home address irrespective of its current point of attachment. When home address irrespective of its current point of attachment. When
the mobile node is connected to the intranet directly, it uses Mobile the mobile node is connected to the intranet directly, it uses Mobile
IP for internal mobility. IP for internal mobility.
When the mobile node roams and connects to an untrusted network When the mobile node roams and connects to an untrusted network
outside the enterprise, it sets up a VPN tunnel to the VPN gateway. outside the enterprise, it sets up a VPN tunnel to the VPN gateway.
However, it still maintains a valid binding cache entry at the i-HA. However, it still maintains a valid binding cache entry at the i-HA.
It uses the VPN TIA, allocated by the VPN gateway, as the co-located It uses the VPN-TIA, allocated by the VPN gateway, as the co-located
CoA for registration with the i-HA. If the VPN TIA changes or if the CoA for registration with the i-HA. If the VPN-TIA changes or if the
mobile node moves and connects to another VPN gateway, then it sends mobile node moves and connects to another VPN gateway, then it sends
a Registration Request to the i-HA using the new co-located CoA. a Registration Request to the i-HA using the new co-located CoA.
If the mobile node moves while outside the enterprise and its access If the mobile node moves while outside the enterprise and its access
network changes, it uses the MOBIKE protocol to update the VPN network changes, it uses the MOBIKE protocol to update the VPN
gateway of its current address. The internal home agent is not aware gateway of its current address. The internal home agent is not aware
of the mobile node's movement as long as the mobile node is attached of the mobile node's movement as long as the mobile node is attached
to the same VPN gateway and the TIA remains the same. to the same VPN gateway and the TIA remains the same.
Figure 1 depicts the network topology assumed for the solution. It Figure 1 depicts the network topology assumed for the solution. It
also shows the possible mobile node locations and access modes. also shows the possible mobile node locations and access modes.
{h} (MN) [i-HA] {home} (MN) [i-HA]
\ / \ /
.-+---+-. .-+---+-.
( ) ( )
[mVPN] `--+----' [mVPN] `--+----'
! ! ! !
.--+--. [R] .--+--. [R]
( DMZ ) ! ( DMZ ) !
.-+-------+--. `--+--' .-----+------. .-+-------+--. `--+--' .-----+------.
( ) ! ( ) ( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net ) ( external net +---[R]----[FW]----[R]--+ internal net )
skipping to change at page 6, line 27 skipping to change at page 5, line 27
`--+---------' `---+---+----' `--+---------' `---+---+----'
/ / \ / / \
[DHCP] [R] [DHCP] [R] [R] [i-FA] [DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ / \ / \ / \ /
.+--+---. .-+-+--. .--+--+-. .+--+---. .-+-+--. .--+--+-.
( ) ( ) ( ) ( ) ( ) ( )
`---+---' `--+---' `---+---' `---+---' `--+---' `---+---'
! ! ! ! ! !
(MN) {mc} (MN) {c} (MN) {f} (MN) {mc} (MN) {c} (MN) {f}
Figure 1: Network Topology using MIPv4 and MOBIKE Figure 1: Network Topology Using MIPv4 and MOBIKE
The solution described above results in a Mobile IP tunnel inside an The solution described above results in a Mobile IP tunnel inside an
IPsec tunnel. The Mobile IP tunnel is between the mobile node and IPsec tunnel. The Mobile IP tunnel is between the mobile node and
the home agent and the IPsec tunnel is between the MN and the mVPN the home agent, and the IPsec tunnel is between the mobile node (MN)
gateway. The mobile node MUST reverse tunnel through the home agent and the mVPN gateway. The mobile node MUST reverse tunnel through
[8] when the Mobile IP tunnel is inside an IPsec tunnel. the home agent [RFC3024] when the Mobile IP tunnel is inside an IPsec
tunnel.
The overhead of running a Mobile IP tunnel inside an IPsec tunnel can The overhead of running a Mobile IP tunnel inside an IPsec tunnel can
be avoided by having the Mobile IP foreign agent functionality on the be avoided by having the Mobile IP foreign agent functionality on the
VPN gateway. This is out of scope for this document and is further VPN gateway. This is out of scope for this document and is further
described in [9]. described in [MEGHANA].
Whenever the mobile node attaches to a new link, it may encounter a Whenever the mobile node attaches to a new link, it may encounter a
foreign agent. The mobile node MUST not use the foreign agent foreign agent. The mobile node MUST not use the foreign agent
care-of address with the i-HA when attached to an untrusted access care-of address with the i-HA when attached to an untrusted access
network. The default behavior for the mobile node is to always network. The default behavior for the mobile node is to always
configure an address from the access link using DHCP. The mobile configure an address from the access link using DHCP. The mobile
node then checks if it is attached to a trusted access network by node then checks if it is attached to a trusted access network by
sending a registration request to the i-HA in the co-located care-of sending a Registration Request to the i-HA in the co-located care-of
address mode. If the mobile node discovers that it is attached to a address mode. If the mobile node discovers that it is attached to a
trusted access network, then it MAY start using foreign agent care-of trusted access network, then it MAY start using a foreign agent
address with the i-HA. In order to do this, the mobile node has to care-of address with the i-HA. In order to do this, the mobile node
perform a new registration with the i-HA. has to perform a new registration with the i-HA.
The mobile node can use a foreign agent on a untrusted access The mobile node can use a foreign agent on a untrusted access
network, if there is an external home agent that the mobile node is network, if there is an external home agent that the mobile node is
able to use. The use of an external home agent in the untrusted able to use. The use of an external home agent in the untrusted
access network and a home agent in the trusted access network at the access network and a home agent in the trusted access network at the
same time is described in detail in [6]. same time is described in detail in [RFC5265].
Some IPsec VPN implementations allow a host to send traffic directly Some IPsec VPN implementations allow a host to send traffic directly
to the Internet when attached to an untrusted network. This traffic to the Internet when attached to an untrusted network. This traffic
bypasses the IPsec tunnel with the VPN gateway. This document does bypasses the IPsec tunnel with the VPN gateway. This document does
not prevent such traffic from being sent out from the host, but there not prevent such traffic from being sent out from the host, but there
will be no mobility or session continuity for the traffic. Any data will be no mobility or session continuity for the traffic. Any data
traffic that is sent through the Mobile IP tunnel with the home agent traffic that is sent through the Mobile IP tunnel with the home agent
is always sent through the VPN gateway. is always sent through the VPN gateway.
3.1. Access modes 3.1. Access Modes
The following access modes are used in the solution described in this The following access modes are used in the solution described in this
document. document.
3.1.1. Access mode: 'h' 3.1.1. Access Mode: 'c'
This access mode is standard Mobile IPv4 [2] when the mobile node is
attached to its home link. The mobile node must detect that it is
connected to home link before using this mode.
3.1.2. Access mode: 'c'
This access mode is standard Mobile IPv4 [2] with a co-located This access mode is standard Mobile IPv4 [RFC3344] with a co-located
care-of address. The mobile node must detect that it is connected to care-of address. The mobile node must detect that it is connected to
an internal trusted network before using this mode. The co-located an internal trusted network before using this mode. The co-located
care-of address is assigned by the access network to which the mobile care-of address is assigned by the access network to which the mobile
node is attached to. node is attached.
3.1.3. Access mode: 'f' 3.1.2. Access Mode: 'f'
This access mode is standard Mobile IPv4 [2] with a foreign agent This access mode is standard Mobile IPv4 [RFC3344] with a foreign
care-of address. The mobile node can use this mode only when it agent care-of address. The mobile node can use this mode only when
detects that it is connected to an internal trusted network and also it detects that it is connected to an internal trusted network and
detects a foreign agent on the access network. also detects a foreign agent on the access network.
3.1.4. Access mode: 'mc' 3.1.3. Access Mode: 'mc'
This access mode involves using both Mobile IPv4 and a MOBIKE enabled This access mode involves using both Mobile IPv4 and a MOBIKE-enabled
IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec
tunnel. The mobile node uses the VPN TIA as the co-located CoA for tunnel. The mobile node uses the VPN-TIA as the co-located CoA for
registering with the home agent. This mode is used only when the registering with the home agent. This mode is used only when the
mobile node is attached to an untrusted network and is required to mobile node is attached to an untrusted network and is required to
set up an IPsec tunnel with a VPN gateway to gain access to the set up an IPsec tunnel with a VPN gateway to gain access to the
trusted network. trusted network.
3.2. Mobility within the enterprise 3.2. Mobility within the Enterprise
When the mobile node is inside the enterprise network and attached to When the mobile node is inside the enterprise network and attached to
the intranet, it uses Mobile IPv4 [2] for subnet mobility. The the intranet, it uses Mobile IPv4 [RFC3344] for subnet mobility. The
mobile node always configures a care-of address address through DHCP mobile node always configures a care-of address through DHCP on the
on the access link and uses it as the co-located care-of address. access link and uses it as the co-located care-of address. The
The mobile node MAY use a foreign agent care-of address, if a foreign mobile node MAY use a foreign agent care-of address, if a foreign
agent is available. However, the foreign agent care-of address is agent is available. However, the foreign agent care-of address is
used only when the mobile node is attached to the trusted access used only when the mobile node is attached to the trusted access
network. The mobile node attempts Foreign Agent discovery and CoA network. The mobile node attempts Foreign Agent discovery and CoA
address acquisition through DHCP simultaneously in order to avoid the address acquisition through DHCP simultaneously in order to avoid the
delay in discovering a foreign agent when there is no foreign agent delay in discovering a foreign agent when there is no foreign agent
available. The mobile node maintains a valid binding cache entry at available. The mobile node maintains a valid binding cache entry at
all times at the home agent mapping the the home address to the all times at the home agent mapping the home address to the current
current CoA. Whenever the mobile node moves, it sends a Registration CoA. Whenever the mobile node moves, it sends a Registration Request
Request to update the binding cache entry. to update the binding cache entry.
The Mobile IP signaling messages between the mobile node and the home The Mobile IP signaling messages between the mobile node and the home
agent are authenticated as described in [2]. agent are authenticated as described in [RFC3344].
The mobile node maintains a valid binding cache entry at the home The mobile node maintains a valid binding cache entry at the home
agent even when it is outside the enterprise network. agent even when it is outside the enterprise network.
3.3. Mobility when outside the enterprise 3.3. Mobility When outside the Enterprise
When the mobile node is attached to an untrusted network, it sets up When the mobile node is attached to an untrusted network, it sets up
an IPsec VPN tunnel with the VPN gateway to gain access to the an IPsec VPN tunnel with the VPN gateway to gain access to the
enterprise network. If the mobile node moves and its IP address enterprise network. If the mobile node moves and its IP address
changes, it initiates the MOBIKE protocol [3] to update the address changes, it initiates the MOBIKE protocol [RFC4555] to update the
on the VPN gateway. address on the VPN gateway.
The mobile node maintains a binding at the home agent even when it is The mobile node maintains a binding at the home agent even when it is
outside the enterprise network. If the TIA changes due to the mobile outside the enterprise network. If the TIA changes due to the mobile
node re-connecting to the VPN gateway or attaching to a different VPN node re-connecting to the VPN gateway or attaching to a different VPN
gateway, the mobile node should send a Registration Request to its gateway, the mobile node should send a Registration Request to its
home agent to update the binding cache with the new TIA. home agent to update the binding cache with the new TIA.
3.4. Crossing Security Boundaries 3.4. Crossing Security Boundaries
Security boundary detection is based on the reachability of the i-HA Security boundary detection is based on the reachability of the i-HA
from the mobile node's current point of attachment. Whenever the from the mobile node's current point of attachment. Whenever the
mobile node detects a change in network connectivity, it sends a mobile node detects a change in network connectivity, it sends a
Registration Request to the i-HA without any VPN encapsulation. If Registration Request to the i-HA without any VPN encapsulation. If
the mobile node receives a Registration Reply, then it assumes that the mobile node receives a Registration Reply with the Trusted
it is on a trusted network. The mobile node MUST check that the Networks Configured (TNC) extension from the i-HA, then it assumes
Registration Reply is integrity protected using the mobile node-home that it is on a trusted network. The TNC extension is described in
agent mobility security association before concluding it is attached [RFC5265]. The mobile node MUST check that the Registration Reply is
to a trusted network. This security boundary detection is based on integrity protected using the mobile node-home agent mobility
the mechanism described in [6] to detect attachment to the internal security association before concluding it is attached to a trusted
trusted network. The mobile node should re-transmit the Registration network. This security boundary detection is based on the mechanism
Request if it does not receive the Registration Reply within a described in [RFC5265] to detect attachment to the internal trusted
timeout period. The number of times the mobile node should re- network. The mobile node should re-transmit the Registration Request
transmit the Registration Request and the timeout period for if it does not receive the Registration Reply within a timeout
receiving the Registration Reply are configurable on the mobile node. period. The number of times the mobile node should re-transmit the
Registration Request and the timeout period for receiving the
Registration Reply are configurable on the mobile node.
When the mobile node is attached to an untrusted network and is using When the mobile node is attached to an untrusted network and is using
an IPsec VPN to the enterprise network, the ability to send a an IPsec VPN to the enterprise network, the ability to send a
Registration Request to the i-HA without VPN encapsulation would Registration Request to the i-HA without VPN encapsulation would
require some interaction between the IPsec and MIPv4 modules on the require some interaction between the IPsec and MIPv4 modules on the
mobile node. This is local to the mobile node and out of scope for mobile node. This is local to the mobile node and out of scope for
this document. this document.
If the mobile node has an existing VPN tunnel to its VPN gateway, it If the mobile node has an existing VPN tunnel to its VPN gateway, it
MUST send a MOBIKE message at the same time as the registration MUST send a MOBIKE message at the same time as the registration
request to the i-HA whenever the IP address changes. If the mobile request to the i-HA whenever the IP address changes. If the mobile
node receives a response from the VPN gateway, but not from the i-HA, node receives a response from the VPN gateway, but not from the i-HA,
it assumes it is outside the enterprise network. If it receives a it assumes it is outside the enterprise network. If it receives a
response from the i-HA, then it assumes it is inside the enterprise response from the i-HA, then it assumes it is inside the enterprise
network. network.
There could also be some out-of-band mechanisms that involve There could also be some out-of-band mechanisms that involve
configuring the wireless access points with some information which configuring the wireless access points with some information that the
the mobile node can recognize as access points that belong to the mobile node can recognize as access points that belong to the trusted
trusted network in an enterprise network. Such mechanisms are beyond network in an enterprise network. Such mechanisms are beyond the
the scope of this document. scope of this document.
The mobile node should not send any normal traffic while it is trying The mobile node should not send any normal traffic while it is trying
to detect whether it is attached to the trusted or untrusted network. to detect whether it is attached to the trusted or untrusted network.
This is described in more detail in [6]. This is described in more detail in [RFC5265].
3.4.1. Operation when moving from an untrusted network 3.4.1. Operation When Moving from an Untrusted Network
When the mobile node is outside the enterprise network and attached When the mobile node is outside the enterprise network and attached
to an untrusted network, it has an IPsec VPN tunnel with its mobility to an untrusted network, it has an IPsec VPN tunnel with its mobility
aware VPN gateway, and a valid registration with a home agent on the aware VPN gateway, and a valid registration with a home agent on the
intranet with the VPN TIA as the care-of address. intranet with the VPN-TIA as the care-of address.
If the mobile nodes moves and its IP address changes, it performs the If the mobile node moves and its IP address changes, it performs the
following steps: following steps:
1a. Initiate an IKE mobility exchange to update the VPN gateway with 1a. Initiate an IKE mobility exchange to update the VPN gateway with
the current address. If the new network is also untrusted, this the current address. If the new network is also untrusted, this
will be enough for setting up the connectivity. If the new will be enough for setting up the connectivity. If the new
network is trusted, and if the VPN gateway is reachable, this network is trusted, and if the VPN gateway is reachable, this
exchange will allow the mobile node to keep the VPN state alive exchange will allow the mobile node to keep the VPN state alive
while on the trusted side. If the VPN gateway is not reachable while on the trusted side. If the VPN gateway is not reachable
from inside, then this exchange will fail. from inside, then this exchange will fail.
1b. At the same time as step 1, send a Mobile IPv4 Registration 1b. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal home agent without VPN encapsulation. Request to the internal home agent without VPN encapsulation.
2. If the mobile node receives a Registration Reply to the request 2. If the mobile node receives a Registration Reply to the request
sent in step 1b, then the current subnet is a trusted subnet, and sent in step 1b, then the current subnet is a trusted subnet,
the mobile node can communicate without VPN tunneling. The mobile and the mobile node can communicate without VPN tunneling. The
node MAY tear down the VPN tunnel. mobile node MAY tear down the VPN tunnel.
3.4.2. Operation when moving from a trusted network 3.4.2. Operation When Moving from a Trusted Network
When the mobile node is inside the enterprise and attached to the When the mobile node is inside the enterprise and attached to the
intranet, it does not use a VPN tunnel for data traffic. It has a intranet, it does not use a VPN tunnel for data traffic. It has a
valid binding cache entry at its home agent. If the VPN gateway is valid binding cache entry at its home agent. If the VPN gateway is
reachable from the trusted network, the mobile node MAY have valid reachable from the trusted network, the mobile node MAY have valid
IKEv2 security associations with its VPN gateway. The IPsec security IKEv2 security associations with its VPN gateway. The IPsec security
associations can be created when required. The mobile node may have associations can be created when required. The mobile node may have
to re-negotiate the IKEv2 security associations to prevent them from to re-negotiate the IKEv2 security associations to prevent them from
expiring. expiring.
skipping to change at page 10, line 50 skipping to change at page 10, line 9
4. If the mobile node didn't receive the response in step 3, and if 4. If the mobile node didn't receive the response in step 3, and if
the VPN tunnel is successfully established and registered in step the VPN tunnel is successfully established and registered in step
1, then the mobile node sends a Registration Request over the VPN 1, then the mobile node sends a Registration Request over the VPN
tunnel to the internal home agent. After receiving a tunnel to the internal home agent. After receiving a
Registration Reply from the home agent, the mobile node can start Registration Reply from the home agent, the mobile node can start
communicating over the VPN tunnel with the Mobile IP home communicating over the VPN tunnel with the Mobile IP home
address. address.
4. NAT Traversal 4. NAT Traversal
There could be a NAT device between the mobile node and the home There could be a Network Address Translation (NAT) device between the
agent in any of the access modes, 'c', 'f' and 'mc', and between the mobile node and the home agent in any of the access modes, 'c', 'f',
mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 and 'mc', and between the mobile node and the VPN gateway in the
NAT traversal, as described in [10] should be used by the mobile node access mode 'mc'. Mobile IPv4 NAT traversal, as described in
and the home agent in access modes 'c' or 'f', when there is a NAT [RFC3519], should be used by the mobile node and the home agent in
device present. When using access mode, 'mc', IPsec NAT traversal access modes 'c' or 'f', when there is a NAT device present. When
[11] [12] should be used by the mobile node and the VPN gateway, if using access mode, 'mc', IPsec NAT traversal [RFC3947] [RFC3948]
there is a NAT device present. Typically, the TIA would be a should be used by the mobile node and the VPN gateway, if there is a
routable address inside the enterprise network. But in some cases, NAT device present. Typically, the TIA would be a routable address
the TIA could be from a private address space associated with the VPN inside the enterprise network. But in some cases, the TIA could be
gateway. In such a case, Mobile IPv4 NAT traversal should be used in from a private address space associated with the VPN gateway. In
addition to IPsec NAT traversal in the 'mc' mode. such a case, Mobile IPv4 NAT traversal should be used in addition to
IPsec NAT traversal in the 'mc' mode.
5. Security Considerations 5. Security Considerations
Enterprise connectivity typically requires very strong security, and Enterprise connectivity typically requires very strong security, and
the solution described in this document was designed keeping this in the solution described in this document was designed keeping this in
mind. mind.
Security concerns related to the mobile node detecting that it is on Security concerns related to the mobile node detecting that it is on
a trusted network and thereafter dropping the VPN tunnel are a trusted network and thereafter dropping the VPN tunnel are
described in [6]. described in [RFC5265].
When the mobile node sends a registration request to the i-HA from an When the mobile node sends a Registration Request to the i-HA from an
untrusted network that does not go through the IPsec tunnel, it will untrusted network that does not go through the IPsec tunnel, it will
reveal the i-HA's address, its own identity including the NAI and the reveal the i-HA's address, its own identity including the NAI and the
home address, and the Authenticator value in the authentication home address, and the Authenticator value in the authentication
extensions to the untrusted network. This may be a concern in some extensions to the untrusted network. This may be a concern in some
deployments. deployments.
Please see [3] for MOBIKE-related security considerations, and [10], Please see [RFC4555] for MOBIKE-related security considerations, and
[11] for security concerns related to the use of NAT traversal [RFC3519], [RFC3947] for security concerns related to the use of NAT
mechanisms for Mobile IPv4 and IPsec. traversal mechanisms for Mobile IPv4 and IPsec.
6. IANA Considerations
This document requires no action from IANA.
7. Acknowledgments 6. Acknowledgments
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval
Shah and John Cruz for their participation in developing this Shah, and John Cruz for their participation in developing this
solution. solution.
The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ
Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni
Korhonen and Sami Vaarala for reviewing the document. Korhonen, and Sami Vaarala for reviewing the document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[5] Kent, S. and K. Seo, "Security Architecture for the Internet [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-based VPN Gateways", IPsec-Based VPN Gateways", RFC 5265, June 2008.
draft-ietf-mip4-vpn-problem-solution-02 (work in progress),
November 2005.
8.2. Informative References 7.2. Informative References
[7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 [RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile
Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, IPv4 Traversal of Virtual Private Network (VPN) Gateways",
August 2005. RFC 4093, August 2005.
[8] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
RFC 3024, January 2001. revised", RFC 3024, January 2001.
[9] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure [MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to
Connectivity and Mobility", Secure Connectivity and Mobility", Work in Progress,
draft-meghana-mip4-mobike-optimizations-01 (work in progress), February 2008.
October 2006.
[10] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Address Translation (NAT) Devices", RFC 3519, May 2003. Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[11] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[12] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, Stenberg, "UDP Encapsulation of IPsec ESP Packets",
January 2005. RFC 3948, January 2005.
[13] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
Appendix A. Applicability to a Mobile Operator Network Appendix A. Applicability to a Mobile Operator Network
The solution described in this document can also be applied to a The solution described in this document can also be applied to a
Mobile Operator's network when the Operator deploys heterogeneous Mobile Operator's network when the Operator deploys heterogeneous
access networks and some of the access networks are considered as access networks and some of the access networks are considered as
trusted networks and others as untrusted networks. Figure 2 trusted networks and others as untrusted networks. Figure 2
illustrates such a network topology. illustrates such a network topology.
+----------------------+ +----------------------+
skipping to change at page 13, line 39 skipping to change at page 13, line 32
| |
| |
| |
[mVPN] [mVPN]
+----------------+ | +----------------+ |
| | | | | |
(MN)----+ untrusted +--------------+ (MN)----+ untrusted +--------------+
{mc} | access network | {mc} | access network |
+----------------+ +----------------+
Figure 2: Network Topology of a Mobile Operator with trusted and Figure 2: Network Topology of a Mobile Operator with Trusted and
untrusted networks Untrusted Networks
An IPsec VPN gateway provides secure connectivity to the Operator's An IPsec VPN gateway provides secure connectivity to the Operator's
internal network for mobile nodes attached to an untrusted access internal network for mobile nodes attached to an untrusted access
network. The VPN gateway supports MOBIKE extensions so that the network. The VPN gateway supports MOBIKE extensions so that the
IPsec tunnels survive any IP address change when the mobile node IPsec tunnels survive any IP address change when the mobile node
moves while attached to the untrusted access networks. moves while attached to the untrusted access networks.
When the mobile node is attached to the trusted access network it When the mobile node is attached to the trusted access network, it
uses Mobile IP with the i-HA. It uses the IP address obtained from uses Mobile IP with the i-HA. It uses the IP address obtained from
the trusted access network as the co-located care-of address to the trusted access network as the co-located care-of address to
register with the i-HA. If a foreign agent is available in the register with the i-HA. If a foreign agent is available in the
trusted access network, the mobile node may use foreign agent care-of trusted access network, the mobile node may use a foreign agent
address. If the mobile node moves and attaches to an untrusted care-of address. If the mobile node moves and attaches to an
access network, it sets up an IPsec tunnel with the VPN gateway to untrusted access network, it sets up an IPsec tunnel with the VPN
access the Operator's internal network. It uses the IPsec TIA as the gateway to access the Operator's internal network. It uses the IPsec
co-located care-of address to register with the i-HA thereby creating TIA as the co-located care-of address to register with the i-HA
a Mobile IP tunnel inside an IPsec tunnel. thereby creating a Mobile IP tunnel inside an IPsec tunnel.
When the mobile node is attached to the trusted access network, it When the mobile node is attached to the trusted access network, it
can either by attached to a foreign link in the trusted network or to can either be attached to a foreign link in the trusted network or to
the home link directly. This document does not impose any the home link directly. This document does not impose any
restrictions. restrictions.
Authors' Addresses Authors' Addresses
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Wichorus
3121 Jay Street 3590 North First Street
Santa Clara, CA 95054 San Jose, CA 95134
USA USA
Email: vijay.devarapalli@azairenet.com EMail: vijay@wichorus.com
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com EMail: pasi.eronen@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 15, line 44 skipping to change at line 634
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 93 change blocks. 
234 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/