Internet Draft S. Tessier
Document: draft-tessier-mobileip-ipsec-01.txt T-Systems Nova
Expires: June 2003 December 2002
Guidelines for Mobile IP and IPSec VPN Usage
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that oher
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
1. Abstract
This document highlights some of the issues that should be considered
when IPSec [2] and Mobile IP [3] inter-work with each other.
This work finds some applications in the following fields: VPN
traversal requirement [4], IPSec Remote access client co-located
with a Mobile Node, IPSec security Gateway running in parallel with
a Home Agent or a MIP Proxy [5]. The purpose of this document is
informational. Rather that strictly indicating how both protocol
should take advantages of each other (IPSec running on top of Mobile
IP or the other way around), which is a subjective task left to the
user and implementation developers of both protocol, it rather
proposes some usage guidelines and general considerations regarding
the preference of one solution over the other one.
2. Motivation
Mobile IP finds an application as tunneling mechanisms for VPN usage:
IP encapsulation within IP [5] is indeed a tunneling mechanisms.
There is only little change to perform to turn this layer-3 tunneling
mechanism into a layer-3 VPN mechanism, basically encryption. Since
Tessier Expires June 2003 [Page 1]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
IPSecÆs ESP provides encryption, many activities early started to
evaluate the feasibility of a combination of both protocol [6].
More recently, an increasing demand raised from the so-called mobile
VPN area to allow NAT [7] and VPN [3] [8] tunneling for Mobile IP
messages especially but not only control (registration) messages.
This document describes some implication of an Mobile IP and IPSec
integrating picture with regards to network topology and environment.
For more information about VPN usage scenarios the reader is invited
to check the above mentioned references as well as section 3 of [9].
For the sake of conciseness we restrict our discussion to ESP and
confuse the term IPSec Tunnel with ESP encapsulation (In a first
approximation, tunnel mode and transport mode are not distinguished).
More exactly, when talking about IPSec, this document only means IKE
and ESP.
3. Order of Tunneling
There is only two way of co-operation between the IPSec and the
Mobile IP stack: Either the IPSec (ESP) tunnel takes place within the
Mobile IP tunnel or the other way around, meaning that the Mobile IP
tunnel is secured as payload within an ESP tunnel. The following two
sections describe those modes and provides pros and cons for each
method regarding a mobile VPN deployment. It is assumed that bi-
directional tunneling (Mobile IP reverse tunneling) is applied [10].
3.1. IPSec tunnel inside the Mobile IP tunnel
In that case, the tunneling order of figure 1 applies between MN, HA
and IPSec/VPN Gateway. Case 1 and 2 differentiate the type of care-
of-address aquired by the MN, case 1 for co-located care-of-address
and case 2 for FA care-of-address.
<---------Internet--------> <--DMZ--> <--Intranet-->
1. MN([---------------------]VPN GW--------)HA---CN
2. MN[---------]FA([--------]VPN GW--------)HA---CN
[--] IPSec tunnel (--) Mobile IP tunnel
Figure 1: Mobile IP tunnel in IPSec VPN tunnel
The benefit is:
- Seamless mobility due to Mobile IP that means real mobility
support which is the obvious definition of mobile VPNs.
While the drawbacks are:
- Since local networks use usually private addresses, NAPT is a
major problem. A solution like the one described in [7] needs
to be applied
- It prevents integration of Mobile IP in already existing
IPSec-based VPN products
Tessier Expires June 2003 [Page 2]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
- Home FW has to pass through Mobile IP traffic to the HA and
therefore to trust the HA, MN and CN which will be
unacceptable by system administrators.
3.2. Mobile IP tunnel inside the IPSec tunnel
In that case, the tunneling order of figure 2 applies between MN, HA
and IPSec Gateway. Case 1 and 2 differentiate the type of care-of-
address aquired by the MN, case 1 for co-located care-of-address and
case 2 for FA care-of-address. For illustrative purpose, [11]
provides a concrete realization of such a procedure.
<-------Internet------> <----DMZ----> <-Intranet->
1. MN[(------------------FW---)]HA---FW---------CN
2. MN[--------FA(--------FW---)]HA---FW---------CN
[--] IPSec tunnel (--) Mobile IP tunnel
Figure 2: IPSec VPN tunnel in Mobile IP tunnel
The benefits are:
- Authentication with the FA based on AAA is useful for a number
of business models
- NAPT is not a problem for MIP since it is supposed to be
solved by the IPSec tunnel [12]
- Most Hotspots, ISPs etc. provide DHCP-based (care-of)
addresses --> FA are not really a problem
- The home FW has full authority to apply corporate policies to
the Mobile IP data traffic.
While drawbacks are:
- No seamless mobility
- In the case where FA care-of-address is used, security
association needs to be hop-by-hop established
4. Distinction between Mobile IP signaling and data messages
Mobile IP control messages, namely agent advertisements, agent
solicitations, registration requests and registration replies, are
fundamentally different from Mobile IP tunneled packets. Though there
is nothing like a signaling channel in the today Internet for this
kind of message, finding a way to effectively handle them with a
special treatment is a benefit since those critical control messages
condition all the re-routing of Mobile IP.
Considering Mobile IP as a stand alone protocol, this distinction is
evident since registration messages are authorized. Concerns have
also early raised about the fact that discovery messages (agent
advertisement and solicitation) should be made secure i.e. trustful.
But considering the global picture where Mobile IP and IPSec work
together, there could be a subsidiary distinction, regarding the
Tessier Expires June 2003 [Page 3]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
IPSec policy apply to Mobile IP messages according to their nature:
control plane or user plane messages.
An illustrative example of that policy is the following one.
For outbound packets from the Mobile Node IPSec layer:
Apply IPSec to all packet except Mobile IP registration request
For outbound packets from the VPN GW IPSec layer:
Apply IPSec to all packet except Mobile IP registration request
The discrimination rule is done according to the given nature
(Transport Protocol and Port Number) of Mobile IP registration
messages and IPSec SPD is configured appropriately.
This procedure does not add new security threats, with the exception
of location privacy, that is no more ensured, since Mobile IP
registration packets are only authenticated and not cyphered.
Moreover, such a distinction may be needed in some deployment
scenarios: For example, encrypting Mobile IP registration messages
between Mobile Node and VPN Gateway will indeed prohibit Foreign
Agents, if present, to understand them (see the drawbacks of section
3.2.).
5. Cooperation between both tunneling
There is no fundamental motivation for excluding one or the other way
of ordering the IP in IP and the ESP tunneling mechanism in one order
or the other. Section 8 illustrates that the level of security in one
configuration or in the other is the same or at least comparable in
its effective realization.
From a purely design perspective, there is no restriction of applying
IPSec to an IP in IP encapsulated packet. Touch and Eggert already
considered that problematic in [13] and concluded that great
attention should be put on how the IPSec policy is apply, though
their work was not related to Mobile IP itself. Here is quotted a
very useful statement from Annex A:
ôThere are inconsistencies between the IPIP encapsulation rules
specified by IPsec and those specified by Mobile IP. The latter
specification is standards track, and the IP protocol number of 4
(payload of an IP packet of type 4) is assigned by IANA to RFC 2003
[5]. IPsec does not specify any limits on the types of IP packets
which can be secured by transport mode, so the use of IPIP inside an
IPsec transport packet can be confused with IPsec tunnel mode.ö
6. Network Topology
There maybe situation where the network topology itself will dictate
the way how IPSec and Mobile IP should work together.
Tessier Expires June 2003 [Page 4]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
Corporate LANs very often use NAT and therefore private addresses or
non-globally routable addresses. However NA(P)T is a well-known nasty
problem and it might even be impossible to find out a single
unambiguous outer identifier on behalf of NATted hosts [14].
The type (private or public) of the care-of-address and the fact that
this type could be predict by specific usage scenario (type of
visited network, e.g. cellular link, hot-spot) is also a criteria
that should influence the way the Security Association should be
renew/refresh after movement of the end terminal and the subsequent
IP-subnet change.
7. Mobile IPv6 Consideration
Since the problems motivating this document are inherent to IPv4
Mobile IPv4 and since a rough consensus as well as a original design
intention seem both to state that Mobile IPv6 will solve these
problems, no considerations is here made about Mobile IPv6.
[15] provides some guidelines about interaction between IPSec and
Mobile IPv6.
8. Security Considerations
This document consider the usage of IPSec and therefore adopt the
considerations of RFC2401.
The fundamental requirement driving the way both protocol should work
together is security: No new threat should be added in one solution
with regard to the other one.
Table 1 compares both way of cooperation -IPSec in Mobile IP or the
other way around- in a security perspective with the indication of
possible mechanisms used for ensuring given non-exhaustive security
services.
|----------------------------------------------------------------|
| | Mobile IP in IPSec | IPSec in Mobile IP |
|----------------------------------------------------------------|
|Confidentiality | Absolute - ESPÆs | Relative - ESPÆs |
| | cipher algorithm | cipher algorithm |
|----------------------------------------------------------------|
| Privacy | IKE (MM) | None |
|----------------------------------------------------------------|
| Integrity | Absolute û ESPÆs | Relative û ESPÆs |
| | hash algorithm | hash algorithm |
|----------------------------------------------------------------|
| Authentication| Authentication Data | Mobile-Home |
| | field of ESP header |Authentication extension |
|----------------------------------------------------------------|
| Anti-replay | Sequence number | Identification field of |
| | field of ESP header | registration message |
|----------------------------------------------------------------|
Table 1: Security services provided by both solutions
Tessier Expires June 2003 [Page 5]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
Note that privacy is here to be understood in the sense of identity
protection. Note that Mobile IP differentiates between control plane
and user plane packets and that without IPSec, security services are
only provided to control plane packets.
A deeper analyze is needed before drawing any conclusion (besides the
fact that the author does not consider himself as a security expert)
whether one solution could be more secure than the other but it
should already be clear that the mechanisms themselves are comparable
in their realization e.g. in both cases ESP is used for
confidentiality.
Indeed, the future task could be answering the following question:
Does an IP-in-IP encapsulation eliminate the security benefits
provided by ESP?
The following statement should be considered: Mobile IP should
leverage off of the developments of IPSec rather than developing its
own security framework.
9. References
[1] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January
2002.
[3] Adrangi, F., Leung, K., Kulkarni, M., Patel, A., Zhang, Q., Lau.,
J. ôProblem Statement and Requirements for Mobile IPv4 Traversal
Across VPN Gatewaysö draft-ietf-mobileip-vpn-problem-statement-00.txt
(work in progress), March 2002.
[4] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A., Zhang,
Q., Lau, J. ôMobile IPv4 Traversal Across IPsec-based VPN Gatewaysö
draft-adrangi-mobileip-vpn-traversal-02.txt (work in progress), June
2002.
[5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[6] The Portland State University Secure Mobile Networking Project,
http://www.cs.pdx.edu/research/SMN/.
[7] Levkowetz, H. and Vaarala, S., ôMobile IP NAT/NAPT Traversal
using UDP Tunnellingö draft-ietf-mobileip-nat-traversal-04.txt (work
in progress), May 2002.
[8] Sjostrand, H. and Levkowetz, H., ôMobile IP and Virtual Private
Networks Problem Statementö draft-sjostrand-mobileip-vpn-problem-
stat-00.txt (work in progress), February 2002.
Tessier Expires June 2003 [Page 6]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
[9] Kelly, S., Ramamoorthi, S., ôRequirements for IPsec Remote Access
Scenariosö draft-ietf-ipsra-reqmts-05.txt (work in progress), March
2002.
[10] Montenegro, G., et al., ôReverse Tunneling for Mobile IPö,
revised, RFC3024, January 2001.
[11] M. Danzeisen, T. Braun: Access of Mobile IP Users to Firewall
Protected VPNs, Mobile Communication over Wireless LAN, Workshop at
Informatik 2001, Vienna, September 26-29, 2001.
[12] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf-
ipsec-nat-reqts-02.txt (work in progress), August 2002.
[13] Touch, J. and Eggert, L., ôUse of IPSec Transport Mode for
Dynamic Routingö draft-touch-ipsec-vpn-04.txt (work in progress),
June 2002.
[14] Daigle, L. and IAB, ôIAB Considerations for UNilateral Self-
Address Fixing(UNSAF)Across Network Address Translationö, RFC 3424,
November 2002.
[15] Arko, J., Devarapalli, V., Dupont, F., "Using IPsec to Protect
Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
draft-ietf-mobileip-mipv6-ha-ipsec-01.txt (work in progress),
October 2002.
10. Acknowledgments
The author would like to overall thank the authors of the references
listed above for their help in better understanding the problematic
of IPSec use in conjunction with Mobile IP.
11. Author's Addresses
Serge Tessier
T-Systems Nova GmbH
Berkom
Goslarer Ufer 35, D-10589 Berlin, Germany
Phone: +49 (30) 34 97-31 14
Email: serge.tessier@t-systems.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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
Tessier Expires June 2003 [Page 7]
Internet Draft Guidelines for Mobile IP and IPSec Usage December 2002
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.
Tessier Expires June 2003 [Page 8]