Internet DRAFT - draft-antoine-mip4-proxymobike
draft-antoine-mip4-proxymobike
Network Working Group Stephane Antoine
Internet-Draft France Telecom Research and
Intended status: Standards Track Development
Expires: August 17, 2008 February 14, 2008
Mobility using Proxy MIP and Mobike
draft-antoine-mip4-proxymobike-01.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.
This document may not be modified, and derivative works of it may not
be created.
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 August 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The simultaneous use of Mobike and Mobile IPv4 has been proposed to
provide secure connectivity and session continuity to roaming
corporate users. Optimization of this solution have eliminated the
tunneling overhead of Mobile IPv4 in the vpn tunnel by having a
Foreign Agent co-located to the mobile vpn gateway. This document
further proposes an interaction between Mobike and Proxy Mobile IP
Stephane Antoine Expires August 17, 2008 [Page 1]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
that simplifies implementation and deployment of the previous
methods. The mobile vpn gateway is co-located to the Mobility Proxy
Agent and each Access Point in the corporate network is equipped with
Proxy Mobile IP. When moving outside the corporate network, the
Mobile Node secure connectivity and session continuity is handled by
Mobike. Proxy Mobile IP alone is used to handle mobility when the
Mobile Node moves within the corporate network. This document
introduces an interaction between Internet Key Exchange v2 and Proxy
Mobile IP in which the Internet Key Exchange AUTH request triggers
the Proxy Mobile IP registration request to the internal Home Agent.
This interaction easily allows the Mobile Node's home address to be
used as vpn Tunnel Inner Address.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture and solution overview . . . . . . . . . . . . . . 3
4. Solution description . . . . . . . . . . . . . . . . . . . . . 5
4.1. VPN establishment and HoA address acquisition. . . . . . . 5
4.2. Detecting that MN has moved into the trusted network. . . 6
4.3. Moving to the trusted network . . . . . . . . . . . . . . 6
4.4. Moving outside the trusted network . . . . . . . . . . . . 6
4.5. Moving back to an un-trusted network . . . . . . . . . . . 7
4.6. Moving within the enterprise network . . . . . . . . . . . 7
5. Routing considerations . . . . . . . . . . . . . . . . . . . . 7
6. Packet formats . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Reduction of the overhead . . . . . . . . . . . . . . . . 8
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Stephane Antoine Expires August 17, 2008 [Page 2]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
1. Introduction
To provide secure connectivity and session continuity to corporate
users a combination of mobike and Mobile IPv4 (MIPv4) has been
proposed [SECURE]. Mobike is used to achieve vpn session continuity
as the Mobile Node (MN) is moving outside the corporate network
premises. The MIPv4 session alone which is anchored to an internal
Home Agent (i-HA) is used to handle mobility as the MN is moving
inside the corporate network. To eliminate the overhead of MIPv4 in
the vpn tunnel, an optimisation introduced a Foreign Agent (FA) co-
located with the mobile VPN (mVPN) gateway. However this
optimisation introduced complexity in setting the MN's Home address
as the vpn tunnel inner address. In the present document, a
combination of Mobike and Proxy MIP eliminates the previous problems.
The Proxy Mobility Agent is co-located to the mVPN gateway. Outside
the corporate network, the MN uses Mobike for secure connectivity and
session continuity. When the MN moves within the corporate network,
proxy MIP alone is used with the i-HA to maintain the MN's session
continuity. The Internet Key Exchange (IKEv2) AUTH request triggers
the Proxy MIP (PMIP) registration hence making it easy for the Home
Address to be assigned as the vpn Tunnel Inner Address (TIA). It
also removes some complexity as the MN only has an instance of Mobike
on the MN and its mobility inside the corporate network is handled by
the network through Proxy MIP.
.
2. Terminology
The terminology in [SECURE] applies for this document and we further
introduce the following terms: GMPA: Gateway Mobility Proxy Agent.
MPA collocated to the mVPN gateway. i-MPA: Internal Mobility Proxy
Agent residing in the trusted enterprise network.
3. Architecture and solution overview
The architecture considered involved a mVPN Gateway, the
demilitarized zone and the internal network which is the trusted
network
Stephane Antoine Expires August 17, 2008 [Page 3]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
(MN) (MN) [i-HA]
! \ /
.------. .-+---+-.
( ) ( )
------- [mVPN/GMPA] --+----
\ ! !
[R/(MPA)] .--+--. [AR/MPA]
\ ( DMZ ) !
.+------------. --+---- .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
-----+--------- ---+---+------
/ / \
[DHCP] [R] [DHCP] [AR/MPA] [AR/MPA][i-MPA]
\ / \ / \ /
.+-+---. .-+-+--. .--+--+-.
( ) ( ) ( )
--+--- --+---- ---+-----
! ! !
(MN) (MN) (MN)
Figure 1: Network topology with GMPA colocated with VPN Gateway
The architecture described supports PMIP in the corporate network.
In this architecture, it is assumed that every Access Point or Access
Router (AR) in the corporate network is a MPA implementing the
functionalities of PMIP. In this architecture, the MPAs and the i-HA
are not directly accessible from the external network. The mobility
service provided by the i-HA is not available to un-trusted users.
When a trusted MN moves within the corporate network, PMIP is used to
maintain the MN session continuity. The MPA maintains a valid
Binding cache entry at all times at the Home Agent mapping the Home
address to the current CoA (Address of the MPA or of the FA).
Whenever, the MN attaches a new MPA, the MPA sends a registration
request to update the binding cache entry for that MN. If the mobile
node moves while outside the enterprise and its access network
changes, it uses the MOBIKE protocol [MOB] to update the VPN gateway
of its current address. When the MN is connected to the same VPN
Gateway, the GMPA still maintains a valid binding cache entry at the
i-HA. The i-HA is not aware of the mobile node's movement as long as
the MN is attached to the same VPN gateway and the GMPA address
remains the same. In order to maintain session continuity of the MN
as it moves between networks, the Home Address (HoA) stays unchanged.
If the MN had to change VPN gateway, the new GMPA would update the
i-HA with the new Care of Address.
Stephane Antoine Expires August 17, 2008 [Page 4]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
4. Solution description
The few set of functionality introduced in the document are depicted
in this section.
4.1. VPN establishment and HoA address acquisition.
To use the MN's HoA as the vpn TIA, the current solution proposes
that the IKE AUTH request of the vpn session establishment triggers
the Proxy MIP registration. Figure 2 illustrates the interaction
between the IKEv2 signalling exchange and the first proxy MIP
registration.
MN mVPN/GMPA i-HA
| | |
|------------------------>| |
1| IKE_SA_INIT | |
|<------------------------| |
| | |
|IKE_AUTH request | |
2|------------------------>| |
|IDi=NAI | |
|CP_CFG_REQUEST | |
|initial address= 0.0.0.0 | |
| | |
| | Reg_Req: (HoA=0.0.0.0) |
| |3------------------------>|
| |<------------------------4|
| | Reg_Repl (HoA) |
| IKE_AUTH response | |
5| <-----------------------| |
|CP(CFG_REPLY)= Internal_address (HoA) |
| | |
Figure 2: Initial registration and HoA acquisition
1. The first message exchange is the IKE_SA_INIT.
2. The MN presents its NAI in the IDi (Identification of initiator)
payload of the IKE_AUTH request. The GMPA will use the NAI to
send the Registration request for the MN. IKE_AUTH request will
also contain a CP_CFG_REQUEST payload containing the internal
address 0.0.0.0 indicating that the MN is requesting an IP
address from the internal network.
Stephane Antoine Expires August 17, 2008 [Page 5]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
3. Following the Reception of the IKE_AUTH request and correct
processing, the GMPA sends a Registration Request to the i-HA.
4. The i-HA will return the HoA to be allocated to the MN in the
Registration reply.
5. When the GMPA receives the Reg_Reply with the HoA, the mVPN sends
that HoA in the CP(CFG_REPLY) payload of the IKE_AUTH response.
4.2. Detecting that MN has moved into the trusted network.
When a new network becomes available, the MN performs network access
authentication on that network. During this authentication, the MN
presents its NAI to the Access Router. Alternatively, if network
access authentication is not required, the client Fully Qualified
Domain Name (FQDN) sub-option [DHCP] will present the MN's FQDN to
the AR. Assuming that in each MPA of the trusted network, it exists
a mapping between the FQDN and the NAI; the MN will be identified by
that mapping. The AR/MPA then sends a Proxy Registration Request for
the MN's NAI to the i-HA address. The MN uses reception of native
unprotected data to its HoA as an indication that it is in the
trusted network.
4.3. Moving to the trusted network
In the trusted network, the MN does not use the vpn tunnel to send
and receive traffic. So the vpn tunnel may be torn down when the MN
detects that it has moved in the trusted network. The SAs that used
to protect the traffic between the MN and the mVPN gateway can be
deleted. To that end the MN can send a Mobike DELETE message (with
address 0.0.0.0) to the mVPN gateway. The IPsec SA can be created
when required. The MN may have to re-negotiate IKEv2 SA to prevent
the IKE SA from expiring. This negotiation can be done through the
old network if it is still available or through the internal network
if the vpn gateway is reachable from the internal network.
4.4. Moving outside the trusted network
Mobike is used to handle mobility of the MN when it is roaming
outside the trusted network. The HoA which is the VPN TIA stays
unchanged to maintain session continuity. When the MN disconnects
from the VPN gateway or attaches a different VPN gateway, it should
re-connect and obtain the same VPN TIA as the previous one. This
will allow sessions to survive VPN disconnection as the Mobility
Bindings for the MN's HoA at the i-HA have remained in spite of the
VPN disconnection.
Stephane Antoine Expires August 17, 2008 [Page 6]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
4.5. Moving back to an un-trusted network
After detecting that it has moved outside the trusted network, the MN
will re-establish the VPN connection with possibly the old IKE SA it
had before tearing the VPN tunnel down. The mobile node may not have
to re-negotiate the IKEv2 SA if it has maintained the VPN states
alive in the VPN gateway while it was receiving traffic directly from
the trusted network [SECURE].
4.6. Moving within the enterprise network
Within the corporate network, PMIP as described in [PMIP4] is
handling mobility of MN with the i-HA serving as the mobility anchor.
5. Routing considerations
The GMPA is configured with the i-HA as its default router. Packets
from the MN are de-capsulated by the m-VPN gateway which, pass the
inner packets to the GMPA. The GMPA reverse tunnel them in IP to the
i-HA. Packets from the i-HA are de-capsulated by the GMPA and then
re-encapsulated in the IPsec tunnel to the MN. The GMPA might use a
private address as source address of the Registration Request sent to
the i-HA. For routing simplifications, most corporate networks would
not have any NAT between the MPA and the i-HA. Encapsulation would
then be of the type IP in IP for both forward and reverse tunnels.
6. Packet formats
Packet format from MN to the mVPN gateway:
Outer IPv4 header: (Src: local IPA, Dst: mVPN Gtwy)
ESP header
Inner IPv4 header: (Src: HoA=TIA, Dst: CN )
Payload
Packet from the MPA to the i-HA:
Outer IPv4 header: (Src: MPA, Dst: i-HA)
Inner IPv4 header: ( Src: HoA, Dst: CN)
Payload
Packet from the i-HA to the CN:
IPv4 header: (Src: HoA, Dst: CN)
Payload
For the forward path, the source and destination addresses are
reversed.
Stephane Antoine Expires August 17, 2008 [Page 7]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
7. Solution Benefits
7.1. Simplicity
This method makes it easy to assign the MN's HoA as the VPN TIA. It
thus removes the complexity associated with the method proposed in
[OPT] where the MN runs an instance of MIP and where the FA is co-
located to the mVPN gateway. This method suggested to; first
allocate a TIA to the MN during vpn (IPsec tunnel mode) setup and
then replace the TIA with the home address. This would violate RFC
4301 [SEC] which; states that the TIA cannot be changed without
rendering the tunnel mode IPsec SAs invalid. An alternative method
was suggested to perform an additional CREATE_CHILD_SA exchange after
the initial exchange to create an IPsec SA for the Home Address and
let the first CHILD SA with the TIA expires. This method introduced
significant complexity. Instead; the interaction between PMIP and
Mobike works simply to allocate the HoA as the VPN TIA without any
additional mechanism. The method presented in this document also
reduces the amount of signalling that would be necessary if Dynamic
Host Configuration Protocol (DHCP) was used to obtain the HoA after
the establishment of the VPN connection.
7.2. Reduction of the overhead
With this method, the MIPv4 overhead in [SECURE] is removed between
the MN and the mVPN gateway. Moreover, the present method eliminates
the MIPv4 Registration overhead that still occurs between the MN and
the FA in the method described in [OPT]. The great benefit of PMIP
lies in the elimination of the MIP signalling between the MN and the
MPA.
8. Conclusion
This document introduces the interaction between Mobike and Proxy MIP
to provide secure connectivity and mobility to the corporate users.
The proposed architecture involves a Gateway Proxy Mobility Agent co-
located with the mVPN gateway and a MPA on each AP within the
enterprise network. When moving outside the corporate network,
Mobike is used to maintain the user secure connectivity with the
intranet. Proxy MIP is used to maintain session continuity within
the corporate network. During the initial IKEv2 negotiation, the
IKEv2 IKE_AUTH Request message triggers the Proxy Registration
Request for the MN. The Home Address allocated for the MN in the
Registration Reply is passed to the MN in the IKE_AUTH Reply. The
MN's Home Address henceforth coincides with the MN's VPN Tunnel Inner
Address. Combining Proxy MIP and Mobike simplifies the deployment of
a seamless mobility solution for corporate users while removing the
Stephane Antoine Expires August 17, 2008 [Page 8]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
overhead of MIPv4 in the vpn tunnel. Using PMIP, guarantees mobility
in the intranet without requiring the Mobile Node to run any mobility
management protocol such as MIPv4.
9. Acknowledgements
10. Normative References
[DHCP] M. Stapp, B. Volz, Y. Rekhter, "The Dynamic Host
Configuration Protocol (DHCP) Client, Fully Qualified
Domain Name (FQDN) Option, Request for Comments: 4702",
October 2006.
[MOB] P. Eronen, "Mobike, Internet draft; IKEv2 Mobility and
Multihoming Protocol (MOBIKE)", February 2006.
[OPT] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to
Secure Connectivity and Mobility,
draft-meghana-mip4-mobike-optimizations-01 (work in
progress)", October 2006.
[PMIP4] K. Leung, G. Dommety, P. Yegani, K. Chowdhury, "Mobility
Management using Proxy Mobile IPv4", January 2007.
[SEC] S. Kent, K. Seo, "Security Architecture for the Internet
protocol, rfc 4301", December 2005.
[SECURE] V. Devarapalli, P. Eronen, Editor., "Secure Connectivity
and Mobility using Mobile IPv4 and Mobike, MIPv4-Mobike: ht
tp://www.ietf.org/internet-drafts/
draft-ietf-mip4-mobike-connectivity-02.txt", January
2007.
Author's Address
Stephane Antoine
France Telecom Research and Development
Chiswick Park
London, Chiswick W4 5XS
United Kingdom
Phone: + 44 (0)208 849 5821
Fax: +44 (0)208 849 0991
Email: stephane.antoine@orange-ftgroup.com
Stephane Antoine Expires August 17, 2008 [Page 9]
Internet-Draft Mobility using Proxy MIP and Mobike February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Stephane Antoine Expires August 17, 2008 [Page 10]
