Network Working Group A. Nuopponen
Internet-Draft S. Vaarala
Expires: January 17, 2003 Netseal
July 19, 2002
Mobile IPv4 coexistence with IPsec remote access tunnelling
draft-nuopponen-vaarala-mipvpn-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 January 17, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a simple method that allows a mobile node to
use a home agent situated inside a protected intranet, while also
allowing the mobile to roam between the public internet and the
intranet without losing active sessions. Whenever the mobile is
outside the intranet, it connects to the intranet using an IPsec
tunnel and registers the IPsec-assigned inner tunnel address as its
co-located care-of address to the internal home agent. If desired,
handover performance while outside the intranet can be enhanced by
employing another Mobile IP layer underneath IPsec. The solution
does not require any new protocols, only a profile for using existing
protocols. Only the mobile node needs to be modified in order to use
Nuopponen & Vaarala Expires January 17, 2003 [Page 1]
Internet-Draft MIPv4 and IPsec remote access July 2002
this profile.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Description of the solution . . . . . . . . . . . . . . . 4
2.1 Network topology . . . . . . . . . . . . . . . . . . . . . 4
2.2 Summary of solution . . . . . . . . . . . . . . . . . . . 5
2.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Mobile node in the intranet . . . . . . . . . . . . . . . 6
2.3.1.1 Mobile node in the home subnet . . . . . . . . . . . . . . 6
2.3.1.2 Mobile node uses a co-located intranet address . . . . . . 6
2.3.1.3 Mobile node uses an intranet foreign agent . . . . . . . . 7
2.3.1.4 Mobile node uses a trusted foreign agent in the external
network . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Mobile node in the external network, no external Mobile IP 7
2.3.3 Mobile node in the external network, using external
Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.3.1 Mobile node uses an external co-located care-of address . 8
2.3.3.2 mobile node uses an external foreign agent . . . . . . . . 8
2.4 Some issues . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Use of reverse tunnelling . . . . . . . . . . . . . . . . 8
2.4.2 Detecting internal and external network . . . . . . . . . 9
2.4.3 Packet overhead . . . . . . . . . . . . . . . . . . . . . 9
2.4.4 Co-located care-of address registration through a foreign
agent . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.5 Using an external foreign agent . . . . . . . . . . . . . 9
2.4.6 Mobile node network stack arhitecture considerations . . . 9
2.4.7 AAA considerations . . . . . . . . . . . . . . . . . . . . 10
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . 13
Nuopponen & Vaarala Expires January 17, 2003 [Page 2]
Internet-Draft MIPv4 and IPsec remote access July 2002
1. Introduction
In some deployment scenarios it is desireable to use Mobile IPv4 in a
protected corporate intranet to provide mobility for users, while
using a VPN device on the network edge to protect against
unauthorized access. In such a deployment, it would be desireable
for users to be able to roam from the intranet to the external
network (and back) while maintaining active sessions.
Mobile IPv4 and VPN coexistence problem statement and solution
requirements are described in [2]. This document describes a simple
method for solving these coexistence problems by defining a profile
for combining Mobile IPv4 and IPsec in a certain way.
Nuopponen & Vaarala Expires January 17, 2003 [Page 3]
Internet-Draft MIPv4 and IPsec remote access July 2002
2. Description of the solution
2.1 Network topology
The network topology assumed by the solution is described in this
section. The description is described with regards to service
rendered for a single mobile node.
The home network consists of the following components:
o the home agent providing service to the mobile node
o optional foreign agents
o optional site-to-site IPsec tunnels
o the intranet interface(s) of one or more IPsec devices (which are
not necessarily in the home network, but in the trusted side of
the device anyway)
The external network consists of the following components:
o the external interface(s) of one or more IPsec devices
o optional "trusted foreign agents" that are connected to the home
network using a static IPsec tunnel, and are thus logically part
of the intranet (see [2] for definition)
o optional external Mobile IP home agent used to optimize IPsec
tunnel handover performance
o optional foreign agents to support the use of the abovementioned
external home agent
o possibly NAT device(s) between (not all apply):
* the mobile node and the IPsec device
* a trusted foreign agent and the IPsec device
* the mobile node and an external home agent
* the external home agent and the IPsec device
The external network access alternatives are summarized in the
following figure.
Nuopponen & Vaarala Expires January 17, 2003 [Page 4]
Internet-Draft MIPv4 and IPsec remote access July 2002
1a. mn ================================ vpn -- ha
1b. mn == nat ========================= vpn -- ha
1c. mn ++ t-fa ======================== vpn -- ha
1d. mn ++ t-fa == nat ================= vpn -- ha
2a. mn ################# e-ha ========= vpn -- ha
2b. mn ################# e-ha == nat == vpn -- ha
2c. mn ## nat ########## e-ha ========= vpn -- ha
2d. mn ## nat ########## e-ha == nat == vpn -- ha
2e. mn == e-fa ######### e-ha ========= vpn -- ha
2f. mn == e-fa ######### e-ha == nat == vpn -- ha
2g. mn == e-fa ## nat ## e-ha ========= vpn -- ha
2h. mn == e-fa ## nat ## e-ha == nat == vpn -- ha
Encapsulation markers:
-- unprotected, Mobile IP tunnelled (reverse tunnelling)
== Mobile IP tunnelled, then IPsec protected
++ unprotected, plain packets (not Mobile IP tunnelled)
## Mobile IP tunnelled, then IPsec protected, then
(possibly) Mobile IP tunnelled again
Network elements:
mn mobile node
vpn IPsec edge device
ha internal home agent
t-fa trusted foreign agent (logically part of intranet)
e-ha external home agent
e-fa external foreign agent, used to communicate with the
external home agent
nat NAT device
2.2 Summary of solution
When the mobile node resides in the home network, Mobile IPv4 is
applied normally.
Site-to-site IPsec tunnels work transparently: the mobile still uses
standard Mobile IPv4, and the registration request/reply messages and
data messages are tunneled normally between sites.
When outside the home network, the mobile node can be considered to
be at the remote end of a site-to-site IPsec tunnel consisting only
of a single address, the "inner" address of the IPsec tunnel. This
address is either configured manually, or the IPsec-DHCP mechanism
Nuopponen & Vaarala Expires January 17, 2003 [Page 5]
Internet-Draft MIPv4 and IPsec remote access July 2002
can be leveraged [4].
The "inner" address of the IPsec tunnel is used as a co-located care-
of address for a standard Mobile IPv4 registration. Because the
routing in the intranet is organized in a way that ensures that
packets destined to this care-of address are routed to the IPsec
device, they will get tunnelled to the mobile node normally.
Because the mobile node never logically leaves the intranet, sessions
survive mobility between the intranet and the external network.
Because IPsec is not mobile by nature, handovers when in the external
network force the mobile node to re-establish IPsec connectivity.
Since this may be unacceptable in some scenarios, the IPsec tunnel
can be made mobile by using Mobile IP underneath IPsec to provide for
a static "outer" tunnel address (i.e. the Mobile IP home address
obtained from the external home agent is used as the IPsec tunnel
remote outer endpoint address).
NAT traversal is addressed by the Mobile IPv4 NAT specification [3]
whenever applicable (i.e. when Mobile IP is the lowest layer
protocol) and IPsec NAT traversal ([5], [6]) whenever applicable
(i.e. when IPsec is the lowest layer protocol).
Note that this document does not specify how the mobile node detects
it is in the external network and should try to establish an IPsec
tunnel.
2.3 Scenarios
2.3.1 Mobile node in the intranet
2.3.1.1 Mobile node in the home subnet
No difference to standard Mobile IPv4; however, the mobile node MUST
have some secure means of ensuring that it has indeed returned home.
This document does not specify such a mechanism.
2.3.1.2 Mobile node uses a co-located intranet address
The mobile node acquires a care-of address e.g. using DHCP.
Site-to-site IPsec tunnels do not affect the registration (or
routing) procedure other than that reverse tunnelling SHOULD be used
to avoid problems with IPsec policy selectors. If the site-to-site
IPsec tunnel is not a "bridging" tunnel, there is a different subnet
at each end of the tunnel. In this case each IPsec tunnel endpoint
MUST do a sort of ingress filtering as a part of IPsec policy
Nuopponen & Vaarala Expires January 17, 2003 [Page 6]
Internet-Draft MIPv4 and IPsec remote access July 2002
processing. Thus, reverse tunneling is required.
2.3.1.3 Mobile node uses an intranet foreign agent
No difference to standard Mobile IPv4.
2.3.1.4 Mobile node uses a trusted foreign agent in the external network
A trusted foreign agent, as described in [2], is located in the
external network and would typically have a static IPsec tunnel to
secure communication between the FA and the HA.
This scenario is essentially identical to using an intranet foreign
agent from the home agent and mobile node perspectives. If there is
a NAT device between the trusted foreign agent and the IPsec device,
IPsec NAT traversal ([5], [6]) is required.
From the mobile node perspective, there MUST be a secure way to
identify a trusted foreign agent. This document does not specify
such a mechanism.
2.3.2 Mobile node in the external network, no external Mobile IP
The mobile node acquires an IPsec tunnel outer address using some
unspecified means (manual configuration, DHCP, etc). The node then
forms an IPsec tunnel using e.g. IKE.
The inner address of the tunnel is the one that is used to route
traffic from the home network to the IPsec device. The mobile node
has to obtain this address somehow, e.g. by manual configuration or
by using the IPsec-DHCP mechanism [4]. If there is a NAT between the
external home agent and the DHCP device, IPsec NAT traversal should
be used ([5], [6]).
Once the IPsec tunnel has been formed, the mobile node uses the
tunnel inner address as its co-located care-of address and proceeds
with Mobile IPv4 registration normally.
Note that this scenario is a degenerated version of the site-to-site
IPsec tunnel registration. Mobile IP reverse tunneling MUST be used
for the same reason as with the site-to-site scenario.
2.3.3 Mobile node in the external network, using external Mobile IP
In these scenarios, Mobile IP is used as a mobility mechanism for
transporting IPsec tunnel packets. There is an external home agent
in the external network, and two logical mobile nodes (in the Mobile
IP sense) in the mobile node host: one for the intranet home agent,
Nuopponen & Vaarala Expires January 17, 2003 [Page 7]
Internet-Draft MIPv4 and IPsec remote access July 2002
and another for the IPsec mobility home agent.
Since the external Mobile IP is only involved in transporting IPsec,
there are no limitations on e.g. use of reverse tunnelling. Thus,
packets sent by the mobile node can be, if desired, sent directly to
the IPsec device without going through the external home agent (if
ingress filtering is not in use).
2.3.3.1 Mobile node uses an external co-located care-of address
The mobile node obtains an external co-located care-of address e.g.
using DHCP. The mobile node then uses this care-of address to
register to the external Mobile IP home agent. If there is a NAT
between the mobile node and the external home agent, Mobile IP NAT
traversal [3] should be used.
Once the external mobility binding is set up, the mobile node can use
the home address (from the external home agent address space) as an
IPsec tunnel outer address. The inner address is still obtained e.g.
by manual configuration or the IPsec-DHCP mechanism [4]. If there is
a NAT between the external home agent and the DHCP device, IPsec NAT
traversal should be used ([5], [6]).
Once the IPsec tunnel has been formed, the mobile node uses the
tunnel inner address as its co-located care-of address and proceeds
with Mobile IPv4 registration normally, this time registering to the
intranet home agent.
Note that this scenario is a degenerated version of the site-to-site
IPsec tunnel registration. Mobile IP reverse tunneling MUST be used
for the same reason as with the site-to-site scenario.
2.3.3.2 mobile node uses an external foreign agent
The mobile node detects the foreign agent and registers to the
external home agent using the foreign agent. If there is a NAT
device between the external foreign agent and the external home
agent, Mobile IP NAT traversal should be used [3].
Otherwise the scenario plays out as in Section 2.3.3.1.
2.4 Some issues
2.4.1 Use of reverse tunnelling
Since IPsec security associations are bound to the "inner" addresses,
Mobile IP reverse tunneling MUST be used when registering through an
IPsec device, using the tunnel "inner" address as a co-located care-
Nuopponen & Vaarala Expires January 17, 2003 [Page 8]
Internet-Draft MIPv4 and IPsec remote access July 2002
of address.
2.4.2 Detecting internal and external network
The mobile node needs a mechanism for detecting which scenario it is
currently in, i.e. a mechanism to detect that it is in the outside
network or in the intranet. A simple mechanism is to try
registration without IPsec first, and if that consistently fails for
a reasonable period of time, automatically try IPsec. If the mobile
node makes an error, it is never fatal security-wise because the
mobile node errs on the side of trying to set up the IPsec tunnel in
vain.
2.4.3 Packet overhead
The solution does not optimize packet overhead. However, since only
standard nodes are needed in the solution, some extra overhead may be
acceptable.
2.4.4 Co-located care-of address registration through a foreign agent
When a mobile node registers using a co-located care-of address, a
foreign agent can be used for the registration, although this case
has not been explicitly covered in the scenarios.
2.4.5 Using an external foreign agent
If the mobile node must be able to communicate to the home network
even when connected to an external foreign agent, use of Mobile IP
underneath IPsec is no longer optional. Without the use of external
Mobile IP, this access scenario will not work.
2.4.6 Mobile node network stack arhitecture considerations
The solution calls for changes in the composition of the mobile node
network stack depending on whether the mobile node is outside or
inside the home network. In particular, IPsec needs to be enabled or
disabled (an effect that may also be achieved by configuring IPsec
policy dynamically), and two instances of Mobile IP may be required,
one underneath and one above IPsec.
Since the mobility bindings established through the IPsec tunnel are
entirely transparent to the internal home agent, all Mobile IP
features (e.g. simultaneous bindings) can be used in the solution.
In addition, the mobile node is free to do split tunnelling, although
it places more requirements on the architecture of the mobile node
network stack.
Nuopponen & Vaarala Expires January 17, 2003 [Page 9]
Internet-Draft MIPv4 and IPsec remote access July 2002
2.4.7 AAA considerations
TBD
Nuopponen & Vaarala Expires January 17, 2003 [Page 10]
Internet-Draft MIPv4 and IPsec remote access July 2002
3. Acknowledgements
The authors would like to thank colleagues at Netseal, especially
Ilkka Pietikainen and Timo Aalto, and people on the the MIP/VPN
coexistence mailing list, especially Farid Adrangi and Alan O'Neill,
for feedback on the approach.
Nuopponen & Vaarala Expires January 17, 2003 [Page 11]
Internet-Draft MIPv4 and IPsec remote access July 2002
References
[1] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January
2002.
[2] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A.,
Zhang, Q. and J. Lau, "Problem Statement for Mobile IPv4
Traversal Across VPN Gateway (draft-ietf-mobileip-vpn-problem-
statement-00)", March 2002.
[3] Levkowetz, H. and S. Vaarala, "Mobile IP NAT/NAPT Traversal
using UDP Tunnelling (draft-ietf-mobileip-nat-traversal-04)",
May 2002.
[4] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "DHCPv4
Configuration of IPsec Tunnel Mode (draft-ietf-ipsec-dhcp-13)",
June 2001.
[5] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe,
"Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat-
t-ike-03)", June 2002.
[6] Huttunen, A., Swander, B., Stenberg, M., Volpe, V. and L.
DiBurro, "UDP Encapsulation of IPsec Packets (draft-ietf-ipsec-
udp-encaps-03)", June 2002.
Authors' Addresses
Antti Nuopponen
Netseal
Niittykatu 6
P.O.Box 38
Espoo FIN-02201
Finland
EMail: antti.nuopponen@netseal.com
Sami Vaarala
Netseal
Niittykatu 6
P.O.Box 38
Espoo FIN-02201
Finland
EMail: sami.vaarala@iki.fi
Nuopponen & Vaarala Expires January 17, 2003 [Page 12]
Internet-Draft MIPv4 and IPsec remote access July 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nuopponen & Vaarala Expires January 17, 2003 [Page 13]