One document matched: draft-meghana-mip4-mobike-optimizations-00.txt
MIP4 Working Group M. Sahasrabudhe
Internet-Draft Nokia
Expires: September 18, 2006 V. Devarapalli
Azaire Networks
March 17, 2006
Optimizations to Secure Connectivity and Mobility
draft-meghana-mip4-mobike-optimizations-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Users that need to connect to their enterprise network from an
untrusted network require secure connectivity and mobility.
Enterprise users are increasingly using mobile nodes. A user may
need to connect to the enterprise network from anywhere, and in a
number of scenarios, from untrusted networks. There are existing
specifications developed by the Mobile IPv4 working group that
describe solutions for enterprise secure connectivity and mobility.
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 1]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
This document proposes optimizations to those solutions to reduce the
tunneling overhead and allow for a number of new access modes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview with FA on VPN Gateway . . . . . . . . . . . 4
3.1. Access modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Access mode: 'fvf' . . . . . . . . . . . . . . . . . . . . 6
3.3. Access mode: 'cvf' . . . . . . . . . . . . . . . . . . . . 7
3.4. Access mode: 'mf' . . . . . . . . . . . . . . . . . . . . 7
4. Solution Overview with HA on VPN Gateway . . . . . . . . . . . 8
4.1. Access mode: 'fvh' . . . . . . . . . . . . . . . . . . . . 8
4.2. Access mode: 'cvh' . . . . . . . . . . . . . . . . . . . . 9
4.3. Access mode: 'mh' . . . . . . . . . . . . . . . . . . . . 10
5. Home Address as IPsec TIA . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 2]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
1. Introduction
It is assumed that the reader is familiar with
draft-ietf-mip4-mobike-connectivity-00.txt [2]. This document talks
about optimizations to the solution proposed in [2] and also to [6].
An enterprise user authenticates to the VPN gateway from an untrusted
network to gain access to the services on the enterprise network.
While inside the network, a user doesn't need to use the VPN gateway.
When a user roams in and out from a trusted to an untrusted network
the sessions currently active should not drop and the change in
connectivity should be seamless to the user.
The solution in [2] elaborates that the user uses only Mobile IPv4
[3] when inside the enterprise network and uses IPsec VPNs with
MOBIKE extensions to IKEv2 when roaming outside the enterprise
network to have access to the services provided by the enterprise.
Point to note is that this solution does not support legacy IPsec
VPNs. The VPN gateways have to implement mobility extensions to
IKEv2 [4]. The solution also does not require multiple Home Agents
or a Home Agent in the DMZ. The Home Agent is always located inside
the enterprise network. The tunnel inner address of the IPsec tunnel
is used as the MIPv4 co-located care of address (CCoA). As long as
the mobile node is connected to the same VPN gateway and its TIA
remains the same, there is no change in the CoA used by the mobile
node. When the mobile node moves to a new VPN gateway or gets a new
TIA, it updates its home agent with its new CCoA.
The packet format for packets sent from the mobile node to a
correspondent node, when the mobile node is outside the enterprise,
looks as follows
IPv4 hdr (src=IPA, dst=VPN_GW)
ESP Hdr
IPv4 hdr (src=TIA, dst=HA)
IPv4 hdr (src=HoA, dst=CN)
Payload
From the VPN gateway to the correspondent node the packet looks as
follows
IPv4 hdr (src=TIA, dst=HA)
IPv4 hdr (src=HoA, dst=CN)
Payload
When the mobile node is inside the enterprise the packet format looks
as follows
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 3]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
IPv4 hdr (src=IPA, dst=HA)
IPv4 hdr (src=HoA, dst=CN)
Payload
There is additional tunneling overhead when the mobile node is
roaming in an untrusted network. This overhead can be avoided by
having the Mobile IPv4 Foreign Agent functionality on the VPN
gateway. This would avoid having to encapsulate a Mobile IP tunnel
inside an IPsec tunnel. The following sections describe an optimized
connectivity and roaming solution that reduces the packet overhead
from the solution described in [2].
2. Terminology
i-MIP: Mobile IP layer used for internal enterprise mobility. Home
Agent is inside the enterprise network.
x-MIP: Mobile IP layer used for access from outside the enterprise
network. Home Agent resides either in the Internet or in the DMZ
before the VPN gateway looking from the Internet
i-HA: Home Agent inside the enterprise network
x-HA: Home Agent outside the enterprise network
i-FA: Mobile IPv4 foreign agent residing in the trusted enterprise
network
FA CoA: Foreign Agent mode care of address
cCoA: co-located care of address
HoA: Home address
TIA: Tunnel Inner Address, the address given out to the mobile node
by the VPN gateway during IKE setup
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 with FA on VPN Gateway
The two optimizations proposed in this document place the Foreign
Agent on the VPN gateway in one and the Home Agent on the VPN gateway
in the other. These reduces the tunnel overhead as the additional
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 4]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
tunneling from the TIA to the Home Agent is not required. In the FA
optimization, when the VPN gateway receives the packet from the
mobile node, it removes the IPsec header and the FA functionality on
the VPN GW encapsulates the original packet and sends it to the Home
Agent inside the enterprise. In the HA optimization, since the Home
Agent functionality is on the VPN gateway itself, the Mobile Node is
always on the Home Network even when roaming.
In the FA optimization, the packet format from the mobile node to the
VPN gateway now looks as follows
IPv4 hdr (src=IPA, dst=VPN_GW/FA)
ESP hdr
IPv4 hdr (src=HoA, dst=CN)
Payload
From the VPN gateway to the correspondent node the packet looks as
follows
IPv4 hdr (src=VPN_GW/FA, dst=HA)
IPv4 hdr (src=HoA, dst=CN)
Payload
The figure below depicts the network topology assumed for the
solution. It also shows the possible mobile node locations and
access modes.
(MN) {mf} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [MVPN/FA] `--+----'
\ ! !
[R/FA] .--+--. [R]
\ ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mf} (MN) {c} (MN) {f}
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 5]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
The tunnel overhead reduction is significant especially if the mobile
node is connected over a wireless network. The optimization
requirement of co-locating the Foreign Agent with the VPN gateway can
place the FA multiple hops away from the mobile node. FA
availability is hence an issue here. The FA still has to be on link
for the mobile node to receive Agent Advertisement messages. There
already exists a tunnel interface between the mobile node and the VPN
gateway. This tunnel interface can be used so the FA can appear just
one hope away and on link to the mobile node. The FA sends out Agent
Advertisement messages on the tunnel interface. The mobile node too
can send out MIP control messages to the FA on the tunnel interface.
3.1. Access modes
The access modes possible in [1] are
f: i-MIP with FA-CoA
c: i-MIP with CCoA
mc: mobile enhanced VPN, i-MIP with VPN TIA as CCoA
The additional access modes possible with this optimization are
fvf: x-MIP with FA CoA/ VPN/ i-MIP with FA CoA
cvf: x-MIP with CCoA/VPN/ i-MIP with FA CoA
mf: mobile enhanced VPN, i-MIP with FA CoA
3.2. Access mode: 'fvf'
In this access mode there are two home agents. One Home Agent is
located inside the enterprise and one outside the enterprise in the
internet or the DMZ before the VPN gateway looking from the internet.
In this mode the mobile node uses the external care-of address
(x-FACoA) and an external home address (x-HoA). Packets are first
tunneled to the external home Agent, then to the VPN gateway and
eventually to the internal home Agent.
Packet format from the mobile node to the VPN gateway looks as
follows:
IPv4 hdr (src=x-FA-CoA, dst=x-HA)
IPv4 hdr (src=i-HoA, dst=VPN_GW/FA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the correspondent node looks as
follows:
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 6]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
IPv4 hdr (src=VPN_GW/FA, dst=i-HA)
IPv4 hdr (src=i-HoA, dst=CN)
Payload
3.3. Access mode: 'cvf'
There are two home agents here also. One Home Agent is located
inside the enterprise and one outside the enterprise in the internet
or the DMZ before the VPN gateway looking from the internet. In this
mode tme mobile node uses the external co-located care-of address
(x-cCoA) and an external home address ( x-HoA).Packets are first
tunneled to the external home Agent, then to the VPN gateway and
eventually to the internal home Agent.
Packet format from the mobile node to the VPN gateway looks as
follows:
IPv4 hdr (src=x-cCoA, dst=x-HA)
IPv4 hdr (src=i-HoA, dst=VPN_GW/FA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the CN looks as follows:
IPv4 hdr (src=VPN_GW/FA, dst=i-HA)
IPv4 hdr (src=i-HoA, dst=CN)
Payload
3.4. Access mode: 'mf'
In this mode the VPN gateway is mobility aware in the sense that it
also implements MOBIKE extensions in addition to being a Foreign
Agent. The mobile node uses the home address as TIA.
Packet format from mobile node to the VPN GW/FA looks as follows:
IPv4 hdr (src=IPA, dst=VPN_GW/FA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the correspondent node looks as
follows:
IPv4 hdr (src=FA, dst=i-HA)
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 7]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
The advantage in using access modes "fvf" and "cvf" is that these can
still be used with legacy IPsec VPNs. Hence these can be deployed in
existing enterprise networks that may have already invested heavily
in legacy VPNs and would be reluctant to upgrade the VPN gateways in
the enterprise network.
4. Solution Overview with HA on VPN Gateway
The figure below depicts the network topology assumed for the
solution when the HA is co-located with the VPN gateway. It also
shows the possible mobile node locations and access modes.
(MN) {mh}
!
.--+---.
( )
`--+---' [MVPN/i-HA]
\ !
[R/FA] .--+--.
\ ( DMZ )
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mh} (MN) {c} (MN) {f}
The additional access modes possible with this optimization are
fvh: x-MIP with FA CoA/ VPN/ i-MIP with MN at home
cvh: x-MIP with CCoA/VPN/ i-MIP with MN at home
mh: mobile enhanced VPN, i-MIP with MN at home
4.1. Access mode: 'fvh'
In this access mode there are two home agents. One Home Agent is
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 8]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
located inside the enterprise and one outside the enterprise in the
internet or the DMZ before the VPN gateway looking from the internet.
In this mode the mobile node uses the external care-of address
(x-FACoA) and an external home address (x-HoA). Packets are first
tunneled to the external home Agent, then to the VPN gateway/Home
Agent.
Packet format from the mobile node to the VPN gateway looks as
follows:
IPv4 hdr (src=x-FA-CoA, dst=x-HA)
IPv4 hdr (src=i-HoA, dst=VPN_GW/HA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the correspondent node looks as
follows:
IPv4 hdr (src=i-HoA, dst=CN)
Payload
4.2. Access mode: 'cvh'
There are two home agents here also. One Home Agent is located
inside the enterprise and one outside the enterprise in the internet
or the DMZ before the VPN gateway looking from the internet. In this
mode the mobile node uses the external co-located care-of address
(x-cCoA) and an external home address ( x-HoA).Packets are first
tunneled to the external home Agent, then to the VPN gateway/Home
Agent.
Packet format from the mobile node to the VPN gateway looks as
follows:
IPv4 hdr (src=x-cCoA, dst=x-HA)
IPv4 hdr (src=i-HoA, dst=VPN_GW/HA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the CN looks as follows:
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 9]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
4.3. Access mode: 'mh'
In this mode the VPN gateway is mobility aware in the sense that it
also implements MOBIKE extensions in addition to being a Home Agent.
The mobile node uses the home address as TIA.
Packet format from mobile node to the VPN GW/HA looks as follows:
IPv4 hdr (src=IPA, dst=VPN_GW/HA)
ESP hdr
IPv4 hdr (src=i-HoA, dst=CN)
Payload
Packet format from the VPN gateway to the correspondent node looks as
follows:
IPv4 hdr (src=i-HoA, dst=CN)
Payload
The advantage in using access modes "fvh" and "cvh" is that these can
still be used with legacy IPsec VPNs. Hence these can be deployed in
existing enterprise networks that may have already invested heavily
in legacy VPNs and would be reluctant to upgrade the VPN gateways in
the enterprise network.
5. Home Address as IPsec TIA
When the mobile node sets up an IPsec tunnel with the VPN gateway it
is allocated a tunnel inner address (TIA). The TIA is used as the
source address for all traffic sent through the IPsec tunnel. In
tunnel mode IPsec security associations are created based on TIA.
But when a foreign agent functionality exists on the VPN gateway, the
mobile node MUST use the home address as the source address on the
data traffic. Moreover, the optimization described in Section 3.4 is
possible only if the home address is equal to the TIA.
In order for the home address to be equal to the TIA, there is a need
for close interaction between the IKEv2 implementation and Foreign
agent implementation on the VPN gateway. This may not be possible
with all implementations, since the IPsec tunnel setup happens before
an Foreign Agent Advertisement can be sent over the IPsec tunnel to
the mobile node. One possible solution would be to allocate a TIA
when the IPsec tunnel is setup and later replace the TIA with the
home address. This would require updating the IPsec SAs with the new
home address. But this would violate RFC 4301 [8] which says the TIA
cannot be changed without rendering the tunnel mode IPsec SAs
invalid.
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 10]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
A simple solution would be for the mobile node to setup an IPsec
tunnel with the TIA allocated by the VPN gateway, and then run a
separate CREATE_CHILD_SA exchange [5] to setup new tunnel mode IPsec
security associations for the home address. This would however
introduce additional delay in the form of an additional
CREATE_CHILD_SA exchange when the mobile node connects to the
enterprise network from outside. The security associations created
earlier for the TIA can be either torn down or allowed to expire
based on the configuration on the mobile node.
When the Home Agent is co-located with the VPN gateway the allocated
TIA can be the Home Address at the initial IPsec tunnel establishment
itself.
6. Security Considerations
The solution described in this document does not introduce any new
security vulnerabilities on top of what is described in the security
considerations sections of [2], [6] and [7].
7. IANA Considerations
This document requires no action from IANA.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility
using Mobile IPv4 and MOBIKE",
draft-ietf-mip4-mobike-connectivity-00 (work in progress),
January 2006.
[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-08 (work in progress), February 2006.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 11]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
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] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 12]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
Authors' Addresses
Meghana Sahasrabudhe
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: meghana.saha@nokia.com
Vijay Devarapalli
Azaire Networks
4800 Great America Parkway
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 13]
Internet-Draft VPN Gateway and FA/HA co-location March 2006
Intellectual Property Statement
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.
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sahasrabudhe & Devarapalli Expires September 18, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 08:59:12 |