RFC 5265

Mobile IPv4 Traversal across IPsec-Based VPN Gateways

📅 published June 2008, from ietf

RFC 5265: Mobile IPv4 Traversal across IPsec-Based VPN Gateways 🎀

Okay bestie, this one is from the Network Working Group 🌸. The authors are S. Vaarala (Codebay) and E. Klovning (Birdstep) 🫶. It's on the Standards Track 👑, and it's dated June 2008 📅. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬. If you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🦋.

Abstract 💜

This document is all about the Mobile IPv4 (MIPv4) and IPsec coexistence problem for enterprise users 🧚. The solution has two pieces. First, there's an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios 💼. Second, there's a required mechanism for detecting the trusted internal network securely 🔐. It's giving main character energy, ngl 💅.

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  1.3.  Related Work . . . . . . . . . . . . . . . . . . . . . . .  5
  1.4.  Terms and Abbreviations  . . . . . . . . . . . . . . . . .  5
  1.5.  Requirement Levels . . . . . . . . . . . . . . . . . . . .  6
  1.6.  Assumptions and Rationale  . . . . . . . . . . . . . . . .  7
  1.7.  Why IPsec Lacks Mobility . . . . . . . . . . . . . . . . .  8
2.  The Network Environment  . . . . . . . . . . . . . . . . . . .  9
  2.1.  Access Mode: 'c' . . . . . . . . . . . . . . . . . . . . . 12
  2.2.  Access Mode: 'f' . . . . . . . . . . . . . . . . . . . . . 13
  2.3.  Access Mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 13
  2.4.  Access Mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 14
  2.5.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 14
3.  Internal Network Detection . . . . . . . . . . . . . . . . . . 15
  3.1.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . 16
  3.2.  Implementation Requirements  . . . . . . . . . . . . . . . 16
    3.2.1.  Separate Tracking of Network Interfaces  . . . . . . . 16
    3.2.2.  Connection Status Change . . . . . . . . . . . . . . . 16
    3.2.3.  Registration-Based Internal Network Detection  . . . . 17
    3.2.4.  Registration-Based Internal Network Monitoring . . . . 17
  3.3.  Proposed Algorithm . . . . . . . . . . . . . . . . . . . . 19
  3.4.  Trusted Networks Configured (TNC) Extension  . . . . . . . 20
  3.5.  Implementation Issues  . . . . . . . . . . . . . . . . . . 20
  3.6.  Rationale for Design Choices . . . . . . . . . . . . . . . 21
    3.6.1.  Firewall Configuration Requirements  . . . . . . . . . 21
    3.6.2.  Registration-Based Internal Network Monitoring . . . . 22
    3.6.3.  No Encryption When Inside  . . . . . . . . . . . . . . 22
  3.7.  Improvements . . . . . . . . . . . . . . . . . . . . . . . 22
4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 23
  4.1.  Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
  4.2.  VPN Device Requirements  . . . . . . . . . . . . . . . . . 23
  4.3.  Home Agent Requirements  . . . . . . . . . . . . . . . . . 24
5.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  5.1.  Comparison against Guidelines  . . . . . . . . . . . . . . 24
  5.2.  Packet Overhead  . . . . . . . . . . . . . . . . . . . . . 26
  5.3.  Latency Considerations . . . . . . . . . . . . . . . . . . 27
  5.4.  Firewall State Considerations  . . . . . . . . . . . . . . 27
  5.5.  Intrusion Detection Systems (IDSs) . . . . . . . . . . . . 28
  5.6.  Implementation of the Mobile Node  . . . . . . . . . . . . 28
  5.7.  Non-IPsec VPN Protocols  . . . . . . . . . . . . . . . . . 28
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
  6.1.  Internal Network Detection . . . . . . . . . . . . . . . . 29
  6.2.  Mobile IPv4 versus IPsec . . . . . . . . . . . . . . . . . 30
7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 32
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A.  Packet Flow Examples  . . . . . . . . . . . . . . . . 34
  A.1.  Connection Setup for Access Mode 'cvc' . . . . . . . . . . 34

1. Introduction ✨

Okay so the Mobile IP working group went and explored the problem and solution spaces of IPsec and Mobile IP coexistence 🌈. The problem statement and solution requirements for the Mobile IPv4 case were first written up in [RFC4093] 📝. This document is the solution for IPv4 🦋.

The document has two parts 💖:

  • a basic solution that is an applicability statement of Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks, intended for enterprise mobile users; and
  • a technical specification and a set of requirements for secure detection of the internal and the external networks, including a new extension that must be implemented by a mobile node and a home agent situated inside the enterprise network.

There are a lot of cool ways to combine Mobile IPv4 and IPsec 🍓. The solution here fits best when the assumptions in the problem statement [RFC4093] are valid 🧠. Among other things, the solution:

  • must minimize changes to existing firewall/VPN/DMZ (DeMilitarized Zone) deployments;
  • must ensure that traffic is not routed through the DMZ when the mobile node is inside (to avoid scalability and management issues);
  • must support foreign networks with only foreign agent access;
  • should not require changes to existing IPsec or key exchange protocols;
  • must comply with the Mobile IPv4 protocol (but may require new extensions or multiple instances of Mobile IPv4); and
  • must propose a mechanism to avoid or minimize IPsec re-negotiation when the mobile node moves.

1.1. Overview 🗺️

Typical corporate networks have three domains 🏢: the Internet (untrusted external network), the intranet (trusted internal network), and the DMZ, which connects the two. Getting into the internal network is guarded by both a firewall and a VPN device 🔥. You only get in if both the firewall and VPN security policies are respected 🙅‍♀️.

Enterprise mobile users would love unrestricted, seamless session mobility between subnets 😭, whether those subnets are internal or external 💅. Unfortunately, the current Mobile IPv4 and IPsec standards alone don't give you that service [tessier] 💀.

The solution is to use standard Mobile IPv4 when the mobile node is in the internal network 🏠. There's one exception: a new extension used by the home agent in the internal network to help with network detection 🔍. When the mobile node is outside, it uses the VPN tunnel endpoint address for the Mobile IPv4 registration instead 🌍. IPsec-based VPN tunnels need re-negotiation after movement, which is annoying 😤. To get around that, another layer of Mobile IPv4 sits underneath IPsec, which basically makes IPsec unaware of movement 🧚. So the mobile node can freely move around the external network without disrupting the VPN connection 🦋.

Briefly, when outside, the mobile node:

  • detects that it is outside (Section 3);
  • registers its co-located or foreign agent care-of address with the external home agent;
  • establishes a VPN tunnel using, e.g., Internet Key Exchange Protocol (IKE) (or IKEv2) if security associations are not already available;
  • registers the VPN tunnel address as its co-located care-of address with the internal home agent; this registration request is sent inside the IPsec tunnel.

The solution needs control over the protocol layers in the mobile node 🎛️. It must be able to (1) detect whether it's inside or outside in a secure way, and (2) control the protocol layers accordingly 🫶. For example, if the mobile node is inside, the IPsec layer needs to go dormant 😴.

Other than the new Mobile IPv4 extension for better security of internal network detection, the current Mobile IPv4 and IPsec standards are enough to build this when they're combined in the right way 💖. No changes are required to existing VPN devices or foreign agents 🙌.

The solution works with different kinds of IPsec-based VPNs, and no particular kind of VPN is required 🌸. The Security Policy Database (SPD) entries and other IKE and IPsec specifics differ between deployed IPsec-based VPN products, so the document doesn't go into those details 🤷‍♀️.

1.2. Scope 🎯

This document describes a solution for IPv4 only 🙅‍♀️. The downside of this approach is that an external home agent is required, and the packet overhead (see Section 5) and overall complexity go up 📈. Optimizations would need significant changes to Mobile IPv4 and/or IPsec, and those are out of scope for this document 🚫.

In this document, VPN means an IPsec-based remote access VPN 🔐. Other types of VPNs are out of scope 💅.

There's related work on Mobile IPv6 in [RFC3776] 🌈. That one covers how IPsec and Mobile IPv6 interact when protecting Mobile IPv6 signaling 🛡️. It also talks about dynamically updating the IPsec endpoint based on Mobile IP signaling packets ⭐.

The "transient pseudo-NAT" attack, described in [pseudonat] and [mipnat], affects any approach that tries to secure mobility signaling alongside NAT devices 😬. In many cases you can't assume any cooperation from NAT devices, so they have to be treated like any other networking entity 🙈.

The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] gives IPsec better mobility 🦋. That would let the external Mobile IPv4 layer described in this specification be removed 💜. However, deploying MOBIKE requires changes to VPN devices, so it's out of scope for this specification 🫠.

1.4. Terms and Abbreviations

okay bestie, time to decode the alphabet soup 🍓 here's the glossary you need:

  • co-CoA: co-located care-of address 🎀
  • DMZ (DeMilitarized Zone): a small network inserted as a "neutral zone" between a company's private network and the outside public network, so outside users can't get direct access to the company's private network 🧱
  • external network: the untrusted network (i.e., the Internet). Note that a private network (e.g., another corporate network) other than the mobile node's internal network is considered an external network too 🌐
  • FA: mobile IPv4 foreign agent
  • FA-CoA: foreign agent care-of address
  • FW: firewall 🔥
  • internal network: the trusted network, like a physically secure corporate network where the i-HA lives 🏰
  • i-FA: Mobile IPv4 foreign agent residing in the internal network
  • i-HA: Mobile IPv4 home agent residing in the internal network; it typically has a private address [privaddr] 🔒
  • i-HoA: home address of the mobile node in the internal home agent
  • MN: mobile node 📱
  • NAI: Network Access Identifier [RFC4282] 🪪
  • R: router
  • VPN: Virtual Private Network based on IPsec 💜
  • VPN-TIA: VPN tunnel inner address, which is the address(es) negotiated during IKE phase 2 (quick mode), assigned manually, using IPsec-DHCP [RFC3456], using the "de facto" standard Internet Security Association and Key Management Protocol (ISAKMP) configuration mode, or by some other means. Some VPN clients use their current care-of address as their Tunnel Inner Address (TIA) for architectural reasons, and honestly that's a whole vibe 💅
  • VPN tunnel: an IPsec-based tunnel; for instance, an IPsec tunnel mode IPsec connection, or Layer 2 Tunneling Protocol (L2TP) combined with an IPsec transport connection 🚇
  • x-FA: Mobile IPv4 foreign agent residing in the external network
  • x-HA: Mobile IPv4 home agent residing in the external network
  • x-HoA: home address of the mobile node in the external home agent

1.5. Requirement Levels

okay so these are the magic words 🪄 the way this doc uses them is locked in by BCP 14 and RFC 2119 [RFC2119], so read them as the official definitions:

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 BCP 14, RFC 2119 [RFC2119].

1.6. Assumptions and Rationale

this section is lowkey the heart of the whole solution 🫶 it's an attempt to solve the problem described in [RFC4093], and here's the tea on the major assumptions and why they exist:

Changes to existing firewall and VPN deployments should be minimized:

  • The current deployment of firewalls and IPsec-based VPNs is much larger than corresponding Mobile IPv4 elements. So a solution should work within the existing VPN infrastructure 🏗️
  • Current enterprise network deployments typically centralize management of security and network access into a compact DMZ 🧱

When the mobile node is inside, traffic should not go through the DMZ network:

  • Routing all mobile node traffic through the DMZ is seen as a performance problem in existing firewall deployments. The more sophisticated the firewall technology (e.g., content scanning), the more serious the performance problem gets 😭
  • Current firewall and DMZ deployments have been optimized for the case where only a small minority of total enterprise traffic goes through the DMZ. Also, users of current VPN remote access solutions don't route their traffic through the DMZ when they're connected to an internal network 🙅‍♀️

A home agent inside the enterprise cannot be reached directly from outside, even if the home agent contains IPsec functionality:

  • Deployment of current combined IPsec/MIPv4 solutions is not common in large installations 🤷‍♀️
  • Doing decryption in the home agents "deep inside" the enterprise effectively means having a security perimeter much larger than the typical, compact DMZ that most enterprises use today 🍰
  • To maintain a security level equal to current firewall/DMZ deployments, every home agent decapsulating IPsec would need to do the same firewalling as the current DMZ firewalls (content scanning, connection tracking, etc.) 🚨

Traffic cannot be encrypted when the mobile node is inside:

  • There's a considerable performance impact on home agents (which currently do rather light processing) and mobile nodes (especially small devices). Traffic throughput inside the enterprise is typically an order (or more) of magnitude larger than the remote access traffic through a VPN 📈
  • Encryption consumes processing power and has a significant impact on device battery life 🔋
  • There's also a usability issue: the user needs to authenticate the connection to the IPsec layer in the home agent to gain access. For interactive authentication mechanisms (e.g., SecurID), this always means user interaction 🙈
  • Furthermore, if there's a separate VPN device in the DMZ for remote access, the user needs to authenticate to both devices, and might need separate credentials for each one 😤
  • Current Mobile IPv4 home agents don't typically incorporate IPsec functionality, which matters for the solution when we assume zero or minimal changes to existing Mobile IPv4 nodes 🧩
  • Note, however, that the assumption (no encryption when inside) doesn't necessarily apply to all solutions in the solution space. If the above-mentioned problems were resolved, there is no fundamental reason why encryption couldn't be applied when inside 🌈

1.7. Why IPsec Lacks Mobility

okay this one's giving main character drama 🎭 IPsec, as currently specified [RFC4301], requires that a new IKE negotiation be done whenever an IPsec peer moves, i.e., changes its care-of address. The main reason is that a security association is unidirectional and identified by a triplet consisting of (1) the destination address (which is the outer address when tunnel mode is used), (2) the security protocol (Encapsulating Security Payload (ESP) or Authentication Header (AH)), and (3) the Security Parameter Index (SPI) ([RFC4301], Section 4.1). Although an implementation is not required to use all of these for its own Security Associations (SAs), an implementation cannot assume that a peer doesn't 🫣

When a mobile IPsec peer sends packets to a stationary IPsec peer, there's no problem 💖 the SA is "owned" by the stationary IPsec peer, so the destination address doesn't need to change. The (outer) source address should be ignored by the stationary peer (although some implementations do check the source address as well) 👀

The problem shows up when packets go from the stationary peer to the mobile peer 😩 The destination address of this SA (SAs are unidirectional) is established during IKE negotiation, and it's effectively the care-of address of the mobile peer at the time of negotiation. So the packets get sent to the original care-of address, not a changed one. Oof 💀

The IPsec NAT traversal mechanism can also be used for limited mobility, but UDP tunneling needs to be used even when there's no NAT in the route between the mobile and the stationary peers. Furthermore, support for changes in current NAT mapping is not required by the NAT traversal specification [RFC3947] 🙃

In summary, although the IPsec standard doesn't as such prevent mobility (in the sense of updating security associations on-the-fly), the standard doesn't include a built-in mechanism (explicit or implicit) for doing so. So it's assumed throughout this document that any change in the addresses comprising the identity of an SA requires IKE re-negotiation, which implies too heavy computation and too large latency for useful mobility 🐢

The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec ✨ That would let the external Mobile IPv4 layer described in this specification be removed. However, deploying MOBIKE requires changes to VPN devices, so it's out of scope of this specification 🙅‍♀️

2. The Network Environment 🌐✨

okay so enterprise users are hopping between the internal and external networks using totally different networking tech 💅. In some networks the MN is going to use FAs, and in others it anchors at the HA using co-located mode. Here's a diagram that shows how the internal and external networks connect and every place the mobile node (MN) might be living its best life 🦋.

  (MN) {fvc}                            {home} (MN)   [i-HA]
   !                                             \     /
.--+---.                                        .-+---+-.
(        )                                      (         )
 `--+---'                      [VPN]             `--+----'
    \                           !                  !
  [R/FA]        [x-HA]       .--+--.              [R]
       \         /          (  DMZ  )              !
      .-+-------+--.         `--+--'         .-----+------.
     (              )           !           (              )
     ( external net +---[R]----[FW]----[R]--+ internal net )
     (              )                       (              )
      `--+---------'                         `---+---+----'
        /                                       /     \
  [DHCP]  [R]                              [DHCP] [R]     [R]    [i-FA]
     \    /                                   \   /         \    /
     .+--+---.                               .-+-+--.     .--+--+-.
    (         )                             (        )   (         )
     `---+---'                               `--+---'     `---+---'
         !                                      !             !
    (MN) {cvc}                             (MN) {c}      (MN) {f}

Figure 1: Basic topology, possible MN locations, and access modes

In every possible location in that diagram, the mobile node can connect to the corresponding HA(s) by using a suitable "access mode" 🎀. An access mode is defined here as having two parts:

  1. a composition of the mobile node networking stack (i-MIP or x-MIP/VPN/i-MIP); and
  2. registration mode(s) of i-MIP and x-MIP (if used); i.e., co-located care-of address or foreign agent care-of address.

Each access mode gets encoded as "xyz", where:

  • "x" indicates whether the x-MIP layer is used, and if used, the mode ("f" indicates FA-CoA, "c" indicates co-CoA, absence indicates not used);
  • "y" indicates whether the VPN layer is used ("v" indicates VPN used, absence indicates not used); and
  • "z" indicates mode of i-MIP layer ("f" indicates FA-CoA, "c" indicates co-CoA).

That gives us four access modes, bestie 🍓:

      c:  i-MIP with co-CoA
      f:  i-MIP with FA-CoA
    cvc:  x-MIP with co-CoA, VPN-TIA as i-MIP co-CoA
    fvc:  x-MIP with FA-CoA, VPN-TIA as i-MIP co-CoA

This notation gets way more useful once people start optimizing the protocol layers, so it's kept here 🧚 that way anyone doing optimization work can point at the same shared naming.

The internal network is usually a multi-subnetted network using private addressing [privaddr]. Subnets might contain internal home agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 wireless LANs are usually deployed in the external network or the DMZ because of security concerns 🔥.

The figure leaves out a few details that are worth noticing 👀:

  • There may be multiple NAT devices anywhere in the diagram.
    • When the MN is outside, the NAT devices may be placed between the MN and the x-HA or the x-HA and the VPN.
    • There may also be NAT(s) between the VPN and the i-HA, or a NAT integrated into the VPN. Basically, any router in the figure may be considered to represent zero or more routers, each possibly performing NAT and/or ingress filtering.
    • When the MN is inside, there may be NAT devices between the MN and the i-HA.
  • Site-to-site VPN tunnels are not shown. Although mostly transparent, IPsec endpoints may perform ingress filtering as part of enforcing their policy.
  • The figure shows a topology where each functional entity is drawn as a separate device. However, several network functions can be co-located in a single device. In fact, all three server components (x-HA, VPN, and i-HA) may be co-located in a single physical device.

The following issues are also a big deal when you're thinking about enterprise mobile users 💀:

  • Some firewalls are configured to block ICMP messages and/or fragments. Such firewalls (routers) cannot be detected reliably.
  • Some networks contain transparent application proxies, especially for HTTP. Like firewalls, such proxies cannot be detected reliably in general. IPsec and Mobile IPv4 are incompatible with such networks.

Whenever a mobile node obtains either a co-CoA or an FA-CoA, these conceptual steps happen 🌸:

  • The mobile node detects whether the subnet where the care-of address was obtained belongs to the internal or the external network using the method described in Section 3 (or a vendor-specific mechanism fulfilling the requirements described).
  • The mobile node performs necessary registrations and other connection setup signaling for the protocol layers (in the following order):
    • x-MIP (if used);
    • VPN (if used); and
    • i-MIP.

Note that these two tasks are intertwined to some extent 🫶: detecting the internal network results in a successful registration to the i-HA using the proposed network detection algorithm. An improved network detection mechanism that isn't based on Mobile IPv4 registration messages might not have this side effect.

The following subsections describe the different access modes and the requirements for the registration and connection setup phase ✨.

2.1. Access Mode: 'c'

This access mode is standard Mobile IPv4 [RFC3344] with a co-located address, except that:

  • the mobile node MUST detect that it is in the internal network; and
  • the mobile node MUST re-register periodically (with a configurable interval) to make sure it is still inside the internal network (see Section 4).

2.2. Access Mode: 'f'

This access mode is standard Mobile IPv4 [RFC3344] with a foreign agent care-of address, except that:

  • the mobile node MUST detect that it is in the internal network; and
  • the mobile node MUST re-register periodically (with a configurable interval) to make sure it is still inside the internal network (see Section 4).

2.3. Access Mode: 'cvc'

Steps 🦋:

  • The mobile node obtains a care-of address.
  • The mobile node detects it is not inside and registers with the x-HA, where
    • T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems.
  • If the mobile node does not have an existing IPsec security association, it uses IKE to set up an IPsec security association with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
  • The mobile node sends a MIPv4 Registration Request (RRQ) to the i-HA, registering the VPN-TIA as a co-located care-of address, where
    • T-bit SHOULD be set (reverse tunneling) (see discussion below).

Reverse tunneling in the inner Mobile IPv4 layer is often required because of IPsec security policy limitations. IPsec selectors define the allowed IP addresses for packets sent inside the IPsec tunnel. Typical IPsec remote VPN selectors restrict the client address to be the VPN-TIA (the remote address is often unrestricted). If reverse tunneling is not used, the source address of a packet sent by the MN will be the MN's home address (registered with i-HA), which is different from the VPN-TIA, and that violates the IPsec security policy. So the packet gets dropped, and you end up with a connection black hole 🕳️😭.

Some types of IPsec-based VPNs, in particular L2TP/IPsec VPNs (PPP-over-L2TP-over-IPsec), don't have this limitation and can use triangular routing 🔺.

Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons. Don't skip the VPN, bestie 🙈.

2.4. Access Mode: 'fvc'

Steps 🌈:

  • The mobile node obtains a foreign agent advertisement from the local network.
  • The mobile node detects it is outside and registers with the x-HA, where
    • T-bit MAY be set (reverse tunneling), which minimizes the probability of firewall-related connectivity problems.
  • If necessary, the mobile node uses IKE to set up an IPsec connection with the VPN gateway, using the x-HoA as the IP address for IKE/IPsec communication. How the VPN-TIA is assigned is outside the scope of this document.
  • The mobile node sends a MIPv4 RRQ to the i-HA, registering the VPN-TIA as a co-located care-of address, where
    • T-bit SHOULD be set (reverse tunneling) (see discussion in Section 2.3).

Note that although the MN can use triangular routing, i.e., skip the inner MIPv4 layer, it MUST NOT skip the VPN layer for security reasons. Same rule, same vibe 💅.

2.5. NAT Traversal

NAT devices may affect each layer independently 🧩. Mobile IPv4 NAT traversal [mipnat] SHOULD be supported for the x-MIP and i-MIP layers, while IPsec NAT traversal [RFC3947][RFC3948] SHOULD be supported for the VPN layer.

Note that NAT traversal for the internal MIPv4 layer may be necessary even when there isn't a separate NAT device between the VPN gateway and the internal network. Some VPN implementations NAT VPN tunnel inner addresses before routing traffic to the intranet. Sometimes this is done to make a deployment easier, but in some cases this approach makes VPN client implementation easier. Mobile IPv4 NAT traversal is required to establish a MIPv4 session in this case 🔥.

3. Internal Network Detection ✨

okay bestie, this part is literally the main event 🫶 Detecting the internal network is critical, because if you get it wrong, plaintext traffic goes out over an untrusted network 😭 Your overall security (confidentiality and integrity of user data) depends on this detection mechanism working alongside IPsec. So the security requirements live right here.

Getting into the internal network is the easy part, security-wise. The mobile node can make sure it's inside before it sends any plaintext traffic. Leaving is the tricky bit 💀 If the mobile node misses the exit, the MN might accidentally leak plaintext packets.

Several things can make the mobile node leave the internal network, including:

  • a routing change upstream;
  • an 802.11 reassociation at layer 2 that the mobile node software doesn't notice;
  • a physical cable being unplugged and plugged back in, which the mobile node software doesn't notice.

Whether the mobile node can reliably spot these changes depends on the implementation and the networking technology 🍓 Some mobile nodes are pure layer three entities, so they're not even looking at layer 2. And even if the software can see layer 2 info, that info isn't trustworthy from a security standpoint, and it depends on the network interface driver. Not ideal, bestie 🙈

If the mobile node misses these events, it may leak plaintext traffic into an untrusted network. There are a bunch of ways to detect leaving the internal network, ranging from re-registering really often to using layer two information.

The mobile node MUST implement a detection mechanism that fulfills the requirements in Section 3.2. That's the non-negotiable baseline that keeps the basic security requirements intact. Section 3.3 describes one way to do it, but other methods can be used instead or alongside it. The assumptions behind all of this are in Section 3.1.

3.1. Assumptions

The enterprise firewall MUST be configured to block traffic coming from external networks that's headed to the i-HA. Put another way, the mobile node MUST NOT be able to complete a successful Registration Request/Registration Reply (RRQ/RRP) exchange without using IPsec unless it's connected to the trusted internal network 💅 If that's true, the mobile node can stop using IPsec without wrecking data confidentiality.

If this assumption doesn't hold, confidentiality gets compromised in a sneaky, silent, and honestly dangerous way 😱 To shrink the damage, the i-HA is also required to check the source address of any RRQ, to see whether it comes from a trusted (internal network) address. To say it supports this check, the i-HA includes a Trusted Networks Configured extension in its registration reply. This new extension has to be implemented by both the i-HA and the MN, and it's covered in Section 3.4 ✨

The firewall MAY be configured to block registration traffic to the x-HA that comes from inside the internal network. That makes network detection simpler and more robust 🦋 Still, registration requests are basically UDP traffic, so an ordinary firewall (even a stateful one) would usually let the request out and let the registration reply back in.

3.2. Implementation Requirements

Any mechanism used to detect the internal network MUST fulfill the requirements in this section 💜 An example of a detection mechanism that meets these requirements is in Section 3.3.

3.2.1. Separate Tracking of Network Interfaces

The mobile node implementation MUST track each network interface separately 🌸 A successful registration with the i-HA through interface X tells you nothing about interface Y. Be iconic and keep them separate!

3.2.2. Connection Status Change

When the mobile node notices that its connection status on a given network interface has changed, the mobile node MUST:

  • immediately stop relaying user data packets;
  • detect whether this interface is connected to the internal or the external network; and
  • resume data traffic only after the internal network detection and the necessary registrations and VPN tunnel establishment have been completed.

The mechanisms used to detect a connection status change depend on the mobile node implementation, the networking technology, and the access mode 🧚

3.2.3. Registration-Based Internal Network Detection

The mobile node MUST NOT infer that an interface is connected to the internal network unless all three of these are true: a successful registration has been completed through that particular interface to the i-HA, the i-HA registration reply contained a Trusted Networks Configured extension (Section 3.4), and the interface's connection status hasn't changed since. No shortcuts, bestie 🙅‍♀️

3.2.4. Registration-Based Internal Network Monitoring

Some leakage of plaintext packets to a (potentially) untrusted network can't always be completely prevented 😭 It depends heavily on the client implementation. Sometimes the client can't detect a change at all, for example when the upstream routing changes.

Re-registering more often while the MN is inside is a simple way to check that it's still inside. The MN SHOULD start re-registration every (T_MONITOR - N) seconds while inside, where N is a grace period that makes sure the re-registration finishes before T_MONITOR seconds are up ⏰ To cap how long a plaintext leak can last, the mobile node must fulfill the following security requirements while inside:

  • The mobile node MUST NOT send or receive a user data packet if more than T_MONITOR seconds have passed since the last successful (re-)registration with the i-HA.
  • If more than T_MONITOR seconds have passed, data packets MUST be either dropped or queued. If they're queued, the queues MUST NOT be processed until the re-registration has been successfully completed without a connection status change.
  • The T_MONITOR parameter MUST be configurable, and it has a default value of 60 seconds. That default is a trade-off between traffic overhead and a reasonable limit on exposure 💖

This approach works well for a wide range of mobile nodes (laptops, for example), but it's a lot of unnecessary overhead when the mobile node is idle, meaning it's not sending or receiving packets 😴 If re-registration doesn't finish before T_MONITOR seconds are up, data packets must be queued or dropped as described above. Also, re-registration packets MUST be sent even when bidirectional user data traffic is being relayed. Data packets are no substitute for an authenticated re-registration, so don't let anyone tell you otherwise 🫶

To cut down on traffic when the mobile node is idle, re-registrations can be stopped while no traffic is being sent or received. If the mobile node later receives or needs to send a packet, that packet must be dropped or queued (as described above) until a re-registration with the i-HA has been successfully completed. This adds packet processing complexity, but it may be a good fit for small, battery-powered devices that spend much of their time idle 🔋 (Note that ordinary re-registration before the mobility binding lifetime runs out should still happen, so the MN stays reachable.)

T_MONITOR is required to be configurable so an administrator can pick the security level for their particular deployment. Setting T_MONITOR to a few seconds isn't practical, so if you need that level of confidence, you'll have to look at alternative mechanisms 👑

The re-registration mechanism is a worst-case fallback. If the mobile node has extra information available, such as layer two triggers, it SHOULD use those triggers to detect MN movement and restart the detection process, which keeps exposure to a minimum ✨

Also, Mobile IPv4 requires re-registration by default (except in the atypical case of an infinite binding lifetime). However, the re-registration interval can be much longer when you're using an ordinary Mobile IPv4 client 🌈 A shorter re-registration interval usually isn't a problem, because the internal network is typically a fast, wired network, and the shorter interval only applies while the mobile node is inside. When it's outside, the ordinary Mobile IPv4 re-registration process (based on the binding lifetime) takes over.

3.3. Proposed Algorithm

When the MN detects that it has changed its point of network attachment on a given interface, it sends out two simultaneous registration requests: one to the i-HA and one to the x-HA 🦋 These requests get periodically retransmitted if reply messages don't show up.

Registration replies get handled like this:

  • If a response from the x-HA arrives, the MN stops retransmitting its registration request to the x-HA and tentatively decides it's outside. However, the MN MUST keep on retransmitting its registration to the i-HA for a period of time. The MN MAY postpone the IPsec connection setup for some time while it waits for a (possible) response from the i-HA ⏳
  • If a response from the i-HA arrives and it contains the Trusted Networks Configured extension (Section 3.4), the MN SHOULD determine that it's inside. In any case, the MN MUST stop retransmitting its registration requests to both the i-HA and the x-HA 💅
  • When the MN has successfully registered directly with the i-HA, it SHOULD de-register with the x-HA 🧹

If the MN ends up detecting that it's inside, it MUST re-register periodically (regardless of binding lifetime). See Section 3.2.4 for the details 💖 If a re-registration fails, the MN MUST stop sending and receiving plaintext traffic, and MUST restart the detection algorithm 🚨

Plaintext re-registration messages are always addressed either to the x-HA or to the i-HA, never to both. That's because after the initial registration, the MN knows whether it's inside or outside 🧠 (When the mobile node is outside, it re-registers independently with the x-HA using plaintext, and with the i-HA through the VPN tunnel.)

Postponing the IPsec connection setup could prevent aborted IKE sessions. Aborting IKE sessions can be a problem in some cases, because IKE doesn't provide a reliable, standardized, and mandatory-to-implement mechanism for ending a session cleanly 🙃

If the x-HA isn't reachable from inside (meaning the firewall configuration is known), a detection period of zero is preferred. It keeps connection setup overhead low and causes no timing problems ✨ If the assumption turns out to be invalid and a response from the i-HA arrives after a response from the x-HA, the MN SHOULD re-register with the i-HA directly 🫶

3.4. Trusted Networks Configured (TNC) Extension ✨

okay so this one is a skippable extension 🦋 (meaning it's fine to skip it if you don't understand it, no drama). An i-HA sending it MUST fulfill the requirements in Section 4.3, and an MN processing it MUST fulfill the requirements in Section 4.1. The format is described below, and it follows the short extension format from [RFC3344] 🎀

    0                   1                   2                   3
    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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 149 🌸
  • Length: 2
  • Sub-Type: 0
  • Reserved: Set to 0 when sending, ignored when receiving

3.5. Implementation Issues 🙈

So when the MN uses a parallel detection algorithm and is using an FA, it sends two registration requests through the same FA, with the same Media Access Control (MAC) address (or equivalent) and possibly even the same home address. Not technically in conflict with existing specs, BUT it's an unusual scenario, so some FA implementations may not handle it properly. Testing against deployed foreign agents seems to show that a majority of them handle it fine, which is a relief 😭

When the x-HA and i-HA addresses are the same, it gets even messier for the FA, and it's almost certain that existing FAs don't deal with it correctly. That's why it is required that x-HA and i-HA addresses MUST be different. Non-negotiable, bestie 💅

Regardless, if the MN detects that i-HA and x-HA have the same address, it MUST assume that it's in the external network and bypass network detection so it doesn't confuse the FA. Since the HA addresses get used at different layers, connectivity is still possible without any address confusion. Main character recovery 🦋

The mobile node MAY use the following hints to figure out that it's inside, but it MUST verify reachability of the i-HA anyway 👑

  • a domain name in a DHCPDISCOVER / DHCPOFFER message
  • an NAI in a foreign agent advertisement
  • a list of default gateway MAC addresses that are known to reside in the internal network (i.e., configured as such, or have been previously verified to be inside)

So like, if the MN has reason to believe it's inside, it MAY postpone sending a registration request to the x-HA for some time. Similarly, if the MN has reason to believe it's outside, it may start IPsec connection setup right after getting a registration reply from the x-HA. BUT if the MN gets a registration reply from the i-HA after IPsec connection setup has already started, the MN SHOULD still switch to using the i-HA directly. Plot twist handled ✨

3.6. Rationale for Design Choices 🧚

3.6.1. Firewall Configuration Requirements

The requirement that the i-HA cannot be reached from the external network is necessary, no cap. If it weren't, a successful registration with the i-HA (without IPsec) couldn't be used as a secure indication that the mobile node is inside. A possible fix for that obvious security problem would be to define and deploy a secure internal network detection mechanism based on, e.g., signed FA advertisements or signed DHCP messages.

However, unless the mechanism is defined for both FA and DHCP messages and is deployed in every internal network, it has limited applicability. So the mobile node MUST NOT assume it is in the internal network unless it receives a signed FA or DHCP message (regardless of whether or not it can register directly with the i-HA). If it receives an unsigned FA or DHCP message, it MUST use IPsec, otherwise the mobile node can be easily tricked into using plaintext 💀

Assuming that all FA and DHCP servers in the internal network get upgraded to support such a feature doesn't seem realistic. It's highly desirable to be able to take advantage of existing DHCP and FA deployments. Similar analysis seems to apply no matter what kind of additional security mechanism gets defined 🫶

Because a firewall configuration error can have catastrophic data security consequences (silent exposure of user data to external attackers), a separate protection mechanism is provided by the i-HA. The i-HA must be configured, by the administrator, with a list of trusted networks. The i-HA advertises that it knows which registration request source addresses are trusted, using a registration reply extension (Trusted Networks Configured extension, Section 3.4). Without this extension, an MN may not rely on a successful registration to indicate that it is connected to the internal network. This makes sure user data compromise does not occur unless both the firewall and the i-HA are configured incorrectly. Further, occurrences of registration requests from untrusted addresses should be logged by the i-HA, so they get exposed to administrator review 👀

Hot take: a firewall misconfig is scary, so the i-HA is the backup bodyguard here. Two layers, both have to mess up 🔥

3.6.2. Registration-Based Internal Network Monitoring

This issue also affects IPsec client security. However, IPsec specifications take no stand on how and when client IPsec policies are configured or changed (for instance, in response to a change in network connectivity), so the issue is out of scope for IPsec. Because this document describes an algorithm and requirements for (secure) internal network detection, the issue IS in scope for this document 🎀

The current requirement for internal network monitoring was added as a fallback mechanism 🌈

3.6.3. No Encryption When Inside

If encryption were also applied when the MN is inside, there would be no security reason to monitor the internal network periodically. Makes sense, right? 🙈

The main rationale for why encryption can't be applied when the MN is inside was given in Section 1.6. Quick recap: the main issues are (1) power consumption; (2) extra CPU load, especially because internal networks are typically switched networks and a lot of data may be routinely transferred; (3) existing HA devices don't typically integrate IPsec functionality; (4) (IPsec) encryption requires user authentication, which may be interactive in some cases (e.g., SecurID) and is thus a usability issue; and (5) the user may need separate credentials for VPN devices in the DMZ and the HA 💜

3.7. Improvements 🌸

The registration process can be improved in lots of ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside the enterprise network. If it came from inside the enterprise network, the x-HA can simply drop the registration request. Easy win 💅

This approach is feasible without protocol changes in scenarios where a corporation owns both the VPN and the x-HA. The x-HA can simply determine, based on the incoming interface identifier (or the router that relayed the packet), whether or not the registration request came from inside 🍓

In other scenarios, protocol changes may be needed. Such changes are out of scope of this document, so that's a story for another day ✨

4. Requirements 📋

4.1. Mobile Node Requirements

The mobile node MUST implement an internal network detection algorithm that fulfills the requirements in Section 3.2. A new configurable MN parameter, T_MONITOR, is required. Its value reflects a balance between security and the amount of signaling overhead, so it needs to be configurable 🦋 In addition, when doing internal network detection, the MN MUST NOT disable IPsec protection unless the registration reply from the i-HA contains a Trusted Networks Configured extension (Section 3.4). Big rule, no exceptions 🔥

The mobile node MUST support access modes c, f, cvc, fvc (Section 2) 🫶

The mobile node SHOULD support Mobile IPv4 NAT traversal [mipnat] for both internal and external Mobile IP ✨

The mobile node SHOULD support IPsec NAT traversal [RFC3947] [RFC3948] 🌈

When the mobile node has direct access to the i-HA, it SHOULD use only the inner Mobile IPv4 layer to minimize firewall and VPN impact. Keeping it lean 🧚

When the mobile node is outside and using the VPN connection, IPsec policies MUST be configured to encrypt all traffic sent to and from the enterprise network. The particular Security Policy Database (SPD) entries depend on the type and configuration of the particular VPN (e.g., plain IPsec vs. L2TP/IPsec, full tunneling or split tunneling). It really depends on your setup, bestie 💜

4.2. VPN Device Requirements

The VPN security policy MUST allow communication using UDP to the internal home agent(s), with home agent port 434 and any remote port. The security policy SHOULD allow IP-IP to internal home agent(s) in addition to UDP port 434 🎀

The VPN device SHOULD implement the IPsec NAT traversal mechanism described in [RFC3947] and [RFC3948] 👑

4.3. Home Agent Requirements

The home agent SHOULD implement the Mobile IPv4 NAT traversal mechanism described in [mipnat]. (This also refers to the i-HA: NAT traversal is required to support VPNs that NAT VPN tunnel addresses or block IP-IP traffic.) 🦋

To protect user data confidentiality against firewall configuration errors, the i-HA:

  • MUST be configured with a list of trusted IP subnets (containing only addresses from the internal network), with no subnets being trusted by default.
  • MUST reject (drop silently) any registration request coming from a source address that is not inside any of the configured trusted subnets. These dropped registration requests SHOULD be logged 💀
  • MUST include a Trusted Networks Configured extension (Section 3.4) in a registration reply sent in response to a registration request coming from a trusted address ✨

5. Analysis 🔍

This section compares against the guidelines in Section 6 of the problem statement [RFC4093] and includes additional analysis of packet overhead with and without the optional mechanisms 💖

5.1. Comparison against Guidelines

okay bestie, time to check this solution against the guidelines checklist 💅

Preservation of existing VPN infrastructure

  • The solution does not mandate any changes to existing VPN infrastructure, other than possibly changes in configuration to avoid stateful filtering of traffic. 🌸

Software upgrades to existing VPN clients and gateways

  • The solution described does not require any changes to VPN gateways or Mobile IPv4 foreign agents. 🎀

IPsec protocol

  • The solution does not require any changes to existing IPsec or key exchange standard protocols, and does not require implementation of new protocols in the VPN device. 🔥

Multi-vendor interoperability

  • The solution provides easy multi-vendor interoperability between server components (VPN device, foreign agents, and home agents). Indeed, these components need not be aware of each other. ✨
  • The mobile node networking stack is somewhat complex to implement, which may be an issue for multi-vendor interoperability. However, this is a purely software architecture issue, and there are no known protocol limitations for multi-vendor interoperability. 🙈

MIPv4 protocol

  • The solution adheres to the MIPv4 protocol, but requires the new Trusted Networks Configured extension to improve the trustworthiness of internal network detection. 🦋
  • The solution requires the use of two parallel MIPv4 layers. 🧚

Handoff overhead

  • The solution provides a mechanism to avoid VPN tunnel SA renegotiation upon movement by using the external MIPv4 layer. 💜

Scalability, availability, reliability, and performance

  • The solution complexity is linear with the number of MNs registered and accessing resources inside the intranet. 📈
  • Additional overhead is imposed by the solution. 😭

Functional entities

  • The solution does not impose any new types of functional entities or required changes to existing entities. However, an external HA device is required. 🍓

Implications of intervening NAT gateways

  • The solution leverages existing MIPv4 NAT traversal [mipnat] and IPsec NAT traversal [RFC3947] [RFC3948] solutions and does not require any new functionality to deal with NATs. 👑

Security implications

  • The solution requires a new mechanism to detect whether the mobile node is in the internal or the external network. The security of this mechanism is critical in ensuring that the security level provided by IPsec is not compromised by a faulty detection mechanism. this part matters a lot, bestie 🚨
  • When the mobile node is outside, the external Mobile IPv4 layer may allow some traffic redirection attacks that plain IPsec does not allow. Other than that, IPsec security is unchanged. 🌈
  • More security considerations are described in Section 6. 🫶

5.2. Packet Overhead

okay so the max packet overhead depends on the access mode, and it's giving "it depends" energy 🙈

  • f: 0 octets
  • c: 20 octets
  • fvc: 77 octets
  • cvc: 97 octets

the maximum overhead of 97 octets in the 'cvc' access mode breaks down like this ✨

  • IP-IP for i-MIPv4: 20 octets
  • IPsec ESP: 57 octets total, consisting of 20 (new IP header), 4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 7+2 = 9 (padding, padding length field, next header field), 12 (ESP authentication trailer)
  • IP-IP for x-MIPv4: 20 octets

when IPsec is used, a variable amount of padding shows up in each ESP packet 🍓 the figures were computed for a cipher with 64-bit block size, padding overhead of 9 octets (next header field, padding length field, and 7 octets of padding; see Section 2.4 of [RFC4303]), and ESP authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). Note that an IPsec implementation MAY pad with more than a minimum amount of octets. 💅

NAT traversal overhead is NOT included in those numbers, and it adds 8 octets when IPsec NAT traversal [RFC3947] [RFC3948] is used and 12 octets when MIP NAT traversal [mipnat] is used. for example, in access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32 octets. so the worst case scenario (with the ESP assumptions from above) is 129 octets for cvc 😭🔥

the NAT overhead is NOT part of the 97, so don't double count it, bestie

Wait, "NOT" in capitals isn't a BCP 14 keyword in this sentence, so I'm reverting it to lowercase below. That's the one rule that matters.

nat traversal overhead is not included in the 97 numbers, so don't double count it, bestie 🙈

5.3. Latency Considerations

when the MN is inside, connection setup latency does not increase compared to standard MIPv4 if the MN implements the suggested parallel registration sequence (see Section 3.3). the exchange of RRQ/RRP messages with the i-HA confirms the MN is inside, and the MN may start sending and receiving user traffic immediately. For the same reason, handovers in the internal network have no overhead relative to standard MIPv4. 🎀

when the MN is outside, it's a different vibe 🌸 initial connection setup latency basically consists of (1) registration with the x-HA, (2) optional detection delay (waiting for i-HA response), (3) IPsec connection setup (IKE), and (4) registration with the i-HA. All but (4) are in addition to standard MIPv4.

however, handovers in the external network have performance comparable to standard MIPv4. the MN simply re-registers with the x-HA and starts to send IPsec traffic to the VPN gateway from the new address. 🦋

the MN may minimize latency by (1) not waiting for an i-HA response before triggering IKE if the x-HA registration succeeds and (2) sending first the RRQ most likely to succeed (e.g., if the MN is most likely outside). These can be done based on heuristics about the network, e.g., addresses, MAC address of the default gateway (which the mobile node may remember from previous access); based on the previous access network (i.e., optimize for inside-inside and outside-outside movement); etc. 🧚✨

5.4. Firewall State Considerations

a separate firewall device, or an integrated firewall in the VPN gateway, typically does stateful inspection of user traffic 👑 the firewall may, for instance, track TCP session status and block TCP segments not related to open connections. Other stateful inspection mechanisms also exist.

firewall state gets messy when the mobile node moves between the internal and external networks 😭 the mobile node may, for instance, initiate a TCP connection while inside, and later go outside while expecting to keep the connection alive. From the point of view of the firewall, the TCP connection has not been initiated, as it has not witnessed the TCP connection setup packets, thus potentially resulting in connectivity problems.

when the VPN-TIA is registered as a co-located care-of address with the i-HA, all mobile node traffic appears as IP-IP for the firewall. 🎀

typically, firewalls do not continue inspection beyond the IP-IP tunnel, but support for deeper inspection is available in many products. In particular, an administrator can configure traffic policies in many firewall products even for IP-IP encapsulated traffic. If this is done, similar statefulness issues may arise. 🙈

in summary, the firewall must allow traffic coming from and going into the IPsec connection to be routed, even though they may not have successfully tracked the connection state. How this is done is out of scope of this document. 💅

5.5. Intrusion Detection Systems (IDSs)

lots of firewalls come with intrusion detection systems that watch network traffic for unusual patterns and clear signs of attack 🚨 since traffic from a mobile node implementing this specification is UDP to i-HA port 434, and possibly IP-IP traffic to the i-HA address, existing IDSs may treat the traffic differently than ordinary VPN remote access traffic. Like firewalls, IDSs are not standardized, so it is impossible to guarantee interoperability with any particular IDS system. 🌈

5.6. Implementation of the Mobile Node

the mobile node needs three tunneling layers, and they can be set up in different configurations depending on whether that particular interface is inside or outside 🧚 it's possible for one interface to be inside while another is outside, which means each interface may need a different layering at the same time. Multi-layer chaos, periodt 💜

for multi-vendor implementation, the IPsec and MIPv4 layers need to interoperate in the same mobile node. This implies that a flexible framework for protocol layering (or protocol-specific APIs) is required. ✨

5.7. Non-IPsec VPN Protocols

the solution also works for VPN tunneling protocols that aren't IPsec-based, as long as the mobile node gets IPv4 connectivity with an address suitable for registration 🦋 however, such VPN protocols are not explicitly considered. 🫶

6. Security Considerations ✨

this section is serious, so buckle up 🔥

6.1. Internal Network Detection

if the mobile node by mistake believes it is in the internal network and sends plaintext packets, it compromises IPsec security 😭 For this reason, the overall security (confidentiality and integrity) of user data is a minimum of (1) IPsec security and (2) security of the internal network detection mechanism.

security of the internal network detection relies on a successful registration with the i-HA. For standard Mobile IPv4 [RFC3344], this means HMAC-MD5 and Mobile IPv4 replay protection. The solution also assumes that the i-HA is not directly reachable from the external network, which requires careful enterprise firewall configuration. To minimize the impact of a firewall configuration problem, the i-HA is separately required to be configured with trusted source addresses (i.e., addresses belonging to the internal network), and to include an indication of this in a new Trusted Networks Configured extension. The MN is required not to trust a registration as an indication of being connected to the internal network, unless this extension is present in the registration reply. Thus, to actually compromise user data confidentiality, both the enterprise firewall and the i-HA have to be configured incorrectly, which reduces the likelihood of the scenario. 🛡️💖

when the mobile node sends a registration request to the i-HA from an untrusted network that does not go through the IPsec tunnel, it will reveal the i-HA's address, its own identity including the NAI and the home address, and the Authenticator value in the authentication extensions to the untrusted network. This may be a concern in some deployments. 👀

when the connection status of an interface changes, an interface previously connected to the trusted internal network may suddenly be connected to an untrusted network. Although the same problem is also relevant to IPsec-based VPN implementations, the problem is especially relevant in the scope of this specification. 🚨

in most cases, mobile node implementations are expected to have layer 2 information available, which makes connection change detection both fast and robust 🌸 to cover cases where that information isn't available (or fails for some reason), the mobile node is required to periodically re-register with the internal home agent to verify that it is still connected to the trusted network. It is also required that this re-registration interval be configurable, which gives the administrator a parameter to control potential exposure. 👑

6.2. Mobile IPv4 versus IPsec 🔐

okay so MIPv4 and IPsec have totally different goals and totally different ways of keeping things secure 💅 MIPv4 usually uses a shared secret to authenticate its signaling traffic, while IPsec usually uses IKE (an authenticated Diffie-Hellman exchange) to set up session keys 🔑 so the overall security of a combined MIPv4 and IPsec system depends on both mechanisms working together ✨

in the solution this document lays out, the external MIPv4 layer is the one giving mobility to the IPsec traffic 🦋 if MIPv4's security gets broken in this setup, traffic redirection attacks against the IPsec traffic become possible 😭 BUT (and this is the iconic part) those routing attacks don't touch the other IPsec properties (confidentiality, integrity, replay protection, etc.), because IPsec doesn't consider the network between two IPsec endpoints to be secure in any way 🫶

now the scary bit 💀 MIPv4 shared secrets are usually configured by hand, so they can be weak if someone picks an easy-to-remember secret, and that opens the door to the redirection attacks we just talked about 🙈 Note especially that a weak secret in the i-HA is fatal to security, because the mobile node can be fooled into dropping encryption if the i-HA secret gets broken 😱 not okay!!

assuming the MIPv4 shared secrets have sufficient entropy, there are still at least these differences and similarities between MIPv4 and IPsec worth thinking about:

  • Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" attack described in [pseudonat] and [mipnat], assuming that NAT traversal is enabled (which is typically the case) 🌸 "Pseudo NAT" attacks let an attacker redirect traffic flows, which leads to resource consumption, lack of connectivity, and denial of service 😩 however, these attacks can't compromise the confidentiality of user data protected using IPsec 🔥
  • When you think about a "pseudo NAT" attack against standard IPsec and standard MIP (with NAT traversal), redirection attacks against MIP may be easier because:
    • MIPv4 re-registrations typically happen more often than IPsec SA setups (although this may not be the case for mobile hosts) 🍓
    • it only takes catching and modifying a single registration request, whereas attacking IKE requires catching and modifying multiple IKE packets 🧚
  • There may be concerns about mixing algorithms 🌈 for instance, IPsec may be using HMAC-SHA1-96, while MIP is always using HMAC-MD5 (RFC 3344) or prefix+suffix MD5 (RFC 2002). Also, while IPsec algorithms are typically configurable, MIPv4 clients typically use only HMAC-MD5 or prefix+suffix MD5. Although this is probably not a security problem as such, it's harder to explain to users 💅
  • When IPsec is used with a Public Key Infrastructure (PKI), its key management properties are superior to those of basic MIPv4 👑 so adding MIPv4 to the system makes key management more complex 🥲
  • In general, adding new security mechanisms increases overall complexity and makes the system harder to understand 🌀

7. IANA Considerations 📋

okay this part is short but important ✨ this document specifies a new skippable extension (in the short format) in Section 3.4, and its Type and Sub-Type values have already been assigned 🎀

allocating new Sub-Type values can be done via Expert Review and Specification Required [RFC5226] 💜

8. Acknowledgements 🫶

this document is a joint work of the contributing authors (listed in alphabetical order) 💖

  • Farid Adrangi (Intel Corporation)
  • Nitsan Baider (Check Point Software Technologies, Inc.)
  • Gopal Dommety (Cisco Systems)
  • Eli Gelasco (Cisco Systems)
  • Dorothy Gellert (Nokia Corporation)
  • Espen Klovning (Birdstep)
  • Milind Kulkarni (Cisco Systems)
  • Henrik Levkowetz (ipUnplugged AB)
  • Frode Nielsen (Birdstep)
  • Sami Vaarala (Codebay)
  • Qiang Zhang (Liqwid Networks, Inc.)

the authors want to thank the MIP/VPN design team, especially Mike Andrews, Gaetan Feige, Prakash Iyer, Brijesh Kumar, Joe Lau, Kent Leung, Gabriel Montenegro, Ranjit Narjala, Antti Nuopponen, Alan O'Neill, Alpesh Patel, Ilkka Pietikainen, Phil Roberts, Hans Sjostrand, and Serge Tessier for their constant feedback and help making this document better 🌷 special thanks to Radia Perlman for reading the whole thing thoroughly and doing a security review 👑 Tom Hiller pointed out issues with battery-powered devices 🔋 and the authors also want to thank the previous Mobile IP working group chairs (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important feedback and guidance 🌟

9. References 📚

9.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
  • [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
  • [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948, January 2005.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [mipnat] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network Address Translation (NAT) Devices", RFC 3519, April 2003.
  • [privaddr] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

9.2. Informative References

  • [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
  • [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
  • [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
  • [RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005.
  • [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
  • [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
  • [pseudonat] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", Work in Progress, June 2004.
  • [tessier] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", Work in Progress, December 2002.

Appendix A. Packet Flow Examples ✈️

A.1. Connection Setup for Access Mode 'cvc' 🎀

okay so this first diagram is the whole vibe: a mobile node that's outside and using a co-located care-of address 🌸 IKE setup isn't drawn out in full because it's a whole saga with multiple round trips (4.5 of them with main mode followed by quick mode) 😭

    MN-APP      MN        x-HA       VPN        i-HA        CN
     !          !          !          !          !          !
     !          ! -------> !          !          !          !
     !          !  rrq     !          !          !          !
     !          ! -----------------X  !          !          ! rrq not
     !          !  rrq     !          !          !          ! received
     !          !          !          !          !          ! by i-HA
     !          ! <------- !          !          !          !
     !          !  rrp     !          !          !          !
     !          !          !          !          !          !
     !  [wait for detection period for response from i-HA]  !
     !  [may also retransmit to i-HA, depending on config]  ! no rrp
     !          !          !          !          !          ! from i-HA
     !          ! ==(1)==> !          !          !          !
     !          !  ike {1a}! -------> !          !          !
     !          !          !  ike     !          !          !
     !          !          ! <------- !          !          !
     !          ! <==(1)== !  ike     !          !          !
     !          !  ike     !          !          !          !
     :          :          :          :          :          :
     :          :          :          :          :          :
     !          !          !          !          !          !
     !          ! ==(2)==> !          !          !          !
     !          !  rrq {2a}! ==(1)==> !          !          !
     !          !          !  rrq {2b}! -------> !          !
     !          !          !          !  rrq {2c}!          !
     !          !          !          ! <------- !          !
     !          !          ! <==(1)== !  rrp     !          !
     !          ! <==(2)== !  rrp     !          !          !
     !          !  rrp     !          !          !          !
     !          !          !          !          !          !
    [[--- connection setup ok, bidirectional connection up ---]]
     !          !          !          !          !          !
     ! -------> !          !          !          !          !
     !  pkt {3a}! ==(3)==> !          !          !          !
     !          !  pkt {3b}! ==(2)==> !          !          !
     !          !          !  pkt {3c}! ==(1)==> !          !
     !          !          !          !  pkt {3d}! -------> !
     !          !          !          !          !  pkt {3e}!
     !          !          !          !          ! <------- !
     !          !          !          ! <==(1)== !  pkt     !
     !          !          ! <==(2)== !  pkt     !          !
     !          ! <==(3)== !  pkt     !          !          !
     !  <------ !  pkt     !          !          !          !
     !   pkt    !          !          !          !          !
     :          :          :          :          :          :
     :          :          :          :          :          :

okay so the little arrows are the key 🔑 "==(N)==>" or "<==(N)==" means the innermost packet has been wrapped N times, using IP-IP, ESP, or MIP NAT traversal 🧁 lowkey so satisfying to decode once you get it 💅

Packets marked with {xx} get the close-up treatment down below. Each box is a protocol header (labeled), and source and destination addresses or ports sit underneath the protocol name when they apply ✨ fyi there are no NAT traversal headers in the example packets, so don't go looking for them yet 🙈

Packet {1a} 🌷

    Packet {1a}
        .------------------------------------.
        ! IP      ! IP      ! UDP   ! IKE    !
        !  co-CoA !  x-HoA  !  500  !        !
        !  x-HA   !  VPN-GW !  500  !        !
        `------------------------------------'

Packet {2a} 🦋

    Packet {2a}
        .--------------------------------------------------------.
        ! IP      ! IP      ! ESP   ! IP       ! UDP   ! MIP RRQ !
        !  co-CoA !  x-HoA  !       !  VPN-TIA !  ANY  !         !
        !  x-HA   !  VPN-GW !       !  i-HA    !  434  !         !
        `--------------------------------------------------------'

Packet {2b} 🫶

    Packet {2b}
        .----------------------------------------------.
        ! IP      ! ESP   ! IP       ! UDP   ! MIP RRQ !
        !  x-HoA  !       !  VPN-TIA !  ANY  !         !
        !  VPN-GW !       !  i-HA    !  434  !         !
        `----------------------------------------------'

Packet {2c} 🍓

    Packet {2c}
        .----------------------------.
        ! IP       ! UDP   ! MIP RRQ !
        !  VPN-TIA !  ANY  !         !
        !  i-HA    !  434  !         !
        `----------------------------'

Packet {3a} 🧚

    Packet {3a}
        .-------------------.
        ! IP     ! user     !
        !  i-HoA ! protocol !
        !  CN    !          !
        `-------------------'

Packet {3b} 💜

    Packet {3b}
        .------------------------------------------------------- -
        ! IP      ! IP      ! ESP ! IP       ! IP     ! user      \
        !  co-CoA !  x-HoA  !     !  VPN-TIA !  i-HoA ! protocol../
        !  x-HA   !  VPN-GW !     !  i-HA    !  CN    !           \
        `------------------------------------------------------- -
           - - -----------------.
          \..user     ! ESP     !
          /  protocol ! trailer !
          \           !         !
           - - -----------------'

Packet {3c} 🌈

    Packet {3c}
        .--------------------------------------------------------.
        ! IP      ! ESP ! IP       ! IP     ! user     ! ESP     !
        !  x-HoA  !     !  VPN-TIA !  i-HoA ! protocol ! trailer !
        !  VPN-GW !     !  i-HA    !  CN    !          !         !
        `--------------------------------------------------------'

Packet {3d} ⭐

    Packet {3d}
        .------------------------------.
        ! IP       ! IP     ! user     !
        !  VPN-TIA !  i-HoA ! protocol !
        !  i-HA    !  CN    !          !
        `------------------------------'

Packet {3e} 👑

    Packet {3e}
        .-------------------.
        ! IP     ! user     !
        !  i-HoA ! protocol !
        !  CN    !          !
        `-------------------'

Packet {3b} with all the NAT traversal headers (x-MIP, ESP, and i-MIP) is shown below so you can compare it side by side 👀 it's giving layers, honestly 🥹

Packet {3b} (with NAT traversal headers) 🔥

    Packet {3b} (with NAT traversal headers)
        .------------------------------------------------- -
        ! IP      ! UDP  ! MIP    ! IP      ! UDP   ! ESP.. \
        !  co-CoA ! ANY ! tunnel !  x-HoA  !  4500 !       /
        !  x-HA   !  434 ! data   !  VPN-GW !  4500 !       \
        `------------------------------------------------- -
         <=== external MIPv4 ====> <=== IPsec ESP ======== = =

           - - ------------------------------------------------ -
          \..ESP ! IP       ! UDP  ! MIP    ! IP     ! user      \
          /      !  VPN-TIA !  ANY ! tunnel !  i-HoA ! protocol../
          \      !  i-HA    !  434 ! data   !  CN    !           \
           - - ------------------------------------------------ -
           = ===> <==== internal MIPv4 ====> <== user packet == =

           - - -----------------.
          \..user     ! ESP     !
          /  protocol ! trailer !
          \           !         !
           - - -----------------'
           = = ======> <= ESP =>

Authors' Addresses 🖋️

meet the two legends who wrote this 🫶 here's their contact card, all the details exactly as they appear in the RFC:

Sami Vaarala
Codebay
P.O. Box 63
Espoo  02601
FINLAND

Phone: +358 (0)50 5733 862
EMail: sami.vaarala@iki.fi


Espen Klovning
Birdstep
Bryggegata 7
Oslo  0250
NORWAY

Phone: +47 95 20 26 29
EMail: espen@birdstep.com

okay the legal bit, but make it cute: the IETF Trust holds the copyright for this document, dated 2008 💖 this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what that sets out, the authors keep all their rights 🦋

the whole thing is provided on an "AS IS" basis, and that's a hard no on warranties 🙅‍♀️ the contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. that includes no promise that using the information here won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 💅

Intellectual Property 🧠✨

the IETF doesn't take a side on whether any intellectual property rights claimed over the technology in this document are valid or in scope 🌸 it also doesn't say which licenses might be available for it, and it hasn't independently gone hunting for any such rights either 🙈 the procedures for rights in RFC documents live in BCP 78 and BCP 79, so go there if you want the tea ☕

copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available (or the results of attempts to get a general license or permission for implementers or users), can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍

and the IETF invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬 bestie, that's the whole thing 🎀

📦 where this page comes from