Network Working Group S. Vaarala (Ed.)
Internet-Draft Netseal
Expires: July 2, 2003 N. Baider
Check Point
G. Dommety
E. Gelasco
M. Kulkarni
Cisco
F. Adrangi
Intel
H. Levkowetz
ipUnplugged
Q. Zhang
Liqwid
D. Gellert
Nokia
January 2003
Mobile IPv4 Traversal Across IPsec-based VPN Gateways
draft-ietf-mobileip-vpn-problem-solution-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 July 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 1]
Internet-Draft MIPv4-VPN January 2003
Abstract
This document outlines the proposed solutions and pro/con analysis
for the Mobile IPv4 and IPsec coexistence problem for enterprise
users. The intent is to first document existing analysis, and in a
later version move towards a single solution for IPv4.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Related work . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Terms and abbreviations . . . . . . . . . . . . . . . . . 4
2. Proposed solutions . . . . . . . . . . . . . . . . . . . . 5
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Dual HA (draft-nuopponen-vaarala-mipvpn-00) . . . . . . . 5
2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 Security concerns . . . . . . . . . . . . . . . . . . . . 7
2.3 Optimized dual HA
(draft-adrangi-mobileip-mipvpn-traversal-00) . . . . . . . 8
2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Use of Mobile IP signaling to VPN gateway (route
optimization) . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02) . . . 12
2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6 Making VPN GW accept outer IP changes . . . . . . . . . . 14
2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . 14
2.6.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Use IPsec instead of GRE/IP-IP for MIP tunnelling . . . . 16
2.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . 16
2.7.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 16
2.8 Host routing and end-to-end security . . . . . . . . . . . 17
2.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . 17
2.8.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Explicit signaling to update IPsec endpoint . . . . . . . 18
2.9.1 Description . . . . . . . . . . . . . . . . . . . . . . . 18
2.9.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 18
2.10 Use Foreign Agent to route ESP . . . . . . . . . . . . . . 18
2.10.1 Description . . . . . . . . . . . . . . . . . . . . . . . 18
2.10.2 Pros/cons . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Intellectual property rights . . . . . . . . . . . . . . . 20
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . 22
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 2]
Internet-Draft MIPv4-VPN January 2003
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . 25
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 3]
Internet-Draft MIPv4-VPN January 2003
1. Introduction
The Mobile IP working group started a design team to explore the
problem and solution spaces of IPsec and Mobile IP coexistence. The
problem statement and solution requirements for Mobile IPv4 case was
first documented in [1]. The design team then set out to evaluate
solution candidates and ultimately arrive at a solution draft.
The current version of this document outlines the solutions and the
pro/con analysis of each solution done by the design team. Most of
the material is from the design team mailing list and from conference
calls. The intent is to first document existing analysis, and in a
later version move towards a single solution for IPv4.
1.1 Related work
Related work has been done on Mobile IPv6 in [2] which discusses the
interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6
signalling. The draft also discusses dynamic updating of the IPsec
endpoint based on Mobile IP signaling packets.
There has also been discussion on the IPsec mailing list about
updating the IPsec endpoint when packets arrive from a new address.
When NAT traversal is used, an update of the UDP port for NAT
traversal is also required.
The "transient pseudo-NAT" attack, described in [3] and [4], affects
any approach which attempts to provide security of mobility
signalling in conjunction with NAT devices. In many cases, one
cannot assume any co-operation from NAT devices which thus have to be
treated as "adversaries" of a sort.
1.2 Scope
This document only covers a solution for IPv4.
1.3 Terms and abbreviations
TBD.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 4]
Internet-Draft MIPv4-VPN January 2003
2. Proposed solutions
2.1 Overview
Multiple solution candidates have been identified by the design team.
Some have been described in drafts while others on the mailing list
or in face-to-face meetings.
The sections correspond to originally identified proposals (in
previous design team discussion) as follows:
o Option 1.1: Section 2.2.
o Option 1.2: Section 2.3.
o Option 1.3: Section 2.4.
o Option 2: Section 2.5.
o Option 3: Section 2.6.
o Option 4: Section 2.7.
o Option 5: Section 2.8.
o Option 6: Section 2.9.
o Option 7: Section 2.10.
2.2 Dual HA (draft-nuopponen-vaarala-mipvpn-00)
2.2.1 Description
The basic idea of this approach is to use three layers of tunnelling
when the mobile node is outside the trusted network and has to go
through a VPN to gain access. The outermost layer is "external
Mobile IP", the middle layer is IPsec, and the innermost layer is
"internal Mobile IP". Two home agents are required, one for the
internal Mobile IP and another for the external Mobile IP.
The solution has been documented in [5].
2.2.2 Pros/cons
Pros:
o Does not require specification of new protocols (but an algorithm
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 5]
Internet-Draft MIPv4-VPN January 2003
for secure detection of the trusted network is still required).
o Does not require changes to VPN gateway (except to allow Mobile IP
traffic to pass).
o Doesn't require new functional entities.
o Is a clean solution from protocol perspective.
o Doesn't require removing or disabling the SA as MN moves from
outside to inside the firewall (compare to optimized dual HA
solution which has this requirement).
o Although MN software needs to be changed, existing HA/FA elements
can be used because no protocol changes are required.
Cons:
o Software complexity resulting from running two instances of MIP
layer. For instance, the following complexities may apply to
Microsoft Windows:
1. Layering and ordering of MIP layers in a standard way (i.e.,
using standard filterclass values) could be an issue in
Windows NDIS network architecture.
2. Not using standard NDIS filterclass values to do layering and
ordering of the MIP layers, could have implications in getting
the driver to be signed by Microsoft.
3. Implementing the solution for Microsoft IPsec client becomes
very complicated, as TCP/IP and IPsec are combined into one
layer. This means that the upper MIP layer has to be placed
above MS TCP/IP! Note: Corporate ITs are moving towards
replacing vendor IPsec clients with MS IPsec clients to reduce
overhead and cost in customer support and software
distribution. VPN vendors also like the idea as it reduces
their development, deployment, and support cost.
o Packet Overhead - 20 bytes due to additional MIP layer, though
this was not considered critical.
o Routing inefficiencies - MIP traffic always traverse inside the
firewall. Consider two MNs communicating outside the firewall,
their traffic will have to route to the internal HA and back to
outside the firewall.
o MIP layer has to somehow query the VPN client for TIA (Tunnel
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 6]
Internet-Draft MIPv4-VPN January 2003
Inner Address), which is most likely assigned by the VPN gateway.
o The solution will not work where VPN gateway does NATing before it
sends the decrypted packet inside. This is common in deployments
where VPN client uses the care-of address as both tunnel inner and
outer addresses. To get around this problem, the internal HA MUST
implement MIP NAT extension.
o Content scanning and filtering in the VPN or a separate firewall
may block internal MIP traffic (which is IP-IP or IP-over-UDP
encapsulated).
o In summary, the most important concern is the software complexity
which may prevent implementation and deployment of the solution
for certain IPsec client architecture (e.g. Microsoft Windows).
2.2.3 Security concerns
MIPv4 and IPsec have different goals and approaches for providing
security services. MIPv4 typically uses a shared secret for
authentication of (only) signalling traffic, while IPsec typically
uses IKE (an authenticated Diffie-Hellman exchange) to set up session
keys. Thus, the overall security properties of a combined MIPv4 and
IPsec system depend on both mechanisms.
In a "dual HA" solution the external MIPv4 layer provides mobility
for IPsec traffic. If the security of MIPv4 is broken in this
context, traffic redirection attacks against the IPsec traffic are
possible. However, such routing attacks do not affect other IPsec
properties (confidentiality, integrity, replay protection, etc),
because IPsec does not consider the network between two IPsec
endpoints to be secure in any way.
Because MIPv4 shared secrets are usually configured manually, they
may be weak if easily memorizable secrets are chosen, thus opening up
redirection attacks described above.
Assuming the MIPv4 shared secrets have sufficient entropy, there are
still at least the following differences and similarities between
MIPv4 and IPsec worth considering:
o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT"
attack described in [3] and [4], assuming that NAT traversal is
enabled (which is typically the case).
o When considering a "pseudo NAT" attack against standard IPsec and
standard MIP (with NAT traversal), redirection attacks against MIP
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 7]
Internet-Draft MIPv4-VPN January 2003
may be easier because:
* MIPv4 re-registrations typically occur more frequently than
IPsec SA setups (although this may not be the case for mobile
hosts).
* It suffices to catch and modify a single registration request,
whereas attacking IKE requires that multiple IKE packets are
caught and modified.
o There may be concerns about mixing of algorithms. For instance,
IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC-
MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Furthermore,
while IPsec algorithms are typically configurable, MIPv4 clients
typically use only HMAC-MD5 or prefix+suffix MD5. Although this
is probably not a security problem as such, it is more difficult
to communicate.
o When IPsec is used with a PKI, the key management properties are
superior to those of basic MIPv4. Thus, adding MIPv4 to the
system makes key management more complex.
o In general, adding new security mechanisms increases overall
complexity and makes the system more difficult to understand.
2.3 Optimized dual HA (draft-adrangi-mobileip-mipvpn-traversal-00)
2.3.1 Description
The main motivation behind this solution is to eliminate the double
MIP encapsulation, which in turn eliminates the extra 20 byte
overhead. This is done to mainly reduce the software complexity as
the dual HA solution requires dual Mobile IP layer running on the
client.
In a sense, the VPN incorporates some FA features, in particular
detunneling of IP-IP -- consider the VPN tunnel as a "private link"
between an MN and an FA, capable of exchanging packets which use the
MN's home address. However, this analogy is not complete because
there is no FA advertisement support and the VPN does not participate
in the registration directly.
The proposal is described in [6].
2.3.2 Pros/cons
Pros:
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 8]
Internet-Draft MIPv4-VPN January 2003
o Optimizes 20 bytes of packet overhead compared to "basic dual HA"
when MN is outside.
o When two MNs which are outside communicate with each other,
traffic does not go through the HA(s).
* Comment: Is this desireable? The HA may be used as a policy
enforcement point, and this mechanism bypasses the HA.
* Comment: The draft could be applied without bypassing the HA,
so this is just an option.
o Client network stack architecture may be easier (than in basic
dual HA solution) in some cases, as only one actual MIP layer
(underneath IPsec) is required.
* When MN outside, the inner MIP registration can be sent using a
normal UDP socket. In other words, there *are* two MIP layers,
but only one IP-IP encaps/decaps layer.
* This advantage is pronounced when the IPsec implementation is
built into the TCP/IP stack and packet interception between the
IPsec and the TCP/IP is difficult. For instance, consider
Windows 2000/XP IPsec implementation.
o Because the VPN sees MN traffic in unencapsulated form (and is
required to decapsulate encapsulated traffic), content scanning
and NATing are not a problem.
Cons:
o The client requires a rather broad MIP/VPN "coexistence API".
Since we're not specifying this API, the promise of multi-vendor
solutions may not be actually realized (i.e. there will be a de
facto API, or vendor specific APIs, etc).
o The VPN software needs a software upgrade (both VPN client and VPN
gateway).
* If the vendor does not yet have a patch, or decides that it
will not implement a patch, the customer has to change VPN
vendor to take advantage of this solution. This goes against
preserving existing investment (in some cases).
* Even if a patch is available, there is a coupling between MIP
and VPN vendors, as the MIP vendor needs to deal with various
VPNs and their software upgrades. This goes against
independence of MIP and VPN solutions; ideally MIP and VPN
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 9]
Internet-Draft MIPv4-VPN January 2003
deployments should not interfere.
* Note, however, that even the basic "dual HA" solution may
require a VPN patch or at least reconfiguration. Consider for
instance VPN devices that perform stateful session tracking
etc. Although these are not part of the IPsec specifications,
such configurations exist.
o MIP and IPsec are tightly bound in the solution, which may not be
architecturally wise. Layering violations often manifest as
subtle problems later.
o The MN needs to know the VPN private interface address when
outside.
* This is a piece of information that may or may not be available
in a "standard IPsec implementation". There is no standard for
getting this information -- hence a solution would either use a
proprietary protocol or manual configuration. Neither seems
appealing.
* What if the VPN private interface address changes -- e.g. the
admin changes network numbering? How are the MNs informed? If
manual config is used, do all MNs need to be reconfigured
manually?
* What if multiple routes to intranet are used (i.e. there are
multiple private interfaces)? Should all such addresses be
given to the MN? If so, which address should the MN use?
Should the MN and the VPN dynamically negotiate this somehow?
o The VPN routing is quite complex. Routing decisions need to be
based on existence of IPsec SAs -- a packet destined to an
intranet address is either (a) sent to the intranet if there is no
SA for the host (host is in intranet or does not exit), or (b)
sent to the internet using an IPsec SA because an SA exists.
* In other words, existence of an SA is taken to imply that the
MN is outside, which may not be a sound assumption, and not
rooted in the IPsec specs. As a result, the MN is required to
delete all IPsec SAs (on the VPN gateway) when it returns to
the intranet; otherwise packets from other MNs which are
outside end up in a black hole.
* IP-IP decapsulation + subsequent IPsec SA application may not
be easy in all VPN architectures.
* However, some VPN vendors have indicated that this change is no
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 10]
Internet-Draft MIPv4-VPN January 2003
big deal to them. If this generalizes to a vast majority of
VPN implementations, then perhaps this is not such a big
concern.
o The fact that IPsec SA deletion is mandatory raises a few further
requirements:
* IKE DELETE must be supported; not all vendors support that
now.
* What if the MN crashes? The MN must use INITIAL-CONTACT to
flush out any SAs used before the crash; this in turn requires
support from the VPN, and places more requirements on the
client API.
* The MN must be able to send the IKE DELETE to the VPN public
address *from the intranet*. Sometimes firewalls do not allow
this, which raises new firewall requirements.
o IPsec SA deletion also implies that in a scenario where the MN (1)
first sets up an SA, (2) goes back inside (deleting SAs), then (3)
goes back outside, the MN is (unnecessarily) required to
reauthenticate. This is emphasized when IPsec uses legacy
authentication and requires user interaction during
authentication.
* Although many VPN vendors use keepalives and delete inactive
SAs, there's nothing in the IPsec specs to prevent one from
reusing existing SAs even after a period of inactivity.
* Thus there is no IPsec reason not to pick up old SAs when the
MN goes back outside (remember that the MN may be inside only
for a few minutes in some cases; the proposed approach
requires SA deletion in all cases).
o Handling of non-unicast packets requires non-standard use of the
"D"-bit in the RRQ (see Section 2.2.2.1). (Does the same apply to
GRE?)
o Dynamic home address allocation is complicated, as the draft
assumes that the (internal) home address is known when setting up
an IPsec tunnel. The draft requires a two-phase solution where an
IPsec SA with "any" address is established first (in order to get
the home address), and then a new IPsec SA is established.
The security considerations described in Section 2.2.3 apply to this
proposal as well.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 11]
Internet-Draft MIPv4-VPN January 2003
2.4 Use of Mobile IP signaling to VPN gateway (route optimization)
2.4.1 Description
Use of Mobile IP signaling to VPN gateway (use of Update message to
update the MN binding).
2.4.2 Pros/cons
Pros:
o Works well even if there is a outside HA (by another
party/operator).
Cons:
o New MIPv4 functionality on VPN gateway (but only route
optimization part of MIPv4).
o Need to consider the route optimization draft which has a lot of
other things.
2.5 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02)
2.5.1 Description
The proposed Mobile IPv4 proxy solution is described in [7]. A quote
from the draft summarizes the idea:
This draft introduces a logical component called the Mobile IP
Proxy (MIP Proxy) to enable seamless Mobile IPv4 functionality
across VPN gateways, without requiring any IPsec VPN protocol
changes to VPN gateways. The solution aims specifically at
extending the use of deployed IPsec-based VPN gateways, a feature
that is much desired by corporate IT departments. The solution
also leverages [11] to support Mobile traversal across "NAT and
VPN" gateways. The "NAT and VPN" refers to a network topology
where Mobile IP traffic has to traverse one or more NAT gateway(s)
followed by a VPN gateway in the path to its final destination.
While the discussion in this draft is limited to IPsec-based VPN
gateways, it should be compatible with other IP-based VPN
solutions as well.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 12]
Internet-Draft MIPv4-VPN January 2003
2.5.2 Pros/cons
Pros:
o Uses standard (single mode) mobile IP client.
* MIP client will run only one MIP layer and still enable
seamless VPN traversal.
* MIP layer is inserted below the VPN layer. This is an
advantage given that most operating systems will allow it.
Insertion above the VPN layer is in general more complicated at
least in multi-vendor solutions.
o Tunneling overhead:
* MIP proxies will keep the Mobile IP tunneling overhead at a
minimum, that is, Mobile IP tunneling for a single MIP layer.
Cons:
o Assumes that the VPN client and Mobile IP client use the same IP
address (MN-Perm).
* This is complicated in most if not all operating systems and
will require close integration between the VPN client and the
MIP client. VPN clients that use specific VPN adapters are one
example. These adapters are usually enabled when the tunnel is
established, and disabled when the tunnel goes down. Since MN-
Perm is used for application binding too, the VPN adapter
scheme used by numerous VPN solutions must be handled in a
different way.
* In addition, there is a problem on the server side since both
VPN gateway and Internal HA needs control over the same IP
address. There are interesting ARP issues related to this.
o New Mobile IP entity, i.e. MIP Proxy:
* MIP proxy will require a lengthy standardization process.
* Support for new HA parameter extension is necessary to convey
the IP address of the internal HA.
* An additional entity will only add to the installation
complexity of Mobile IP systems.
* MIP Proxies must be deployed in the DMZ. In larger
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 13]
Internet-Draft MIPv4-VPN January 2003
organization, this can be a problem due to limited scalability
regarding the number of users and the overall performance.
* Enterprises can not leverage public Mobile IP services.
o Requires specific DMZ setup and network design:
* The traffic paths for incoming and outgoing traffic are
asymmetric and complicated with impact on DMZ routing. In
addition, there are non-trivial L2-switching/L3-routing issues
in both the VPN gateway and MIP proxy to make the scheme work.
* The security depends on DMZ firewall configuration and routing.
* Non-trivial firewall rules for inner and outer FW are necessary
to make the scheme work properly.
o Upgrade/transition path to IPv6:
* There are no evident upgrade or transition paths to Mobile
IPv6. It will be very hard to run different IP versions on
both sides of the MIP proxy. The surrogate operation is
already non-trivial and the translation will be even harder in
a IPv4/IPv6 MIP proxy.
o To summarize, the biggest concerns are introduction of a new
entity and the use of a common MN-Perm address. At the moment,
this will make it very hard to implement a multi-vendor client
solution use existing VPN solutions. This can probably be handled
by the VPN vendors, but it will take time and effort to do it.
o Applicability in enterprises with distributed or redundant VPN
gateway solutions may be an issue.
2.6 Making VPN GW accept outer IP changes
2.6.1 Description
The suggestion is for the VPN GW to detect changes in the source IP
address of the incoming IPsec packets coming from the MN, and send
IPsec packets to the updated address. The primary IP address to be
used, is the one the IKE negotiation came from. If that IP changes,
it is assumed that this is because the MN IP address or care-of-
address has changed.
A related idea is updating the UDP source port when doing IPsec NAT
traversal. This idea has also been suggested on the IPsec mailing
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 14]
Internet-Draft MIPv4-VPN January 2003
list.
2.6.2 Pros/cons
Pros:
o It is the quickest way to change IP.
o No registration is required.
o No dual HA is required, just a single instance of MIPv4.
o It is difficult to break as it is difficult to fake a legally
encrypted and authenticated IPsec packet.
o Even if, in some way, a bogus IPsec packet succeeds to change what
the GW sees as the MN care-of-address, the next packet from the MN
to the GW will reinstate the proper address.
Cons:
o The "Security Architecture for the Internet Protocol" RFC (2401)
states:
* A security association is uniquely identified by a triple
consisting of a Security Parameter Index (SPI), an IP
Destination Address, and a security protocol (AH or ESP)
identifier.
o It is probably commonly assumed that the IP Destination Address is
the external IP header destination, while the current proposal
suggests changing it. It is not clear, however, if the security
benefit of fixing the destination IP is significant. It is also
possible to consider the tunnel internal IP as the fixed
destination IP, which alleviates the need to modify the RFC
definition.
o If the MN changes it's care-of-address, and no traffic is going
from the MN to the VPN GW at that time, it may be required to send
an IPsec packet to the GW just for the update. Doesn't sound so
bad, but yet another design consideration.
Open:
o Is this implemented in majority of VPNs?
o Does this break IPsec?
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 15]
Internet-Draft MIPv4-VPN January 2003
o Is this within the purview of IPsec?
o Can we make this a recommendation for VPN gateways?
2.7 Use IPsec instead of GRE/IP-IP for MIP tunnelling
2.7.1 Description
The general idea is that instead of IP-IP or GRE (or minimal
encapsulation) provided by Mobile IPv4 at the moment, IPsec tunneling
would be used in place of IP-IP. IPsec tunneling provides the same
functionality as IP-IP tunneling so this should be reasonable
straightforward.
MN --------- FA ------------------- HA -------- CN
MN using FA CoA |======================|
IPSec Tunnel
MN using CCoA |====================================|
IPSec Tunnel
The mobility agents and their placement is as shown in the figure
above. MN can use either FA CoA or Collocated COA as shown above and
hence there will be two cases of IPSec tunnel.
2.7.2 Pros/cons
Pros:
o Mobility and security are logically at the same level of the
protocol stack. This approach combines the two and hence makes
the system design simple.
o No extra tunneling overhead (IP-IP or GRE).
Cons:
o When MN uses FA CoA, the IPSec tunnel is between HA and FA. HA to
FA traffic is encrypted, but the data goes in clear between MN and
FA.
o The above problem can be fixed if the IPSec tunnel is between MN
and HA, then all the traffic is encrypted. But it creates another
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 16]
Internet-Draft MIPv4-VPN January 2003
problem. When the MN changes CoA, the IPSec tunnel end-point
changes, terminating the IPSec tunnel. IKE re-negotiation must
take place between the HA and the new CoA. This will lead to
sessions getting dropped, not to mention more IKE overheads due to
frequent MN movements.
o When the FA and HA are not in the same administrative domain,
deployment issues may arise because FA and HA can not share
credentials. That means IKE/IPSec between HA and FA can't work.
o This is a new functionality involving all mobility agents. Hence
change is required in the implementation of HA, FA and MN.
2.8 Host routing and end-to-end security
2.8.1 Description
The general idea was to use some sort of "full" or "partial" (i.e.
only some routers support) host routing when the mobile node is
outside. (The idea is similar to the Cellular IP and HAWAII
approaches for limited host routing.)
2.8.2 Pros/cons
Pros:
o No change to IPsec.
o No extra packet overhead.
Cons:
o Deviation from Mobile IP. Basically we invent a modified mobility
management mechanism.
o Security model unknown.
o Overlapping IP addresses are harder to accommodate.
o Route convergence and route explosion for large number of mobiles,
especially if moving between two access types.
o Distributed solution, hard to manage.
General feeling: too much deviation from Mobile IP, impractical.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 17]
Internet-Draft MIPv4-VPN January 2003
2.9 Explicit signaling to update IPsec endpoint
2.9.1 Description
This proposal is essentially the same as Section 2.6 except that
explicit signalling is used to update IPsec SA endpoints. The form
of signalling could be e.g. Mobile IP messages.
2.9.2 Pros/cons
Open:
o What are the security considerations to IPsec?
o Is this within purview of IPsec?
o Is it acceptable to make recommendations to VPN gateway
implementations?
2.10 Use Foreign Agent to route ESP
2.10.1 Description
Referring to Figure 11 of the problem statement [1], the problem is
that the FA cannot understand MIP signalling because it is
encapsulated inside IPsec. Thus we add some signalling to IPsec
which gives the FA the information it would otherwise get through MIP
signalling.
A brief analysis of this is that this in effect, if not in exact
implementation, would be equivalent to wrapping the IPsec inside
another layer of MIP, to get the relevant signalling through to the
FA.
There are at least two approaches:
o Add signalling to the IPsec protocol, and at the same time add
functionality to the FA and VPN-GW to make them understand the
signalling. This signalling would replicate equivalent MIP
signalling but within IPsec.
o Wrap IPsec inside a MIP tunnel which carries the signalling
between FA and VPN-GW. However, this alternative is the "dual HA"
solution.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 18]
Internet-Draft MIPv4-VPN January 2003
2.10.2 Pros/cons
Pros:
o No new overhead to IPsec, but functionality similar to wrapping
IPsec inside MIP.
o Would allow (modified) FAs to be used, to conserve address space,
etc.
Cons:
o Makes two currently independent protocols (MIPv4 and IPsec)
dependent.
o Introduces changes to FA, VPN gateway, and the IPsec protocol.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 19]
Internet-Draft MIPv4-VPN January 2003
3. Intellectual property rights
Design team members were still investigating possible IPR issues when
this draft was submitted. More detail will be presented in later
versions of the draft.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 20]
Internet-Draft MIPv4-VPN January 2003
4. Acknowledgements
The authors would like to thank MIP/VPN design team, especially
Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung,
Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti
Nuopponen, Alan O'neill, Gaetan Feige, Brijesh Kumar for their
continuous feedback and helping us improve this draft.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 21]
Internet-Draft MIPv4-VPN January 2003
References
[1] Adrangi, F., Kulkarni, M., Dommety, G., Gelasco, E., Zhang, Q.,
Vaarala, S., Gellert, D., Baider, N. and H. Levkowetz, "Problem
Statement and Solution Guidelines for Mobile IPv4 Traversal
Across IPsec-based VPN Gateways (draft-ietf-mobileip-vpn-
problem-statement-guide-00e, work in progress)", January 2003.
[2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in
progress)", October 2002.
[3] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how
NATs are even more evil than you believed (draft-dupont-
transient-pseudonat-01, work in progress)", December 2002.
[4] Levkowetz, H. and S. Vaarala, "Mobile IP NAT/NAPT Traversal
using UDP Tunnelling (draft-ietf-mobileip-nat-traversal-07, work
in progress)", November 2002.
[5] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with
IPsec remote access tunnelling (draft-nuopponen-vaarala-mipvpn-
00, work in progress)", July 2002.
[6] Adrangi, F., Iyer, P., Zhang, Q. and N. Baider, "Mobile IPv4
Traversal Across IPsec-based VPN Gateways (draft-adrangi-
mobileip-mipvpn-traversal, work in progress)", January 2003.
[7] Adrangi, F., Iyer, P., Leung, K., Kulkarni, M., Patel, A.,
Zhang, Q. and J. Lau, "Mobile IPv4 Traversal Across IPsec-based
VPN Gateways (draft-adrangi-mobileip-vpn-traversal-02)", July
2002.
Authors' Addresses
Sami Vaarala
Netseal
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 22]
Internet-Draft MIPv4-VPN January 2003
Nitsan Baider
Check Point Software Technologies, Inc.
Gopal Dommety
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: gdommety@cisco.com
Eli Gelasco
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: egelasco@cisco.com
Milind Kulkarni
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Phone: +1 408-527-8382
EMail: mkulkarn@cisco.com
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR
USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 23]
Internet-Draft MIPv4-VPN January 2003
Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 8 725 9513
EMail: henrik@levkowetz.com
Qiang Zhang
Liqwid Networks, Inc.
1000 Wilson Blvd, Suite 900
Arlington, VA 22209
USA
Phone: +1 703-224-1120 -x 203
EMail: qzhang@liqwidnet.com
Dorothy Gellert
Nokia Corporation
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 24]
Internet-Draft MIPv4-VPN January 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Vaarala (Ed.), et al. Expires July 2, 2003 [Page 25]
