One document matched: draft-adrangi-mobileip-vpn-traversal-02.txt
Differences from draft-adrangi-mobileip-vpn-traversal-01.txt
Internet Engineering Task Force Farid Adrangi
INTERNET DRAFT Prakash Iyer
<draft-adrangi-mobileip-vpn-traversal-02> Intel Corp.
Date: July 17 2002
Expires: January 2003 Kent Leung
Milind Kulkarni
Alpesh Patel
Cisco Systems
Qiang Zhang
Liqwid Networks
Joe Lau
Hewlett Packard
Corp.
Mobile IPv4 Traversal Across IPsec-based 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
Multi-subnetted IEEE 802.11 WLAN networks are being widely
deployed in Enterprise Intranets û(in many cases requiring a
VPN tunnel to connect back and access Intranet resources), and
public areas such as airports, coffee shops, convention centers
and shopping malls. Many of these WLAN networks also employ NAT
Expires January 2003. [Page 1]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
to translate between non-routable and routable IPv4 care-of
(point of attachment) addresses. WWAN networks such as those
based on GPRS, 1xRTT and eventually EDGE, 1xEV, CDMA2000 and
UMTS are also starting to see deployment. These deployments are
paving the way for applications and usage scenarios requiring
TCP/IP session persistence and constant reachability while
connecting back to a secured (VPN protected), target ôhomeö
network. This in turn drives the need for a mobile VPN solution
that is multi-vendor interoperable, providing seamless access
with persistent VPN sessions - through NAT gateways when
needed. This draft proposes a solution framework that enables
efficient, seamless operation of Mobile IPv4 when combined with
an IPsec-based VPN and supporting NAT traversal when needed.
The solution has no link layer dependencies and can be applied
to other 802.3-compatible wired and wireless physical media as
well.
Table Of Contents
1. Introduction....................................................3
1.2. Goals.........................................................3
1.3. Problem Description...........................................4
1.4. Solution Overview.............................................5
1.4.1. Assumptions and Applicability...............................5
1.5. Terminology...................................................6
1.6. Acronyms......................................................6
2. Registration....................................................6
2.1. Authentication................................................7
2.2. Registration Request Process..................................7
2.2.1. Registration Request Bits...................................7
2.2.2. Registration Request Fields.................................8
2.2.3. Registration Request Extensions.............................8
2.2.4. Registration Request Validity Check.........................8
2.3. Registration Reply Process....................................9
2.3.1. Registration Reply Fields...................................9
2.4. Registration Reply Initiated by the MIP Proxy................10
2.4.1. New Registration Reply Codes...............................10
2.5. Mobile Node Considerations...................................10
2.5.1. Location Detection.........................................10
2.5.2. New Configuration Requirement..............................10
2.5.3. HA Parameter Extension.....................................10
2.6. MIP Proxy Considerations.....................................11
2.6.1. Algorithm for location detection...........................11
2.6.2. Simultaneous Mobility Binding..............................12
2.6.3. Mobile IP NAI Extension....................................13
2.6.4. Dynamic HA Assignment......................................13
2.6.5. Pending Registration List..................................13
2.6.6. Mobility Bindings..........................................14
2.6.7. Handling ICMP Error Messages...............................14
2.7. MIPv4 Registration Packet Flow...............................14
2.7.1. MIPv4 Registration Request Packet Flow from MN to HA.......14
2.7.2. MIPv4 Registration Reply Packet Flow from HA to MN.........15
3. Functions Not Performed By The MIP Proxy.......................15
Adrangi, Iyer Expires January 2003 [Page 2]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
4. MIP Proxy Integration with VPN.................................16
4.1. One-Box Integration..........................................16
4.1.1. Redundancy.................................................16
4.2. Two-Box Integration..........................................17
4.2.1. Two-Box Integration Requirements...........................17
5. MIPv4 Data Traffic Routing Through VPN.........................17
5.1. Establishment of Secured MIPv4 Traffic.......................17
5.2. Association Between VPN Inner and MN Home IP Address.........17
5.3. MIPv4 Data Traffic from MN on External Network to CN.........18
5.4. MIPv4 Data Traffic from CN to MN on External Network.........20
5.5. Key Management and SA Preservation...........................22
5.6. Supporting Other IPsec-based VPN Configurations..............22
5.7 Routing Considerations........................................22
5.7.1. Broadcast / multicast Datagrams............................22
5.7.2. MN Registration through a Trusted FA.......................23
6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways...........23
6.1. MIPv4 Registration Message Flow..............................24
6.1.1. MIPv4 Registration Requests................................24
6.1.2. MIPv4 Registration Replies.................................24
6.2. MIPv4 Data Flow..............................................25
6.2.1. Data Flow from the MN to the CN............................25
6.2.2. Data Flow from the CN to the MN............................25
7. Security Implications..........................................26
8. Acknowledgements...............................................26
9. Intellectual Property Rights...................................27
10. Revision History..............................................27
11. References....................................................27
1. Introduction
The problem statement and solution requirements for MIPv4
traversal across VPN gateways are articulated in [15]. To
understand the motivation and rationale for the solution proposed
in this draft, we strongly encourage the audience to read [15]
first.
This draft introduces a logical component called the Mobile IP
Proxy (MIP Proxy) to enable seamless Mobile IPv4 functionality
across VPN gateways, without requiring any IPsec VPN protocol
changes to VPN gateways. The solution aims specifically at
extending the use of deployed IPsec-based VPN gateways, a feature
that is much desired by corporate IT departments. The solution
also leverages [11] to support Mobile traversal across ôNAT and
VPNö gateways. The ôNAT and VPNö refers to a network topology
where Mobile IP traffic has to traverse one or more NAT gateway(s)
followed by a VPN gateway in the path to its final destination.
While the discussion in this draft is limited to IPsec-based VPN
gateways, it should be compatible with other IP-based VPN
solutions as well.
1.2. Goals
Adrangi, Iyer Expires January 2003 [Page 3]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
A MN whose home network is in a protected 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 (i.e, the HA is not directly
reachable by the MN), as illustrated in Figure 1.2.
It is desirable in this scenario to connect back to the Intranet
via a VPN while maintaining the transport connections prior to
the move, and stay connected as the user roams from one external
IP subnet to another outside the DMZ, or the user decides to roam
back inside the DMZ.
+----------------+ +-----+ +------+ +-----+ +---------------+
|Foreign network | | | ->|VPN-GW|<---- | | |Home network |
|+----+ +----+ | |Outer| | +------+ | |Inner| | +----+ +----+ |
|| MN | | FA | |--|FW |--| |--|FW |-| |HA | | CN | |
|+----+ +----+ | | | | +---------+ | | | | +----+ +----+ |
| | | | ->|MIP Proxy|<- | | | |
|+----+ | +-----+ +---------+ +-----+ | +----+ |
||NAT | | ^ ^ | | MN | |
|+----+ | |----- Firewall/DMZ ----- | | +----+ |
+----------------+ +---------------+
Figure 1.2 û MN moves from its home network to a foreign network
outside the DMZ
1.3. Problem Description
With respect to Figure 1.2 above, the problem can be summarized
in the following 3 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 undesirable 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 and will not be able to setup SAs with the MNÆs VPN gateway
and will consequently not be able to relay MIPv4 packets between
the MN and the VPN gateway.
Scenario 3: The MN could roam into a NATÆed network that may or
may not employ a FA. In this scenario, the MIPv4 traffic has to
traverse a NAT followed by a VPN gateway. The problem statement
Adrangi, Iyer Expires January 2003 [Page 4]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
and solution for MIPv4 traversal across NAT gateways is
articulated in [11].
1.4. Solution Overview
The solution introduces a new Mobile IP logical entity, called
Mobile IP Proxy (MIP Proxy). With respect to Figure 1.2 above,
the MIP Proxy is placed in the DMZ, co-located or running in
parallel with the VPN. The MIP Proxy is in the path between a MN
outside the DMZ and its corresponding actual HA.
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 the MN and its actual 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 SHOULD belong to the same
administrative domain as any of its associated home agents and
their corresponding MNs. It MUST share SAs for various MIPv4
registration extensions with its associated HA(s).
The MIP Proxy will nominally run on a dual-homed host - one of
its interfaces on the private (LAN) side, and the other on the
public (WAN) side. The MIP Proxy can be instantiated on a singly
homed host - however in this document we assume that the MIP
Proxy is instantiated on a dual-homed host. The MIP Proxy MAY be
implemented as a standalone device or combined with a VPN
gateway.
1.4.1. Assumptions and Applicability
The solution is derived based on the following assumptions and
applicability criteria:
- An 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 an IPsec tunnel as
they are authenticated and integrity protected. However, they
MUST be terminated inside the DMZ to enable authenticated
firewall traversal.
- The DMZ outer firewall MUST allow inbound tunneled IP packets
destined to the MIP Proxy.
- The DMZ outer firewall MUST permit inbound UDP registration
packets (destination port = 434 and destination address = MIP
Proxy interface on the public (WAN) side).
- The DMZ inner firewall MUST permit the forwarding of
registration request and reply messages from the MIP Proxy to
one or more HAs.
Adrangi, Iyer Expires January 2003 [Page 5]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
1.5. Terminology
Administrative Domain:
In the context of this draft an administrative domain is the
entity that specifies security parameters for Mobile IP
registration extensions for one or more Home Agents and their
corresponding mobile nodes. The administrative domain also
manages policies that govern negotiation of security associations
for VPN sessions that terminate or initiate at the edge of the
network under its jurisdiction.
Actual Home Agent:
It is the mobile nodeÆs real home agent, as defined by [1].
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
[5].
1.6. Acronyms
DMZ: De-Militarized Zone
FA-COA: Foreign Agent care-of address
FA-Routed: FAÆs interface address on the routed network
FA-Visited: FAÆs interface address on the visited network
GRE: Generic Routing Encapsulation
IP-D: IP Destination Address
IP-S: IP source Address
ISP: Internet Service provider
MIPv4: Mobile IP for IPv4
MIPv6: Mobile IP for IPv6
MN-COA: Co-located care-of address of the MN
MN-Perm: Permanent home address of the MN
MIPP-Priv: MIP Proxy interface address on the private (HA) side
MIPP-Pub: MIP Proxy interface address on the public (Internet)
side
NAT: Network Address Translation
NATGW-Priv: NAT gatewayÆs IP address on the private (LAN) side
NATGW-Pub: NAT gatewayÆs IP address on the public (WAN) side
VPNGW-Priv: VPN Gateway Private/Intranet IP Address
VPNGW-Pub: VPN Gateway Public/External IP Address
2. Registration
The MN roaming outside the DMZ sends MIPv4 registration requests
directly to the MIP Proxy. The registration messages are not
protected by an IPsec tunnel, and MUST be excluded from the tunnel
SA applied to flows between the MN and any correspondent hosts via
the VPN gateway. The MIP Proxy terminates and authenticates the
registration requests. It then generates a new registration
request and forwards it to the corresponding actual HA. The
Adrangi, Iyer Expires January 2003 [Page 6]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
registration replies from the actual HA will also go through the
MIP Proxy bypassing the VPN gateway.
A railroad diagram illustrating the MIPv4 registration process is
shown below.
MN MIP Proxy HA
|Reg. Request | |
|-------------> | |
| |Reg. Request |
| |-------------> |
| |Reg. Reply |
| |<------------- |
|Reg. Reply | |
|<--------------| |
Figure 2. û Mobile IP registration protocol between
MN and HA
2.1. Authentication
Each MN and the MIP proxy MUST share the SA for the MN-HA
authentication extension. The MIP Proxy MUST authenticate
received Registration Requests or Replies before processing them.
The mechanisms to share SAs are beyond the current scope of this
draft. 2.2. Registration Request Process
The MIP Proxy MUST relay all valid Registration Requests received
from a MN to its actual HA, after updating its pending
registration request list. Here, relaying means that the MIP
Proxy creates a new Registration Request on the behalf of the MN
and sends it to the MNÆs actual HA. The MIP Proxy MUST be
compliant with [1], and it MUST adhere to the rules specified in
the following sub-sections in creating the new Registration
Request.
2.2.1. Registration Request Bits
- The new Registration Request header MAY have the same æMÆ,
æGÆ, rsv bit values included in the Registration Request
received from the MN.
- The æBÆ bit in new Registration Request header MUST be set
ifthe æBÆ bit in the Registration Request received from the MN
is set and the MIP Proxy supports broadcast.
- The æDÆ bit in the new Registration Request MUST NOT be set,
if the æBÆ bit is set. Although the surrogate MN side of the
MIP Proxy always uses a co-located care-of address (i.e, MIPP-
Priv), this restriction is enforced to cause the actual HA to
encapsulate a broadcast or a multicast IP datagram in a unicast
datagram addressed to the MNÆs home address, and then tunnel
Adrangi, Iyer Expires January 2003 [Page 7]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
this encapsulated datagram to the MIP Proxy (i.e, MIPP-Priv).
Otherwise, the MIP Proxy will not be able to route the
broadcast or multicast IP datagrams received from the HA(s), as
it cannot determine to which MN the packet should be routed.
- The æTÆ bit in the new Registration Request MUST be set, if
the MIP Proxy may route the MIPv4 data traffic received from
the MN to CN in reverse tunneling mode.
- The new Registration Request MUST NOT set the æSÆ bit, as the
actual HA will always have the same care-of address (MIPP-Priv)
for all its MNs roaming outside the DMZ. Please see section
2.7.1. for more details.
2.2.2. Registration Request Fields
- The new Registration Request header MUST have equal or
smaller lifetime value included in the registration request
received from the MN.
- The new Registration Request header MUST have the same
identification value included in the Registration Request
received from the MN.
- The new Registration Request header MUST have the same Home
Address value included in the Registration Request received
from the MN.
- The new Registration Request headerÆs HA address field MUST
be set to the MNÆs actual HA address.
- The new Registration Request headerÆs care-of address field
MUST be set to MIPP-Priv.
2.2.3. Registration Request Extensions
- The new Registration Request MUST contain all Registration
extensions included in the Registration Request received from
the MN, with the exception of the ones specific to the MN and
the MIP Proxy protocol negotiation and the authentication
extension protecting the registration message between the MN
and the MIP Proxy.
- The new Registration Request MUST include the MN-HA
authentication extension.
2.2.4. Registration Request Validity Check
When a Registration Request is received from a MN, the MIP
proxy MUST validate the registration request and respond to a
malformed registration request as a HA would, as specified in
[1]. In addition, the MIP proxy MUST also check the
Registration Request for the following:
Adrangi, Iyer Expires January 2003 [Page 8]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
- The æTÆ bit MUST be set in the Registration Request. If not,
the MIP Proxy MUST return a Registration Reply to the MN with
an appropriate error code specified in[2].
- The MIP proxy MUST check for the existence of the HA
Parameter extension, specified in section 2.6.3. In the absence
of a valid HA Parameter extension, the MIP proxy MUST return a
Registration Reply to the MN with an appropriate error code
specified in section 2.4.1 if MIP Proxy cannot determine an
appropriate HA to service the MN.
2.3. Registration Reply Process
The MIP proxy MUST relay Registration Replies received from
actual HAs to appropriate MNs. Here, relaying means that the MIP
Proxy creates a new Registration Reply on the behalf of the MNÆs
actual HA and sends it to the MN. The MIP proxy MUST update its
record of mobility bindings associated with a MN, before relaying
the registration reply to the MN.
In processing a registration reply, the MIP proxy MUST be
compliant with [1]. And, it MUST adhere to the rules specified in
the following sub-sections.
2.3.1. Registration Reply Fields
- The new Registration Reply header MUST have the same Code
value as in the Registration Reply received from the MNÆs
actual HA, except when MIP Proxy received accepted Registration
Reply from the actual HA but cannot service the MN (eg. create
mobility binding, route, tunnel). In this case, insufficient
resource (133) error code should be set in the Registration
Reply to the MN.
- The new Registration Reply header MUST have the same lifetime
value as in the Registration Reply received from the MNÆs
actual HA. If the lifetime value is zero, the MIP Proxy should
also retire the entry/entries in its mobility-binding list for
the MN, as specified in [1].
- The new Registration Reply header MUST have the same Home
Address value as in the Registration Reply received from the
MNÆs actual HA.
- The new Registration Reply headerÆs Home Agent address field
MUST be set to MIPP-Pub.
- The new Registration Reply header MUST have the same
identification value as the Registration Reply received from
the MNÆs actual HA.
Adrangi, Iyer Expires January 2003 [Page 9]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
- The new Registration Reply MUST contain all non-
authentication extensions included in the Registration Reply
received from the MNÆs actual HA.
- The new Registration Reply MUST include the ôMN-HAö
authentication extension.
- The new Registration Reply MAY include the ôFA-HAö
authentication extension, as needed.
2.4. Registration Reply Initiated by the MIP Proxy
The MIP proxy MAY deny a Registration Request for various
reasons. If so, the MIP Proxy MUST use an appropriate
registration denied code, specified in the following section.
2.4.1. New Registration Reply Codes
The following values are defined for use within the Code field.
Registration denied by the MIP Proxy:
200 missing HA Parameter extension
201 non zero HA address Required in HA Parameter extension
202 home agent unreachable (when ICMP unreachable received)
203 MISSING-NAI
204 MISSING-HOMEADDR
205 MISSING-HOME-AGENT
206 ASSIGNED-HOME-AGENT
2.5. Mobile Node Considerations
2.5.1. Location Detection
Location detection is done by MIP Proxy and MN is aware of its
location as per the response from MIP Proxy. Please see
section 2.6.1 for more details.
2.5.2. New Configuration Requirement
A mobile node MUST be configured with the MIPP-Pub, unless
dynamic MIPP-Pub discovery is used, which is outside the scope
of this draft.
2.5.3. HA Parameter Extension
When a MN registers with the MIP Proxy, it MUST include the
non-skippable HA Parameter extension. This extension is used
to indicate the IP address of the actual HA to the MIP Proxy.
HA address in the extension MAY be set to zero, to request
dynamic HA assignment û please see section 2.7.3. for more
details.
Adrangi, Iyer Expires January 2003 [Page 10]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
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 | Sub-Type |Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : To be assigned by IANA (non-skippable)
Length :
Indicates the length (in bytes) of the data fields
within the extension, excluding the Type and Length
bytes.
Sub-Type: To be assigned by IANA
Reserved: For future use.
Home Agent Address: IP address of the MNÆs actual HA
2.6. MIP Proxy Considerations
2.6.1. Algorithm for location detection
MN always communicates to the MIP Proxy (public address),
whether on internal or external network. MIP Proxy detects
location of MN either by 1) care-of address in the
Registration Request or source address if MN registers using
NAT traversal or 2) inside or outside interface receiving the
Registration Request.
As per #1 above, MIP Proxy does location detection based on
care-of-address in Registration Request. Internal addresses
(enterprise private and public addresses) are known at the
MIP Proxy and so MIP Proxy can determine if the care-of-
address is internal. If the Registration Request from MN
indicates NAT traversal (mismatch of source and care-of-
address), MIP Proxy uses the source address to determine the
location of MN.
If the network design can guarantee that internal traffic
reaches the MIP Proxy on internal interface and external
traffic reaches the MIP Proxy on external interface, then the
MIP Proxy can interpret the MNÆs location based on the
interface on which it receives Registration Request, as
mentioned in #2 above.
Regardless of location detection algorithm, if the
Registration Request originates from external network, MIP
Proxy forwards the Registration Request to the appropriate
HA. If the Registration Request originates from internal
network, MIP Proxy rejects the Registration Request with
error code 206. This informs MN to use the HA address
specified in HA Parameter Extension.
Adrangi, Iyer Expires January 2003 [Page 11]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
If MN is registering using dynamic HA assignment (HA address
in HA Parameter Extension set to zero) and if MN is
registering from internal network, MIP Proxy selects the home
agent and puts that address in home agent field in HA
Parameter Extension in Registration Reply with error code
206. If MN is registering using dynamic HA assignment from
external network, HA includes the home agent address in HA
Parameter Extension in Registration Reply (if successful).
If MN receives a Registration Reply with code set to 206, MN
interprets as being in internal network and registers
directly with the home agent. If MN is behind NAT in internal
network, it will register with the specified home agent using
UDP tunnel extension. The home agent in this case SHOULD
support NAT traversal.
When MN re-registers due to a change in care-of-address, MN
always registers with the MIP Proxy and includes the HA
Parameter extension. If MN is just renewing its registration,
MN registers with HA or MIP Proxy, the entity with which it
last registered.
HA Parameter Extension is always present in both Registration
Request and Registration Reply.
2.6.2. Simultaneous Mobility Binding
The MIP proxy MAY support simultaneous mobility bindings,
regardless of if a MNÆs actual HA supports this feature or not.
When a Registration Request with an æSÆ bit set (i.e.
simultaneous binding requested by a MN) is received, the MIP
proxy MUST NOT set the æSÆ bit in the new Registration Request,
whether or not it support simultaneous mobility bindings.
If the MIP Proxy supports simultaneous bindings and it receives
a Registration Request with an æSÆ set, it MUST set the
lifetime value in the relayed Registration Request to the
maximum of the remaining lifetime values of all existing
mobility bindings for this MN and the lifetime value of the new
Registration Request received from the MN. Any subsequent
Registration Request refreshes received for any of the existing
simultaneous mobility bindings MUST follow the same rule with
respect to setting the lifetime value in the Registration
Request to be relayed to the MNÆs actual home agent.
When the Registration Reply is received from the MNÆs actual
HA, the lifetime value in the mobility bindings list for this
MN MUST be set to the lesser value of the accepted lifetime
(reflected in the Registration Reply) and the existing lifetime
(the request lifetime through the Registration Request) in the
mobility bindings list of the MIP proxy.
Adrangi, Iyer Expires January 2003 [Page 12]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
If the MIP Proxy does not support simultaneous bindings and it
receives a Registration with an æSÆ bit set, it MUST send a
Registration Reply to the MN as specified in[1].
2.6.3. Mobile IP NAI Extension
The MIP proxy MAY support the Mobile IP NAI extension,
specified in [14].
If the MIP Proxy receives a Registration Request whose Home
Address is zero and includes the Mobile IP NAI extension, it
MUST use NAI instead in its pending registration request list.
If the Registration Reply has a non-zero Home Address and
includes the Mobile IP NAI extension, the MIP Proxy MUST update
its mobility bindings list for this MN, and relay the
Registration Reply to the MN.
The MIP Proxy MUST do the following validity checks, if it
supports the Mobile IP NAI extension.
- If Home Address is zero in the Registration Request and the
MIP Proxy does not support the Mobile IP NAI extension, the MIP
Proxy MUST silently discard the Request since there is no SA.
- If the MIP Proxy receives a Registration Request with a value
of zero in the Home Address field and no NAI extension, it MUST
silently discard the Request since there is no SA.
- If the Registration Reply from the MNÆs actual HA does not
include the Mobile Node NAI extension, the MIP proxy SHOULD
send the Registration Reply to the mobile node with an error
code indicating MISSING-NAI, as defined in section 2.4.1.
- If the Registration Reply from the MNÆs actual HA includes a
zero Home Address or zero Home Agent address, the MIP proxy
SHOULD send the Registration Reply to the mobile node with an
error code indicating MISSING-HOMEADDR or MISSING-HOME-AGENT,
as defined in section 2.4.1.
2.6.4. Dynamic HA Assignment
The MIP proxy MAY support dynamic HA assignment in conjunction
with dynamic home address assignment for a MN. If the MN sends
a Registration Request with the Home Agent field set to zero in
the HA Parameter extension and includes a valid NAI extension,
the MIP Proxy can dynamically assign a HA from a pool of HA IP
addresses. The selection of a HA is beyond the scope of this
draft. The selected HA MUST support the NAI extension in the
Registration Request. However, this scheme is NOT intended to
support dynamic HA handovers.
2.6.5. Pending Registration List
Adrangi, Iyer Expires January 2003 [Page 13]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
For each pending registration, the MIP Proxy maintains the
following information:
- The IP destination address of the actual HA
- The care-of address in the received Registration Request
- The identification in the received Registration Request
- The lifetime in the received Registration Request, and
- The remaining Lifetime of the pending registration
2.6.6. Mobility Bindings
The MIP Proxy MUST maintain a mobility binding list similar to
the one specified in [1] for a HA, in order to forward the
registration replies and subsequent MIPv4 data traffic. The MIP
Proxy updates its binding table, when a successful Registration
Reply is received from an actual HA.
For each mobility binding entry, the MIP Proxy maintains the
following information:
- The IP destination address of the actual HA
- The home address of the MN
- NAI if in the received Registration Request
- The care-of address in the received Registration Request
- The identification in the received Registration Request
- The lifetime in the received Registration Request, and
The MIP Proxy MUST also use the same methods defined in [1] for
deleting or retiring the entries in its mobility-binding
list(s).
2.6.7. Handling ICMP Error Messages
When the MIP Proxy sends a Registration Request to an actual HA
on the behalf of a MN, it may receive an ICMP error message
indicating that the actual HA is not reachable for a specific
reason (i.e., network unreachable, host unreachable, port
unreachable, protocol unreachable). If so, the MIP Proxy MUST
send a Registration Reply to the MN with Code indicating why
the actual HA was not reachable.
2.7. MIPv4 Registration Packet Flow
2.7.1. MIPv4 Registration Request Packet Flow from MN to HA
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.
Adrangi, Iyer Expires January 2003 [Page 14]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
From the MN to a FA:
+--------------------------------------------------+
|IP-S = MN-Perm | Permanent Address = MN-Perm |
|IP-D = FA-Visited| Home Agent = MIPP-Pub |
| | Care-of Address = FA-COA |
| | . . . |
+--------------------------------------------------+
From the FA to the MIP Proxy:
+--------------------------------------------------+
|IP-S = FA-Routed | 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 |
| | |
+--------------------------------------------------+
2.7.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-Routed | . . . |
+-----------------------------------------------+
From the FA to the MN:
+-----------------------------------------------+
|IP-S = FA-Visited| Home Agent = MIPP-Pub |
|IP-D = MN-Perm | . . . |
+-----------------------------------------------+
3. Functions Not Performed By The MIP Proxy
The MIP Proxy MUST NOT perform the following HA functions, as
defined in [1]:
- It MUST NOT generate agent advertisements
- It MUST NOT send gratuitous ARPs
Adrangi, Iyer Expires January 2003 [Page 15]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
- It MUST NOT perform Proxy ARP
- It MUST NOT support Route Optimization [10]
The MIP proxy MUST NOT perform the following MN functions, as
specified by [1]:
- It MUST NOT generate agent solicitations or functions pertaining
to agent discovery
- It MUST NOT implement any move detection mechanisms
- The MIP Proxy MUST NOT manage registration lifetimes and MUST
NOT reinitiate a registration request with the actual HA prior to
its expiration.
4. MIP Proxy Integration with VPN
The MIP Proxy as described in this draft is a logical functional
entity and as such can be integrated with VPN in 2 possible ways,
which are one-box and two-box solutions.
4.1. One-Box Integration
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. Figure 4.1. depicts a network stack resulted
from the one-box integration of the MIP proxy with the VPN
gateway. Please note that IPsec and the MIP Proxy layers can be
combined into one layer (tightly coupled integration), or they
can be layered as shown in figure 4.1. (loosely coupled
integration).
+------------+
| TCP/IP |
+------------+
| IPsec |
+------------+
| MIP Proxy |
+------------+
| Link Layer |
+------------+
| Physical |
| Layer |
+------------+
Figure 4.1. û One-Box Integration of MIP Proxy with VPN
4.1.1. Redundancy
A MIP Proxy redundancy protocol is desirable to effect high
availability in public and Enterprise deployments, when two box
solution approach is used. Details of such a protocol are
beyond the current scope of this draft.
Adrangi, Iyer Expires January 2003 [Page 16]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
4.2. Two-Box Integration
Implemented as a standalone device deployed in parallel with the
VPN gateway as depicted in Figure 1.2. 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 a MN and a CN.
4.2.1. Two-Box Integration Requirements
- 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.
- 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.
5. MIPv4 Data Traffic Routing Through VPN
This section describes MIPv4 data traffic flow through VPN with
the aid of the MIP Proxy. For clarity, this section assumes a
two-box solution approach.
5.1. Establishment of Secured MIPv4 Traffic
There are two steps that MUST be successfully completed in order
to establish secured MIPv4 traffic between a MN and a CN.
The first step is that the MN MUST complete MIPv4 registration
with its actual home agent through the MIP Proxy, as discussed in
section 2. The second step is that the MN MUST establish IPsec
tunnel SA to the VPN gateway through the MIP Proxy, as shown in
Figure 3.a. Any subsequent registration and SA refreshes may
occur independent of each other.
MN MIP Proxy VPN Gateway
| IKE-Phase 1/MIPv4 |
| --------------> | IKE-phase 1 |
| |-----------------> |
| | IKE-phase 2 |
| IKE-Phase 2/MIPv4|<-------------------|
| <---------------- | |
Figure 3.a û IPsec Tunnel SA Establishment
(Two Box Solution)
The data forwarding is described in the following 2 sub-sections.
5.2. Association Between VPN Inner and MN Home IP Address
Adrangi, Iyer Expires January 2003 [Page 17]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
To support continuous mobility and constant reachability, the
tunnel inner IP address assigned to a MN MUST be the same as the
home IP address.
5.3. MIPv4 Data Traffic from MN on External Network 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 or FA-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 MIP Proxy MUST perform the following validity checks on
received MIP data packets whose destination IP address is set to
MIPP-Pub (i.e., packets received from outside the DMZ).
- The received packet MUST be encapsulated by an appropriate
method (e.g., IP-in-IP, Minimal Encapsulation, GRE) that the
MIP Proxy supports
- The inner IP packetÆs destination IP address MUST be set to
a VPN gateway IP address that the MIP Proxy supports
- An ESP header MUST follow the inner IP header
If any of above validity checks fail, then the MIP Proxy MUST
silently drop the packet.
The packet routing from the MIP Proxy to the CN may differ
depending on whether the CN belongs to any of ômobility subnetsö
that the MIP Proxy supports. The following railroad diagrams
depict the packet flow sequence for both cases, followed by a
description of packets as they traverse the network.
MN FA MIP Proxy VPN Gateway HA CN
| | | | | |
| ----> | | | | |
| | -----> | | | |
| | | ------------> | | |
| | | | -----------------> |
Figure 5.2a û Packet flow from MN to CN, where the CN does not
belong to any of ôMobility subnetsö that the MIP Proxy supports
From the MN to FA: IP-ESP-IP-Data
From the FA to MIP Proxy: IP-IP-ESP-IP-Data
From MIP Proxy to VPN: IP-ESP-IP-Data
From VPN Gateway to CN: IP-Data
Adrangi, Iyer Expires January 2003 [Page 18]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
MN FA MIP Proxy VPN Gateway HA CN
| | | | | |
| ----> | | | | |
| | -----> | | | |
| | | ------------> | | |
| | | <----------- | | |
| | | -------------------------->| |
| | | | |-------->|
| | | OR |
| | |-----------------------------------> |
Figure 5.2b û Packet flow from MN to CN, where the CN belongs to
a ôMobility subnetö that the MIP Proxy supports
From the MN to FA: IP-ESP-IP-Data
From the FA to MIP Proxy: IP-IP-ESP-IP-Data
From MIP Proxy to VPN: IP-ESP-IP-Data
From VPN Gateway to MIP Proxy: IP-Data
(forwarded back to the MIP Proxy using via Network route
installed on the VPN gateway)
Reverse tunneling delivery method is used:
------------------------------------------
From MIP Proxy to HA: IP-IP-Data
From HA to CN: IP-Data
Non-Reverse Tunneling delivery method is used:
----------------------------------------------
From MIP Proxy to CN: IP-Data
The packet flow analysis from the MN to the CN is described
below. The analysis assumes that the CN does not belong to any
ômobility subnetsö that the MIP Proxy supports.
From the MN to the FA:
+------------------------------------------------+
| IP-S=MN-Perm |IPsec-ESP |IP-S=MN-Perm| Data |
| 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-Routed|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. FA only reverse tunnel traffic to the MIP
Proxy.
Adrangi, Iyer Expires January 2003 [Page 19]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
From the MIP Proxy to the VPN gateway:
The MIP Proxy strips off the outermost IP header and forwards the
packet (whose destination address is set to VPNGW-Pub) 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:
The VPN gateway completes IPsec tunnel processing on the packet,
strips off the outermost IP and ESP headers and forwards the
original IP datagram to the CN.
+---------------------+
|IP-S=MN-Perm| Data |
|IP-D=CN | |
+---------------------+
5.4. MIPv4 Data Traffic from CN to MN on External Network
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 CN to the HA: IP-Data
From the HA to the MIP Proxy: IP-IP-Data
From the MIP Proxy to the VPN gateway: IP-Data
From the VPN gateway to the MIP Proxy: IP-ESP-IP-Data
From the MIP Proxy to the FA: IP-IP-ESP-IP-Data
From the FA to the MN: IP-ESP-IP-Data
Adrangi, Iyer Expires January 2003 [Page 20]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
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 packet is intercepted by the actual HA, as the MN has moved
outside its home subnet.
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.
+---------------------+
|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| |
+--------------------------------------------------------+
Adrangi, Iyer Expires January 2003 [Page 21]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
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.
5.5. Key Management and SA Preservation
The MIPv4 data traffic routing described in the previous section
binds the IPsec tunnel SA to the normally invariant permanent
(home) 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 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 a 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.
5.6. 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. However the solution should apply to L2TP over IPsec
transport [12] and ESP-in-UDP VPN [13] configurations as well.
Note that ESP-in-UDP VPN is not necessary when Mobile IP UDP
tunnels [11] are in use.
5.7 Routing Considerations
VPN gateway must insert a route for the home network(s) to point
to the MIP Proxy. This route MUST not be redistributed via an
IGP.
On the MIP Proxy, packets that come from a MIP tunnel (on either
the Public or Private interface) must be forwarded (via layer-two
mechanism) to the VPN Gateway for IPSec tunnel
encapsulation/decapsulation.
5.7.1. Broadcast / multicast Datagrams
Adrangi, Iyer Expires January 2003 [Page 22]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
When an actual HA receives a broadcast or a multicast datagram,
it forwards the datagram to the MIP proxy for any qualified MNs
outside the DMZ.
Since the MIP proxy always unsets the æDÆ bit in a Registration
Request that it sends to the actual HA on the behalf of the MN
(see section 2.2.1), the actual home agent applies double
encapsulation on broadcast or multicast packets that need to be
forwarded to the MN, as specified in [1]. When the MIP Proxy
receives the double encapsulated packets from an actual HA, it
decapsulates the outer IP header, and then forwards the packet
to the VPN as shown below.
From Actual HA to the MIP Proxy:
+--------------------------------------------------+
|IP-S=HA |IP-S=HA | IP-S=CN | Data |
|IP-D=MIPP-Priv|IP-D=MN | IP-D=Bcast or | |
| | | IP-D=Mcast | |
+--------------------------------------------------+
From the MIP Proxy to VPN:
+-----------------------------------+
|IP-S=HA | IP-S=CN | Data |
|IP-D=MN | IP-D=Bcast or | |
| | IP-D=Mcast | |
+-----------------------------------+
5.7.2. MN Registration through a Trusted FA
A MN may roam into a network served by a trusted FA. The
trusted FA refers to a FA that has SA with the VPN-GW or a FA
whose hosting network has SA with VPN-GW and an IPsec tunnel
will be established between the FA or its hosting network and
the VPN-GW while necessary to protect any traffic between. In
this case, the MN MUST use the NAI extension in the FA route
advertisement or other mechanisms which are out of the scope of
this draft to determine that the FA is a trusted FA. The MN
MUST not use the MIP Proxy in this scenario, the FA is
responsible for properly tunneling the traffic including the
MIP signaling and data through the VPN-GW.
6. MIPv4 Traversal Through IPsec ôNAT and VPNö Gateways
This section extends MIPv4 VPN traversal solution described in
section 5 to support MIPv4 traversal across ôNAT and VPNö
scenario, in which MN has to traverse one or more NAT gateway(s)
followed by a VPN gateway in the path to its final destination.
A solution for MIPv4 traversal across intervening NAT gateways is
provided in [11] through a MN/HA protocol extension. The solution
cannot be directly applied here, since the MNÆs home agent is not
Adrangi, Iyer Expires January 2003 [Page 23]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
directly reachable. However, the solution can be leveraged by
simply corresponding the MIP Proxy surrogate HA to the HA in [11].
The following sub-sections show MIPv4 control and data packets
flow between a MN and a CN.
6.1. MIPv4 Registration Message Flow
6.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 = MN-COA |
| | . . . |
+-----------------------------------------------+
Please refer to section 4.5 and the [11] draft for detailed
discussion of required registration extensions.
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 = MN-COA |
| | . . . |
+-----------------------------------------------+
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 |
| | . . . |
+-----------------------------------------------+
6.1.2. MIPv4 Registration Replies
From the actual HA to the MIP Proxy:
+-------------------------------------+
|IP-S=HA | Home Agent = HA |
|IP-D=MIPP-Priv | . . . |
+-------------------------------------+
Adrangi, Iyer Expires January 2003 [Page 24]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
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=MIPP-Pub | Home Agent = MIPP-Pub |
|IP-D=MN COA | . . . |
+----------------------------------------+
6.2. MIPv4 Data Flow
6.2.1. Data Flow from the MN to the CN
From MN to the NAT gateway:
+--------------------------------------------------------+
|IP-S= | UDP|IP-S= |IPsec-ESP |IP-S=MN-Perm| Data |
| MN-Priv | |MN-Perm | | | |
|IP-D= | |IP-D= |MN-Perm to|IP-D=CN | |
|MIPP-Pub | |VPNGW-Pub | VPNGW-Pub| | |
+--------------------------------------------------------+
From the NAT gateway to the MIP Proxy:
+----------------------------------------------------------+
|IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=MN-Perm| Data |
|NATGW-Pub | | MN-Perm | | | |
|IP-D= | |IP-D= |MN-Perm to|IP-D=CN | |
|MIPP-Pub | |VPNGW-Pub |VPNGW-Pub | | |
+----------------------------------------------------------+
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 | |
+---------------------+
6.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| |
+---------------------+
Adrangi, Iyer Expires January 2003 [Page 25]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
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= | UDP |IP-S=VPNGW-Pub|IPsec-ESP |IP-S=CN| Data |
|MIPP-Pub | | | | | |
|IP-D= | |IP-D=NM-Perm |VPNGW-Pub to|IP-D= | |
|NATGW-Pub| | | |MN-Perm| |
| | | |MN-Perm | | |
+----------------------------------------------------------+
From the NAT gateway to MN:
+------------------------------------------------------------+
|IP-S= | UDP |IP-S= |IPsec-ESP |IP-S=CN |Data |
|MIPP-Pub | |VPNGW-Pub | | | |
|IP-D= | |IP-D= |VPNGW-Pub to|IP-D=MN-Perm| |
|MN-Priv | |NM-Perm | MN-Perm | | |
| | | | | | |
+------------------------------------------------------------+
7. 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 vulnerability to
the mobile IP protocol.
8. Acknowledgements
Adrangi, Iyer Expires January 2003 [Page 26]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
The authors would like to thank Mike Andrews, Changwen Liu and
Ranjit Narjala of Intel Corporation, Sami Vaarala of Netseal,
Alexis Oliverean of Motorola for their review and feedback on this
draft.
9. Intellectual Property Rights
Intel Corporation is in the process of filing one or more patent
applications that may be relevant to this IETF draft.
Cisco Systems is in the process of filing one or more patent
applications that may be relevant to this IETF draft.
10. Revision History
1) Initial Version
9/2001
2) Second Version 3/2002
+ Modified the draft to meet requirements defined in
[15]
+ General Clean up
+ Made changes to reflect comments/feedbacks from
Sami Vaarala of Netseal, Qiang Zhang of
Ecutel, Alexis Oliverean of Motorola
11. References
[1] Perkins. IP mobility support for IPv4. RFC 3220, January 2002
[2] Montenegro. Reverse tunneling for mobile IP. RFC 3024,
January 2001
[3] Perkins. Minimal encapsulation within IP. RFC 2004, October
1996
[4] Hanks, Farinacci, Traina. Generic Routing encapsulation. RFC
1701, October 1994
[5] Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997
[6] Rekhter, Moskowitz, Karrenberg. Address Allocation for Private
Internets. RFC 1918, Feburary 1996
[7] Droms. Dynamic Host Configuration Protocol. RFC 2131, March
1997
[8] <draft-bpatil-mobileip-sec-guide-01.txt> - Requirements /
Implementation Guidelines for Mobile IP using IP Security
[9] Cheshire, Aboba. Dynamic Configuration of IPv4 Link-Local
Addresses. <draft-ietf-zeroconf-ipv4-linklocal-03>, April 2002
[10] Perkins, Johnson. Route Optimization in Mobile IP. <draft-
ietf-mobileip-optim-11.txt>, September 2001
[11] Levkowetz, Vaarala. Mobile IP NAT/NAPT Traversal using UDP
Tunneling. <draft-ietf-mobileip-nat-traversal-01.txt>, March 2002
[12] Patel, Aboba, Zorn, Booth, RFC 3193 û Securing L2TP with
IPsec
[13] Huttunen , Dixon, Swander. UDP Encapsulation of IPsec Packets
<draft-ietf-ipsec-udp-encaps-02>, April 2002
Adrangi, Iyer Expires January 2003 [Page 27]
Internet Draft draft-adrangi-mobileip-vpn-traversal-02 July 2002
[14] Calhoun, Perkins. Mobile IP Network Access Identifier
Extension for IPv4. RFC 2794, March 2000
[15] Adrangi, Leung, Kulkarni, Patel, Zhang, Lau. Problem
Statement and Requirements for Mobile IPv4 Traversal Across VPN
Gateways. <draft-ietf-mobileip-vpn-problem-statement-00.txt>,
March 2002
Authors:
Farid Adrangi Email: farid.adrangi@intel.com
Phone: 503-712-1791
Prakash Iyer Email: prakash.iyer@intel.com
Phone: 503-264-1815
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR 97124
USA
Kent Leung Email: kleung@cisco.com Phone: 408-526-5030
Milind Kulkarni Email: mkulkarn@cisco.com Phone: 408-527-8382
Alpesh Patel Email: alpesh@cisco.com Phone: 408-853-9580
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134
Qiang Zhang Email: qzhang@liqwidnet.com
Phone:703 8641327
Liqwid Networks Inc.
Joe Lau Email: jlau@cup.hp.com Phone: 408 447-2159
Hewlett-Packard Company
19420 Homestead Road, MS 4301
Cupertino, CA 95014
Adrangi, Iyer Expires January 2003 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-21 18:48:33 |