Network Working Group S. Vaarala (Ed.)
Internet-Draft Netseal
Expires: October 8, 2003 April 9, 2003
Mobile IPv4 Traversal Across IPsec-based VPN Gateways
draft-ietf-mobileip-vpn-problem-solution-01
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 October 8, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document outlines the proposed solution for the Mobile IPv4 and
IPsec coexistence problem for enterprise users. The solution
consists of: an applicability statement for using Mobile IPv4 and
IPsec for session mobility in corporate remote access scenarios; a
required mechanism for detecting the trusted internal network
securely; and optional mechanisms for IPsec and Mobile IPv4 to
optimize overhead of the solution. The basic solution requires only
changes to the mobile node; changes to Mobile IPv4 or IPsec are not
required.
Vaarala (Ed.) Expires October 8, 2003 [Page 1]
Internet-Draft MIPv4-VPN April 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Terms and abbreviations . . . . . . . . . . . . . . . . . . 7
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Access modes . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Access mode: 'vc' (optional) . . . . . . . . . . . . . . . . 13
3.4 Access mode: 'vf' (optional) . . . . . . . . . . . . . . . . 14
3.5 Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . . 15
3.6 Access mode: 'cvf' (optional) . . . . . . . . . . . . . . . 15
3.7 Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . . 16
3.8 Access mode: 'fvf' (optional) . . . . . . . . . . . . . . . 16
3.9 NAT traversal . . . . . . . . . . . . . . . . . . . . . . . 17
4. Internal network detection . . . . . . . . . . . . . . . . . 18
4.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Implementation requirements . . . . . . . . . . . . . . . . 19
4.2.1 Registration-based internal network detection . . . . . . . 19
4.2.2 Registration-based internal network monitoring . . . . . . . 19
4.2.3 Connection status change . . . . . . . . . . . . . . . . . . 20
4.2.4 Handling of network interfaces . . . . . . . . . . . . . . . 21
4.3 Proposed algorithm . . . . . . . . . . . . . . . . . . . . . 21
4.4 Implementation issues . . . . . . . . . . . . . . . . . . . 22
4.5 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5.1 Firewall configuration requirements . . . . . . . . . . . . 23
4.5.2 Registration-based internal network monitoring . . . . . . . 23
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Mobile node requirements . . . . . . . . . . . . . . . . . . 24
5.2 VPN device requirements . . . . . . . . . . . . . . . . . . 24
5.3 Home agent requirements . . . . . . . . . . . . . . . . . . 25
6. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1 Comparison against guidelines . . . . . . . . . . . . . . . 26
6.2 Packet overhead . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Firewall state considerations . . . . . . . . . . . . . . . 30
6.4 Implementation of mobile node . . . . . . . . . . . . . . . 30
6.5 IPsec endpoint update vs. zero-overhead MIP tunnelling . . . 31
6.6 Non-IPsec VPN protocols . . . . . . . . . . . . . . . . . . 32
6.7 Miscellaneous issues . . . . . . . . . . . . . . . . . . . . 32
Vaarala (Ed.) Expires October 8, 2003 [Page 2]
Internet-Draft MIPv4-VPN April 2003
7. Security considerations . . . . . . . . . . . . . . . . . . 33
7.1 Detection of internal/external network . . . . . . . . . . . 33
7.2 Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . . 33
7.3 Optional mechanisms . . . . . . . . . . . . . . . . . . . . 34
8. Intellectual property rights . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
References . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . 38
A. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B. Optional mechanism: FA in VPN device . . . . . . . . . . . . 40
B.1 Capability negotiation . . . . . . . . . . . . . . . . . . . 42
B.2 Foreign agent advertisement . . . . . . . . . . . . . . . . 42
B.3 New SA attribute . . . . . . . . . . . . . . . . . . . . . . 42
B.4 Registration . . . . . . . . . . . . . . . . . . . . . . . . 43
B.5 VPN packet processing . . . . . . . . . . . . . . . . . . . 43
B.6 Dynamic home address allocation . . . . . . . . . . . . . . 44
B.7 IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
B.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
C. Optional mechanism: IPsec SA endpoint update . . . . . . . . 46
C.1 Capability negotiation . . . . . . . . . . . . . . . . . . . 47
C.2 New SA attribute . . . . . . . . . . . . . . . . . . . . . . 47
C.3 SA endpoint update . . . . . . . . . . . . . . . . . . . . . 48
C.4 Security considerations . . . . . . . . . . . . . . . . . . 48
C.5 IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
D. Optional mechanism: Zero-overhead MIPv4 tunnelling . . . . . 49
D.1 Capability negotiation . . . . . . . . . . . . . . . . . . . 49
D.2 Packet processing . . . . . . . . . . . . . . . . . . . . . 49
E. Proposed solutions . . . . . . . . . . . . . . . . . . . . . 51
E.1 Dual HA (draft-nuopponen-vaarala-mipvpn-00) . . . . . . . . 51
E.1.1 Security concerns . . . . . . . . . . . . . . . . . . . . . 53
E.2 Optimized dual HA
(draft-adrangi-mobileip-mipvpn-traversal-00) . . . . . . . . 54
E.3 Use of Mobile IP signaling to VPN gateway (route
optimization) . . . . . . . . . . . . . . . . . . . . . . . 57
E.4 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02) . . . . 58
E.5 Making VPN GW accept outer IP changes . . . . . . . . . . . 60
E.6 Use IPsec instead of GRE/IP-IP for MIP tunnelling . . . . . 61
E.7 Host routing and end-to-end security . . . . . . . . . . . . 62
E.8 Explicit signaling to update IPsec endpoint . . . . . . . . 63
E.9 Use Foreign Agent to route ESP . . . . . . . . . . . . . . . 63
Full Copyright Statement . . . . . . . . . . . . . . . . . . 65
Vaarala (Ed.) Expires October 8, 2003 [Page 3]
Internet-Draft MIPv4-VPN April 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 proposed solution
for IPv4. Some details are yet to be decided, and are documented as
such. Previous approaches are retained in the appendix.
This document contains three parts:
o a basic solution which is an applicability statement of Mobile
IPv4 and IPsec to provide session mobility between internal and
external networks, intended for enterprise mobile users;
o a technical specification and a set of requirements for secure
detection of the internal and the external networks; and
o technical specifications to improve the basic solution in several
dimensions, such as packet overhead, handover latency, and
installation complexity.
The basic solution places only requirements on the implementation of
the mobile node. The suggested optional mechanisms are extensions of
the VPN device or the home agent(s), and are automatically negotiated
when available.
The optional mechanisms are described in the Appendix. At this
stage, the mechanisms are strawmen to provide some concreteness, and
will be later moved off to separate drafts, or dropped completely.
1.1 Overview
Typical corporate networks consist of three different domains: the
Internet (untrusted external network), the intranet (trusted internal
network), and the DMZ, which connects the two networks. Access to
the internal network is guarded both by a firewall and a VPN device;
access is only allowed if both firewall and VPN security policies are
respected.
Enterprise mobile users benefit from unrestrained seamless session
mobility between subnets, regardless of whether the subnets are part
of the internal or the external network. Unfortunately the current
Mobile IPv4 and IPsec standards alone do not provide such a service
[11].
Vaarala (Ed.) Expires October 8, 2003 [Page 4]
Internet-Draft MIPv4-VPN April 2003
The proposed solution is to use standard Mobile IPv4 when the mobile
node is in the internal network, and to use the inner address of a
VPN tunnel (VPN-TIA) as a co-located care-of address for Mobile IPv4
registration when outside. IPsec-based VPN tunnels require re-
negotiation after movement; thus, some additional mechanism must deal
with mobility when the MN is outside.
The proposed solution for external mobility is to use another layer
of Mobile IPv4 underneath IPsec, in effect making IPsec unaware of
movement. Thus, the mobile node can freely move in the external
network without disrupting the VPN connection. The downside of this
approach is that an external home agent is required, and that the
packet overhead is considerable (see Section 6).
Briefly, when outside, the mobile node:
o detects (securely) that it is outside (Section 4);
o registers its co-located or foreign agent care-of address with the
external home agent;
o establishes a VPN tunnel using e.g. IKE (or IKEv2) if security
associations are not already available;
o registers the VPN tunnel inner address (VPN-TIA) as its co-located
care-of address with the internal home agent; this registration
request is sent inside the IPsec tunnel.
The proposed solution requires a "multi mode client", which is
capable of (1) detecting whether it is in the internal or the
external network in a secure fashion, and (2) varying its network
stack layering accordingly (i.e. proper combinations of Mobile IPv4
and IPsec). Detecting the internal network is security critical;
thus, requirements for such an algorithm as well as a basic algorithm
fulfilling the requirements is presented in Section 4.
Current Mobile IPv4 and IPsec standards, when used in a suitable
combination, are sufficient to implement the basic solution; no
changes are required to existing VPN devices, home agents, or foreign
agents. However, the basic solution has a number of shortcomings
especially in terms of overhead and complexity, analyzed in Section
6. To deal with these shortcomings, the following optional
mechanisms are proposed:
o an IPsec extension to include foreign agent functionality in the
VPN device, thus eliminating an extra layer of encapsulation for
mobile node traffic (Appendix B); and
Vaarala (Ed.) Expires October 8, 2003 [Page 5]
Internet-Draft MIPv4-VPN April 2003
o an IPsec extension which allows IPsec security associations to be
implicitly updated when the mobile node moves, thus obviating the
need for an external home agent when a co-located care-of address
is available (Appendix C);
o a Mobile IPv4 extension to eliminate an extra layer of
encapsulation when the mobile node is communicating with the
external home agent, and is sending data mostly to the VPN device
(Appendix D).
Note that the design team has not made any decisions regarding which
optimizations are in scope; the mechanisms are included in this
document to make it easier to discuss the alternatives.
1.2 Scope
This document describes a solution for IPv4 only.
VPN, in this document, refers to an IPsec-based remote access VPN.
Other types of VPNs are out of scope.
1.3 Related work
Proposed solutions from a previous version of this draft have been
included in Appendix E.
Related work has been done on Mobile IPv6 in [12] 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.
The "transient pseudo-NAT" attack, described in [13] and [3], 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.4 Terms and abbreviations
co-CoA: co-located care-of address
external network: the untrusted network (i.e. Internet; see Section
2). Note that a private network (e.g. another corporate network)
other than the mobile node's internal network is considered an
external network.
FA-CoA: foreign agent care-of address
Vaarala (Ed.) Expires October 8, 2003 [Page 6]
Internet-Draft MIPv4-VPN April 2003
internal network: the trusted network; for instance, a physically
secure corporate network (see Section 2).
inside: in the internal network; each network interface may be
independently inside or outside
i-FA: Mobile IPv4 foreign agent residing in the internal network
i-HA: Mobile IPv4 home agent residing in the internal network;
typically has a private address [4]
i-HoA: home address of the mobile node in the internal home agent
VPN-CoA: VPN tunneling address, referring to the care-of address
advertised by a combined VPN/FA device as described in Appendix B
VPN-TIA: VPN tunnel inner address, the address(es) negotiated during
IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP,
using mode config, or by some other means. Some VPN clients use
their current care-of address as their TIA for architectural
reasons.
VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode
IPsec connection, or L2TP combined with IPsec transport
connection.
outside: in the external network; each network interface may be
independently inside or outside
x-FA: Mobile IPv4 foreign agent residing in the external network
x-HA: Mobile IPv4 home agent residing in the external network
x-HoA: home address of the mobile node in the external home agent
Vaarala (Ed.) Expires October 8, 2003 [Page 7]
Internet-Draft MIPv4-VPN April 2003
2. Topology
The following figure describes an example network topology
illustrating the relationship between the internal and external
networks, the possible locations of the mobile node ("MN" in
parenthesis). The access modes (described later in Section 3)
available to the mobile node from each location are also shown in
curly braces.
(MN) {fvc,fvf} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [VPN] `--+----'
\ ! !
[R/FA] [x-HA] .--+--. [R]
\ / ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {cvc,vc,cvf,vf} (MN) {c} (MN) {f}
Figure: Basic topology, possible MN locations and access modes
The internal network is typically a multi-subnetted network which
uses private addressing [4]. Subnets may contain internal home
agent(s) (typically using private addresses), DHCP server(s), and/or
foreign agent(s). Current IEEE 802.11 wireless LANs are typically
deployed in the external network or the DMZ because of security
concerns.
The external network term used in this document includes the public
Internet, and private networks other than the mobile node's internal
network.
The de-militarized zone (DMZ) is a tiny network typically containing
servers that need to be accessed from both internal and external
Vaarala (Ed.) Expires October 8, 2003 [Page 8]
Internet-Draft MIPv4-VPN April 2003
networks; for instance, VPN devices.
The figure leaves out a few details worth noticing:
o There may be multiple NAT devices anywhere in the diagram.
* When the MN is outside, the NAT devices may be placed between
the MN and the x-HA, the x-HA and the VPN, or the MN and the
VPN.
* There may be also be NAT(s) between the VPN and the i-HA, etc.
(In essence, any router in the figure may be considered to
represent zero or more routers, each possibly performing NAT
and/or ingress filtering.)
* When the MN is inside, there may be NAT devices between the MN
and the i-HA, although this is not typical.
o Site-to-site VPN tunnels are not shown. Although mostly
transparent, IPsec endpoints may perform ingress filtering as part
of enforcing their policy. (Thus, reverse tunnelling SHOULD
always be used.)
o Trusted foreign agents (in this context referring to foreign
agents connected to the internal network using an IPsec tunnel)
are not shown. Trusted foreign agents are logically part of the
internal network.
o The figure represents a "canonical" topology where each functional
entity is illustrated as a separate device. However, it is
possible that in a physical network several functions are co-
located in a single device (for instance, the x-HA and VPN
functionalities). In fact, all three server components (x-HA,
VPN, and i-HA) may be co-located in a single physical device.
The following issues are also of importance:
o Some firewalls are configured to block ICMP messages and/or
fragments. Such firewalls (routers) cannot be detected reliably.
o Some networks contain transparent application proxies, especially
for the HTTP protocol. Like firewalls, such proxies cannot be
detected reliably in general.
o In other words, there are networks where typical enterprise
applications may work, but the networks are still unsuitable for
remote access to another corporate network. (This a generic
problem with Mobile IP and IPsec, and is out of scope.)
Vaarala (Ed.) Expires October 8, 2003 [Page 9]
Internet-Draft MIPv4-VPN April 2003
3. Access modes
In every possible location described in Section 2 the mobile node can
establish a connection to its i-HA by using a suitable "access mode".
An access mode is here defined to consist of:
1. a composition of the mobile node networking stack (i-MIP, VPN/i-
MIP, or x-MIP/VPN/i-MIP); and
2. registration mode(s) of i-MIP and x-MIP (if used); i.e. co-
located care-of address or foreign agent care-of address.
Each possible access mode is encoded as "xyz", where:
o "x" indicates whether the x-MIP layer is used, and if used, the
mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence
indicates not used);
o "y" indicates whether the VPN layer is used ("v" indicates VPN
used, absence indicates not used);
o "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c"
indicates co-CoA).
This results in eight access modes:
c: i-MIP w/ co-CoA
f: i-MIP w/ FA-CoA
vc: VPN-TIA as i-MIP co-CoA
vf: VPN-CoA as i-MIP FA-CoA
cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA
cvf: x-MIP w/ co-CoA, VPN-CoA as i-MIP FA-CoA
fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA
fvf: x-MIP w/ FA-CoA, VPN-CoA as i-MIP FA-CoA
Note that access modes vc, vf, cvf, and fvf require one or both of
the optional mechanisms described in Appendix B and Appendix C.
Whenever a mobile node obtains either a co-CoA (using e.g. DHCP) or
a FA-CoA (from a foreign agent advertisement), the following steps
(conceptually) take place:
o The mobile node detects whether the subnet where the care-of
address was obtained belongs to the internal or the external
network using the method described in Section 4 (or a proprietary
mechanism fulfilling the requirements described).
o The mobile node performs necessary registrations, capability
Vaarala (Ed.) Expires October 8, 2003 [Page 10]
Internet-Draft MIPv4-VPN April 2003
detection, and other connection setup signalling for the following
layers (in order):
* x-MIP (if used);
* VPN (if used); and
* i-MIP.
Note that these two tasks are intertwined to some extent: detection
of internal network may actually result in a successful registration
to the i-HA, for instance.
Capability negotiation related to optional features is performed
during registration and connection setup phase for each layer
separately. Similarly, NAT detection and negotiation of traversal
occurs during the setup phase for each layer separately.
The following subsections describe the different access modes and the
requirements for registration and connection setup phase.
3.1 Access mode: 'c'
This access mode is standard Mobile IPv4 [2] with a co-located
address, except that:
o the mobile node MUST detect that it is in the internal network;
and
o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see
Section 5).
The registration request SHOULD request reverse tunnelling.
3.2 Access mode: 'f'
This access mode is standard Mobile IPv4 [2] with a foreign agent
care-of address, except that
o the mobile node MUST detect that it is in the internal network;
and
o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see
Section 5).
The registration request SHOULD request reverse tunnelling.
Vaarala (Ed.) Expires October 8, 2003 [Page 11]
Internet-Draft MIPv4-VPN April 2003
3.3 Access mode: 'vc' (optional)
Steps:
o The mobile node obtains a care-of address from e.g. a DHCP
server.
o The mobile node detects it is outside.
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway. The VPN-TIA is assigned in some
manner (or determined by the MN). VPN capability negotiation is
done at the same time:
* the mobile node advertises support for the IPsec endpoint
update mechanism described in Appendix C;
* the VPN gateway responds and acknowledges support for the
feature; and
* the mobile node negotiates use of this feature for the SA being
established.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, and:
* D-bit MUST be set (co-located)
* T-bit MUST be set (reverse tunnelling)
The IKE negotiation in this access mode uses the co-located care-of
address as the IKE source address. This implies that any IPsec
security associations established will be (atleast initially)
associated with the co-located care-of address.
If it turns out that the VPN device does not support the optional
mechanism described in Appendix C, the mobile node should:
o abandon the initial IKE negotiation (which uses the co-located
care-of address as source address);
o register the co-located care-of address with the x-HA;
o restart IKE using the x-HoA as the IKE source address (to ensure
that the IPsec security associations are associated with the x-
HoA).
Both the MN and the VPN must support the mechanism described in
Vaarala (Ed.) Expires October 8, 2003 [Page 12]
Internet-Draft MIPv4-VPN April 2003
Appendix C.
3.4 Access mode: 'vf' (optional)
Steps:
o The mobile node obtains a care-of address from e.g. a DHCP
server.
o The mobile node detects it is outside.
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway. The mobile node selects VPN-TIA
(which equals i-HoA). VPN capability negotiation is done at the
same time:
* the mobile node advertises support for the IPsec endpoint
update mechanism described in Appendix C, as well as support
for the VPN/FA feature described in Appendix B;
* the VPN gateway responds and acknowledges support for both
features, and also relays a foreign agent advertisement to the
mobile node (containing the VPN-CoA); and
* the mobile node negotiates use of both features for the SA
being established.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-CoA as a foreign agent care-of address, and
* D-bit MUST NOT be set (foreign agent)
* T-bit MUST be set (reverse tunnelling)
The IKE negotiation in this access mode uses the co-located care-of
address as the IKE source address. This implies that any IPsec
security associations established will be (atleast initially)
associated with the co-located care-of address.
If it turns out that the VPN device does not support the optional
mechanism described in Appendix C, the mobile node should:
o abandon the initial IKE negotiation (which uses the co-located
care-of address as source address);
o register the co-located care-of address with the x-HA;
o restart IKE using the x-HoA as the IKE source address (to ensure
Vaarala (Ed.) Expires October 8, 2003 [Page 13]
Internet-Draft MIPv4-VPN April 2003
that the IPsec security associations are associated with the x-
HoA).
Both the MN and the VPN must support the mechanisms described in
Appendix B and Appendix C.
3.5 Access mode: 'cvc'
Steps:
o The mobile node obtains a care-of address from e.g. a DHCP
server.
o The mobile node detects it is outside and registers with the x-HA
(possibly as a side effect of the detection process).
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway, using the x-HoA as the IP address
for IKE/IPsec communication. The VPN-TIA is assigned in some
manner (or chosen by the MN). VPN capability negotiation is done
at the same time.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, and
* D-bit MUST be set (co-located)
* T-bit MUST be set (reverse tunnelling)
3.6 Access mode: 'cvf' (optional)
Steps:
o The mobile node obtains a care-of address from e.g. a DHCP
server.
o The mobile node detects it is outside and registers with the x-HA
(possibly as a side effect of the detection process).
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway, using the x-HoA as the IP address
for IKE/IPsec communication. The mobile node selects VPN-TIA
(which equals i-HoA). VPN capability negotiation is done at the
same time:
* the mobile node advertises support for the VPN/FA feature
described in Appendix B;
Vaarala (Ed.) Expires October 8, 2003 [Page 14]
Internet-Draft MIPv4-VPN April 2003
* the VPN gateway responds and acknowledges support for the
feature, and also relays a foreign agent advertisement to the
mobile node (containing the VPN-CoA); and
* the mobile node negotiates use of the feature for the SA being
established.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-CoA as a foreign agent care-of address, and
* D-bit MUST NOT be set (foreign agent)
* T-bit MUST be set (reverse tunnelling)
Both the MN and the VPN must support the mechanism described in
Appendix B.
3.7 Access mode: 'fvc'
Steps:
o The mobile node obtains a foreign agent advertisement from the
local network.
o The mobile node detects it is outside and registers with the x-HA
(possibly as a side effect of the detection process).
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway, using the x-HoA as the IP address
for IKE/IPsec communication. The VPN-TIA is assigned in some
manner (or chosen by the MN). VPN capability negotiation is done
at the same time.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, and
* D-bit MUST be set (co-located)
* T-bit MUST be set (reverse tunnelling)
3.8 Access mode: 'fvf' (optional)
Steps:
o The mobile node obtains a foreign agent advertisement from the
local network.
Vaarala (Ed.) Expires October 8, 2003 [Page 15]
Internet-Draft MIPv4-VPN April 2003
o The mobile node detects it is outside and registers with the x-HA
(possibly as a side effect of the detection process).
o If necessary, the mobile node uses IKE to set up an IPsec
connection with the VPN gateway, using the x-HoA as the IP address
for IKE/IPsec communication. The mobile node selects VPN-TIA
(which equals i-HoA). VPN capability negotiation is done at the
same time:
* the mobile node advertises support for the VPN/FA feature
described in Appendix B;
* the VPN gateway responds and acknowledges support for the
feature, and also relays a foreign agent advertisement to the
mobile node (containing the VPN-CoA); and
* the mobile node negotiates use of the feature for the SA being
established.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-CoA as a foreign agent care-of address, and
* D-bit MUST NOT be set (foreign agent)
* T-bit MUST be set (reverse tunnelling)
Both the MN and the VPN must support the mechanism described in
Appendix B.
3.9 NAT traversal
NAT devices may affect each layer independently (and even all three
layers at the same time). Mobile IPv4 NAT traversal MUST be used
for x-MIP and i-MIP layers, while IPsec NAT traversal [5][6] MUST be
used for VPN layer.
Note that NAT traversal for the internal MIPv4 layer may be necessary
even when there is no separate NAT device between the VPN gateway and
the internal network. Some VPN implementations NAT VPN tunnel inner
addresses before routing traffic to the intranet. Sometimes this is
done to make a deployment easier, but in some cases this approach
makes VPN client implementation easier. Mobile IPv4 NAT traversal is
required to establish a MIPv4 session in this case.
Vaarala (Ed.) Expires October 8, 2003 [Page 16]
Internet-Draft MIPv4-VPN April 2003
4. Internal network detection
Secure detection of the internal network is security critical: if the
mechanism fails for some reason, plaintext traffic may be sent to an
untrusted network. In other words, the overall security
(confidentiality and integrity of user data) is a minimum of IPsec
security and the internal network detection mechanism security. For
this reason, a set of requirements relevant to security are described
in this section.
In addition to detecting entry into the internal network, the mobile
node must also detect when it leaves the internal network. Entry
into the internal network is easier security-wise: the mobile node
can take all the time it needs to ensure that it is inside the
internal network before sending any plaintext traffic. Exit from the
internal network is more difficult to detect, and the MN may
accidentally leak plaintext packets if the event is not detected
properly.
Several events cause the mobile node to exit the internal network,
for instance:
o a routing change upstream;
o a reassociation of 802.11 on layer 2 which the mobile node
software does not detect;
o a physical cable disconnect and reconnect which the mobile node
software does not detect.
Whether the mobile node can detect such changes in the current
connection reliably depends on the implementation. For instance,
some mobile nodes may be implemented as pure layer three entities.
Even if the mobile node software has access to layer two information,
such information is not trustworthy security-wise (and depends on the
network interface driver).
If the mobile node does not detect these events properly, it may leak
plaintext traffic into an untrusted network. A number of approaches
can be used to detect exit from the internal network, ranging from
frequent re-registration to the use of layer two information.
A mobile node MUST implement a detection mechanism fulfilling the
requirements described in Section 4.2; this ensures that basic
security requirements are fulfilled. The basic algorithm described
in Section 4.3 is one way to do that, but alternative methods may be
used instead or in conjunction. The assumptions that the
requirements and the proposed mechanism rely upon are described in
Vaarala (Ed.) Expires October 8, 2003 [Page 17]
Internet-Draft MIPv4-VPN April 2003
Section 4.1.
4.1 Assumptions
The firewall MUST be configured to block traffic originating from
external networks going to the i-HA. In other words, if the mobile
node succeeds in registering with the i-HA directly (without using
IPsec), the mobile node may safely infer that it is connected to the
trusted internal network, and may therefore use plaintext traffic.
It is explicitly NOT assumed that the x-HA is not reachable from the
internal network. As the registration request is basically UDP
traffic, an ordinary firewall (even a stateful one) would typically
allow the registration request to be sent, and a registration reply
to be received through the firewall.
4.2 Implementation requirements
Any mechanism used to detect the internal network MUST fulfill the
following requirements.
4.2.1 Registration-based internal network detection
The mobile node MUST NOT infer that an interface is connected to the
internal network unless a successful registration has been completed
through that particular interface and the connection status of the
interface has not changed since.
(Need to define connection status change.)
4.2.2 Registration-based internal network monitoring
Some leak of plaintext packets to a (potentially) untrusted network
cannot always be completely prevented; this depends heavily on the
client implementation. In some cases the client cannot detect such a
change (for instance if the subnet is reconnected to another place in
the network topology in its entirety).
To bound the maximum amount of time that such a leak may persist, the
mobile node MUST fulfill the following requirements when inside:
o When the mobile node is registered directly to the i-HA (i.e. not
using IPsec), the mobile node MUST re-register with the i-HA
periodically to ensure that is still connected to the trusted
internal network.
o This re-registration interval and associated retransmission
parameters MUST be configurable in the mobile node, so that the
Vaarala (Ed.) Expires October 8, 2003 [Page 18]
Internet-Draft MIPv4-VPN April 2003
maximum exposure time can be reliably controlled.
o The default values MUST ensure that the mobile node will stop
sending plaintext traffic within one minute of the change of i-HA
reachability.
o When the mobile node fails to re-register, it MUST stop sending
and receiving plaintext traffic immediately, to prevent plaintext
traffic from leaking out and untrusted data from leaking in.
The re-registration requirement allows the administrator to determine
the required security level for the particular deployment.
Configuring the re-registration interval to a very small value (i.e.
in the order of few seconds) is not practical; alternative mechanisms
need to be considered if such confidence is required.
Note that this is just the fallback mechanism. If additional
information (such as layer two information) is available to the
mobile node, the mobile node SHOULD assume it has moved and restart
the registration process to minimize exposure.
Also note that the re-registration interval only applies when the
mobile node is inside the internal network. When outside, ordinary
Mobile IPv4 re-registration process (based on registration lifetime)
is used.
(Note: We could describe the above requirement also as requiring that
the mobile node use a different requested binding lifetime when
inside, and that this lifetime should be configurable. The mobile
node would be prohibited from sending or receiving any traffic when
the binding is not active.)
4.2.3 Connection status change
When the mobile node detects that its connection status on a certain
network interface changes, the mobile node MUST:
o immediately stop relaying user data packets;
o detect whether this interface is connected to the internal or the
external network;
o resume data traffic only after the internal network detection has
been completed.
Note that a mobile node is not required to use any particular
connection status change monitoring, except registration-based
monitoring.
Vaarala (Ed.) Expires October 8, 2003 [Page 19]
Internet-Draft MIPv4-VPN April 2003
(Need to define connection status change.)
4.2.4 Handling of network interfaces
The mobile node implementation MUST track each network interface
separately. Successful registration with the i-HA through interface
X does not imply anything about the status of interface Y.
4.3 Proposed algorithm
When the MN detects that it has changed its point of network
attachment, it issues two simultaneous registration requests, one to
the i-HA and another to the x-HA. These registration requests are
periodically retransmitted if reply messages are not received.
Registration replies are processed as follows:
o If a response from the x-HA is received, the MN stops
retransmitting its registration request to the x-HA and determines
it is outside. However, the MN MUST keep on retransmitting its
registration to the i-HA for a period of time. The MN MAY
postpone the IPsec connection setup for some period of time
("detection period") while it waits for a response from the i-HA.
(This prevents unnecessary switching between registrations; a
waiting period of a few seconds should suffice in most cases.)
o If a response from the i-HA is received, the MN MUST determine
that it is inside. If a previous registration reply from the x-HA
has been received, the MN SHOULD de-register with the x-HA. In
any case, the MN MUST stop retransmitting its registration
requests to both i-HA and x-HA.
o If a response from the x-HA is received while the MN has
successfully registered with the i-HA, the MN SHOULD de-register
with the x-HA.
If the MN ends up detecting that it is inside, it MUST re-register
periodically (regardless of binding lifetime). The re-registration
interval and related parameters (e.g. for retransmission) MUST be
configurable, as it is a security related parameter (see Section
4.2.2). If the re-registration fails, the MN MUST stop sending and
receiving plaintext traffic, and MUST restart the detection
algorithm.
Registration refreshes are always addressed either to the x-HA or the
i-HA, not to both. This is because the MN knows, after initial
registration, whether it is inside or outside.
Vaarala (Ed.) Expires October 8, 2003 [Page 20]
Internet-Draft MIPv4-VPN April 2003
Note that the "detection period" should be at most a few seconds to
avoid application timeouts. Also, the mobile node may simply use a
detection period of zero. However, this may result in many aborted
IKE sessions. Since IKE does not provide a reliable, standardized,
and mandatory mechanism for terminating a session, frequently aborted
IKE sessions may be a problem in some cases.
Note that it is possible that an i-HA is initially unreachable for
some time, but later becomes reachable (consider e.g. a routing
problem in the internal network). To eventually detect the i-HA, the
MN MAY send periodic registration attempts to the i-HA even after
determining initially that it is outside. The period of such re-
registration attempts should be in the order of minutes (e.g. 10
minutes), and configurable.
4.4 Implementation issues
When the MN uses a parallel detection algorithm and is using an FA,
the MN sends two registration requests through the same FA with the
same MAC address (or equivalent) and possibly even the same home
address. Although this is not in conflict with existing
specifications, it is not a usual scenario; hence some FA
implementations may not work properly in such a situation. However,
practical testing against deployed foreign agents seems to indicate
that a majority of foreign agents handle this situation correctly.
When the x-HA and i-HA addresses are the same, the scenario is even
more difficult for the FA, and it is almost certain that existing FAs
do not deal with the situation correctly. Therefore, it is required
that x-HA and i-HA addresses MUST be different. This requirement is
automatically satisfied if the x-HA has a public address.
The mobile node MAY use the following hints to determine that it is
inside, but MUST verify reachability of the i-HA anyway:
o a domain name in a DHCPDISCOVER / DHCPOFFER message;
o a NAI in a foreign agent advertisement;
o a list of default gateway MAC addresses which are known to reside
in the internal network (i.e. configured as such, or have been
previously verified to be inside).
For instance, if the MN has reason to believe it is inside, it MAY
postpone sending of registration request to the x-HA for some time.
Similarly, if the MN has a reason to believe it is outside, it may
start IPsec connection setup immediately after receiving a
registration reply from the x-HA. However, should the MN receive a
Vaarala (Ed.) Expires October 8, 2003 [Page 21]
Internet-Draft MIPv4-VPN April 2003
registration reply from the i-HA after IPsec connection setup has
been started, the MN MUST still switch to using the i-HA directly.
4.5 Rationale
4.5.1 Firewall configuration requirements
The assumption that the i-HA cannot be reached from the external
network is, in practice, unavoidable. Suppose the assumption is not
made, i.e. the i-HA is reachable from some external networks. As a
result, a successful registration with the i-HA (without IPsec)
cannot be used as a secure indication that the mobile node is inside.
A possible solution to the obvious security problem would be to
define and deploy a secure internal network detection mechanism based
on e.g. signed FA advertisement or signed DHCP messages.
However, unless the mechanism is defined for both FA and DHCP
messages and is deployed in every internal network, it has limited
applicability. In other words, the mobile node MUST NOT assume it is
in the internal network unless it receives a signed FA or DHCP
message (regardless of whether it can register directly with the i-
HA!). If it receives an unsigned FA or DHCP message, it MUST use
IPsec; otherwise the mobile node can be easily tricked into using
plaintext.
Assuming that all FA and DHCP servers in the internal network are
upgraded to support such a feature does not seem realistic; it is
highly desirable to be able to take advantage of existing DHCP and FA
deployments. Similar analysis seems to apply regardless of what kind
of additional security mechanism is defined.
4.5.2 Registration-based internal network monitoring
This issue also affects IPsec client security. However, as IPsec
specifications take no stand on how and when the client applies
IPsec, the issue is out of scope for IPsec. Because this document
describes an algorithm and requirements for (secure) internal network
detection, the issue is in scope of the document.
The current requirement for internal network monitoring was added as
a fallback mechanism. It seems to be the best what can be done with
only layer three mechanisms.
Vaarala (Ed.) Expires October 8, 2003 [Page 22]
Internet-Draft MIPv4-VPN April 2003
5. Requirements
5.1 Mobile node requirements
The mobile node MUST:
o implement a secure detection algorithm, fulfilling the
requirements described in Section 4.2;
o support access modes: c, f, cvc, fvc; always preferring direct
access to the internal network if possible;
o support Mobile IPv4 NAT traversal [3] for both internal and
external Mobile IP; and
o support IPsec NAT traversal [5][6] if operation without external
home agent is supported.
The mobile node SHOULD:
o support IPsec NAT traversal [5][6] even when external home agent
is used.
The mobile node MAY:
o support the VPN/FA feature described in Appendix B, and access
modes: cvf, fvf;
o support operation without x-HA, i.e. support the IPsec SA
endpoint update mechanism described in Appendix C, access mode vc,
and access mode vf (if VPN/FA supported);
o support the zero-overhead Mobile IPv4 tunnelling described in
Appendix D.
5.2 VPN device requirements
(Should we describe some minimal IPsec policy requirements here? For
the basic solution, we need at least UDP to port 434 and IP-IP,
unless NAT traversal to internal network is used. Since there are
implications to efficiency, I think we should document them here.)
The VPN device SHOULD:
o implement the IPsec NAT traversal mechanism described in [5][6].
The VPN device MAY:
Vaarala (Ed.) Expires October 8, 2003 [Page 23]
Internet-Draft MIPv4-VPN April 2003
o implement the VPN/FA feature described in Appendix B;
o implement the IPsec SA endpoint update feature described in
Appendix C.
5.3 Home agent requirements
The home agent (especially external) MUST:
o implement the Mobile IPv4 NAT traversal mechanism described in
[3]. (This is required to support VPNs that NAT VPN tunnel
addresses.)
The home agent (especially external) MAY:
o implement the zero-overhead Mobile IPv4 tunnelling mechanism
described in Appendix D.
Vaarala (Ed.) Expires October 8, 2003 [Page 24]
Internet-Draft MIPv4-VPN April 2003
6. Analysis
This section provides a comparison against guidelines described in
Section 6 of the problem statement [1] and additional analysis of
packet overhead with and without the optional mechanisms.
6.1 Comparison against guidelines
Preservation of existing VPN infrastructure
o The proposed solution does not mandate any changes to existing VPN
infrastructure, other than possibly changes in configuration to
avoid stateful filtering of traffic.
o To improve the solution, optional VPN changes can be made,
requiring a software upgrade; however, existing infrastructure can
be maintained.
Software upgrades to existing VPN clients and gateways
o The solution described does not require any changes to VPN
gateways or Mobile IPv4 home agents or foreign agents.
o Packet overhead can be optimized using an optional mechanism
(VPN/FA) which requires an upgrade to both VPN client and gateway,
and interoperation of VPN client and internal Mobile IPv4 layers
in the client.
IPsec protocol
o Proposed solution does not require any changes to existing IPsec
or key exchange standard protocols, and does not require
implementation of new protocols in the VPN device.
o However, an optional optimization mechanism which requires new VPN
protocol is proposed. The mechanism uses automatic backwards
compatible negotiation.
Multi-vendor interoperability
o The proposed solution provides easy multi-vendor interoperability
between server components (VPN device, foreign agents and home
agents). Indeed, these components need not be aware of each
other.
o The mobile node networking stack is somewhat complex to implement
(see concerns described in Appendix E.1). The VPN/FA mechanism
can be used to alleviate client complexity in some platforms (in
Vaarala (Ed.) Expires October 8, 2003 [Page 25]
Internet-Draft MIPv4-VPN April 2003
particular, the Windows client platform).
MIPv4 protocol
o The solution adheres to the MIPv4 protocol.
o The solution introduces an optional zero-overhead tunnelling
extension which uses an automatic negotiation mechanism.
o The solution requires the use of two parallel MIPv4 layers. When
using a co-located care-of address from an external network, the
external MIPv4 layer is optional if IPsec mobility is provided for
by the optional IPsec SA update mechanism Appendix C.
Handoff overhead
o The solution provides a mechanism to avoid VPN tunnel SA
renegotiation upon movement by using the external MIPv4 layer.
o In addition, to avoid possible complexity introduced by the
external MIPv4 layer, an optional IPsec SA update mechanism is
proposed to deal with the handoff problem without requiring the
external MIPv4 layer.
Scalability, availability, reliability, and performance
o The solution complexity is linear with the number of MNs
registered and accessing resources inside the intranet.
o Additional overhead is imposed by the solution. Optional
mechanisms to reduce overhead are proposed; the resulting overhead
is identical to ordinary VPN remote access.
Functional entities
o The solution does not impose any new types of functional entities
or required changes to existing entities. However, unless the VPN
device contains an integrated MIPv4 HA, an external HA device is
required.
Implications of intervening NAT gateways
o The solution leverages existing MIPv4 NAT traversal [3] and IPsec
NAT traversal [5][6] solutions and does not require any new
functionality to deal with NATs.
Security implications
Vaarala (Ed.) Expires October 8, 2003 [Page 26]
Internet-Draft MIPv4-VPN April 2003
o The solution requires a new mechanism to detect whether the mobile
node is in the internal or the external network. The security of
this mechanism is critical in ensuring that the security level
provided by IPsec is not compromised by a faulty detection
mechanism.
o When the mobile node is outside, the external Mobile IPv4 layer
may allow some traffic redirection attacks that plain IPsec does
not allow. Other than that, IPsec security is unchanged.
o When using the IPsec SA update mechanism, a new denial-of-service
vulnerability is introduced. However, to exploit the
vulnerability the attacker requires on-path read/write access
which enables a number of attacks in any case. When the attacker
leaves the path, the first legitimate packet from the mobile node
restores routing.
o More security considerations are described in Section 7.
6.2 Packet overhead
Vaarala (Ed.) Expires October 8, 2003 [Page 27]
Internet-Draft MIPv4-VPN April 2003
Table: Analysis of packet overhead in various situations
(maximum overhead between MN and nearest router, assumes IP-IP)
! basic ! + vpn/fa ! + vpn/fa ! + vpn/fa ! + vpn/fa !
! ! ! + sa-update ! + zot ! + sa-update !
! ! ! ! ! + zot !
-----------+--------+----------+-------------+-----------+-------------+
inside ! ! ! ! ! !
w/ fa ! 0 ! 0 ! 0 ! 0 ! 0 !
! ! ! ! ! !
-----------+--------+----------+-------------+-----------+-------------+
inside ! ! ! ! ! !
w/ co-CoA ! 20 ! 20 ! 20 ! 20 ! 20 !
! ! ! ! ! !
-----------+--------+----------+-------------+-----------+-------------+
outside ! ! ! ! ! !
w/ FA ! 77 ! 57 ! 57 ! 57 ! 57 !
w/ x-MIP ! ! ! ! ! !
-----------+--------+----------+-------------+-----------+-------------+
outside ! ! ! ! ! !
w/ co-COA ! 97 ! 77 ! 77 ! 57 ! 57 !
w/ x-MIP ! ! ! ! ! !
-----------+--------+----------+-------------+-----------+-------------+
outside ! ! ! ! ! !
w/ co-COA ! not ! not ! 57 ! not ! 57 !
w/o x-MIP ! mobile ! mobile ! ! mobile ! !
-----------+--------+----------+-------------+-----------+-------------+
Mechanisms:
vpn/fa: FA in VPN device
sa-update: IPsec SA endpoint update
zot: Zero-overhead MIPv4 tunnelling
When IPsec is used, a variable amount of padding is present in each
ESP packet. The figures in the table above were computed for a
cipher with 64-bit block size, padding overhead of 9 octets (next
header field, padding length field, and 7 octets of padding, see
Section 2.4 of [7]), and ESP authentication field of 12 octets (HMAC-
SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad
with more than a minimum amount of octets.
NAT traversal overhead is not included, and adds 8 octets when IPsec
NAT traversal [5][6] is used and 12 octets when MIP NAT traversal [3]
is used. For instance, when using access mode cvc, the maximum NAT
traversal overhead is 12+8+12 = 32 octets.
In summary, packet overhead is:
Vaarala (Ed.) Expires October 8, 2003 [Page 28]
Internet-Draft MIPv4-VPN April 2003
o 20 octets when inside and using a co-located care-of address;
o 97 octets when outside and using a co-located care-of address, can
be optimized to 57 octets (i.e. normal IPsec overhead) by using:
* VPN/FA and zero-overhead tunnelling; or
* VPN/FA and IPsec SA endpoint update mechanism, and not using an
x-HA.
o 77 octets when outside and using a foreign agent, can be optimized
to 57 octets (i.e. normal IPsec overhead) by using the VPN/FA
mechanism.
6.3 Firewall state considerations
A separate firewall device or an integrated firewall in the VPN
gateway typically performs stateful inspection of user traffic. The
firewall may, for instance, track TCP session status and block TCP
segments not related to open connections. Other stateful inspection
mechanisms also exist.
Firewall state poses a problem when the mobile node moves between the
internal and external networks. The mobile node may, for instance,
initiate a TCP connection while inside, and later go outside while
expecting to keep the connection alive. From the point of view of
the firewall, the TCP connection has not been initiated, as it has
not witnessed the TCP connection setup packets, thus potentially
resulting in connectivity problems.
When the VPN-TIA is registered as a co-located care-of address with
the i-HA, all mobile node traffic appears as IP-IP for the firewall.
Typically firewalls don't continue inspection beyond the IP-IP
tunnel, but it is not inconceivable that some firewalls may do that.
In summary, the firewall must allow traffic coming from and going
into the IPsec connection to be routed, even though they may not have
successfully tracked the connection state. How this is done is out
of scope of this document.
6.4 Implementation of mobile node
Implementation of the mobile node requires the use of three
tunnelling layers, which may be used in various configurations
depending on whether that particular interface is inside or outside.
Note that it is possible that one interface is inside and another
interface is outside, which requires a different layering for each
Vaarala (Ed.) Expires October 8, 2003 [Page 29]
Internet-Draft MIPv4-VPN April 2003
interface at the same time.
For multi-vendor implementation, the IPsec and Mobile IPv4 layers
need to interoperate in the same mobile node. This implies that a
flexible framework for protocol layering (or protocol-specific APIs)
are required.
6.5 IPsec endpoint update vs. zero-overhead MIP tunnelling
External Mobile IPv4 combined with zero-overhead MIPv4 tunnelling is
equivalent in overhead to an IPsec endpoint update mechanism. The
main difference is in management: external Mobile IPv4 requires
configuration of mobile node and the external HA.
Note, however, that an x-HA box is not required. Instead, the x-HA
can be integrated into the VPN gateway, resulting in essentially the
same functionality as an IPsec endpoint mechanism, but with the
following pros:
o the IPsec layer is unaware of this functionality (in both client
and gateway; in particular, the VPN client software does not need
to be changed);
o IPsec NAT traversal is not required;
o the solution works with any IPsec key management mechanism (IKEv1
or IKEv2);
o the MIPv4 NAT traversal layer solves IPsec fragmentation issues
transparently (note that no IPsec standard exists to avoid
fragmentation although demonstrably a problem in real networks);
and
o the security analysis is much simpler: from a security
perspective, this is equivalent to using external MIPv4.
Note that the mobile node does not need to know whether the x-HA is
integrated into the VPN device or not.
The cons include:
o even though there is no separate box, the layer needs to be
configured and managed (MIPv4 parameters and authentication key).
Vaarala (Ed.) Expires October 8, 2003 [Page 30]
Internet-Draft MIPv4-VPN April 2003
6.6 Non-IPsec VPN protocols
The proposed solution works also for VPN tunneling protocols that are
not IPsec-based, provided that the mobile node is provided IPv4
connectivity with an address suitable for registration. However,
such VPN protocols are not explicitly considered.
6.7 Miscellaneous issues
IKE suffers from a combinatorial explosion in quick mode. The two
proposed VPN extensions each add a new SA attribute; to offer all
combinations, the number of sub-payloads in a proposal would
quadruple. This is clearly not desirable, and should be considered
if new VPN options are defined (as options).
The proposed solution has the following shortcomings for enterprise
use:
o Networks which provide only HTTP access (sometimes found in
corporate networks) cannot be used for remote access.
o Fragments are filtered by some routers. MIP NAT traversal [3]
solves some, but not all, fragment related issues.
However, solution to these problems are not part of the problem
statement.
Vaarala (Ed.) Expires October 8, 2003 [Page 31]
Internet-Draft MIPv4-VPN April 2003
7. Security considerations
7.1 Detection of internal/external network
If the mobile node mistakenly believes it is in the internal network
and sends plaintext packets, it compromises IPsec security. For this
reason, the overall security (confidentiality and integrity) of user
data is a minimum of (1) IPsec security, and (2) security of the
internal network detection mechanism.
Security of the internal network detection relies on a successful
registration with the i-HA. For standard Mobile IPv4 [2] this means
HMAC-MD5 and Mobile IPv4 replay protection.
When the connection status of an interface changes, an interface
previously connected to the trusted internal network may suddenly be
connected to an untrusted network. Although the same problem is also
relevant to IPsec-based VPN implementations, the problem is relevant
in the scope of this specification.
In most cases, mobile node implementations are expected to have layer
two information available, making connection change detection both
fast and robust. To cover cases where such information is not
available (or fails for some reason), the mobile node is required to
periodically re-register with the internal home agent to verify that
it is still connected to the trusted network. It is also required
that this re-registration interval be configurable, thus giving the
administrator a parameter by which potential exposure may be
controlled robustly even for the worst case.
7.2 Mobile IPv4 versus IPsec
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
Vaarala (Ed.) Expires October 8, 2003 [Page 32]
Internet-Draft MIPv4-VPN April 2003
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 [13] and [3], 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
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 to users.
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.
7.3 Optional mechanisms
(Security of the optional mechanisms needs to be discussed in more
detail when the mechanisms have more concrete definitions. The zero-
overhead MIPv4 tunnelling and the VPN/FA mechanism should not have
any obvious security issues. The IPsec endpoint update mechanism
does have, and requires careful discussion.)
Vaarala (Ed.) Expires October 8, 2003 [Page 33]
Internet-Draft MIPv4-VPN April 2003
8. Intellectual property rights
Birdstep Technology has submitted patent application(s) related to
the dual mobile IP design for VPN gateway traversal. Birdstep's
objective is to seek intellectual property protection for its mobile
IP client implementation of such a design. If any standards arising
from this document are or become protected by one or more patents
assigned to Birdstep Technology, and if any claims of any issued
Birdstep patents are necessary for practicing such a standard, any
party will be able to obtain a license from Birdstep to use any such
patent claims under reasonable, non-discriminatory terms, with
reciprocity, to implement and fully comply with the standard.
Netseal may or may not have patents or patent applications related to
the non-mandatory mechanisms described in this document.
Intel may or may not have patents or patent applications related to
the non-mandatory mechanisms described in this document.
Vaarala (Ed.) Expires October 8, 2003 [Page 34]
Internet-Draft MIPv4-VPN April 2003
9. Acknowledgements
This document is a joint work of the contributing authors (in
alphabetical order):
- Farid Adrangi (Intel Corporation)
- Nitsan Baider (Check Point Software Technologies, Inc.)
- Gopal Dommety (Cisco Systems)
- Eli Gelasco (Cisco Systems)
- Dorothy Gellert (Nokia Corporation)
- Espen Klovning (Birdstep)
- Milind Kulkarni (Cisco Systems)
- Henrik Levkowetz (ipUnplugged AB)
- Frode Nielsen (Birdstep)
- Sami Vaarala (Netseal)
- Qiang Zhang (Liqwid Networks, Inc.)
The authors would like to thank MIP/VPN design team, especially Mike
Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent
Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan
O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans
Sjostrand, and Serge Tessier for their continuous feedback and
helping us improve this draft.
Vaarala (Ed.) Expires October 8, 2003 [Page 35]
Internet-Draft MIPv4-VPN April 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] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
2002.
[3] Levkowetz, H. and S. Vaarala, "Mobile IP NAT/NAPT Traversal
using UDP Tunnelling (draft-ietf-mobileip-nat-traversal-07,
work in progress)", November 2002.
[4] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", RFC 1918, BCP
5, February 1996.
[5] Kivinen, T., Swander, B., Huttunen, A. and V. Volpe,
"Negotiation of NAT-Traversal in the IKE (draft-ietf-ipsec-nat-
t-ike-05, work in progress)", January 2003.
[6] Huttunen, A., Swander, B., Stenberg, M., Volpe, V. and L.
DiBurro, "UDP Encapsulation of IPsec packets (draft-ietf-ipsec-
udp-encaps-06, work in progress)", January 2003.
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[8] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with
IPsec remote access tunnelling (draft-nuopponen-vaarala-mipvpn-
00, work in progress)", July 2002.
[9] 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.
[10] 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.
[11] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage",
December 2002.
[12] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Vaarala (Ed.) Expires October 8, 2003 [Page 36]
Internet-Draft MIPv4-VPN April 2003
Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in
progress)", October 2002.
[13] 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.
Author's Address
Sami Vaarala
Netseal
Niittykatu 6
Espoo 02201
FINLAND
Phone: +358 9 435 310
EMail: sami.vaarala@iki.fi
Vaarala (Ed.) Expires October 8, 2003 [Page 37]
Internet-Draft MIPv4-VPN April 2003
Appendix A. Changes
Changes from -00 to -01:
o First description of proposed solution based on basic and
optimized dual HA drafts, as well as IPsec endpoint update
mechanism.
o List of proposed solutions in -00 included in appendix.
Vaarala (Ed.) Expires October 8, 2003 [Page 38]
Internet-Draft MIPv4-VPN April 2003
Appendix B. Optional mechanism: FA in VPN device
This section contains a technical specification for an optional VPN
mechanism to eliminate one extra layer of encapsulation when mobile
node is outside.
When registering using a foreign agent care-of address, standard
Mobile IPv4 requires the following steps:
o the mobile node detects a foreign agent by receiving a foreign
agent advertisement broadcast by the foreign agent periodically
(the mobile node may speed up this process by sending a
solicitation message);
o the mobile node inspects the advertisement and forms a
registration request message based on the advertisement (in
particular, the care-of address field of the registration request
is copied from the advertisement);
o after a successful registration the foreign agent updates its
visitor list; and
o the foreign agent decapsulated packets sent by the home agent (on
behalf of the mobile node) and delivers the unencapsulated packets
to the mobile node; similarly the foreign agent encapsulates
packets sent by the mobile node to the home agent.
The mobile node exchanges packets with the foreign agent using a
layer two connection. Thus, packets can be exchanged without
confusing other hosts in the subnet.
By replacing the layer two connection with a VPN tunnel, the foreign
agent concept can be extended to remote access. However, this
analogy is not complete because:
o there is no advertisement mechanism; and
o the VPN does not ordinarily decapsulate and encapsulate packets
like a foreign agent.
The proposed technical specification addresses these shortcomings,
and consists of:
o a capability negotiation and sending an encapsulated foreign agent
advertisement during IKE phase 1;
o negotiation of VPN/FA feature use for an SA during IKE phase 2
(using new SA attributes);
Vaarala (Ed.) Expires October 8, 2003 [Page 39]
Internet-Draft MIPv4-VPN April 2003
o requirements for mobile node registration through the VPN tunnel;
and
o requirements for VPN packet processing when this extension is
enabled.
The figure below illustrates the mechanism.
Standard MIPv4 VPN/FA mechanism
MN FA MN VPN/FA
! ! ! !
! <----------------- ! ! <----------------> !
! fa advertisement ! ! ike phase 1 !
! ! ! (detect support) !
! -----------------> ! ! (fa adv. to MN) !
! reg. request ! ! !
! ! ! <----------------> !
! <----------------- ! ! ike phase 2 !
! reg. reply ! ! (sa attribute) !
! ! ! !
! ! ! -----------------> !
! ! ! reg. req. (IPsec) !
! ! ! !
! ! ! <----------------- !
! ! ! reg. rep. (IPsec) !
! ! ! !
! ! ! !
! <----------------> ! ! <----------------> !
! L2 communication ! ! IPsec tunneling !
! ! ! !
MN and FA exchange MN and VPN/FA exchange
unencapsulated packets. packets encapsulated only
using IPsec. Tunnel inner
address of MN is internal
Mobile IPv4 home address.
Figure: Comparison of standard Mobile IPv4 and proposed mechanism
(One suggestion was that the FA device could actually be an external
device; the VPN would solicit for an advertisement on behalf of the
mobile node, and relay any advertisement(s) to the mobile node. By
relaying the RRQ through a chosen FA, the FA would automatically
deliver packets to the VPN. The current description could then be
described as physically co-locating the two logically separate
Vaarala (Ed.) Expires October 8, 2003 [Page 40]
Internet-Draft MIPv4-VPN April 2003
boxes.)
B.1 Capability negotiation
To detect support for the mechanism, the mobile node sends a Vendor
ID containing the MD5 hash of XXX in the first message of phase 1
(main or aggressive mode). If the VPN device supports the mechanism,
it returns the same Vendor ID in its response message.
A successful Vendor ID enables the use of a new private payload
Appendix B.2 and a new SA attribute in IKE quick mode Appendix B.3.
B.2 Foreign agent advertisement
Once it has been established that both peers support this mechanism,
the VPN device may use a private payload (defined below) to convey a
foreign agent advertisement to the mobile node. The private payload
MUST be sent in the last message of IKE main mode or aggressive mode
(i.e. encrypted).
The advertisement follows the format specified in [2]. The mobile
node needs to advertisement because it needs to know the foreign
agent care-of address in order to send a properly formatted
registration request through the VPN tunnel. In addition, all normal
extensions can be conveniently sent to the mobile node without need
for additional specifications.
Note: typically the address of the VPN network interface connected to
the internal network would be used as the foreign agent care-of
address. However, the VPN device MAY use a different address to
ensure ordinary packets arriving at the interface are never confused
with the foreign agent function.
The private payload is defined as follows:
(IKE payload, private number, contents are FA adv.)
B.3 New SA attribute
The phase 1 capability negotiation does not enable the use of this
feature directly. The mobile node includes the new SA attribute as a
part of the initiator SA payload of IKE quick mode. The VPN gateway
then determines, based on local policy, whether it allows the feature
to be used.
If the feature is accepted by the VPN gateway, the requirements of
Appendix B.4 and Appendix B.5 MUST be followed by both the mobile
node and the VPN gateway.
Vaarala (Ed.) Expires October 8, 2003 [Page 41]
Internet-Draft MIPv4-VPN April 2003
The initiator SHOULD include two versions of a transform sub-payload,
one with and the other without the new attribute. This ensures that
phase 2 can be completed even when responder policy does not allow
the use of this feature. (Note that it is acceptable to advertise
support in phase 1 and then reject to use the feature.)
B.4 Registration
The registration request fields are set as specified in [2]. In
particular, the "D" bit is not set (i.e. foreign agent
decapsulates), and the care-of address is set to the address
discovered in the previous step.
(Fields here.)
B.5 VPN packet processing
IPsec policy must be configured as follows:
o the encapsulation mode MUST be tunnel;
o the mobile node endpoint MUST be a single address (the i-HoA);
o the VPN gateway endpoint MUST be 0.0.0.0/0 (i.e. any address) or
a suitable subnet including the internal network;
o protocol and port selectors MUST be "any".
For packets received from the mobile node:
o the IPsec encapsulated packet is IPsec-processed (i.e. decrypted,
authenticated, and decapsulated);
o the inner packet source address should equal the mobile node
internal home address while the destination address may be any
(i.e. a correspondent);
o the VPN device encapsulates the packet and sends it to the home
agent, as specified in [2]. (Reverse tunnelling should be
enforced.)
Note that the VPN device MUST NOT relay the packet to the
correspondent node address directly; instead, the packet MUST be sent
to the home agent (reverse tunneling is mandatory). Bindings
maintained by the VPN (in the foreign agent function) may not be up-
to-date; only the home agent has up-to-date binding information.
Thus, all packets should be delivered to the home agent to avoid
problems with routing.
Vaarala (Ed.) Expires October 8, 2003 [Page 42]
Internet-Draft MIPv4-VPN April 2003
Packets received from the internal home agent (i.e. source address
equals internal home agent address) with destination address equal to
the foreign agent care-of address of the VPN device are treated as
follows:
o If the VPN device cannot find an active binding for the mobile
node in question (whose address is peeked from the packet), the
packet is dropped.
o Otherwise the VPN device checks whether the mobile node has active
security association(s) with the VPN device. If not, the packet
is dropped.
o Otherwise, if encapsulation mode was IP-IP, the packet is
decapsulated, protected using the security association in
question, and sent to the mobile node.
o (This requires more work, e.g. with regards to other
encapsulation modes and NAT traversal.)
Multicast and broadcast packets are double encapsulated (see [2],
Section 4.3). By following the procedure above, they are
automatically handled correctly.
B.6 Dynamic home address allocation
Dynamic home address allocation cannot be used together with this
feature: the mobile node MUST always know its home address.
If home address is not known, the mobile node SHOULD:
o use an ordinary VPN tunnel (without VPN/FA feature enabled) and
register the VPN-TIA as a co-CoA to the i-HA;
o obtain a home address using the Mobile IPv4 dynamic home address
assignment procedure [2]; and
o negotiate a new VPN tunnel with the VPN/FA feature enabled using
the home address obtained.
B.7 IKEv2
(IKEv2 contains a similar Vendor ID mechanism, so a similar approach
should work.)
Vaarala (Ed.) Expires October 8, 2003 [Page 43]
Internet-Draft MIPv4-VPN April 2003
B.8 Notes
This mechanism is basically a restatement of the "optimized dual HA"
mechanism described in [9]. The main differences are as follows:
o The encapsulation and decapsulation functionality of the VPN
device have been made explicit by describing them as foreign agent
functions.
o As a result, other foreign agent processing requirements such as
enforcing reverse tunneling, and (optionally) adding extensions of
its own are possible.
o The VPN device is not allowed to short circuit routing when two
mobile nodes which are both outside are exchanging packets; this
is to prevent problems with out-of-date binding information.
o As a result, there is no need to tear down an SA when the mobile
node returns to the internal network. The routing also follows
ordinary foreign agent operation, and is therefore more easily
understandable.
Vaarala (Ed.) Expires October 8, 2003 [Page 44]
Internet-Draft MIPv4-VPN April 2003
Appendix C. Optional mechanism: IPsec SA endpoint update
This section contains a technical specification for an optional VPN
mechanism to eliminate the need for an external home agent when the
mobile node is outside, and using a co-located care-of address.
(This is a sketch to provide some concreteness; another alternative
is an explicit endpoint update mechanism. Since this issue has been
discussed on the IPsec mailing list in the NAT traversal context,
there may be an easy solution based on existing stuff. Simply
forcing the use of UDP encapsulation always, and ensuring that the
client address and UDP port is always updated by the VPN gateway when
the client moves should suffice. This would not require a new
negotiation mechanism; we would just use the existing NAT traversal
stuff.)
Note that the mobile node may change between not using an external
home agent and using an external home agent freely. From the point
of view of the VPN device, it does not matter how the VPN tunnel
outer address is obtained. This also means that the mobile node may
change external home agent without requiring IPsec re-negotiation,
thus improving fail-over and enables use of dynamic selection of
external home agent.
Vaarala (Ed.) Expires October 8, 2003 [Page 45]
Internet-Draft MIPv4-VPN April 2003
MN VPN
! !
! <----------------> ! detect mutual support of feature
! ike phase 1 !
! (detect support) !
! !
! <----------------> ! negotiate endpoint update feature as
! ike phase 2 ! part of SA attribute list (in initiator
! (endpoint update ! SA payload)
! in SA attribute) !
! !
! !
! -----------------> ! broken IPsec packets (i.e. does not pass
! ipsec packet ! decryption or authentication steps) is
! (broken) ! ignored, endpoint not updated
! !
! -----------------> ! proper IPsec packet updates SA endpoint
! ipsec packet ! of reverse direction
! (proper) !
! !
! <----------------- ! IPsec packets in reverse direction
! ipsec packet ! automatically use tunnel outer address
! (reverse dir.) ! of last proper IPsec packet
! !
Figure: Sequence diagram of SA endpoint update feature
C.1 Capability negotiation
(IKE vendor ID in phase 1, SA attribute in phase 2.)
C.2 New SA attribute
The SA endpoint update feature is negotiated in phase 2 (quick mode)
by using a new attribute in the transform sub-payload of the
initiator (and responder) SA payload. The responder can then
determine, based on local policy, whether SA endpoint update feature
is acceptable or not for this peer.
The initiator SHOULD include two versions of a transform sub-payload,
one with and the other without the new attribute. This ensures that
phase 2 can be completed even when responder policy does not allow
the use of this feature. (Note that it is acceptable to advertise
support in phase 1 and then reject to use the feature.)
Vaarala (Ed.) Expires October 8, 2003 [Page 46]
Internet-Draft MIPv4-VPN April 2003
C.3 SA endpoint update
(Client does not need to update, must select SPIs without binding
them to addresses. VPN device updates implicitly when a properly
authenticated packet arrives. VPN device updates all corresponding
outbound SAs. Relationship with IPsec NAT traversal [5][6] and
previous IPsec WG discussion needs to be discussed.)
C.4 Security considerations
(The effects of implicit update on security. Denial-of-Service, but
requirement of properly secured packet and replay protection means
that the attacker is on route => DoS is possible in any case. DoS is
resolved when attack stops and mobile node sends first packet to VPN
device, which restores endpoint.)
C.5 IKEv2
(IKEv2 contains a similar Vendor ID mechanism, so a similar approach
should work.)
Vaarala (Ed.) Expires October 8, 2003 [Page 47]
Internet-Draft MIPv4-VPN April 2003
Appendix D. Optional mechanism: Zero-overhead MIPv4 tunnelling
This section contains a technical specification for an optional
Mobile IPv4 mechanism to eliminate IP-IP tunnelling overhead when (1)
reverse tunneling is used, and (2) the mobile node communicates
almost exclusively with a single destination address (such as a VPN
device).
(Introduction.)
D.1 Capability negotiation
(Non-critical option in RRQ requesting use, and includes default
destination address (i.e. VPN address); critical option in RRP
confirms use.)
D.2 Packet processing
The overhead optimization is based on "address switching". When the
mobile node desires to send a packet to the default destination
address (e.g. a VPN device), it simply sets the packet source
address to the current care-of address, and destination address to
the home agent.
When the home agent receives such a packet, and the current mobility
binding indicates that zero-overhead tunnelling has been negotiated,
the home agent replaces the source address with mobile node home
address, and the destination address with the default destination
address (e.g. the VPN device).
MN x-HA VPN
! ! !
! ------------------> ! !
! rrq w/ skippable ! !
! ext (includes ! !
! VPN address) ! !
! ! !
! <------------------ ! !
! rrp w/ critical ! !
! ext acknowledging ! !
! support ! !
! ! !
[orig. packet] ! !
(IP(HoA,VPN) ! data) ! !
! ! !
[address switch] ! !
! ! !
! ------------------> ! !
Vaarala (Ed.) Expires October 8, 2003 [Page 48]
Internet-Draft MIPv4-VPN April 2003
! IP(CoA,x-HA) ! data ! !
! ! !
! [address switch] !
! ! !
! ! -------------------> !
! ! IP(HoA,VPN) ! data !
! ! !
! ! <------------------- !
! ! IP(VPN,HoA) ! data !
! ! !
! [address switch] !
! ! !
! <------------------ ! !
! IP(x-HA,CoA) ! data ! !
! ! !
[address switch] ! !
! ! !
[final packet] ! !
(IP(VPN,HoA) ! data) ! !
! ! !
The packets are sent using topologically correct addresses, thus
respecting ingress filtering rules, while there is no extra overhead
in encapsulating the packets.
(When zero-overhead allowed? must not be fragment, mobile node dest
address must be default destination.)
(Fallback encapsulation -- escaping to distinguish from zero-overhead
encapsulation. Must be used for re-registration when zero-overhead
registration is active. This is a "brittle" mechanism, so much
detail is needed. Another alternative is to assume that the MN never
needs to communicate to VPN UDP port 434. This would make the
mechanism less generic, however.)
(Impact of NAT traversal.)
(Handling of MTU and ICMP.)
Vaarala (Ed.) Expires October 8, 2003 [Page 49]
Internet-Draft MIPv4-VPN April 2003
Appendix E. Proposed solutions
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: Appendix E.1.
o Option 1.2: Appendix E.2.
o Option 1.3: Appendix E.3.
o Option 2: Appendix E.4.
o Option 3: Appendix E.5.
o Option 4: Appendix E.6.
o Option 5: Appendix E.7.
o Option 6: Appendix E.8.
o Option 7: Appendix E.9.
E.1 Dual HA (draft-nuopponen-vaarala-mipvpn-00)
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 [8].
Pros:
o Does not require specification of new protocols (but an algorithm
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 50]
Internet-Draft MIPv4-VPN April 2003
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
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 51]
Internet-Draft MIPv4-VPN April 2003
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).
E.1.1 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 [13] and [3], 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
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
Vaarala (Ed.) Expires October 8, 2003 [Page 52]
Internet-Draft MIPv4-VPN April 2003
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.
E.2 Optimized dual HA (draft-adrangi-mobileip-mipvpn-traversal-00)
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 [9].
Pros:
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 53]
Internet-Draft MIPv4-VPN April 2003
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
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 54]
Internet-Draft MIPv4-VPN April 2003
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
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
Vaarala (Ed.) Expires October 8, 2003 [Page 55]
Internet-Draft MIPv4-VPN April 2003
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 VPN 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 Appendix E.1.1 apply to this
proposal as well.
E.3 Use of Mobile IP signaling to VPN gateway (route optimization)
Use of Mobile IP signaling to VPN gateway (use of Update message to
update the MN binding).
Pros:
o Works well even if there is a outside HA (by another
party/operator).
Cons:
Vaarala (Ed.) Expires October 8, 2003 [Page 56]
Internet-Draft MIPv4-VPN April 2003
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.
E.4 MIP proxy (draft-adrangi-mobileip-vpn-traversal-02)
The proposed Mobile IPv4 proxy solution is described in [10]. 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.
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).
Vaarala (Ed.) Expires October 8, 2003 [Page 57]
Internet-Draft MIPv4-VPN April 2003
* 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
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 58]
Internet-Draft MIPv4-VPN April 2003
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.
E.5 Making VPN GW accept outer IP changes
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
list.
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 59]
Internet-Draft MIPv4-VPN April 2003
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?
o Is this within the purview of IPsec?
o Can we make this a recommendation for VPN gateways?
E.6 Use IPsec instead of GRE/IP-IP for MIP tunnelling
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.
Pros:
Vaarala (Ed.) Expires October 8, 2003 [Page 60]
Internet-Draft MIPv4-VPN April 2003
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
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.
E.7 Host routing and end-to-end security
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.)
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.
Vaarala (Ed.) Expires October 8, 2003 [Page 61]
Internet-Draft MIPv4-VPN April 2003
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.
E.8 Explicit signaling to update IPsec endpoint
This proposal is essentially the same as Appendix E.5 except that
explicit signalling is used to update IPsec SA endpoints. The form
of signalling could be e.g. Mobile IP messages.
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?
E.9 Use Foreign Agent to route ESP
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.) Expires October 8, 2003 [Page 62]
Internet-Draft MIPv4-VPN April 2003
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.) Expires October 8, 2003 [Page 63]
Internet-Draft MIPv4-VPN April 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.) Expires October 8, 2003 [Page 64]