Internet Engineering Task Force Farid Adrangi
INTERNET DRAFT Prakash Iyer
<draft-adrangi-mipv4-midbox-traversal-00> Intel Corp.
Date: July 2001
Expires: January 2002
Mobile IPv4 Traversal Across NAT and VPN Gateways
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.
To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
Wireless LANs or hot spots are starting to be widely deployed
in Enterprise Intranets and public areas such as airports,
coffee shops, shopping malls etc. based on IPv4. This combined
with the availability of multi-mode networked devices and
applications that can take advantage of continuous mobility and
constant reachability, is driving the need for Mobile IP in
these networks. At the same time, middleboxes (NAT and VPN
gateways for example) are also seeing widespread usage. Mobile
IPv4 has known functional and performance limitations in the
presence of these middleboxes. This draft proposes a solution
framework that enables seamless operation of Mobile IPv4 across
middleboxes without requiring any changes to the middleboxes
themselves. Although the solution is generically extensible,
Expires January 2002
[Page 1]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
the draft specifically focuses on NAT and VPN traversal. The
solution has no link layer dependencies and can be applied to
other 802.3-compatible physical media as well.
Table Of Contents
1. Introduction....................................................3
2. Terminology.....................................................4
3. Acronyms........................................................4
4. The MIP Proxy...................................................4
4.1. Surrogate MN Functionality....................................5
4.2. Surrogate HA Functionality....................................5
4.3. Deploying a MIP Proxy.........................................6
4.4. Discovering a MIP Proxy.......................................6
4.5. MIP Proxy Redundancy..........................................6
5. MIPv4 Traversal Through NAT Gateways............................6
5.1. NAT Traversal Problem Statement..............................6
5.2. Assumptions and Applicability.................................7
5.3. Using the MIP Proxy for NAT Traversal.......................8
5.3.1. When does a MN register with the MIP Proxy?................8
5.3.1.1. Selection of the COA Field in the Registration Request
Payload............................................................9
5.3.1.2. Discovery Registration Extension.........................10
5.3.2. MIPv4 registration protocol between MN and HA..............10
5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic11
5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy..11
5.3.2.3. Parameter Registration Extension.........................12
5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA.....12
5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN.......13
5.3.3. MIPv4 data traffic from MN to CN...........................14
5.3.4. MIPv4 data traffic from CN to MN...........................15
5.4. Summary of changes on MIPv4 components required by this
solution..........................................................16
5.4.1. Required Changes to a MN...................................16
5.4.2. Required Configuration for the MIP Proxy...................16
5.5. Performance Implications of MIP Proxy assisted NAT Traversal.16
5.6. Implications of Twice NAT between the MN and MIP Proxy.......16
6. MIPv4 Traversal Through IPsec VPN Gateways.....................16
6.1. IPsec VPN Traversal Problem Statement........................17
6.2. Integration of MIPv4 and IPsec...............................17
6.3. Assumptions and Applicability................................18
6.4. Solution Considerations......................................18
6.4.1. Fast Handoffs..............................................18
6.4.2. Preserve Existing VPN Infrastructure.......................18
6.4.3. Preserve Existing DMZ Traversal Policies...................19
6.5. Deploying the MIP Proxy to support VPN Traversal.............19
6.5.1. Mobile IPv4 Registration...................................19
6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA.....19
6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN.......20
6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration
Packets...........................................................20
6.5.2. Mobile IPv4 Data Processing................................21
Adrangi, Iyer
Expires January 2002
[Page 2]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
6.5.2.1. MIPv4 Data Traffic from MN to CN.........................21
6.5.2.2. MIPv4 Data Traffic from CN to MN.........................23
6.5.3. Support For Route Optimization.............................24
6.6. Key Management and SA Preservation...........................24
6.7. DMZ and VPN Gateway Configuration Requirements...............25
6.8. Supporting Other IPsec-based VPN Configurations..............25
6.9. Considerations for Integrating the MIP Proxy and VPN Gateway.25
7. Using the MIP Proxy for combined NAT and VPN Traversal.........25
7.1. MIPv4 Registration Message Flow..............................26
7.1.1. MIPv4 Registration Requests................................26
7.1.2. MIPv4 Registration Replies.................................26
7.2. MIPv4 Data Flow..............................................27
7.2.1. Data Flow from the MN to the CN............................27
7.2.2. Data Flow from the CN to the MN............................28
8. Security Implications..........................................29
9. Acknowledgements...............................................29
10. Patents.......................................................29
11. References....................................................29
1. Introduction
The deployment of 802.3-based wired LANs and wireless LAN hot
spots and WAN packet data networks based on 2.5G and 3G
technologies and the availability of multi-mode networked
devices is driving new application scenarios that require
Mobile IPv4 support. These networks are also seeing widespread
use of NAT and VPN gateways. For example, many Enterprises are
deploying wireless LANs outside their corporate DeMilitarized
Zone (DMZ), requiring mobile nodes to "VPN" back into the
Intranet, from NATÆed subnets. Wireless WAN operators are
setting up to offer routable IPv4 addresses to corporate
clients for remote access back to their Enterprise networks,
while offering NAT-based access to their core network and the
Internet to consumers. NAT and firewall-enabled residential
networks are another example where mobile nodes could encounter
such middleboxes. Mobile IPv4 has known functional and
performance limitations, traversing these middleboxes. It is
often unacceptable to deploy workarounds that require any
software or hardware changes to these middleboxes or compromise
their functionality in any way.
The solution proposed in this draft introduces a logical
component called the MIP Proxy to enable seamless Mobile IPv4
functionality across such middleboxes, without requiring any
changes to these middleboxes.
The important sections of this draft are organized as follows:
Section 4 describes the MIP proxy.
Section 5 discusses seamless traversal through NAT gateways.
Section 6 discusses seamless traversal through VPN gateways.
These two solutions can be deployed independently or in
combination depending on specific network configurations, as
discussed in section 7.
Adrangi, Iyer Expires January 2002 [Page 3]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
2. Terminology
Administrative Domain:
A Mobile IP administrative domain specifies the Mobile IP
security parameters for one or more home agents and their
corresponding mobile nodes. The security parameters are used
for authentication or encryption to provide a secure channel
for the Mobile IP control and data traffic between the home
agent and mobile nodes.
Actual Home Agent:
It is the mobile nodeÆs real home agent, as defined by
[RFC2002].
NAT-Router:
It is an IPv4 Router with NAT functionality.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this draft are to be interpreted as described in
[RFC2119].
3. Acronyms
GRE: Generic Routing Encapsulation
ISP: Internet Service provider
MIPv4: Mobile IP for IPv4
MIPv6: Mobile IP for IPv6
NAT: Network Address Translator
MN-Perm: Permanent home address of the MN
MN-COA: Co-located care-of address of the MN
MIPP-Priv: MIP Proxy interface address on the private (HA) side
MIPP-Pub: MIP Proxy interface address on the public side
NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side
NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side
IP-D: IP Destination Address
IP-S: IP source Address
VPNGW-Pub: VPN Gateway Public/External IP Address
VPNGW-Priv: VPN Gateway Private/Intranet IP Address
4. The MIP Proxy
The MIP Proxy is a functional entity that is introduced in the
path between a MN and itÆs corresponding HA as depicted in the
figure below. The MIP Proxy serves two primary functions: that
of a surrogate MN and a surrogate HA to essentially "stitch" an
end-to-end connection between a MN and itÆs HA. A single MIP
Proxy can serve multiple MNs and HAs and can consequently be
associated with multiple home subnets. The MIP Proxy does not
replace any existing HAs. The MIP Proxy MUST belong to the same
administrative domain as any of its associated home agents. It
Adrangi, Iyer Expires January 2002 [Page 4]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
MUST share SAs for various MIPv4 registration extensions with
its associated HA(s).
+----+
| MN |------ +----+
+----+ | |--| HA |
. . . | | +----+
+----+ | +----------+ | +----+
| MN |------------| MIP Proxy|----------|--| HA |
+----+ | +----------+ | +----+
. . . | | +----+
+----+ | |--| HA |
| MN |----- +----+
+----+
Figure 4.0 : MIP Proxy serving multiple MNs and HAs
A MIP Proxy MAY support additional functionality in the context
of support for a specific type of middlebox. For NAT and VPN
gateways, additional functionality, if any, is described in
relevant sections of this draft.
The MIP Proxy will nominally run on a dual-homed host. It MAY
be possible to instantiate the MIP Proxy on a singly homed
host.
4.1. Surrogate MN Functionality
One of the primary functions of the MIP Proxy is to serve as a
MNÆs surrogate when it roams into a foreign network.
As a surrogate MN, the MIP Proxy MUST perform the following MN
compliant functions:
- It MUST perform registration request and reply protocol,
specified by [RFC2002]
- It MUST perform reverse tunneling, defined by [RFC3024]
- It MUST perform authentication mechanism(s) for the MN and
HA, required by [RFC2002]
- It MUST perform replay protection for registration request,
defined by [RFC2002]
The MIP Proxy MUST NOT perform the following MN functions:
- It MUST NOT perform agent solicitation, defined by [RFC2002]
- It MUST NOT perform any functions related to agent discovery,
defined by [RFC2002]
- It MUST NOT perform registration retransmission, defined by
[RFC2002]
- It MUST NOT perform move detection mechanisms, defined by
[RFC2002]
4.2. Surrogate HA Functionality
Adrangi, Iyer Expires January 2002 [Page 5]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
The other primary function of the MIP Proxy is to serve as a
surrogate HA to a roaming MN that is outside its home network,
and with an intervening middlebox such as a NAT or VPN gateway.
As a surrogate HA, the MIP Proxy MUST perform the following MN
compliant functions:
- It MUST perform registration request and reply protocol,
defined by [RFC2002]
- It MUST perform authentication mechanism(s) for the (MN & HA
and the HA & FA), required by [RFC2002]
- It MUST maintain registration binding table, defined by
[RFC2002]
- It MUST perform replay protection for registration request,
defined by [RFC2002]
The MIP Proxy MUST NOT perform the following MN functions:
- It MUST NOT perform agent advertisement, defined by [RFC2002]
- It MUST NOT perform gratuitous ARP, defined by [RFC2002]
- It MUST NOT perform Proxy ARP, defined by [RFC2002]
- It MUST NOT perform Route Optimization [ROUTE-OPT]
4.3. Deploying a MIP Proxy
A MIP Proxy MAY be deployed in a public network serving
multiple HAs in that network as conceptually depicted in the
figure above. It MUST be deployed in a DMZ to supported
authenticated firewall traversal for MIPv4 packets traversing
the DMZ from an MN with an intervening NAT gateway in itÆs
foreign network. It MUST be deployed in parallel with an IPsec-
compatible VPN gateway in a DMZ. Trivially, a subset of the MIP
Proxy functionality MAY be co-located with a HA if appropriate.
The MIP Proxy MAY be located in the same or a different subnet
from any of its associated home agents.
4.4. Discovering a MIP Proxy
A MN MUST be statically configured with the MIPP-Pub address of
the MIP Proxy. Dynamic discovery of the MIP ProxyÆs public IP
address is outside the scope of this draft.
4.5. MIP Proxy Redundancy
A MIP Proxy redundancy protocol is desirable to effect high
availability in public and Enterprise deployment. Details of
such a protocol are beyond the current scope of this draft.
5. MIPv4 Traversal Through NAT Gateways
5.1. NAT Traversal Problem Statement
Adrangi, Iyer Expires January 2002 [Page 6]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
When an MN roams from its home network (which may or may not be
in a routable IP address space) to a foreign network behind a
NAT gateway, it acquires a non-routable care-of address (most
likely through [DHCP]). The acquired non-routable care-of
address is passed to the HA through a registration request.
This causes the MN to lose its connectivity to its home
network, since the HA will not be able to forward the MNÆs
packets to the non-routable care-of address. The scenario is
depicted in Figure 5.1 below.
+-------------------+ +-------------------------+
| Foreign network | | Home Network |
| +----+ | +-----+ | |
| | MN | |----| NAT |---| +----+ +----+ +---+ |
| +----+ | +-----+ | | MN | | HA | |CN | |
| | | +----+ +----+ +---+ |
+-------------------+ | |
| +---+ |
| | FA| |
| +---+ |
+-------------------------+
Figure 5.1 : MN has moved from its home network to a
foreign network
Even if we overcome this problem somehow by using the NAT
gatewayÆs public routable address in the care-of address field
of the registration request, the NAT gateway will not always be
able to demultiplex inbound MIPv4 data traffic properly.
Consider two MNs behind the NAT gateway registered with the
same HA. The inbound IP-in-IP tunneled MIPv4 packets from the
HA to the two MNs will have the source and destination IP
address, making it difficult for the NAT gateway to route the
packets to the appropriate MN.
The implications on Minimal IP [RFC2004] and GRE encapsulation
[RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling.
5.2. Assumptions and Applicability
The solution proposed in the draft is targeted toward network
environments where the following are true.
- The NATÆed foreign network SHOULD NOT be modified. This
implies that no software or hardware changes to the NAT gateway
are feasible and adding a new routing entity (dedicated to
MIPv4 nodes) to such a network is unacceptable. Most
residential and small business networks are typical examples of
such NATÆed networks, wherein an embedded broadband router
(supporting local DHCP and NAT) is employed and additional
resources such as a routable IP address and/or a system are not
obtainable.
- The NAT gateway is capable of doing address and port mapping.
Adrangi, Iyer Expires January 2002 [Page 7]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
- The NATÆed network MUST provide DHCP service to the foreign
subnet or a mobile node MUST be capable of self-assigning or
acquiring by other means, a non-routable care-of address when
it roams behind the NAT.
- The NATÆed network MAY NOT include a foreign agent.
- The NATÆed network MAY NOT be in the same administrative
domain as the MN, MIP Proxy and HA.
- The NATÆed network MUST be configured with the IP addresses
reserved for private Internets by IANA ([RFC1918], [LOCAL-
LINK]).
- If the NATÆed network is multi-subnetted, the routers within
that network cannot be compromised.
- The HA SHOULD NOT be modified.
- MNÆs home network MUST be in a routable IP address domain.
This address domain MAY be behind a firewall/DMZ.
- A FA MAY NOT be available in the ISP access or core network.
- Security implications should not be worse than direct comm.
With HA.
Applicability in other network environments has not been
verified; however it is not explicitly precluded. Furthermore,
the proposed solution MAY be used in combination with other NAT
traversal solutions as appropriate.
If the MNÆs home network is in a non-routable IP address
domain, an appropriate solution (outside the scope of this
draft) MUST be deployed to make the home network accessible
from an external public or private network.
5.3. Using the MIP Proxy for NAT Traversal
The MIP Proxy acts as an intermediate node between a MN in
foreign network behind NAT and itÆs HA. MIPv4 registration
requests from the MN are sent to the MIP Proxy, instead of the
actual HA. The MIP Proxy terminates the registration request
and validates the payload. If the registration request is
acceptable, the MIP Proxy creates a new registration request
and forwards it to the HA on behalf of the MN. The registration
response from the HA is translated into a new response from the
MIP Proxy back to the MN.
All subsequent MIPv4 data traffic between the MN and the MIP
Proxy SHOULD be encapsulated in a UDP tunnel, in order to help
the NAT gateway demultiplex return inbound MIPv4 traffic
NAT/NAPT mechanisms.
The solution is detailed in the following sections.
5.3.1. When does a MN register with the MIP Proxy?
A mobile node MUST register with the MIP Proxy when it roams to
a foreign network behind a NAT gateway. Mechanisms to detect
Adrangi, Iyer Expires January 2002 [Page 8]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
the presence of a NAT gateway are beyond the scope of this
draft.
5.3.1.1. Selection of the COA Field in the Registration Request Payload
As explained in the problem statement, the use of a non-routable
address as the COA causes the MN to lose its connectivity to its
home network. Therefore, the MN MUST use the NAT gatewayÆs
routable (WAN) as the COA in its registration payload. The MN
MAY be configured with the NAT gatewayÆs routable IP address a
priori. However, if this is not feasible, it is imperative for
the MN to use a secured discovery scheme to realize the NAT
gatewayÆs routable address to avoid potential Denial-of-Service
(DoS) attacks. The following diagrams show one possible method
for dynamically discovering and verifying the NAT gatewayÆs
routable address.
MN NAT MIP Proxy
|Registration | |
|Request (COA=0) | |
|-----------------> |Registration |
| |Request |
| |-------------->|
| | |
| |Registration |
| | Reply With |
| | Reject |
| Registration |<------------ |
| Reply With Reject | |
| <---------------- | |
| | |
Figure 5.3a : Discovery of the NAT gatewayÆs routable
address
MN NAT
| |
|ICMP echo Message(s) |
| |
| ----------------------> |
|ICMP Reply Message(s) |
| |
| <----------------------- |
| |
Figure 5.3b : Verification of the NAT gatewayÆs routable
address
The NAT gatewayÆs routable address discovery (as depicted in
Figure 5.3a) is accomplished as a part of the registration
request protocol initiated when the MN roams to a foreign
Adrangi, Iyer Expires January 2002 [Page 9]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
network behind a NAT gateway. The MN MUST send a registration
request to the MIP Proxy with the COA set to a zero. As the
registration payload contains an invalid COA, the MIP Proxy
MUST send a registration reply with error code 134 (Poorly
Formatted). The MIP Proxy MUST also include the NAT Discovery
extension in its reply (see section 5.3.1.2). The MIP Proxy
employs this extension to notify the MN about the possible NAT
gatewayÆs routable address, obtained from the source IP address
of the registration request.
The MN MAY verify this IP address, before it can use it as the
COA in its registration payload. With NAT-router gateways, The
MN MAY achieve this by analyzing the trace-route log (i.e., a
series of ICMP echo and reply messages) from the MN to the
possible NAT gatewayÆs routable address obtained form the
registration discovery extension.
5.3.1.2. Discovery Registration Extension
The following shows the format of the NAT Discovery extension
used in the registration reply from the MIP Proxy to the MN.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Possible NAT GatewayÆs routable Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 180
Length: Indicates (in bytes) of the data fields within the
extension, excluding the Type and Length bytes.
Reserved: For future user.
Possible NAT GatewayÆs routable Address: An IP address
Once the MN obtains and verifies the NAT gatewayÆs public
address, it MUST send a registration request with the COA set
to the NAT gatewayÆs routable address.
5.3.2. MIPv4 registration protocol between MN and HA
Once the MN obtains and verifies the NAT gatewayÆs routable
address, the MN MUST register with its actual home agent via
the MIP Proxy. Therefore,
the normal flow of MIPv4 registration messages between a MN and
a HA are altered as depicted in the figure below.
Adrangi, Iyer Expires January 2002 [Page 10]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
MN NAT Gateway MIP Proxy HA
|Reg.Request | | |
|----------------->|Reg. Request | |
| |-----------------> |Reg. Request |
| | |----------------->|
| | |Reg. Reply |
| |Reg. Reply |<-----------------|
|Reg. Reply |<----------------- | |
|<-----------------| | |
Figure 5.3.2 : Mobile IP registration protocol between
MN and HA
5.3.2.1. Establishing UDP Tunnel Parameters for MIPv4 Data Traffic
To support multiple, simultaneous MIPv4 data sessions from MNs
behind a NAT gateway to a home network via the same HA, a UDP
tunnel MUST be established between the MN and MIP Proxy. The
MN MUST use the parameter registration extension (see section
5.3.2.3) to notify the MIP Proxy about the UDP port number
ought to be used to establish a UDP tunnel for the Mobile IP
data traffic between the MN and MIP Proxy.
The UDP port number 434 MAY be used to tunnel the data traffic
between the MN and MIP Proxy. However, this MAY have some
performance implications. If any UDP port numbers other than
434 is used, a new entry in the NAT gatewayÆs address/port
mapping MUST be created right after a successful registration.
This can be done, by sending a NULL UDP packet (i.e, an empty
payload) from the MN to the MIP proxy.
The mobile node MUST maintain the selected UDP port number for
the lifetime of the registration request. The MN SHOULD ensure
that the NAT gatewayÆs lifetime for the UDP tunnel port mapping
does not expire prior to the expiry of the Registration
lifetime. This MAY be done through some sort of periodic
KeepAlive messages from the MN to MIP Proxy.
5.3.2.2. Discovering the MNÆs actual home agent by the MIP Proxy
The MN MUST notify the MIP Proxy about its actual home agent
address, via the parameter registration extension. The
following shows the parameter registration extension format.
Adrangi, Iyer Expires January 2002 [Page 11]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
5.3.2.3. Parameter Registration Extension
The following shows the format of the parameter extension used
in the registration request from MN to the MIP Proxy.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Port Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Type : 181
Length :
Indicates (in bytes) of the data fields within the
extension, excluding the Type and Length bytes.
Reserved: For future use.
Home Agent Address: An IP address of the MNÆs actual
home agent
UDP Port Number: Used to establish UDP tunnel
Reserved: For future use.
5.3.2.4. MIPv4 Registration Request Packet Flow From MN to HA
The MN sends the Registration Request to the MIP Proxy. The
intervening NAT gateway modifies the source IP address (and
possibly the UDP source port).
From MN to the MIP Proxy:
+--------------------------------------------------+
|IP-S = MN-COA | Permanent Address = MN-Perm |
|IP-D = MIPP-Pub | Home Agent = MIPP-Priv |
| | Care-of Address = NATGW-Pub |
| | . . . |
+--------------------------------------------------+
The NAT gateway modifies the source IP address, and possibly
UDP source port number.
Adrangi, Iyer Expires January 2002 [Page 12]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
+--------------------------------------------------+
|IP-S = NATGW-Pub | Permanent Address = MN-Perm |
|IP-D = MIPP-Pub | Home Agent = MIPP-Priv |
| | Care-of Address = NATGW-Pub |
| | . . . |
+--------------------------------------------------+
The MIP Proxy terminates and authenticates the Registration
Request received from the MN. It then modifies the registration
request payload and forwards a new registration request to the
HA associated with the MN. The MIP Proxy MUST set the Home
Agent and Care-of Address fields of the registration request to
the MNÆs actual HA (learned from the parameter registration
extension) and the MIP ProxyÆs private address respectively.
The packet format is shown below.
+--------------------------------------------------+
|IP-S = MIPP-Priv | Permanent Address = MN-Perm |
|IP-D = HA | Home Agent = HA |
| | Care-of Address = MIPP-Priv |
| | . . . |
+--------------------------------------------------+
The MIP Proxy maintains a registration binding cache similar to
the one specified by [RFC2002] for a HA, in order to forward
the registration replies and subsequent MIPv4 data traffic. In
addition, the MIP Proxy MUST also record the UDP port number
(learned form the parameter registration extension) for the UDP
tunnel between the MN and the MIP Proxy in the registration
binding cache. The MIP Proxy MUST not manage registration
lifetimes and MUST NOT reinitiate a registration request with a
HA prior to its expiration. A MN MUST continue to manage
Registration lifetimes as specified in [RFC2002].
5.3.2.5. MIPv4 Registration Reply Packet Flow From HA to MN
If the actual HA were to accept the registration request, the
reply flow sequence will be as follows:
From the HA to the MIP Proxy:
+--------------------------------------------------+
|IP-S = HA | Home Agent = HA |
|IP-D = MIPP-Pri | . . . |
+--------------------------------------------------+
From the MIP Proxy to the NAT
+-------------------------------------------------+
|IP-S = MIPP-Pub | Home Agent = MIPP-Pub |
|IP-D = NAT-Pub | . . . |
+-------------------------------------------------+
From the NAT to the MN:
Adrangi, Iyer Expires January 2002 [Page 13]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
+--------------------------------------------------+
|IP-S = NAT-Priv | Home Agent = MIPP-Pub |
|IP-D = MN-Perm | . . . |
+--------------------------------------------------+
5.3.3. MIPv4 data traffic from MN to CN
The normal flow of MIPv4 data flow between a MN and a HA are
altered as depicted in the figures below. Note that the data
traffic form the MN to MIP Proxy is encapsulated in a UDP
tunnel.
MN NAT MIP CN
Proxy
| | | |
|IP/UDP/IP| | |
|-------> | | |
| |IP/UDP/IP| |
| |-------> | |
| | | IP |
| | |------>|
Figure 5.3.5 : MIP Proxy forwards data packet directly
to CN
All MIPv4 data traffic between the MN and MIP Proxy will be
encapsulated in a UDP tunnel. The MIP Proxy will strip off the
outer IP and UDP headers, and re-encapsulate the detunneled
packet in an IP header (from MIPP-Pub to MN or from MIPP-Priv
to HA as the case may be) before forwarding it to the MN or HA
respectively. The following figures illustrate the traffic flow
from the MN to the MIP Proxy, and the MIP Proxy to the actual
HA.
MIPv4 data packet flow from the MN to the MIP Proxy:
+-------------------------------------------------------+
|IP-S=MN-COA |UDP Src Port# |IP Src = MN-Perm | Data |
|IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | |
+-------------------------------------------------------+
The intermediate NAT gateway will apply address and port
mapping on the packet, and forward the packet, as follows:
+-------------------------------------------------------+
|IP-S=NAT-Pub |UDP Src Port# |IP Src = MN-Perm |Data |
|IP-D=MIPP-Pub |UDP Dest Port#|IP Dest = CN | |
+-------------------------------------------------------+
Adrangi, Iyer Expires January 2002 [Page 14]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
MIPv4 data packet flow from the MIP Proxy to CN is as follows:
+------------------------------------------------+
| IP-S = MIPP-Pri |IP Src = MN-Perm |Data |
| IP-D = CN |IP Dest = CN | |
+------------------------------------------------+
5.3.4. MIPv4 data traffic from CN to MN
MIPv4 data traffic will be tunneled from the actual HA to the
MIP Proxy IP-in-IP tunnel is illustrated in the figure above,
however the discussion applies to other MIPv4 encapsulation
modes as well). The MIP Proxy strips off the outer IP header,
and forwards the inner IP packet to the MN in a UDP tunnel.
The following figures illustrate the traffic flow from the CN
to the MN (via the actual HA and the MIP Proxy).
The data packets from the CN will be sent to the MNÆs permanent
address, MN-Perm.
+-----------------------------+
| IP-S = CN |Data |
| IP-D = MN-Perm | |
+-----------------------------+
The MNÆs home agent will intercept the data packet, and will
forward it to its current care-of address (i.e., MIP Proxy) as
follows:
+----------------------------------------------+
| IP-S = HA |IP Src = MN-Perm |Data |
| IP-D = MIPP-Priv |IP Dest = CN | |
+----------------------------------------------+
From the MIP Proxy to the NAT gateway:
+---------------------------------------------------------+
|IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data |
|IP-D = NAT-Pub |UDP Dest Port#|IP Dest = CN | |
+---------------------------------------------------------+
The NAT gateway unapplies address and port mapping on the
packet, and forwards the packet, as follows:
From the NAT gateway to the MN:
+----------------------------------------------------------+
| IP-S = MIPP-Pub |UDP Src Port# |IP Src = MN-Perm |Data |
| IP-D = MN-COA |UDP Dest Port#|IP Dest = CN | |
+----------------------------------------------------------+
Adrangi, Iyer Expires January 2002 [Page 15]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
5.4. Summary of changes on MIPv4 components required by this solution
This solution requires changes on the mobile node, and of
course an addition of a new component, the MIP Proxy.
5.4.1. Required Changes to a MN
- The MN MUST be configured with the static IP address of the
MIP Proxy. A mechanism for MIP Proxy discovery MAY be defined
in future.
- The MN MUST be able to determine if it has roamed to a
private address space behind a NAT gateway.
- The MN MUST implement the registration extension as specified
in this draft.
- The MN SHOULD be able to extend the lifetime of the NAT
gatewayÆs address and port mapping entries for the UDP tunnel
beyond the registration lifetime determined with itÆs HA.
5.4.2. Required Configuration for the MIP Proxy
- The MIP Proxy MUST be configured with all of the SAs of an MN
and a HA that it represents as a surrogate.
- The MIP Proxy SHOULD be configured with static IP addresses
to avoid periodic reconfiguration on MNs.
5.5. Performance Implications of MIP Proxy assisted NAT Traversal
- The proposed method creates a layer of indirection (i.e., the
MIP Proxy), which MAY have some performance implications.
- An eight bytes UDP header is added to the Mobile IP data
traffic from the MN to MIP Proxy.
- Discovery and verification method of the NAT gatewayÆs public
address will degrade the registration hand-off performance.
5.6. Implications of Twice NAT between the MN and MIP Proxy
The proposed solution MAY not work if Twice NAT is encountered
in the path between the MN and the MIP proxy.
6. MIPv4 Traversal Through IPsec VPN Gateways
A MN whose home network is in a routable IP address space
behind a VPN gateway could roam to an external public or
private address space. An example would be a user who roams
from within a Corporate Intranet to an external wired or
wireless hot spot. In this case, the MNÆs HA is located in the
Corporate Intranet behind the firewall/DMZ complex, as
illustrated in the figure below.
It is desirable in this scenario to connect back to the
Intranet via a VPN and stay connected even as the user roams
from one external IP subnet to another. The integration of
MIPv4 and IPsec has not been standardized and several issues
Adrangi, Iyer Expires January 2002 [Page 16]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
have to overcome to support seamless end-to-end IPsec. This
draft describes a solution based on the use of the MIP Proxy to
enable seamless traversal across IPsec-based VPNs.
+----------------+ +-----+ +------+ +-----+ +---------------+
|Foreign network | | | ->|VPN-GW|<---- | | |Home network |
|+----+ +----+ | |Outer| | +------+ | |Inner| | +----+ +----+ |
|| MN | | FA | | |FW | | | |FW | | |HA | | CN | |
|+----+ +----+ | | | | +---------+ | | | | +----+ +----+ |
| | | | ->|MIP Proxy|<- | | | |
+----------------+ +-----+ +---------+ +-----+ | +----+ |
^ ^ | | MN | |
|----- Firewall/DMZ ----- | | +----+ |
+---------------+
Figure 6.0 : MN has moved from its home network to a foreign
network outside the DMZ
6.1. IPsec VPN Traversal Problem Statement
With respect to Figure 6.0 above, the problem can be summarized
in the following 2 scenarios:
Scenario 1: The MN could roam into a foreign subnet without a
FA and obtain a COA at its point of attachment (via DHCP or
other means). In an end-to-end security model, an IPsec tunnel
that terminates at the VPN gateway in the DMZ MUST protect the
IP traffic originating at the MN. If the IPsec tunnel is
associated with the COA, the tunnel SA MUST be refreshed after
each subnet handoff which could have some performance
implications on real-time applications.
Scenario 2: The MN could roam into a foreign subnet with a FA.
If the MN were to associate a VPN tunnel with its COA, the FA
(which is likely in a different administrative domain) cannot
parse the IPsec, will not be able to setup SAs with the MNÆs
VPN gateway and will consequently be not able to relay MIPv4
packets between the MN and the VPN gateway.
6.2. Integration of MIPv4 and IPsec
Clearly there are several schemes to apply IPsec to MIPv4
packets. [MIPv4-SEC-GUIDE] describes different segments where
Adrangi, Iyer Expires January 2002 [Page 17]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
IPsec could be applied to MIPv4 packets. This draft is based on
the premise that the most likely acceptable scenario is the one
in which IPsec is applied end-to-end.
6.3. Assumptions and Applicability
The solution is derived based on the following assumptions and
applicability criteria:
- End-to-end IPsec tunnel mode MUST be applied to MIPv4 data
flows; i.e. between the MN and the VPN gateway at the edge of
its home network.
- MIPv4 registration packets MAY NOT require IPsec tunnel as
they are authenticated and integrity protected. However, they
MUST be terminated inside the DMZ to enable authenticated
firewall traversal.
- FA-assisted routing and MN co-located modes of operation MUST
be supported.
- The MN MUST be configured with the MIP Proxy and the VPN
gatewayÆs external IP addresses, and route the MIPv4 traffic
through the MIP Proxy when it is outside the corporate
intranet.
- The MN SHOULD be able to determine if it has roamed outside
the corporate network by some method (e.g., by comparing its
current COA against address blocks used by the corporate
intranet).
- The MN MUST be able to determine when it should exercise its
key exchange protocol to establish the IPsec tunnel SA to the
VPN gateway.
6.4. Solution Considerations
In addition to enabling the use of end-to-end IPsec with MIPv4,
the use of the MIP Proxy in the DMZ enables a solution that can
meet the following criteria:
6.4.1. Fast Handoffs
To support fast handoffs across IP subnets, it is imperative to
keep the key management overhead down to a minimum. In this
draft, we propose a mechanism whereby the IPsec tunnel SA can
be bound to the invariant permanent IP address of the MN. Doing
so, enables the reuse of the SA across IP subnet handoffs and
also minimizes the protocol handshake between the VPN gateway,
actual HA and the MIP Proxy.
6.4.2. Preserve Existing VPN Infrastructure
This implies the following:
- Preserves the investment in existing VPN gateways
- Requires no software upgrades to VPN gateways to explicitly
support MIPv4 users
- Preserves IPsec VPN security requirements that are not
inferior to what is already provided to existing "nomadic
Adrangi, Iyer Expires January 2002 [Page 18]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
computing" remote access users, i.e. for confidentiality,
primary and secondary authentication, message integrity,
protection against replay attacks and related security services
6.4.3. Preserve Existing DMZ Traversal Policies
Most Corporate DMZ policies recommend authenticated firewall
traversal for protocols that traverse the DMZ. Placing devices
outside the outer DMZ firewall to assist with DMZ traversal
exposes the device to hackers and is generally not an
acceptable solution. IT departments prefer that solutions
adhere to and can be accommodated with existing or compliant
DMZ ACLs.
6.5. Deploying the MIP Proxy to support VPN Traversal
As shown in Figure 6.0, the MIP Proxy is deployed in parallel
to an existing VPN gateway in the DMZ to support MIPv4.
6.5.1. Mobile IPv4 Registration
The MN sends MIPv4 registration requests directly to the MIP
Proxy. The MIP Proxy terminates and authenticates the
registration requests. It then generates a new registration
request and forwards it to the corresponding HA. The
registration request MUST include the discovery registration
extension (see section 5.3.1.2.) to notify the MIP Proxy about
the MNÆs actual home agent. The registration replies from the
HA will also go through the MIP Proxy bypassing the VPN
gateway. Note that the MN and the MIP Proxy MUST share the SA
for the MN-HA authentication extension.
This solution also works if the MN were to use a FA in the
foreign network.
A rail-road diagram illustrating the MIPv4 registration process
is shown below.
MN MIP Proxy HA
|Reg. Request | |
|-----------------> | |
| |Reg. Request |
| |----------------->|
| |Reg. Reply |
| |<-----------------|
|Reg. Reply | |
|<----------------- | |
Figure 6.5.1 : Mobile IP registration protocol between
MN and HA
6.5.1.1. MIPv4 Registration Request Packet Flow from MN to HA
Adrangi, Iyer Expires January 2002 [Page 19]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
This draft illustrates the sequence from MN to HA via a FA û it
can be easily extended to describe the flow for a co-located
COA mode MN.
From the MN to a FA:
+--------------------------------------------------+
|IP-S = MN-Perm | Permanent Address = MN-Perm |
|IP-D = FA_COA | Home Agent = MIPP-Pub |
| | Care-of Address = FA COA |
| | . . . |
+--------------------------------------------------+
From the FA to the MIP Proxy:
+--------------------------------------------------+
|IP-S = FA COA | Permanent Address = MN-Perm |
|IP-D = MIPP-Pub | Home Agent = MIPP-Pub |
| | Care-of Address = FA COA |
| | . . . |
+--------------------------------------------------+
From the MIP Proxy to the actual HA:
+--------------------------------------------------+
|IP-S = MIPP-Priv | Permanent Address = MN-Perm |
|IP-D = HA | Home Agent = HA |
| | Care-of Address = MIPP-Priv |
| | . . . |
+--------------------------------------------------+
6.5.1.2. MIPv4 Registration Reply Packet Flow from HA to MN
If the actual HA were to accept the registration request, the
reply flow sequence will be as follows:
From the HA to the MIP Proxy:
+--------------------------------------------------+
|IP-S = HA | Home Agent = HA |
|IP-D = MIPP-Priv | . . . |
+--------------------------------------------------+
From the MIP Proxy to the FA:
+--------------------------------------------------+
|IP-S = MIPP-Pub | Home Agent = MIPP-Pub |
|IP-D = FA | . . . |
+--------------------------------------------------+
From the FA to the MN:
+--------------------------------------------------+
|IP-S = FA | Home Agent = MIPP-Pub |
|IP-D = MN-Perm | . . . |
+--------------------------------------------------+
6.5.1.3. DMZ Configuration Requirements for MIPv4 Registration Packets
Adrangi, Iyer Expires January 2002 [Page 20]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
The DMZ ACLs MUST be setup for the following:
- Inbound UDP registration packets (destination port = 434 and
destination address = MIPP-Pub) MUST be permitted.
- The DMZ inner firewall MUST permit the forwarding of
registration request and reply packets from the MIP Proxy to
one or more HAs.
6.5.2. Mobile IPv4 Data Processing
The following railroad diagram illustrates the sequence of
steps to establish secured MIPv4 traffic between a MN and a CN.
The process initially occurs in 3 sequential steps: MIPv4
registration, IPsec tunnel SA establishment and MIPv4 data
forwarding. Registration and SA refreshes may subsequently
occur independent of each other.
MIPv4 Registration- see Figure 6.5.1
Note that the VPN gateway is not involved in the MIPv4
Registration process.
IPsec Tunnel SA Establishment:
MN VPN Gateway
| |
|IKE Phase 1 (ISAKMP SA) <----------> |
| |
|IKE Phase 2 (Tunnel SA) <----------> |
| |
Note that the MIP proxy is not involved in the Tunnel SA
establishment and will not be involved in SA refreshes.
The data forwarding is described in the following 2 sub-
sections.
6.5.2.1. MIPv4 Data Traffic from MN to CN
The MN generates an IP packet from the MN-Perm interface and
destined to the CN. This packet is encapsulated in an IPsec-ESP
tunnel from MN-Perm to VPNGW-Pub. The packet in turn is
encapsulated in an IP header from MN COA to the MIP Proxy. The
MIP Proxy strips off the outermost IP header and forwards the
inner IP packet (which is from the MNÆs permanent address to
the VPN gateway) to the VPN gateway. The VPN gateway in turn
processes the IPsec VPN tunnel, strips off the IP and ESP
headers and forwards the inner most IP packet to the
destination CN. The railroad diagram depicts the packet flow
sequence, followed by a description of packets as they traverse
the network.
MN FA MIP Proxy VPN Gateway HA CN
| | | | | |
|------>| | | | |
Adrangi, Iyer Expires January 2002 [Page 21]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
| | -------> | | | |
| | | ------------> | | |
| | | | ------------------> |
From the MN to MIP Proxy: IP-IP-ESP-IP-TCP/UDP-Data
From MIP Proxy to VPN: IP-ESP-IP
From VPN Gateway to CN: IP
The packet flow from the MN to the CN is described below. The
analysis assumes than the MN employs reverse tunneling to the
HA (which is the MIP Proxy in this case) and that packets are
routed via a FA.
From the MN to the FA:
+-------------------------------------------------------------+
|IP-S=MN-Perm |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |
|IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| | |VPNGW-Pub | | |
+-------------------------------------------------------------+
In this case, the layer-2 destination address is set to the MAC
address of the FA.
From the FA to the MIP Proxy:
+-------------------------------------------------------------+
|IP-S=FA COA |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |
|IP-D=MIPP-Pub|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| | |VPNGW-Pub | | |
+-------------------------------------------------------------+
Clearly, the FA does not need to know the IPsec tunnel SA to
process the packet.
From the MIP Proxy to the VPN gateway:
The MIP Proxy strips off the outermost IP header and forwards
the packet to the VPN gatewayÆs outer interface using the
layer-2 address corresponding to VPNGW-Pub.
+-----------------------------------------------+
|IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |
|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| |VPNGW-Pub | | |
+-----------------------------------------------+
From the VPN gateway to the CN:
The VPN gateway completes IPsec tunnel processing on the
packet, strips off the outermost IP and ESP headers and
forwards the encapsulated IP datagram to the CN.
+---------------------+
|IP-S=MN-Perm| Data |
|IP-D=CN | |
+---------------------+
Adrangi, Iyer Expires January 2002 [Page 22]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
6.5.2.2. MIPv4 Data Traffic from CN to MN
The outbound MIPv4 data traffic destined to the MNÆs co-located
address is always tunneled to the MIP Proxy (which appears as a
surrogate MN to the actual HA). The MIP Proxy forwards the
inner IP packet (with MN-Perm as the destination address) to
the VPN gateway. The VPN gateway applies the IPsec ESP tunnel
SA on the packet. The VPN gateway forwards the packet back to
the MIP Proxy on its MIPP-Pub interface û this is accomplished
by a routing table update on the VPN gateway. The MIP Proxy in
turn tunnels the IPsecÆed packet to the MNÆs COA. The railroad
diagram depicts the packet flow sequence, followed by a
description of packets as they traverse the network.
MN FA MIP Proxy VPN Gateway HA CN
| | | | | |
| | | | | <------ |
| | | <------------------------ | |
| | | ------------> | | |
| | | <----------- | | |
| | <--------| | | |
| <-----| | | | |
From the HA to the MIP Proxy: IP-IP
From the MIP Proxy to the VPN gateway: IP
From the VPN gateway to the MIP Proxy: IP-ESP-IP
From the MIP Proxy to the MN: IP-IP-ESP-IP
The packet flow from the CN to the MN is described below.
From the CN to the actual HA:
+---------------------+
|IP-S=CN | Data |
|IP-D=MN-Perm| |
+---------------------+
The CN sets the layer-2 destination address to that of the
actual HA.
From the actual HA to the MIP Proxy:
+------------------------------------+
|IP-S=HA |IP-S=CN | Data |
|IP-D=MIPP-Priv|IP-D=MN-Perm| |
+------------------------------------+
From the MIP Proxy to the VPN gateway:
The MIP Proxy strips off the outermost IP header and forwards
the packet to the VPNGW-Priv interface using the corresponding
layer-2 address.
+---------------------+
Adrangi, Iyer Expires January 2002 [Page 23]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
|IP-S=CN | Data |
|IP-D=MN-Perm| |
+---------------------+
From the VPN gateway to the MIP Proxy:
The VPN gateway applies an IPsec ESP tunnel SA to the IP packet
and forwards it back to the MIP Proxy on the MIPP-Pub interface
based on its routing table.
+-------------------------------------------------+
|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data |
|IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| |MN-Perm | | |
+-------------------------------------------------+
From the MIP Proxy to the FA:
The MIP Proxy adds an outer encapsulating IP header to the FA
COA.
+-----------------------------------------------------------+
|IP-S=MIPP-Pub|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data|
|IP-D=FA COA |IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| | |MN-Perm | | |
+-----------------------------------------------------------+
From the FA to the MN:
The FA strips off the outermost IP header and forwards the
packet to the MN.
+-------------------------------------------------+
|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data |
|IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| |MN-Perm | | |
+-------------------------------------------------+
The MN terminates the IPsec tunnel and processes the MIPv4 data
as always.
6.5.3. Support For Route Optimization
The MIP Proxy MUST NOT support Route Optimization [ROUTE-OPT].
However, the Route Optimization between the correspondent node
and the mobile nodeÆs actual home agent MAY be performed.
6.6. Key Management and SA Preservation
The scheme described in the previous section binds the IPsec
tunnel SA to the normally invariant permanent IP address of the
MN. This implies that the tunnel SA can be preserved even when
the MN changes its co-located COA or connects via a FA in a
different IP subnet. The SA however must be refreshed prior to
its lifetime expiration. Also, many VPN gateway implementations
Adrangi, Iyer Expires January 2002 [Page 24]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
support some keep-alive mechanism to detect the presence of a
VPN client and "retire" the SA if the VPN client is not
detected for a period of time. If an MN loses link connectivity
for a period extending the keep-alive timeout interval, it MUST
reestablish the tunnel SA, regardless of whether it reconnects
to the same IP subnet or not.
The scheme also preserves any secondary authentication
mechanisms that may be in the place to authenticate a remote
access user.
6.7. DMZ and VPN Gateway Configuration Requirements
The solution described in this section makes the following
assumptions on the configurability of the VPN gateway and the
DMZ ACLs:
- It MUST be possible to configure the VPN gatewayÆs routing
table to deliver the outbound IPsecÆed MIPv4 packets destined
to MN-Perm to the MIP ProxyÆs MIP-Pub interface, if MIP Proxy
is not co-located with the VPN gateway.
- The outer firewall MUST allow inbound tunneled IP packets
destined to the MIP Proxy
- The MIP Proxy MUST be able to forward packets (destined to
MN) to VPN gateway via layer 2 mechanism. This implies that
the MIP Proxy and VPN Gateway MUST be on the same subnet.
6.8. Supporting Other IPsec-based VPN Configurations
The scheme currently described in this draft assumes a native
IPsec VPN scheme extended to support secondary authentication
schemes. Its applicability to other IPsec VPN configurations
such as L2TP over IPsec transport and ESP-in-UDP tunneling is
yet to be determined.
6.9. Considerations for Integrating the MIP Proxy and VPN Gateway
The MIP Proxy as described in this draft is a logical
functional component and as such can be deployed in the DMZ in
one of 2 possible ways:
- As a standalone device in parallel with the VPN gateway as
depicted in Figure 6.0. This decouples support for MIPv4 users
from any software or hardware upgrades to the VPN gateway
itself and also enables multi-vendor interoperability. The
scheme however adds some overhead to the end-to-end
communication path between an MN and a CN and requires minimal
support from the VPN gateway software (i.e. a mechanism to make
routing table updates).
- Integrated as a software component with the VPN gateway. This
clearly reduces the communication overhead but tightly couples
support for MIPv4 users with any software upgrades to the VPN
gateway itself.
7. Using the MIP Proxy for combined NAT and VPN Traversal
Adrangi, Iyer Expires January 2002 [Page 25]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
The discussion in the draft would be incomplete without
describing a scenario in which a MN roams into a foreign NATÆed
network and has to connect back to itÆs home network which is
behind a DMZ. Many Enterprises are deploying wireless LANs as a
private NATÆed network outside their DMZ-users that roam into
such a network will be forced to VPN back into their Intranet.
Such a scenario can be supported with the MIP Proxy enabling
simultaneous NAT and VPN traversal. The network configuration
would be a combination of Figures X and Y. The analysis assumes
that there is no FA in the NATÆed network.
7.1. MIPv4 Registration Message Flow
7.1.1. MIPv4 Registration Requests
From the MN to the NAT gateway:
+-----------------------------------------------+
|IP-S=MN-Perm | Permanent Address = MN-Perm |
|IP-D=MIPP-Pub | Home Agent = MIPP-Pub |
| | Care-of Address = NATGW-Pub |
| | . . . |
+-----------------------------------------------+
Please see the discussion in section 5 for possible mechanisms
for an MN to determine the NAT gatewayÆs external (public)
routable IP address.
From the NAT gateway to the MIP Proxy:
The NAT gateway performs source address and source UDP port
translation before forwarding the packet to the MIP Proxy.
+-----------------------------------------------+
|IP-S=NATGW-Pub | Permanent Address = MN-Perm |
|IP-D=MIPP-Pub | Home Agent = MIPP-Pub |
| | Care-of Address = NATGW-Pub |
| | . . . |
+-----------------------------------------------+
From the MIP Proxy to the actual HA:
The MIP Proxy terminates and authenticates the registration
request (as described in previous sections). It then creates a
new registration request and forwards it to the actual HA.
+-----------------------------------------------+
|IP-S=MIPP_Priv | Permanent Address = MN-Perm |
|IP-D=HA | Home Agent = HA |
| | Care-of Address = MIPP-Priv |
| | . . . |
+-----------------------------------------------+
7.1.2. MIPv4 Registration Replies
From the actual HA to the MIP Proxy:
Adrangi, Iyer Expires January 2002 [Page 26]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
+--------------------------------------+
|IP-S=HA | Home Agent = HA |
|IP-D=MIPP-Priv | . . . |
+--------------------------------------+
From the MIP Proxy to the NAT gateway:
+--------------------------------------+
|IP-S=MIPP-Pub | Home Agent = MIPP-Pub|
|IP-D=NATGW-Pub | . . . |
+------------------------------- ------+
From the NAT gateway to the MN:
+----------------------------------------+
|IP-S=NATGW-Priv | Home Agent = MIPP-Pub |
|IP-D=MN COA | . . . |
+----------------------------------------+
7.2. MIPv4 Data Flow
Reverse tunneling is assumed in the packet flow descriptions
that follow.
7.2.1. Data Flow from the MN to the CN
From MN to the NAT gateway:
+----------------------------------------------------------------+
|IP-S=MN-Priv | UDP |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm|Data |
|IP-D=MIPP-Pub| |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| | | |VPNGW-Pub | | |
+----------------------------------------------------------------+
From the NAT gateway to the MIP Proxy:
+----------------------------------------------------------------+
|IP-S=NATGW-Pub| UDP |IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm|Data|
|IP-D=MIPP-Pub | |IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| | | |VPNGW-Pub | | |
+----------------------------------------------------------------+
Adrangi, Iyer Expires January 2002 [Page 27]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
From the MIP Proxy to the VPN gateway:
+-----------------------------------------------+
|IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |
|IP-D=VPNGW-Pub|MN-Perm to|IP-D=CN | |
| |VPNGW-Pub | | |
+-----------------------------------------------+
From the VPN gateway to the CN:
+---------------------+
|IP-S=MN-Perm| Data |
|IP-D=CN | |
+---------------------+
7.2.2. Data Flow from the CN to the MN
From the CN to the actual HA:
+---------------------+
|IP-S=CN | Data |
|IP-D=MN-Perm| |
+---------------------+
From the actual HA to the MIP Proxy:
+------------------------------------+
|IP-S=HA |IP-S=CN | Data |
|IP-D=MIPP-Priv|IP-D=MN-Perm| |
+------------------------------------+
From the MIP proxy to the VPN gateway:
The MIP proxy strips off the outer IP header and forwards the
packet on the layer-2 address for VPNGW-Priv.
+---------------------+
|IP-S=CN | Data |
|IP-D=MN-Perm| |
+---------------------+
From the VPN gateway to the MIP Proxy:
+-------------------------------------------------+
|IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN | Data |
|IP-D=MN-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| |MN-Perm | | |
+-------------------------------------------------+
From the MIP Proxy to the NAT gateway:
+------------------------------------------------------------------+
|IP-S=MIPP-Pub | UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data|
|IP-D=NATGW-Pub| |IP-D=NM-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| | | |MN-Perm | | |
+------------------------------------------------------------------+
Adrangi, Iyer Expires January 2002 [Page 28]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
From the NAT gateway to MN:
+-------------------------------------------------------------------+
|IP-S=NATGW-Priv| UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN |Data|
|IP-D=MN-Priv | |IP-D=NM-Perm |VPNGW-Pub to|IP-D=MN-Perm| |
| | | |MN-Perm | | |
+-------------------------------------------------------------------+
8. Security Implications
The MIP Proxy is a functional entity that MUST be implemented on a
secure device especially if it is deployed in the DMZ. The MIP Proxy
is assumed to belong to the same (security) administrative domain as
the MN and the actual HA. The protocol extensions specified in the
draft do not introduce any new vulnerabilities to the mobile IP
protocol.
9. Acknowledgements
The authors would like to thank Mike Andrews and Changwen Liu of
Intel Corporation for their review and feedback on this draft.
10. Patents
Intel Corporation is in the process of filing one or more patent
applications that may be relevant to this IETF draft.
11. References
[RFC2002] RFC 2002 : IP mobility support
[RFC3024] RFC 3024 : Reverse tunneling for mobile IP
[RFC2004] RFC 2004 : Minimal encapsulation within IP
[RFC1701] RFC 1701 : Generic Routing encapsulation
[RFC2119] RFC 2119 : Key words for use in RFCs to Indicate
Requirement Levels
[RFC1918] RFC 1918 : Address Allocation for Private Internets
[DHCP] RFC 2131 : Dynamic Host Configuration Protocol
[MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt -
Requirements / Implementation Guidelines for Mobile IP using IP
Security
[[LOCAL-LINK] : Dynamic Configuration of Iv4 Link-Local Addresses,
<draft-ietf-zeroconf-ipv4-linklocal-03>
[ROUTE-OPT] : Route Optimization in Mobile IP, <draft-ietf-mobileip-
optim-10.txt>
Authors:
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR
USA
Phone: 503-712-1791
Email: farid.adrangi@intel.com
Prakash Iyer
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR
USA
Phone: 503-264-1815
Email: prakash.iyer@intel.com
Adrangi, Iyer Expires January 2002 [Page 29]
Internet Draft draft-adrangi-mipv4-midbox-traversal-00 July 2001
Adrangi, Iyer Expires January 2002 [Page 30]