Mobile IP S. Vaarala
Internet-Draft Stinghorn
Expires: July 6, 2005 E. Klovning
Birdstep
January 5, 2005
Mobile IPv4 Traversal Across IPsec-based VPN Gateways
draft-ietf-mip4-vpn-problem-solution-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 6, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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, and
a required mechanism for detecting the trusted internal network
securely. The solution requires only changes to the mobile node;
Vaarala & Klovning Expires July 6, 2005 [Page 1]
Internet-Draft MIPv4-VPN January 2005
changes to Mobile IPv4 or IPsec are not required.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Related work . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Terms and abbreviations . . . . . . . . . . . . . . . . . 6
1.5 Requirement levels . . . . . . . . . . . . . . . . . . . . 6
1.6 Assumptions and rationale . . . . . . . . . . . . . . . . 7
1.7 Why IPsec lacks mobility . . . . . . . . . . . . . . . . . 8
2. The Network Environment . . . . . . . . . . . . . . . . . . . 10
2.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
2.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . 12
2.3 Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
2.4 Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 13
2.5 NAT traversal . . . . . . . . . . . . . . . . . . . . . . 13
3. Internal network detection . . . . . . . . . . . . . . . . . . 15
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Implementation requirements . . . . . . . . . . . . . . . 16
3.2.1 Connection status change . . . . . . . . . . . . . . . 16
3.2.2 Registration-based internal network detection . . . . 16
3.2.3 Registration-based internal network monitoring . . . . 16
3.3 Proposed algorithm . . . . . . . . . . . . . . . . . . . . 18
3.4 Implementation issues . . . . . . . . . . . . . . . . . . 19
3.5 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Firewall configuration requirements . . . . . . . . . 20
3.5.2 Registration-based internal network monitoring . . . . 20
3.5.3 No encryption when inside . . . . . . . . . . . . . . 20
3.6 Improvements . . . . . . . . . . . . . . . . . . . . . . . 21
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Mobile node requirements . . . . . . . . . . . . . . . . . 22
4.2 VPN device requirements . . . . . . . . . . . . . . . . . 22
4.3 Home agent requirements . . . . . . . . . . . . . . . . . 22
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1 Comparison against guidelines . . . . . . . . . . . . . . 23
5.2 Packet overhead . . . . . . . . . . . . . . . . . . . . . 24
5.3 Latency considerations . . . . . . . . . . . . . . . . . . 25
5.4 Firewall state considerations . . . . . . . . . . . . . . 25
5.5 Intrusion detection systems (IDSs) . . . . . . . . . . . . 25
5.6 Implementation of mobile node . . . . . . . . . . . . . . 25
5.7 Non-IPsec VPN protocols . . . . . . . . . . . . . . . . . 26
6. Security considerations . . . . . . . . . . . . . . . . . . . 27
6.1 Internal network detection . . . . . . . . . . . . . . . . 27
6.2 Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 27
7. Intellectual property rights . . . . . . . . . . . . . . . . . 29
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
Vaarala & Klovning Expires July 6, 2005 [Page 2]
Internet-Draft MIPv4-VPN January 2005
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
A. Packet flow examples . . . . . . . . . . . . . . . . . . . . . 33
A.1 Connection setup for access mode 'cvc' . . . . . . . . . . 33
B. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . 39
Vaarala & Klovning Expires July 6, 2005 [Page 3]
Internet-Draft MIPv4-VPN January 2005
1. Introduction
The Mobile IP working group set out 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 current version of this document outlines the
proposed solution for IPv4.
The document contains two parts:
o a basic solution which is an applicability statement of Mobile
IPv4 and IPsec to provide session mobility between enterprise
Intranets and other external networks, intended for enterprise
mobile users; and
o a technical specification and a set of requirements for secure
detection of the internal and the external networks.
Mobile IPv4 and IPsec can be combined in different ways by changing
the requirements and core assumptions. The solution specified in
this document is most applicable when the assumption documented in
the problem statement [1] are valid; among others that the solution:
o must minimize changes to existing firewall/VPN/DMZ deployments;
o must ensure that traffic is not routed through the DMZ when the
mobile node is inside (to avoid scalability and management
issues);
o must support foreign networks with only foreign agent access;
o should not require changes to existing IPsec or key exchange
standards;
o must adhere to the Mobile IPv4 protocol (but may require new
extensions or multiple instances of Mobile IPv4); and
o must propose a mechanism to avoid or minimize IPsec re-negotiation
when mobile node moves.
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 unrestricted 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
[14].
The proposed solution is to use standard Mobile IPv4 when the mobile
Vaarala & Klovning Expires July 6, 2005 [Page 4]
Internet-Draft MIPv4-VPN January 2005
node is in the internal network, and to use the VPN tunnel endpoint
address for the 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.
This mobility is provided by 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.
Briefly, when outside, the mobile node:
o detects (securely) that it is outside (Section 3);
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 address as its co-located care-of address
with the internal home agent; this registration request is sent
inside the IPsec tunnel.
The solution requires control over the protocol layers in the mobile
node. It must be capable of (1) detecting whether it is inside or
outside in a secure fashion, and (2) control the protocol layers
accordingly. For instance, if the mobile node is inside, the IPsec
layer needs to become dormant.
Current Mobile IPv4 and IPsec standards, when used in a suitable
combination, are sufficient to implement the solution; no changes are
required to existing VPN devices, home agents, or foreign agents.
1.2 Scope
This document describes a solution for IPv4 only. The downside of
the described approach is that an external home agent is required,
and that the packet overhead (see Section 5) and overall complexity
increase. Optimizations would require changes to Mobile IPv4 and/or
IPsec, and are out of scope of this document.
VPN, in this document, refers to an IPsec-based remote access VPN.
Other types of VPNs are out of scope.
1.3 Related work
Related work has been done on Mobile IPv6 in [15] which discusses the
interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6
signaling. The draft also discusses dynamic updating of the IPsec
endpoint based on Mobile IP signaling packets.
Vaarala & Klovning Expires July 6, 2005 [Page 5]
Internet-Draft MIPv4-VPN January 2005
The "transient pseudo-NAT" attack, described in [16] and [6], affects
any approach which attempts to provide security of mobility signaling
in conjunction with NAT devices. In many cases, one cannot assume
any co-operation from NAT devices which thus have to be treated as
any other networking entity.
1.4 Terms and abbreviations
co-CoA: co-located care-of address
DMZ: (DeMilitarized Zone) A small network inserted as a "neutral
zone" between a company's private network and the outside public
network to prevent outside users from getting direct access to the
company's private network
external network: the untrusted network (i.e. Internet). Note that
a private network (e.g. another corporate network) other than the
mobile node's internal network is considered an external network.
FA: Mobile IPv4 foreign agent
FA-CoA: foreign agent care-of address
FW: Firewall
internal network: the trusted network; for instance, a physically
secure corporate network where the i-HA is located.
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 [7]
i-HoA: home address of the mobile node in the internal home agent
MN: Mobile Node
NAI: Network Access Identifier [4]
R: Router
VPN: Virtual Private Network based on IPSEC
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.
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
1.5 Requirement levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
Vaarala & Klovning Expires July 6, 2005 [Page 6]
Internet-Draft MIPv4-VPN January 2005
1.6 Assumptions and rationale
The proposed solution is an attempt to solve the problem described in
[1]. The major assumptions and their rationale is summarized below.
Changes to existing firewall and VPN deployments should be minimized:
o The current deployment of firewalls and IPsec-based VPNs is much
larger than corresponding Mobile IPv4 elements. Thus, a solution
should work within the existing infrastructure.
o Current enterprise network deployments typically centralize
management of security and network access into a compact DMZ.
When the mobile node is inside, traffic should not go through the DMZ
network:
o Routing all mobile node traffic through the DMZ is seen as a
performance problem in existing deployments of firewalls. The
more sophisticated firewall technology is used (e.g. content
scanning), the more serious the performance problem is.
o Current deployments of firewalls and DMZs in general have been
optimized for the case where only a small minority of total
enterprise traffic goes through the DMZ. Furthermore, users of
current VPN remote access solutions do not route their traffic
through the DMZ when connected to an internal network.
An home agent inside the enterprise cannot be reached directly from
outside, even if the home agent contains IPsec functionality:
o Deployment of current combined IPsec/MIPv4 solutions are not
common in large installations.
o Doing decryption in the home agents "deep inside" the enterprise
effectively means having a security perimeter much larger than the
typical, compact DMZ used by a majority of enterprises today.
o In order to maintain a security level equal to current firewall/
DMZ deployments, every home agent decapsulating IPsec would need
to do the same firewalling as the current DMZ firewalls (content
scanning, connection tracking, etc).
Traffic cannot be encrypted when the mobile node is inside:
o There is a considerable performance impact on home agents (which
currently do rather light processing), and mobile nodes
(especially for small devices). Note that traffic throughput
inside the enterprise is typically order(s) of magnitude larger
than the remote access traffic through a VPN.
o Encryption consumes processing power and has a significant impact
on device battery life.
o There is also a usability issue involved; the user needs to
authenticate connection to the IPsec layer in the home agent to
gain access. For interactive authentication mechanisms (e.g.
SecurID) this always means user interaction.
Vaarala & Klovning Expires July 6, 2005 [Page 7]
Internet-Draft MIPv4-VPN January 2005
o Furthermore, if there is a separate VPN device in the DMZ for
remote access, the user needs to authenticate to both devices, and
might need to have separate credentials for both.
o Current Mobile IPv4 home agents do not typically incorporate IPsec
functionality, which is relevant for the proposed solution when we
assume zero or minimal changes to existing Mobile IPv4 nodes.
o Note, however, that the assumption (no encryption when inside)
does not necessarily apply to all solutions in the solution space;
if the abovementioned problems were resolved there is no
fundamental reason why encryption could not be applied when
inside.
1.7 Why IPsec lacks mobility
IPsec, as currently specified [3] requires that a new IKE negotiation
be done whenever an IPsec peer moves (i.e. changes care-of address).
The main reason is that a security association is uni-directional and
identified by a triplet consisting of (1) the destination address
(which is the outer address when tunnel mode is used), (2) the
security protocol (ESP or AH), and (3) the Security Parameter Index
(SPI) ([3], Section 4.1). Although an implementation is not required
to use all of these for its own SAs, an implementation cannot assume
that a peer does not.
When a mobile IPsec peer sends packets to a stationary IPsec peer,
there is no problem; the SA is "owned" by the stationary IPsec peer,
and therefore the destination address does not need to change. The
(outer) source address should be ignored by the stationary peer
(although some implementations do check the source address as well).
The problem arises when packets are sent from the stationary peer to
the mobile peer. The destination address of this SA (SAs are
unidirectional) is established during IKE negotiation, and is
effectively the care-of address of the mobile peer at time of
negotiation. Therefore the packets will be sent to the original
care-of address, not a changed care-of address.
The IPsec NAT traversal mechanism can also be used for limited
mobility, but UDP tunneling needs to be used even when there is no
NAT in the route between the mobile and the stationary peers.
Furthermore, support for changes in current NAT mapping is not
required by the NAT traversal specification (draft)[8].
In summary, although the IPsec standard does not as such prevent
mobility (in the sense of updating security associations on-the-fly),
there is no standardized mechanism (explicit or implicit) for doing
so. Therefore it is assumed throughout this document that any change
in the addresses comprising the identity of an SA requires IKE
Vaarala & Klovning Expires July 6, 2005 [Page 8]
Internet-Draft MIPv4-VPN January 2005
re-negotiation, which implies too heavy computation and too large
latency for useful mobility.
Vaarala & Klovning Expires July 6, 2005 [Page 9]
Internet-Draft MIPv4-VPN January 2005
2. The Network Environment
Enterprise users will access both the internal and external networks
using different networking technologies. In some networks, the MN
will use FAs and in others it will anchor at the HA using co-located
mode. The following figure describes an example network topology
illustrating the relationship between the internal and external
networks, the possible locations of the mobile node (i.e. (MN)).
In every possible location described in the figure, the mobile node
can establish a connection to the corresponding HA(s) 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 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 four access modes:
c: i-MIP w/ co-CoA
f: i-MIP w/ FA-CoA
cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA
fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA
This notation is more useful when optimizations to protocol layers
are considered. The notation is preserved here so that work on the
optimizations can refer to a common notation.
Vaarala & Klovning Expires July 6, 2005 [Page 10]
Internet-Draft MIPv4-VPN January 2005
(MN) {fvc} {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} (MN) {c} (MN) {f}
Figure: Basic topology, possible MN locations and access modes
The internal network is typically a multi-subnetted network using
private addressing [7]. Subnets may contain internal home agent(s),
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 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 or the x-HA and the VPN.
* There may be also be NAT(s) between the VPN and the i-HA, or a
NAT integrated into the VPN. 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.
o Site-to-site VPN tunnels are not shown. Although mostly
transparent, IPsec endpoints may perform ingress filtering as part
of enforcing their policy.
o The figure represents a topology where each functional entity is
illustrated as a separate device. However, it is possible that
several network functions are co-located in a single device. In
fact, all three server components (x-HA, VPN, and i-HA) may be
Vaarala & Klovning Expires July 6, 2005 [Page 11]
Internet-Draft MIPv4-VPN January 2005
co-located in a single physical device.
The following issues are also important when considering enterprise
mobile users:
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. IPsec and Mobile IPv4 are
incompatible with such networks.
Whenever a mobile node obtains either a co-CoA or a FA-CoA, the
following conceptual steps 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 3 (or a vendor
specific mechanism fulfilling the requirements described).
o The mobile node performs necessary registrations and other
connection setup signaling for the protocol layers (in the
following order):
* x-MIP (if used);
* VPN (if used); and
* i-MIP.
Note that these two tasks are intertwined to some extent: detection
of the internal network results in a successful registration to the
i-HA using the proposed network detection algorithm. An improved
network detection mechanism not based on Mobile IPv4 registration
messages might not have this side-effect.
The following subsections describe the different access modes and the
requirements for registration and connection setup phase.
2.1 Access mode: 'c'
This access mode is standard Mobile IPv4 [5] 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 4).
2.2 Access mode: 'f'
This access mode is standard Mobile IPv4 [5] with a foreign agent
care-of address, except that
Vaarala & Klovning Expires July 6, 2005 [Page 12]
Internet-Draft MIPv4-VPN January 2005
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 4).
2.3 Access mode: 'cvc'
Steps:
o The mobile node obtains a care-of address.
o The mobile node detects it is not inside and registers with the
x-HA, where
* T-bit MAY be set (reverse tunneling)
o If the mobile node does not have an existing IPsec security
association, it uses IKE to set up an IPsec security association
with the VPN gateway, using the x-HoA as the IP address for IKE/
IPsec communication. How the VPN-TIA is assigned is outside the
scope of this document.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, where
* T-bit MUST be set (reverse tunneling)
2.4 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,
where
* T-bit MAY be set (reverse tunneling)
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. How the VPN-TIA is assigned is
outside the scope of this document.
o The mobile node sends a MIPv4 RRQ to the i-HA, registering the
VPN-TIA as a co-located care-of address, where
* T-bit MUST be set (reverse tunneling)
2.5 NAT traversal
NAT devices may affect each layer independently. Mobile IPv4 NAT
traversal SHOULD be supported for x-MIP and i-MIP layers, while
IPsec NAT traversal [8][9] SHOULD be supported for the 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
Vaarala & Klovning Expires July 6, 2005 [Page 13]
Internet-Draft MIPv4-VPN January 2005
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 & Klovning Expires July 6, 2005 [Page 14]
Internet-Draft MIPv4-VPN January 2005
3. Internal network detection
Secure detection of the internal network is critical to prevent
plaintext traffic to be sent over an untrusted network. In other
words, the overall security (confidentiality and integrity of user
data) relies on the security of IPsec and the internal network
detection mechanism. 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 has left the internal network. Entry
into the internal network is easier security-wise: the mobile node
can 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 in time.
Several events can cause the mobile node to leave the internal
network, including:
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 and the networking
technlogy. 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 3.2; this ensures that basic
security requirements are fulfilled. The basic algorithm described
in Section 3.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
Section 3.1.
3.1 Assumptions
The firewall MUST be configured to block traffic originating from
Vaarala & Klovning Expires July 6, 2005 [Page 15]
Internet-Draft MIPv4-VPN January 2005
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.
The firewall MAY be configured to block registration traffic to the
x-HA originating from within the internal network, which makes the
network detection algorithm simpler and more robust. However, 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.
3.2 Implementation requirements
Any mechanism used to detect the internal network MUST fulfill the
following requirements.
3.2.1 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 and
necessary registrations and VPN tunnel establishment have been
completed.
The mechanisms used to detect a connection status change depends on
the mobile node implementation, the networking technology, and the
access mode.
3.2.2 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.
3.2.3 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).
Vaarala & Klovning Expires July 6, 2005 [Page 16]
Internet-Draft MIPv4-VPN January 2005
A simple approach to fulfill the requirement is to start
re-registration every (T_MONITOR - N) seconds when inside (where N is
a grace period which ensures that re-registration is completed before
T_MONITOR seconds are up). To bound the maximum amount of time that
such a leak may persist, the mobile node must fulfill the following
security requirements when inside:
o The mobile node MUST NOT send or receive a user data packet (i.e.
any IPv4 packet other than a Mobile IPv4 signaling packet) if more
than T_MONITOR seconds has elapsed since last successful
(re-)registration with the i-HA.
o If more than T_MONITOR seconds has elapsed, data packets MUST be
either dropped or queued. If the packets are queued, the queues
MUST NOT be processed until the re-registration has been
successfully completed without a connection status change.
o The T_MONITOR parameter MUST be configurable, and have the default
value of 60 seconds. This default is a trade-off between traffic
overhead and a reasonable bound to exposure.
This approach is reasonable for a wide range of mobile nodes (e.g.
laptops), but has unnecessary overhead when the mobile node is idle
(not sending or receiving packets). If re-registration does not
complete before T_MONITOR seconds are up, data packets must be queued
or dropped as specified above. Note that re-registration packets
must be sent even if bi-directional user data traffic is being
relayed: data packets are no substitute for an authenticated
re-registration.
To minimize traffic overhead when the mobile node is idle,
re-registrations can be stopped when no traffic is being sent or
received. If the mobile node subsequently receives or needs to send
a packet, the packet must be dropped or queued (as specified above)
until a re-registration with the i-HA has been successfully
completed. Athough this approach adds packet processing complexity,
it may be appropriate for small battery powered devices which may be
idle much of the time. (Note that ordinary re-registration before
the mobility binding lifetime is exhausted should still be done.)
T_MONITOR is required to be configurable so that an administrator can
determine the required security level for the particular deployment.
Configuring T_MONITOR in the order of few seconds is not practical;
alternative mechanisms need to be considered if such confidence is
required.
The re-registration mechanism is a worst case fallback mechanism. If
additional information (such as layer two triggers) are available to
the mobile node, the mobile node SHOULD use the triggers to detect MN
movement and restart the detection process to minimize exposure.
Vaarala & Klovning Expires July 6, 2005 [Page 17]
Internet-Draft MIPv4-VPN January 2005
Note that re-registration is required by Mobile IPv4 by default
(except for the untypical case of an infinite binding lifetime);
however, the re-registration interval may be much larger when using
an ordinary Mobile IPv4 client. Shorter re-registration interval is
usually not an issue, because the internal network is typically a
fast, wired network, and the shortened re-registration interval
applies only when the mobile node is inside the internal network.
When outside, the ordinary Mobile IPv4 re-registration process (based
on binding lifetime) is used.
3.3 Proposed algorithm
When the MN detects that it has changed its point of network
attachment on a certain interface, 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 while
it waits for a response from the i-HA.
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 they are security related parameters (see Section
3.2.3). If the re-registration fails, the MN MUST stop sending and
receiving plaintext traffic, and MUST restart the detection
algorithm.
Plaintext re-registration messages 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. (However,
when the mobile node is outside, it re-registers independently with
the x-HA using plaintext, and with the i-HA through the VPN tunnel.)
Vaarala & Klovning Expires July 6, 2005 [Page 18]
Internet-Draft MIPv4-VPN January 2005
Postponing the IPSec connection setup could prevent aborted IKE
sessions. Aborting IKE sessions may be a problem in some cases
because IKE does not provide a reliable, standardized, and
mandatory-to-implement mechanism for terminating a session cleanly.
If the x-HA is not reachable from inside (i.e. the firewall
configuration is known), a detection period of zero is preferred, as
it minimizes connection setup overhead and causes no timing problems.
Should the assumption have been invalid and a response from the i-HA
received after a response from the x-HA, the MN SHOULD re-register
with the i-HA directly.
3.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,
testing against deployed foreign agents seems to indicate that a
majority of available foreign agents handle this situation.
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.
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
registration reply from the i-HA after IPsec connection setup has
been started, the MN SHOULD still switch to using the i-HA directly.
3.5 Rationale
Vaarala & Klovning Expires July 6, 2005 [Page 19]
Internet-Draft MIPv4-VPN January 2005
3.5.1 Firewall configuration requirements
The requirement that the i-HA cannot be reached from the external
network is necessary. If not, 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
or not!). 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.
3.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.
3.5.3 No encryption when inside
If encryption was applied also when MN was inside, there would be no
security reason to monitor the internal network periodically.
The main rationale for why encryption cannot be applied when the MN
is inside was given in Section 1.6. In short, the main issues are
(1) power consumption; (2) extra CPU load, especially because
internal networks are typically switched networks and a lot of data
may be routinely transferred; (3) existing HA devices do not
typically integrate IPsec functionality; (4) (IPsec) encryption
requires user authentication, which may be interactive in some cases
Vaarala & Klovning Expires July 6, 2005 [Page 20]
Internet-Draft MIPv4-VPN January 2005
(e.g. SecurID) and thus a usability issue; and (5) user may need to
have separate credentials for VPN devices in the DMZ and the HA.
3.6 Improvements
The registration process can be improved in many ways. One simple
way is to make the x-HA detect whether a registration request came
from inside or outside. If it came from inside, the x-HA can simply
drop the registration request.
This approach is feasible without protocol changes in scenarios where
a corporation owns both the VPN and the x-HA. The x-HA can simply
determine based on incoming interface identifier (or the router which
relayed the packet) whether the registration request came from inside
or not.
In other scenarios protocol changes may be needed. Such changes are
out of scope of this document.
Vaarala & Klovning Expires July 6, 2005 [Page 21]
Internet-Draft MIPv4-VPN January 2005
4. Requirements
4.1 Mobile node requirements
The mobile node MUST implement an internal network detection
algorithm fulfilling the requirements set forth in Section 3.2.
The mobile node MUST support access modes: c, f, cvc, fvc (Section
2).
The mobile node SHOULD support Mobile IPv4 NAT traversal [6] for both
internal and external Mobile IP.
The mobile node SHOULD support IPsec NAT traversal [8][9].
When the mobile node has direct access to the i-HA, it SHOULD use
only the inner Mobile IPv4 layer to minimize firewall and VPN impact.
4.2 VPN device requirements
The VPN security policy MUST allow communication using UDP to the
internal home agent(s), with home agent port 434 and any remote port.
The security policy SHOULD allow IP-IP to internal home agent(s) in
addition to UDP port 434.
The VPN device SHOULD implement the IPsec NAT traversal mechanism
described in [8][9].
4.3 Home agent requirements
The home agent SHOULD implement the Mobile IPv4 NAT traversal
mechanism described in [6]. (This also refers to the i-HA: NAT
traversal is required to support VPNs that NAT VPN tunnel addresses
or block IP-IP traffic.)
Vaarala & Klovning Expires July 6, 2005 [Page 22]
Internet-Draft MIPv4-VPN January 2005
5. 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.
5.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.
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.
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.
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,
which may be an issue for multi-vendor interoperability.
MIPv4 protocol
o The solution adheres to the MIPv4 protocol.
o The solution requires the use of two parallel MIPv4 layers.
Handoff overhead
o The solution provides a mechanism to avoid VPN tunnel SA
renegotiation upon movement by using 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.
Functional entities
o The solution does not impose any new types of functional entities
or required changes to existing entities. However, an external HA
device is required.
Vaarala & Klovning Expires July 6, 2005 [Page 23]
Internet-Draft MIPv4-VPN January 2005
Implications of intervening NAT gateways
o The solution leverages existing MIPv4 NAT traversal [6] and IPsec
NAT traversal [8][9] solutions and does not require any new
functionality to deal with NATs.
Security implications
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 More security considerations are described in Section 6.
5.2 Packet overhead
The maximum packet overhead depends on access mode as follows:
o f: 0 octets
o c: 20 octets
o fvc: 77 octets
o cvc: 97 octets
The overhead consists of the following:
o IP-IP for i-MIPv4: 20 octets
o IPsec ESP: 57 octets total, consisting of: 20 (new IP header),
4+4+8 = 16 (SPI, sequence number, cipher initialization vector),
7+2 = 9 (padding, padding length field, next header field), 12
(ESP authentication trailer)
o IP-IP for x-MIPv4: 20 octets
When IPsec is used, a variable amount of padding is present in each
ESP packet. The figures 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 [10]), 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 [8][9] is used and 12 octets when MIP NAT traversal [6]
is used. For instance, when using access mode cvc, the maximum NAT
traversal overhead is 12+8+12 = 32 octets. Thus, the worst case
scenario (with the abovementioned ESP assumptions) is 129 octets for
cvc.
Vaarala & Klovning Expires July 6, 2005 [Page 24]
Internet-Draft MIPv4-VPN January 2005
5.3 Latency considerations
TBD: rewrite this section.
5.4 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 do not 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.
5.5 Intrusion detection systems (IDSs)
Many firewalls incorporate intrusion detection systems monitoring
network traffic for unusual patterns and clear signs of attack.
Since traffic from a mobile node implementing this specification is
UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address,
existing IDSs may treat the traffic differently than ordinary VPN
remote access traffic. Like firewalls, IDSs are not standardized, so
it is impossible to guarantee interoperability with any particular
IDS system.
5.6 Implementation of mobile node
Implementation of the mobile node requires the use of three tunneling
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 interface at
Vaarala & Klovning Expires July 6, 2005 [Page 25]
Internet-Draft MIPv4-VPN January 2005
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.
5.7 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.
Vaarala & Klovning Expires July 6, 2005 [Page 26]
Internet-Draft MIPv4-VPN January 2005
6. Security considerations
6.1 Internal network detection
If the mobile node by mistake 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 [5] 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
especially 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.
6.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 signaling 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 the solution outlined in this document, 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 & Klovning Expires July 6, 2005 [Page 27]
Internet-Draft MIPv4-VPN January 2005
may be weak if easily memorizable secrets are chosen, thus opening up
redirection attacks described above. Note that a weak secret in the
i-HA is fatal to security, as the mobile node can be fooled into
dropping encryption if the i-HA secret is broken.
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 [16] and [6], 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.
Vaarala & Klovning Expires July 6, 2005 [Page 28]
Internet-Draft MIPv4-VPN January 2005
7. 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.
Intel may or may not have patents or patent applications related to
the non-mandatory mechanisms described in this document.
Vaarala & Klovning Expires July 6, 2005 [Page 29]
Internet-Draft MIPv4-VPN January 2005
8. 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 (Stinghorn)
- 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. Special thanks to Radia Perlman for
giving the document a thorough read and a security review. Tom
Hiller pointed out issues with battery powered devices. We would
also like to thank the previous Mobile IP working group chairs
(Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important
feedback and guidance.
9 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[4] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
Vaarala & Klovning Expires July 6, 2005 [Page 30]
Internet-Draft MIPv4-VPN January 2005
2002.
[6] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
Address Translation (NAT) Devices", RFC 3519, April 2003.
[7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", RFC 1918, BCP
5, February 1996.
[8] 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.
[9] 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.
[10] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[11] Nuopponen, A. and S. Vaarala, "Mobile IPv4 coexistence with
IPsec remote access tunnelling
(draft-nuopponen-vaarala-mipvpn-00, work in progress)", July
2002.
[12] 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.
[13] 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.
[14] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage",
December 2002.
[15] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents (draft-ietf-mobileip-mipv6-ha-ipsec-01, work in
progress)", October 2002.
[16] 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)",
Vaarala & Klovning Expires July 6, 2005 [Page 31]
Internet-Draft MIPv4-VPN January 2005
December 2002.
Authors' Addresses
Sami Vaarala
Stinghorn
Elimaenkatu 12-16 6B
Espoo 00510
FINLAND
Phone: +358 (0)201 4425 50
EMail: sami.vaarala@iki.fi
Espen Klovning
Birdstep
Bryggegata 7
Oslo 0250
NORWAY
Phone: +47 95 20 26 29
EMail: espen@birdstep.com
Vaarala & Klovning Expires July 6, 2005 [Page 32]
Internet-Draft MIPv4-VPN January 2005
Appendix A. Packet flow examples
A.1 Connection setup for access mode 'cvc'
The following figure illustrates connection setup when the mobile
node is outside and using a co-located care-of address. IKE
connection setup is not shown in full, and involves multiple round
trips (4.5 round trips when using main mode followed by quick mode).
MN-APP MN x-HA VPN i-HA CN
! ! ! ! ! !
! ! -------> ! ! ! !
! ! rrq ! ! ! !
! ! -----------------------------X ! ! rrq not
! ! rrq ! ! ! ! received
! ! ! ! ! ! by i-HA
! ! <------- ! ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
! [wait for detection period for response from i-HA] !
! [may also retransmit to i-HA, depending on config] ! no rrp
! ! ! ! ! ! from i-HA
! ! ==(1)==> ! ! ! !
! ! ike {1a}! -------> ! ! !
! ! ! ike ! ! !
! ! ! <------- ! ! !
! ! <==(1)== ! ike ! ! !
! ! ike ! ! ! !
: : : : : :
: : : : : :
! ! ! ! ! !
! ! ==(2)==> ! ! ! !
! ! rrq {2a}! ==(1)==> ! ! !
! ! ! rrq {2b}! -------> ! !
! ! ! ! rrq {2c}! !
! ! ! ! <------- ! !
! ! ! <==(1)== ! rrp ! !
! ! <==(2)== ! rrp ! ! !
! ! rrp ! ! ! !
! ! ! ! ! !
[[--- connection setup ok, bidirectional connection up ---]]
! ! ! ! ! !
! -------> ! ! ! ! !
! pkt {3a}! ==(3)==> ! ! ! !
! ! pkt {3b}! ==(2)==> ! ! !
! ! ! pkt {3c}! ==(1)==> ! !
! ! ! ! pkt {3d}! -------> !
! ! ! ! ! pkt {3e}!
Vaarala & Klovning Expires July 6, 2005 [Page 33]
Internet-Draft MIPv4-VPN January 2005
! ! ! ! ! <------- !
! ! ! ! <==(1)== ! pkt !
! ! ! <==(2)== ! pkt ! !
! ! <==(3)== ! pkt ! ! !
! <------ ! pkt ! ! ! !
! pkt ! ! ! ! !
: : : : : :
: : : : : :
The notation "==(N)==>" or "<==(N)==" indicates that the innermost
packet has been encapsulated N times, using IP-IP, ESP, or MIP NAT
traversal.
Packets marked with {xx} are shown in more detail below. Each area
represents a protocol header (labeled). Source and destination
addresses or ports are shown underneath the protocol name when
applicable. Note that there are no NAT traversal headers in the
example packets.
Packet {1a}
.------------------------------------.
! IP ! IP ! UDP ! IKE !
! co-CoA ! x-HoA ! 500 ! !
! x-HA ! VPN-GW ! 500 ! !
`------------------------------------'
Packet {2a}
.--------------------------------------------------------.
! IP ! IP ! ESP ! IP ! UDP ! MIP RRQ !
! co-CoA ! x-HoA ! ! VPN-TIA ! ANY ! !
! x-HA ! VPN-GW ! ! i-HA ! 434 ! !
`--------------------------------------------------------'
Packet {2b}
.----------------------------------------------.
! IP ! ESP ! IP ! UDP ! MIP RRQ !
! x-HoA ! ! VPN-TIA ! ANY ! !
! VPN-GW ! ! i-HA ! 434 ! !
`----------------------------------------------'
Packet {2c}
.----------------------------.
! IP ! UDP ! MIP RRQ !
! VPN-TIA ! ANY ! !
! i-HA ! 434 ! !
`----------------------------'
Packet {3a}
Vaarala & Klovning Expires July 6, 2005 [Page 34]
Internet-Draft MIPv4-VPN January 2005
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b}
.------------------------------------------------------- -
! IP ! IP ! ESP ! IP ! IP ! user \
! co-CoA ! x-HoA ! ! VPN-TIA ! i-HoA ! protocol../
! x-HA ! VPN-GW ! ! i-HA ! CN ! \
`------------------------------------------------------- -
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
Packet {3c}
.--------------------------------------------------------.
! IP ! ESP ! IP ! IP ! user ! ESP !
! x-HoA ! ! VPN-TIA ! i-HoA ! protocol ! trailer !
! VPN-GW ! ! i-HA ! CN ! ! !
`--------------------------------------------------------'
Packet {3d}
.------------------------------.
! IP ! IP ! user !
! VPN-TIA ! i-HoA ! protocol !
! i-HA ! CN ! !
`------------------------------'
Packet {3e}
.-------------------.
! IP ! user !
! i-HoA ! protocol !
! CN ! !
`-------------------'
Packet {3b} with all NAT traversal headers (x-MIP, ESP, and i-MIP) is
shown below for comparison.
Vaarala & Klovning Expires July 6, 2005 [Page 35]
Internet-Draft MIPv4-VPN January 2005
Packet {3b} (with NAT traversal headers)
.------------------------------------------------- -
! IP ! UDP ! MIP ! IP ! UDP ! ESP.. \
! co-CoA ! ANY ! tunnel ! x-HoA ! 4500 ! /
! x-HA ! 434 ! data ! VPN-GW ! 4500 ! \
`------------------------------------------------- -
<=== external MIPv4 ====> <=== IPsec ESP ======== = =
- - ------------------------------------------------ -
\..ESP ! IP ! UDP ! MIP ! IP ! user \
/ ! VPN-TIA ! ANY ! tunnel ! i-HoA ! protocol../
\ ! i-HA ! 434 ! data ! CN ! \
- - ------------------------------------------------ -
= ===> <==== internal MIPv4 ====> <== user packet == =
- - -----------------.
\..user ! ESP !
/ protocol ! trailer !
\ ! !
- - -----------------'
= = ======> <= ESP =>
Vaarala & Klovning Expires July 6, 2005 [Page 36]
Internet-Draft MIPv4-VPN January 2005
Appendix B. Changes
Changes from draft-ietf-mip4-vpn-problem-solution-00 to
draft-ietf-mip4-vpn-problem-solution-01:
o Presentation style cleaned up in many places, wording changes
throughout the document to improve readability.
o More compact introduction section, terminology additions, IPsec
mobility problem description shortened.
o Sections 2 (topology) and 3 (access modes) merged.
o Section 6.8 (shortcoming for enterprise use) removed.
o Appendix A.2 (connection setup for access mode 'fvc') removed, it
contained mostly duplicate information (from A.1).
Changes from draft-ietf-mobileip-vpn-problem-solution-03 to
draft-ietf-mip4-vpn-problem-solution-00:
o Renamed and resubmitted document.
o New boilerplate to match RFCs 3667 and 3668.
Changes from -02 to -03:
o Remaining issues from security review worked into document.
o Short rationale for why (a) IPsec is not mobile, and (b) the
essential problem statement assumptions added.
o Minor wording changes (IETF 57 comments).
o Internal network monitoring section revised with "relaxed
re-registration" approach to improve applicability to battery
powered devices.
o IPR section needs to refer to on-line rights (and current text
moved on-line). Not done yet.
Changes from -01 to -02:
o Packet flow examples added.
o Explicit IDS reference added.
o Requirement levels adjusted; NAT traversal requirements changed
from MUST to SHOULD and other changes.
o MN no longer required to use i-HA directly whenever available (in
some cases that may not be desired).
o IPR section revised.
o Latency considerations section added.
o External HA reachability assumption refined; if firewall properly
configured, handover performance can be improved. This is now
mentioned in the detection section.
o Overhead section simplified, only base solution discussed.
o Proposed solutions section removed from appendix.
o Strawmen of optimizations removed from appendix, references to
optimizations removed from text.
Changes from -00 to -01:
Vaarala & Klovning Expires July 6, 2005 [Page 37]
Internet-Draft MIPv4-VPN January 2005
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 & Klovning Expires July 6, 2005 [Page 38]
Internet-Draft MIPv4-VPN January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vaarala & Klovning Expires July 6, 2005 [Page 39]
