draft-ietf-mip4-mobike-connectivity-02.txt   draft-ietf-mip4-mobike-connectivity-03.txt 
MIP4 Working Group V. Devarapalli MIP4 Working Group V. Devarapalli
Internet-Draft Azaire Networks Internet-Draft Azaire Networks
Intended status: Standards Track P. Eronen Intended status: Best Current P. Eronen
Expires: July 7, 2007 Nokia Practice Nokia
January 3, 2007 Expires: September 3, 2007 March 2, 2007
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE
draft-ietf-mip4-mobike-connectivity-02 draft-ietf-mip4-mobike-connectivity-03.txt
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 July 7, 2007. This Internet-Draft will expire on September 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 [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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
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
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} {h} (MN) [i-HA] {h} (MN) [i-HA]
! \ / \ /
.--+---. .-+---+-. .-+---+-.
( ) ( ) ( )
`--+---' [mVPN] `--+----' [mVPN] `--+----'
\ ! ! ! !
[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]
\ / \ / \ / \ / \ / \ /
.+--+---. .-+-+--. .--+--+-. .+--+---. .-+-+--. .--+--+-.
( ) ( ) ( ) ( ) ( ) ( )
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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 is assumes the mobile node receives a Registration Reply, then it assumes that
that it is on a trusted network. This is based on the mechanism it is on a trusted network. The mobile node MUST check that the
described in [6] to detect attachment to the internal trusted Registration Reply is integrity protected using the mobile node-home
network. The mobile node should re-transmit the Registration Request agent mobility security association before concluding it is attached
if it does not receive the Registration Reply within a timeout to a trusted network. This security boundary detection is based on
period. The number of times the mobile node should re-transmit the the mechanism described in [6] to detect attachment to the internal
Registration Request and the timeout period for receiving the trusted network. The mobile node should re-transmit the Registration
Registration Reply are configurable on the mobile node. Request if it does not receive the Registration Reply within a
timeout 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
skipping to change at page 10, line 4 skipping to change at page 10, line 5
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:
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 2, then the current subnet is a trusted subnet, and sent in step 1b, then the current subnet is a trusted subnet, and
the mobile node can communicate without VPN tunneling. The mobile the mobile node can communicate without VPN tunneling. The mobile
node MAY tear down the VPN tunnel. 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
skipping to change at page 12, line 18 skipping to change at page 12, line 19
[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",
December 2005. RFC 4306, 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] 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 8.2. Informative References
skipping to change at page 14, line 17 skipping to change at page 14, line 21
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 by 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 Azaire Networks
4800 Great America Pkwy 3121 Jay Street
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 13 change blocks. 
36 lines changed or deleted 34 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/