draft-ietf-mip4-mobike-connectivity-00.txt   draft-ietf-mip4-mobike-connectivity-01.txt 
MIP4 Working Group V. Devarapalli MIP4 Working Group V. Devarapalli
Internet-Draft P. Eronen Internet-Draft Azaire Networks
Expires: July 26, 2006 Nokia Expires: December 15, 2006 P. Eronen
January 22, 2006 Nokia
June 13, 2006
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE
draft-ietf-mip4-mobike-connectivity-00 draft-ietf-mip4-mobike-connectivity-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2006. This Internet-Draft will expire on December 15, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 2, line 12 skipping to change at page 2, line 13
IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure
connectivity and mobility. connectivity and mobility.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6 3.1.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 6 3.1.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 7
3.1.3. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 3.1.3. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7
3.2. Mobility within the enterprise . . . . . . . . . . . . . . 7 3.2. Mobility within the enterprise . . . . . . . . . . . . . . 7
3.3. Mobility when outside the enterprise . . . . . . . . . . . 7 3.3. Mobility when outside the enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 8 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 . . . 8
3.4.2. Operation when moving from a trusted network . . . . . 9 3.4.2. Operation when moving from a trusted network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9 4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Applicability to a Mobile Operator Network . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 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 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 [10]. The provide roaming and secure connectivity to an enterprise [6] [7].
solution described in [10] was designed with certain restrictions, The solution described in [6] was designed with certain restrictions,
including requiring no modifications to the VPN gateways and involves including requiring no modifications to the VPN gateways and involves
the use of two layers of MIPv4, with one home agent inside the 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 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 gateway. The per-packet overhead is very high in this solution. It
is also challenging to implement and have two instances of MIPv4 is also challenging to implement and have two instances of MIPv4
active at the same time on a mobile node. However, the solution active at the same time on a mobile node. However, the solution
described here is only applicable when IKEv2 IPsec VPNs are used. described here is only applicable when 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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
o IKEv2 [4] and IPsec [5] are used to set up the VPN tunnels between o IKEv2 [4] and IPsec [5] are used to set up the VPN tunnels between
the mobile node and the VPN gateway. 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 [3].
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. firewalls in the DMZ. Moreover, the DMZ architecture assumes that
the DMZ is less secure than the internal network. Therefore the
DMZ based architecture allows the least amount of traffic to
traverse the DMZ, that is, only traffic between the trusted
network and the external network. Requiring all normal traffic to
the mobile nodes to traverse the DMZ would negate this
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.
Mobility extensions for IKEv2 are being standardized. There is no Mobility extensions for IKEv2 are being standardized. There is no
similar effort for IKEv1 [6]. similar effort for IKEv1 [10].
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.
2. Terminology 2. Terminology
Many of the following terms are defined in [10], but are repeated The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
here to make this document self-contained. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Many of the following terms are defined in [6], but are repeated here
to make this document self-contained.
FA: Mobile IPv4 foreign agent FA: Mobile IPv4 foreign agent
CCoA: co-located Care-of address CCoA: 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)
skipping to change at page 4, line 37 skipping to change at page 5, line 4
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 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 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 [10]. access modes are explained in more detail in [6].
f: i-MIP with FA-CoA f: i-MIP with FA-CoA
c: i-MIP with CCoA c: i-MIP with CCoA
mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA
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 [1].
3. Solution Overview 3. Solution Overview
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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.
(MN) {mc} {home} (MN) [i-HA] (MN) {mc} {home} (MN) [i-HA]
! \ / ! \ /
.--+---. .-+---+-. .--+---. .-+---+-.
( ) ( ) ( ) ( )
`--+---' [MVPN] `--+----' `--+---' [mVPN] `--+----'
\ ! ! \ ! !
[R/FA] .--+--. [R] [R] .--+--. [R]
\ ( DMZ ) ! \ ( DMZ ) !
.-+-------+--. `--+--' .-----+------. .-+-------+--. `--+--' .-----+------.
( ) ! ( ) ( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net ) ( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( ) ( ) ( )
`--+---------' `---+---+----' `--+---------' `---+---+----'
/ / \ / / \
[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 Toplogy 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 MN and the mVPN
gateway. The Mobile IP tunnel uses reverse tunneling through the gateway. The Mobile IP tunnel uses reverse tunneling through the
home agent [12]. home agent [8].
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
VPN gateway. This is out of scope for this document and is further
described in [11].
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: 'c' 3.1.1. Access mode: 'c'
This access mode is standard Mobile IPv4 [2] with a co-located This access mode is standard Mobile IPv4 [2] 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
skipping to change at page 7, line 46 skipping to change at page 7, line 52
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 [3] to update the address
on the VPN gateway. 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 or the mobile outside the enterprise network. If the TIA changes due to the mobile
node attaches to another VPN gateway, the mobile node should send a node re-connecting to the VPN gateway or attaching to a different VPN
Registration Request to its home agent to update the binding cache gateway, the mobile node should send a Registration Request to its
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 that it has moved to a new IP subnet [13] and its mobile node detects that it has moved to a new IP subnet [9] and its
IP address changes, it sends a Registration Request to the i-HA IP address changes, it sends a Registration Request to the i-HA
without any VPN encapsulation. If the mobile node receives a without any VPN encapsulation. If the mobile node receives a
Registration Reply, then it is assumes that it is on a trusted Registration Reply, then it is assumes that it is on a trusted
network. This is based on the mechanism described in [10] to detect network. This is based on the mechanism described in [6] to detect
attachment to the internal trusted network. The mobile node should attachment to the internal trusted network. The mobile node should
re-transmit the Registration Request if it does not receive the re-transmit the Registration Request if it does not receive the
Registration Reply within a timeout period. The number of times the Registration Reply within a timeout period. The number of times the
mobile node should re-transmit the Registration Request and the mobile node should re-transmit the Registration Request and the
timeout period for receiving the Registration Reply are configurable timeout period for receiving the Registration Reply are configurable
on the mobile node. on the mobile node.
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
Registration Request to the i-HA without VPN encapsulation would
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
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 which
the mobile node can recognize as access points that belong to the the mobile node can recognize as access points that belong to the
trusted network in an enterprise network. Such mechanisms are beyond trusted network in an enterprise network. Such mechanisms are beyond
the scope of this document. the scope of this document.
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.
This is described in more detail in [6].
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 nodes moves and its IP address changes, it performs the
following steps: following steps:
skipping to change at page 10, line 5 skipping to change at page 10, line 18
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 NAT device between the mobile node and the home
agent in any of the access modes, 'c', 'f' and 'mc', and between the agent in any of the access modes, 'c', 'f' and 'mc', and between the
mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4 mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4
NAT traversal, as described in [7] should be used by the mobile node NAT traversal, as described in [12] should be used by the mobile node
and the home agent in access modes 'c' or 'f', when there is a NAT and the home agent in access modes 'c' or 'f', when there is a NAT
device present. When using access mode, 'mc', IPsec NAT traversal device present. When using access mode, 'mc', IPsec NAT traversal
[8] [9] should be used by the mobile node and the VPN gateway, if [13] [14] should be used by the mobile node and the VPN gateway, if
there is a NAT device present. Typically, the TIA would be a there is a NAT device present. Typically, the TIA would be a
routable address inside the enterprise network. But in some cases, routable address inside the enterprise network. But in some cases,
the TIA could be from a private address space associated with the VPN the TIA could be from a private address space associated with the VPN
gateway. In such a case, Mobile IPv4 NAT traversal should be used in gateway. In such a case, Mobile IPv4 NAT traversal should be used in
addition to IPsec NAT traversal in the 'mc' mode. 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 [10]. described in [6].
Please see [3] for MOBIKE-related security considerations, and [7], Please see [3] for MOBIKE-related security considerations, and [12],
[8] for security concerns related to the use of NAT traversal [13] for security concerns related to the use of NAT traversal
mechanisms for Mobile IPv4 and IPsec. mechanisms for Mobile IPv4 and IPsec.
6. IANA Considerations 6. IANA Considerations
This document requires no action from IANA. This document requires no action from IANA.
7. Acknowledgments 7. 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 and The authors would also like to thank Henrik Levkowetz, Jari Arkko and
TJ Kniveton for reviewing the document. TJ Kniveton for reviewing the document.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 11, line 9 skipping to change at page 11, line 22
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-07 (work in progress), RFC 4555, June 2006.
December 2005.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
RFC 4306, December 2005. December 2005.
[5] Kent, S. and K. Seo, "Security Architecture for the Internet [5] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 8.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] Montenegro, G., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[9] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network
Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[7] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network [11] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure
Connectivity and Mobility",
draft-meghana-mip4-mobike-optimizations-00 (work in progress),
March 2006.
[12] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
Address Translation (NAT) Devices", RFC 3519, May 2003. Address Translation (NAT) Devices", RFC 3519, May 2003.
[8] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [13] 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.
[9] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [14] 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", RFC 3948,
January 2005. January 2005.
[10] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across Appendix A. Applicability to a Mobile Operator Network
IPsec-based VPN Gateways",
draft-ietf-mip4-vpn-problem-solution-02 (work in progress),
November 2005.
8.2. Informative References The solution described in this document can also be applied to a
Mobile Operator's network when the Operator deploys heterogeneous
access networks and some of the access networks are considered as
trusted networks and others as untrusted networks. Figure 2
illustrates such a network topology.
[11] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 +----------------------+
Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, | +----+ |
August 2005. +----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
[12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", Figure 2: Network Topology of a Mobile Operator with trusted and
RFC 3024, January 2001. untrusted networks
[13] Aboba, B., "Detecting Network Attachment in IPv4 (DNAv4)", An IPsec VPN gateway provides secure connectivity to the Operator's
draft-ietf-dhc-dna-ipv4-18 (work in progress), December 2005. internal network for mobile nodes attached to an untrusted access
network. The VPN gateway supports MOBIKE extensions so that the
IPsec tunnels survive any IP address change when the mobile node
moves while attached to the untrusted access networks.
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
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
trusted access network, the mobile node may use foreign agent care-of
address. If the mobile node moves and attaches to an untrusted
access network, it sets up an IPsec tunnel with the VPN gateway to
access the Operator's internal network. It uses the IPsec TIA as the
co-located care-of address to register with the i-HA thereby creating
a Mobile IP tunnel inside an IPsec tunnel.
Authors' Addresses Authors' Addresses
Vijay Devarapalli Vijay Devarapalli
Nokia Research Center Azaire Networks
313 Fairchild Drive 4800 Great America Pkwy
Mountain View, CA 94043 Santa Clara, CA 95054
USA USA
Email: vijay.devarapalli@nokia.com Email: vijay.devarapalli@azairenet.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
Intellectual Property Statement Intellectual Property Statement
 End of changes. 40 change blocks. 
60 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/