draft-ietf-mip4-mobike-connectivity-01.txt   draft-ietf-mip4-mobike-connectivity-02.txt 
MIP4 Working Group V. Devarapalli MIP4 Working Group V. Devarapalli
Internet-Draft Azaire Networks Internet-Draft Azaire Networks
Expires: December 15, 2006 P. Eronen Intended status: Standards Track P. Eronen
Nokia Expires: July 7, 2007 Nokia
June 13, 2006 January 3, 2007
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE
draft-ietf-mip4-mobike-connectivity-01 draft-ietf-mip4-mobike-connectivity-02
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 35 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 December 15, 2006. This Internet-Draft will expire on July 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
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 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 . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6 3.1.1. Access mode: 'h' . . . . . . . . . . . . . . . . . . . 7
3.1.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 7 3.1.2. Access mode: 'c' . . . . . . . . . . . . . . . . . . . 7
3.1.3. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7 3.1.3. Access mode: 'f' . . . . . . . . . . . . . . . . . . . 7
3.2. Mobility within the enterprise . . . . . . . . . . . . . . 7 3.1.4. Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7
3.3. Mobility when outside the enterprise . . . . . . . . . . . 7 3.2. Mobility within the enterprise . . . . . . . . . . . . . . 8
3.3. Mobility when outside the enterprise . . . . . . . . . . . 8
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 . . . 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 . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Applicability to a Mobile Operator Network . . . . . 12 Appendix A. Applicability to a Mobile Operator Network . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 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.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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.
Mobility extensions for IKEv2 are being standardized. There is no
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.
IPsec VPN gateways that use IKEv1 [13] are not addressed in this
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 [1].
Many of the following terms are defined in [6], but are repeated here Many of the following terms are defined in [6], but are repeated here
to make this document self-contained. to make this document self-contained.
FA: Mobile IPv4 foreign agent FA: Mobile IPv4 foreign agent
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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.
(MN) {mc} {home} (MN) [i-HA] (MN) {mc} {h} (MN) [i-HA]
! \ / ! \ /
.--+---. .-+---+-. .--+---. .-+---+-.
( ) ( ) ( ) ( )
`--+---' [mVPN] `--+----' `--+---' [mVPN] `--+----'
\ ! ! \ ! !
[R] .--+--. [R] [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 32 skipping to change at page 6, line 32
( ) ( ) ( ) ( ) ( ) ( )
`---+---' `--+---' `---+---' `---+---' `--+---' `---+---'
! ! ! ! ! !
(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 MN and the mVPN
gateway. The Mobile IP tunnel uses reverse tunneling through the gateway. The mobile node MUST reverse tunnel through the home agent
home agent [8]. [8] 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 [11]. described in [9].
Whenever the mobile node attaches to a new link, it may encounter a
foreign agent. The mobile node MUST not use the foreign agent
care-of address with the i-HA when attached to an untrusted access
network. The default behavior for the mobile node is to always
configure an address from the access link using DHCP. The mobile
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
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
address with the i-HA. In order to do this, the mobile node has to
perform a new registration with the i-HA.
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
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
same time is described in detail in [6].
Some IPsec VPN implementations allow a host to send traffic directly
to the Internet when attached to an untrusted network. This traffic
bypasses the IPsec tunnel with the VPN gateway. This document does
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
traffic that is sent through the Mobile IP tunnel with the home agent
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: 'c' 3.1.1. Access mode: 'h'
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 [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
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 to.
3.1.2. Access mode: 'f' 3.1.3. Access mode: 'f'
This access mode is standard Mobile IPv4 [2] with a foreign agent This access mode is standard Mobile IPv4 [2] with a foreign agent
care-of address. The mobile node can use this mode only when it care-of address. The mobile node can use this mode only when it
detects that it is connected to an internal trusted network and also detects that it is connected to an internal trusted network and also
detects a foreign agent on the access network. detects a foreign agent on the access network.
3.1.3. Access mode: 'mc' 3.1.4. 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 [2] for subnet mobility. The
mobile node uses a foreign agent care-of address, if a foreign agent mobile node always configures a care-of address address through DHCP
is available. Otherwise it acquires an 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 for Mobile The mobile node MAY use a foreign agent care-of address, if a foreign
IP. The mobile node attempts Foreign Agent discovery and CoA address agent is available. However, the foreign agent care-of address is
acquisition through DHCP simultaneously in order to avoid the delay used only when the mobile node is attached to the trusted access
in discovering a foreign agent when there is no foreign agent network. The mobile node attempts Foreign Agent discovery and CoA
address acquisition through DHCP simultaneously in order to avoid the
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 the home address to the
current CoA. Whenever the mobile node moves, it sends a Registration current CoA. Whenever the mobile node moves, it sends a Registration
Request to update the binding cache entry. Request 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 [2].
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.
skipping to change at page 8, line 12 skipping to change at page 8, line 46
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 that it has moved to a new IP subnet [9] and its mobile node detects a change in network connectivity, it sends a
IP address changes, it sends a Registration Request to the i-HA Registration Request to the i-HA without any VPN encapsulation. If
without any VPN encapsulation. If the mobile node receives a the mobile node receives a Registration Reply, then it is assumes
Registration Reply, then it is assumes that it is on a trusted that it is on a trusted network. This is based on the mechanism
network. This is based on the mechanism described in [6] to detect described in [6] to detect attachment to the internal trusted
attachment to the internal trusted network. The mobile node should network. The mobile node should re-transmit the Registration Request
re-transmit the Registration Request if it does not receive the if it does not receive the Registration Reply within a timeout
Registration Reply within a timeout period. The number of times the period. The number of times the mobile node should re-transmit the
mobile node should re-transmit the Registration Request and the Registration Request and the timeout period for receiving the
timeout period for receiving the Registration Reply are configurable 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 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
skipping to change at page 10, line 18 skipping to change at page 11, line 5
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 [12] should be used by the mobile node NAT traversal, as described in [10] 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
[13] [14] should be used by the mobile node and the VPN gateway, if [11] [12] 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 [6]. described in [6].
Please see [3] for MOBIKE-related security considerations, and [12], When the mobile node sends a registration request to the i-HA from an
[13] for security concerns related to the use of NAT traversal 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
home address, and the Authenticator value in the authentication
extensions to the untrusted network. This may be a concern in some
deployments.
Please see [3] for MOBIKE-related security considerations, and [10],
[11] 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, TJ
TJ Kniveton for reviewing the document. Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni
Korhonen and Sami Vaarala for reviewing the document.
8. References 8. References
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)",
RFC 4555, June 2006. RFC 4555, June 2006.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 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.
8.2. Informative References
[6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across [6] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal Across
IPsec-based VPN Gateways", IPsec-based VPN Gateways",
draft-ietf-mip4-vpn-problem-solution-02 (work in progress), draft-ietf-mip4-vpn-problem-solution-02 (work in progress),
November 2005. November 2005.
8.2. Informative References
[7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 [7] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, Traversal of Virtual Private Network (VPN) Gateways", RFC 4093,
August 2005. August 2005.
[8] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", [8] Montenegro, G., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001. RFC 3024, January 2001.
[9] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network [9] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure
Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[11] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to Secure
Connectivity and Mobility", Connectivity and Mobility",
draft-meghana-mip4-mobike-optimizations-00 (work in progress), draft-meghana-mip4-mobike-optimizations-01 (work in progress),
March 2006. October 2006.
[12] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network [10] 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.
[13] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [11] 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.
[14] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [12] 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.
[13] Harkins, D. and D. Carrel, "The Internet Key Exchange (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 14, line 5 skipping to change at page 14, line 8
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 foreign agent care-of
address. If the mobile node moves and attaches to an untrusted 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 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 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 co-located care-of address to register with the i-HA thereby creating
a Mobile IP tunnel inside an IPsec tunnel. a Mobile IP tunnel inside an IPsec tunnel.
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
the home link directly. This document does not impose any
restrictions.
Authors' Addresses Authors' Addresses
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Azaire Networks
4800 Great America Pkwy 4800 Great America Pkwy
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: vijay.devarapalli@azairenet.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 Full Copyright Statement
Copyright (C) The Internet Society (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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 15, line 29 skipping to change at page 15, line 45
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 34 change blocks. 
85 lines changed or deleted 130 lines changed or added

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