RFC 4093
Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways
RFC 4093: Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways ✨
Okay bestie, this is RFC 4093 🦋 It's an Informational doc from the Network Working Group, dated August 2005. The editors are F. Adrangi (Ed.) from Intel and H. Levkowetz (Ed.) from Ericsson 💅 Its title block doesn't list anything it obsoletes or updates, so it's standing on its own 👑
Status of This Memo 🌸
This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind, and it can be distributed freely, no limits 💖
Copyright Notice 🎀
Copyright (C) The Internet Society (2005).
Abstract ✨
Deploying Mobile-IP v4 in networks that connect to the Internet through a Virtual Private Network (VPN) gateway runs into some problems that don't have well-described solutions yet 😭 This doc describes and illustrates those problems, then suggests some guidelines for possible fixes 🔥
Table of Contents 🧚
1. Introduction ....................................................2
1.1. Overview of the Problem ....................................3
1.2. Specification of Requirements ..............................3
1.3. Terminology ................................................3
2. MIP and VPN Deployment Scenarios ................................4
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway .......5
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border .......6
2.3. Combined VPN Gateway and MIPv4 HA ..........................7
2.4. MIPv4 HA(s) Outside the VPN Domain .........................8
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link .....9
3. Deployment Scenarios Selection ..................................9
4. Problem Statement ..............................................10
4.1. Registering in Co-Located Mode ............................11
4.2. Registering via an FA .....................................12
4.3. Summary: MIP Incompatibilities with IPsec-Based
VPN Gateways ..............................................13
5. Solution Guidelines ............................................14
5.1. Preservation of Existing VPN Infrastructure ...............14
5.2. Software Upgrades to Existing VPN Client and Gateways .....14
5.3. IPsec Protocol ............................................14
5.4. Multi-Vendor Interoperability .............................14
5.5. MIPv4 Protocol ............................................15
5.6. Handoff Overhead ..........................................15
5.7. Scalability, Availability, Reliability, and Performance ...15
5.8. Functional Entities .......................................15
5.9. Implications of Intervening NAT Gateways ..................15
5.10. Security Requirements ....................................16
6. Security Considerations ........................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................171. Introduction 💫
Okay so Mobile IP [RFC3344] agents are getting deployed in enterprise networks so people can move between wired and wireless LANs while roaming around inside the enterprise Intranet 🏢✨ Plus, IEEE 802.11 access points ("hot spots") are popping up everywhere, like hotels, airports, and convention centers, and wireless WAN data networks like General Packet Radio Service (GPRS) are a thing too. So people really need mobile users to keep their transport connections and constant reachability while they connect back to their target "home" networks, which are protected by Virtual Private Network (VPN) technology 🥺 That means Mobile IP and VPN have to coexist and work together to give enterprise mobile users both mobility and security 🫶
The goal of this document is to:
- Identify and describe practical deployment scenarios for Mobile IP and VPN in enterprise and operator environments.
- Identify example usage scenarios for remote users roaming outside the "home" network protected by a VPN gateway.
- Articulate the problems resulting from Mobile IP and VPN coexistence.
- Specify a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways.
1.1. Overview of the Problem 🔐
The Intranet is usually guarded by a firewall and a VPN device, so you only get in if you respect the security policies of both 🙈
When MIP gets deployed in a corporate Intranet (also called a VPN domain), roaming between the Intranet (the trusted domain) and the Internet (the untrusted domain) gets messy 💀 Seamless session mobility between the two would be amazing, because MIP was designed for session mobility no matter where you plug in. Unfortunately, the current MIP standards fall short of that promise for an important group: corporate users who use VPN for remote access and want mobility support, because they need continuous access to Intranet resources while roaming outside the Intranet, whether they're moving from one subnet to another or between the VPN domain and the Internet 🌈
From the very beginning, there was one explicit restriction: installed firewalls and VPN gateways had to stay unchanged, not replaced or upgraded, since they had way wider deployments than MIP at the time of writing 👑 So any solution needs to minimize the impact on existing VPN and firewall deployments, related standards, and "de facto" standards 💅
1.2. Specification of Requirements 📜
In this document, a few words are used to signify the requirements of the specification, and they're often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔥
1.3. Terminology 🍓
Here's the glossary, so we're all on the same page:
MIPv4 Mobile IP for IPv4 [RFC3344]
MIPv6 Mobile IP for IPv6
VPN Virtual Private Network
GW Gateway
VPN Domain An Intranet protected by a VPN gateway.
DMZ (Demilitarized Zone) A small network inserted as a
"neutral zone" between a company's private network and
the outside public network to prevent outside users
from getting direct access to the company's private
network.
Home Network A network, possibly virtual, having a network prefix
matching that of a mobile node's home address.
Home Agent A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is
away from home, and maintains current location
information for the mobile node.
MN Refers to a mobile node that runs both MIP and IPsec-
based VPN client software.
MIPv4 inside IPsec-ESP tunnel
MIPv4 packets are encapsulated in an IPsec-ESP tunnel
established between the Mobile Node and the VPN
gateway.
IPsec-ESP inside MIPv4 tunnel
IPsec-ESP packets are encapsulated in a MIPv4 tunnel
established between the Mobile Node and the home agent.2. MIP and VPN Deployment Scenarios 🦋
This section describes a set of deployment scenarios where MIP agents and VPN gateways have to coexist to give you mobility and security at the same time 🌸 The goal is to find practical scenarios where MIP tech could be extended to solve the problems that come from wanting these two to coexist.
The network topology in the diagrams below is an Intranet connected to the public network (aka the Internet) 🌐 Here, "Intranet" means a private network (where private addresses [RFC1918] are typically used) protected by a VPN gateway, and maybe also by a layer-3 transparent or non-transparent firewall. When private addresses are used, the non-transparent firewall also works as a Network Address Translator (NAT) or Network Address Port Translator (NAPT), bridging the two address realms (the Intranet and the Internet) 🧚
Firewalls can sit on either side of the VPN gateway, and these are called inner and outer firewalls. The inner and outer firewalls typically inspect outbound traffic (from the Intranet to the Internet) and inbound traffic (from the Internet to the Intranet), respectively 🫶 When a firewall is present, it MUST be configured to allow Mobile IP traffic (both control and tunneled data packets) to go through 🚨 Since the focus here is the relationship between MIP and VPN, the firewalls are left out of the scenarios below to keep things simple 💖
Encryption is assumed to not be enforced inside the VPN domain, and here's why:
- the VPN domain (Intranet) is viewed as a trusted network, and users allowed inside the Intranet are also trusted, and
- it's a common VPN deployment practice where the VPN guards Intranet resources from unauthorized users on an untrusted network, and gives authorized users a secure channel to reach Intranet resources from the outside 🔒
The following subsections introduce five representative combinations of MIPv4 HA and VPN gateway placement ✨
In order to give a reasonably complete survey of MIPv4 and VPN coexistence scenarios, the ones in Sections 2.3 and 2.5 are included, even though, as covered in more detail below, there are no coexistence problems to solve in those two cases 🌈
2.1. MIPv4 HA(s) Inside the Intranet behind a VPN Gateway ✨
okay so the MIPv4 HAs live deep inside the Intranet, tucked behind a VPN gateway 🔐. That means MNs chilling outside the Intranet can't reach them directly 😭
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | HA | .
. |away| | | .<=========>| | | 1..n | | 1..n | .
. +----+ +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 1Direct application of MIPv4 standards [RFC3344] works just fine 🎀 for giving mobility to users inside the Intranet. But mobile users outside the Intranet can only reach Intranet resources (like the MIP agents) through the VPN gateway, and that gateway only lets in authenticated IPsec traffic 🧱. So the MIPv4 traffic has to run inside IPsec, and that causes two distinct problems:
- When the foreign network has an FA deployed (for example, in CDMA 2000), MIPv4 registration becomes impossible 💀. The MIPv4 traffic between the MN and the VPN gateway is encrypted, and the FA (which is probably in a different administrative domain) can't inspect the MIPv4 headers it needs for relaying the MIPv4 packets. Check out Section 4.2 for more details 👀.
- In co-located mode, registration does work, but the VPN tunnel has to be re-negotiated every single time the MN changes its point of network attachment 🙃.
These problems are articulated in Section 4 🧚.
This deployment scenario may not be super common yet, but it's practical 💅 and it's becoming important because more and more corporate remote users need continuous access to Intranet resources 🌈.
2.2. VPN Gateway and MIPv4 HA(s) on the VPN Domain Border 🦋
So here, a MIPv4 HA sits on the VPN domain border (think the DMZ) right alongside the VPN gateway, and MNs inside or outside the Intranet can reach it directly 💖.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<=========>| | | 1..n | .
. +----+ +----+ . /\ | GW | +-------+ .
. . || +----+ .
. . || +----+ +-------+ +-------+ .
. . ++====>| HA | | CN | | MNs | .
................... | | | 1..n | | home | .
+----+ +-------+ +-------+ .
. .
................................
Figure 2Please note that in deployments where the security policy blocks direct communication between the MN (roaming outside the Intranet) and outside machines, the HA can be configured to forward only encrypted traffic from/to the MN 🔒.
The MIPv4 HA has a public interface connected to the Internet and a private interface attached to the Intranet 🌸. Mobile users will most likely have a virtual home network tied to the MIPv4 HA's private interface, so mobile users are always away from home and therefore always registered with the MIPv4 HA 🏠. Also, when the VPN gateway and the HA sit in a corporate DMZ, MIPv4 traffic always gets routed through the DMZ, whether the MNs are outside or inside the Intranet 🚦. Big corporations' IT departments might not be okay with that 😬.
This deployment can run with two configurations: "MIPv4 inside IPsec-ESP tunnel" and "IPsec-ESP inside MIPv4 tunnel" 🫶. The "MIPv4 inside IPsec-ESP tunnel" has the same problems as the scenario in Section 2.1. (So MIPv4 registration becomes impossible when registration goes through an FA, and in co-located mode the VPN tunnel has to be re-negotiated every time the MN changes its point of attachment 😩.) The "IPsec-ESP inside MIPv4 tunnel" doesn't have the problems from Section 2.1, but it will need some changes to the routing logic of the MIPv4 HA or the VPN gateway 🛠️.
2.3. Combined VPN Gateway and MIPv4 HA ⭐
This is basically the same as the scenario in Section 2.2, except the VPN gateway and the MIPv4 HA run on the same physical machine 🧃.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . | + | +-------+ .
. . | HA | .
................... +----+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 3Running the MIPv4 HA and the VPN on the same machine fixes the routing issues from Section 2.2 when you use an "IPsec-ESP inside MIPv4 tunnel" configuration ✨. But it doesn't help multi-vendor interoperability in environments where the MIPv4 HA and the VPN technologies have to come from different vendors 🥲.
2.4. MIPv4 HA(s) Outside the VPN Domain 🌍
In this scenario, the MIPv4 HAs are deployed outside the Intranet (for example, in an operator network), as shown in Figure 4 below 🗺️.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ .
. |MNs | | FA | . | VPN| | Router| .
. |away| | | .<==========| GW | | 1..n | .
. +----+ +----+ . /\ | | +-------+ .
. . || | | .
................... || | | +-------+ +-------+ .
|| | | | CN | | MNs | .
.....MIPv4 Home.... || | | | 1..n | | home | .
. .<===++ | | +-------+ +-------+ .
. +------+ . +----+ .
. | HAs | . . .
. | 1..n | . ................................
. +------+ .
...................
Figure 4The IPsec tunnel endpoints are the MN and the VPN gateway 🤝. The 'home network' will most likely be a virtual home network located at the HA. Through it, authorized remote users (the ones who have successfully connected to the corporate VPN) can reach the Corporate Intranet and keep their transport session connectivity while roaming outside the Intranet from one subnet to another 🏃♀️💨. Please note that this deployment does not support mobility inside the Intranet 🙅♀️.
In this case, it's most practical to run IPsec-ESP inside a MIPv4 tunnel 🎀. The MIPv4 tunnel endpoints are the MN and the HA, and the IPsec-ESP packet from the MN to the VPN gateway gets encapsulated in the MIPv4 tunnel. The reason is that the MNs can register with the HA without establishing an IPsec tunnel to the VPN gateway 🧠.
2.5. Combined VPN Gateway and MIPv4 HA(s) on the Local Link 🔥
This is similar to the scenario in Section 2.3, with one difference: the VPN gateway/HA sits on the local link 🔗. The VPN gateway and the HA would most naturally be co-located in the same box, although that's in no way a requirement 📦.
The VPN/HA is assumed to be reachable from the external network. In other words, it's assumed to have a public IP address, and the firewall is assumed to be configured to allow direct access to the VPN/HA from the external network 🌐.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +------+ +-------+ +-------+ .
. |MNs | | FA | . | Fire | | Router| | VPN/HA| .
. |away| | | .<=======>| wall | | 1..n | | 1..n | .
. +----+ +----+ . | | +-------+ +-------+ .
. . | NAT | .
................... +------+ +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 5This deployment works today with no technical problems when IPsec-ESP runs inside a MIPv4 tunnel 🥳. If you ran MIPv4 inside the IPsec-ESP tunnel, you'd get the same problems as in Section 2.1, so it's deployed with IPsec-ESP inside the MIPv4 tunnel instead 🙌. The catch is that this deployment isn't practical for large deployments (on the order of thousands of users) because the security perimeter is large and distributed 😵💫.
3. Deployment Scenarios Selection ✨
okay so first we had to figure out which of the scenarios from Section 2 are actually worth fixing 🧐 we checked each one against two questions: 1) is the scenario common and practical? and 2) does it reveal any problems from MIPv4 and VPN coexisting? 💅
the authors think Section 2.1 is the most important one, because more and more corporate remote users need continuous access to their Intranet resources 💼 once you dig into the scenarios in Sections 2.2 and 2.4, their problems are either the exact same as Section 2.1's or a subset of them 🫶 so solving Section 2.1 also solves those two. the scenarios in Sections 2.3 and 2.5 don't cause any functional problems from MIPv4 and VPN coexistence, so there's no need to hunt for a fix there 🙅♀️ a solution for Section 2.1 is essential, and it can also be applied to problems in the other scenarios. next up, we'll walk through the roaming scenarios, the problems, and the solution guidelines that matter for Section 2.1 🦋
4. Problem Statement 🔥
this section covers the roaming scenarios that match the deployment scenario in Section 2.1, where an MN needs continuous access to Intranet resources whether it's roaming inside or outside the Intranet 🌸 along with each scenario, we get the problems that come with it. these scenarios are built on a multi-subnetted, MIPv4-enabled Intranet (we'll just call it the Intranet or VPN domain from here on) that's protected by an IPsec-based VPN gateway, as shown in Figure 6 💖
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . +----+ .
................... . +-------+ +-------+ .
. | CN | | MNs | .
. | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 6: Intranet protected by a VPN gatewaythe Intranet in Figure 6 can have both wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments 📶 but you can also end up with IEEE 802.11 deployments outside the Intranet, because people don't always trust current 802.11 security 🙈 that setup is shown in Figure 7 🌈
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away| .<=========>| | | 1..n | | 1..n | .
. +----+ . | GW | +-------+ +-------+ .
. . | | .
................... | | +-------+ +-------+ .
| | | CN | | MNs | .
..802.11 Wireless.. <====>| | | 1..n | | home | .
. Network . +----+ +-------+ +-------+ .
. . . .
................... ................................
Figure 7: IEEE 802.11 Wireless deployment outside the home network4.1. Registering in Co-Located Mode 🧚
okay so in co-located mode, the IPsec tunnel endpoints are the MN and the VPN gateway 🎀 assuming we're in the Section 2.1 scenario, that means the mobile-ip tunnel from the MN to the HA ends up encapsulated inside the IPsec tunnel 🌀 see Figure 8 below. it's still possible, but it has some major drawbacks 😭
....Internet....... .....VPN Domain..(Intranet).....
. . . .
. +----+ . +----+ +-------+ +-------+ .
. |MNs | . | VPN| | Router| | VPN/HA| .
. |away|<###################>| |-----| 1..n |->| 1..n | .
. +----+ . \ | GW | +-------+ +-------+ .
. . \ +----+ .
................... mip . +-------+ +-------+ .
inside . | CN | | MNs | .
IPsec . | 1..n | | home | .
. +-------+ +-------+ .
. .
................................
Figure 8the MN gets an address at its point of attachment (through DHCP [RFC2131] or some other method) and then sets up an IPsec tunnel to the VPN gateway 🔐 after that it can register with its HA through the IPsec tunnel ✅ the IPsec tunnel SA (Security Association) is identified by a triplet: the SPI (Security Parameter Index), the MN's IP destination address (the address it got at the point of attachment), and the Security Protocol (AH or ESP) Identifier, as described in [RFC2401] 🧾 that means every time the MN's IP destination address changes on an IP subnet handoff, the IPsec tunnel has to be re-established 💀 this could seriously hurt performance for real-time applications and for resource-constrained wireless networks 📉 basically, there's no mobility support for the tunnel endpoint changes that come with MN movement 😤
4.2. Registering via an FA 🌷
so here's where things get really messy 🙃 this happens when a mobile node is on a network that provides mobility support through an FA, and it has no DHCP-allocated address and co-located mode isn't possible. we run into severe trouble 🆘 Figure 9 shows it and the explanation follows 👇
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. |MNs | | FA | . | VPN| | Router| | VPN/HA| .
. |away|<??| |<###########>| |-----| 1..n |->| 1..n | .
. +----+ \ +----+ . \ | GW | +-------+ +-------+ .
. \ . \ +----+ .
...........\....... mip . +-------+ +-------+ .
\ inside . | CN | | MNs | .
MN expects IPsec . | 1..n | | home | .
IPsec traffic . +-------+ +-------+ .
. .
................................
Figure 9when the MN arrives at the visited network on the left in this figure, it has to reach the FA with registration requests so the FA can pass them on to the HA 📬 but the MN most likely can't register with the FA, because the registration requests are sent encrypted and the FA can't decrypt them 🔒❌ if the MN had a policy allowing split tunneling, so it could reach the FA with clear text messages, the FA still couldn't get through the VPN gateway. that only works if the HA is reachable from outside and the Intranet security policy lets MIP registration packets bypass the VPN gateway 🚪
even if the HA is reachable and the MIP registration succeeds, the FA (which probably sits in a different administrative domain) still can't relay packets between the MN and the VPN gateway 🙅♀️ packets from the MN get encapsulated by the FA with IP-in-IP [RFC2003], and the VPN gateway drops them 🗑️ packets coming from the VPN gateway have ESP payloads (with IP-in-IP inside), and the FA drops those too, because it only expects IP-in-IP-encapsulated traffic to the MN 💀
people have suggested a 'trusted FA' for this scenario, meaning an FA that's actually a combined VPN GW and FA 🧠 this works fine, because the tunnel endpoints end up at the FA and the VPN gateway, as shown in Figure 10 below ✨ but we can't expect FAs in access networks (like wireless hot-spots or CDMA 2000 networks) to have security associations with any given corporate network 🥲 so it's not really realistic for the general mobility case.
..Foreign Network.. .....VPN Domain..(Intranet).....
. . . .
. +----+ +----+ . +----+ +-------+ +-------+ .
. | FA | | VPN| . | VPN| | Router| | VPN/HA| .
. | |<--| GW |<###########>| |-----| 1..n |->| 1..n | .
. +----+ +----+ . \ | GW | +-------+ +-------+ .
. | . \ +----+ .
. +----+ . mip . +-------+ +-------+ .
. |MNs | . inside . | CN | | MNs | .
. |away| . IPsec . | 1..n | | home | .
. +----+ . . +-------+ +-------+ .
................... . .
................................
Figure 10and on top of all that, this solution leaves the traffic between the FA and the MN unprotected 😬 since that link might be wireless, that's clearly not okay 🚨
4.3. Summary: MIP Incompatibilities with IPsec-Based VPN Gateways ✨
okay so bestie 🫶 an MN roaming outside the Intranet has to set up an IPsec tunnel to its home VPN gateway first 😭 before it can register with its home agent, because it literally can't reach its HA (which is hiding inside the private protected network) directly from the outside 🙈. So the MIPv4 traffic from the MN to a node inside the Intranet gets forced to run inside an IPsec tunnel, which means it's not in the clear 🔒. That causes two different problems depending on whether the MN uses co-located or non-co-located modes to register with its HA 💅.
In co-located mode, the IPsec tunnel has to be re-established on every IP subnet handoff, and ngl that's going to hurt performance for real-time apps and resource-constrained wireless networks 💀.
In non-co-located mode (aka using an FA care-of address) it gets even messier 😩. The MN might not be able to register with its HA through the FA at all, because the FA can't understand MIPv4 registration requests if they're encrypted in the IPsec tunnel (aka split tunneling isn't supported). Even if the MN could reach the FA with non-encrypted registration requests (split tunneling supported!) and the requests going from the FA to the HA could get through the VPN gateway, there would still be a routing problem for data packets between the Intranet and the internet 🌐. The VPN won't let IP-in-IP-encapsulated packets from the FA through. And ESP-encapsulated packets from the VPN gateway to the MN get dropped by the FA, since it's expecting IP-in-IP traffic to the MN 💔.
5. Solution Guidelines 🎀
This section describes guidelines for a solution to MIPv4 traversal across VPN gateways 🦋.
5.1. Preservation of Existing VPN Infrastructure
- The solution MUST work with currently deployed VPN gateways 👑. This is the whole raison d'etre of this investigation: finding a way to deploy Mobile-IP in cases where a VPN solution is already in place.
5.2. Software Upgrades to Existing VPN Client and Gateways
- The solution SHOULD minimize changes to existing VPN client/gateway software ✨.
5.3. IPsec Protocol
- The solution SHOULD NOT require any changes to existing IPsec or key-exchange standard protocols implemented by VPN gateways 🙅♀️.
- The solution SHOULD NOT require that the VPN gateway or the VPN client implement any new protocols in addition to the existing standard protocols.
5.4. Multi-Vendor Interoperability
- The solution MUST provide multi-vendor interoperability 🫶, whereby MIPv4 mobility agents, mobility clients (MN), VPN server, and VPN client solutions may come from four different vendors. This is typical for medium and large enterprises that purchase and deploy best-of-breed multi-vendor solutions for IP routing, VPNs, firewalls, etc.
5.5. MIPv4 Protocol
- The solution MUST adhere to MIPv4 protocol [RFC3344]. That is, the solution MUST NOT impose any changes that violate MIPv4 protocol 🚫.
- The solution MAY introduce new extensions to MIPv4 nodes per guidelines specified in the MIPv4 protocol [RFC3344]. However, in order to overcome barriers to deployment, it is highly desirable to avoid any changes to MIPv4 mobility agents such as the FA and HA 🌸.
- The solution MAY require more than one instance of MIPv4 running in parallel (multiple encapsulation).
5.6. Handoff Overhead
- It is imperative to keep the key management overhead down to a minimum 🧚, in order to support fast handoffs across IP subnets. Therefore, the solution MUST propose a mechanism to avoid or minimize IPsec tunnel SA renegotiation and IKE renegotiation as the MN changes its current point of network attachment.
5.7. Scalability, Availability, Reliability, and Performance
- The solution complexity MUST increase at most linearly with the number of MNs registered and accessing resources inside the Intranet 📈.
- The solution MAY introduce additional header or tunneling overhead if needed.
5.8. Functional Entities
- The solution MAY introduce new MIPv4-compliant functional entities 🍓.
5.9. Implications of Intervening NAT Gateways
- The solution MUST be able to work with the existing MIPv4 and IPsec NAT traversal solutions [RFC3519] [RFC3715] [RFC3947] 🦋.
5.10. Security Requirements
- The solution MUST provide security that is not inferior to what is already provided to existing "nomadic computing" remote access users 🔐; i.e., for confidentiality, authentication, message integrity, protection against replay attacks, and related security services.
6. Security Considerations 🚨
This document describes an existing problem and proposes guidelines for possible solutions, so its security implications are indirect, flowing through the guidelines it proposes for the solutions. Section 5.10 gives the relevant security requirements. Read that section, bestie, it's the one that matters 💜.
7. Acknowledgements 🫶
The authors who contributed text to this document were, in no particular order: Farid Adrangi, Milind Kulkarni, Gopal Dommety, Eli Gelasco, Qiang Zhang, Sami Vaarala, Dorothy Gellert, Nitsan Baider, and Henrik Levkowetz.
The authors would like to thank other contributors, especially Prakash Iyer, Mike Andrews, Ranjit Narjala, Joe Lau, Kent Leung, Alpesh Patel, Phil Roberts, Hans Sjostrand, Serge Tessier, Antti Nuopponen, Alan O'Neill, Gaetan Feige, and Brijesh Kumar, for their feedback and help in improving this document 💖.
8. References 📚
8.1. Normative References
8.2. Informative References
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, May 2003.
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
- [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
Authors' Addresses 🏡
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro OR
USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Henrik Levkowetz
Ericsson Research
Torshamsgatan 23
SE-164 80 Stockholm
SWEDEN
Phone: +46 7 08 32 16 08
EMail: henrik@levkowetz.comFull Copyright Statement ©
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ⚖️
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💐
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀✨
📦 where this page comes from
- ietf: rfc4093 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms