Mobile IPv4 Traversal across IPsec-Based VPN Gateways
Extracted elements (30)
IPsec lacks built-in mobility because a Security Association is identified by the triplet (destination address, security protocol, SPI). When the mobile peer changes care-of address, the SA destination becomes stale and the stationary peer continues sending to the old address; IKE re-negotiation is required, imposing too heavy computation and latency for useful mobility.
The firewall MUST be configured to block external access to the i-HA because a successful plaintext registration with the i-HA is used as proof of being inside the trusted network. If the i-HA were reachable from outside, an attacker could trick the mobile node into dropping IPsec protection. As a second layer, the i-HA itself checks source addresses and signals trusted-network awareness via the TNC extension, so both firewall AND i-HA must be misconfigured to expose user data.
The solution uses two parallel Mobile IPv4 layers: an outer (x-MIP) layer to provide mobility beneath IPsec so the VPN tunnel endpoint never changes, and an inner (i-MIP) layer to register the VPN-TIA with the internal home agent. This avoids requiring any changes to existing VPN devices or foreign agents.
Traffic is not encrypted when the mobile node is inside the enterprise network because: (1) IPsec consumes power and CPU on devices that handle large internal traffic volumes; (2) interactive authentication (e.g., SecurID) imposes usability friction; (3) existing home agents do not typically incorporate IPsec; and (4) users would need separate credentials for both VPN devices and home agents.
The solution is compatible with different IPsec-based VPN types (plain IPsec tunnel mode, L2TP/IPsec); L2TP/IPsec VPNs in particular do not restrict source addresses to VPN-TIA and thus support triangular routing for the inner MIPv4 layer, unlike plain IPsec VPNs.
When the MN uses the parallel detection algorithm via a foreign agent, it sends two registration requests through the same FA with the same MAC address; while not protocol-violating, some FA implementations may not handle this correctly. Testing indicates a majority of deployed FAs handle the case, but full interoperability cannot be guaranteed.
A mobile node MUST implement an internal network detection mechanism fulfilling the requirements of Section 3.2, ensuring that the MN does not send plaintext traffic over an untrusted network.
In access modes 'cvc' and 'fvc', the T-bit (reverse tunneling) SHOULD be set in the inner MIPv4 Registration Request to the i-HA, because IPsec selectors typically restrict the source address inside the tunnel to the VPN-TIA; without reverse tunneling the MN's home address would violate the IPsec security policy, silently blackholing traffic.
Mobile IPv4 NAT traversal SHOULD be supported for both x-MIP and i-MIP layers; IPsec NAT traversal (RFC 3947, RFC 3948) SHOULD be supported for the VPN layer. NAT traversal for the inner MIPv4 layer may be necessary even without an explicit NAT if the VPN implementation NATes tunnel inner addresses.
The enterprise firewall MUST be configured to block traffic originating from external networks destined for the i-HA, so that a successful RRQ/RRP exchange without IPsec cannot be achieved unless the MN is on the trusted internal network.
The i-HA MUST be configured with a list of trusted IP subnets (internal-network addresses only, with no subnets trusted by default), MUST silently drop any registration request from a source outside those subnets (and SHOULD log such drops), and MUST include the TNC extension in any reply to a request from a trusted address.
The MN MUST NOT disable IPsec protection unless the registration reply from the i-HA contains a Trusted Networks Configured extension; this prevents a misconfigured firewall alone from causing plaintext exposure.
The MN MUST NOT infer that an interface is connected to the internal network unless: (1) a successful registration has been completed through that interface to the i-HA, (2) the registration reply contained a TNC extension, and (3) the connection status of the interface has not changed since that registration.
The MN MUST NOT send or receive a user data packet if more than T_MONITOR seconds have elapsed since the last successful re-registration with the i-HA; any such packets MUST be dropped or queued, and queues MUST NOT be processed until re-registration succeeds without a connection status change.
The MN MUST NOT skip the VPN (IPsec) layer for security reasons when in access modes 'cvc' or 'fvc', even though the MN could in principle use triangular routing to bypass the inner MIPv4 layer.
The MN MUST support all four access modes: c, f, cvc, and fvc (Section 2). A new configurable T_MONITOR parameter is required.
The mobile node implementation MUST track each network interface separately; a successful registration with the i-HA through interface X implies nothing about the internal-network status of interface Y.
The T_MONITOR parameter MUST be configurable and MUST default to 60 seconds, representing a trade-off between traffic overhead and the maximum window of potential plaintext exposure.
The VPN security policy MUST allow UDP communication to internal home agent(s) on port 434 (any remote port), and SHOULD also allow IP-IP to internal home agent addresses, to permit MIPv4 registration traffic through the IPsec tunnel.
The x-HA and i-HA addresses MUST be different; if the MN detects they are the same it MUST assume it is on the external network and bypass network detection, because a shared address would confuse foreign agents processing the parallel registration requests.
When outside and using the VPN connection, IPsec policies MUST be configured to encrypt all traffic sent to and from the enterprise network; specific SPD entries depend on VPN type (plain IPsec vs. L2TP/IPsec, full vs. split tunneling).
When the MN detects a connection status change on an interface it MUST immediately stop relaying user data packets, re-detect whether the interface is internal or external, and resume data traffic only after detection and any required registrations/VPN establishment are complete.
Four access modes define the protocol layering: 'c' (i-MIP with co-located CoA, inside only), 'f' (i-MIP with FA-CoA, inside only), 'cvc' (x-MIP co-CoA + VPN + i-MIP co-CoA using VPN-TIA, outside), 'fvc' (x-MIP FA-CoA + VPN + i-MIP co-CoA using VPN-TIA, outside). The notation encodes x-MIP mode, VPN presence, and i-MIP mode.
The Trusted Networks Configured (TNC) extension is a new skippable short-format MIPv4 extension included by an i-HA in a Registration Reply when the registration request source address belongs to a configured trusted subnet. Its presence is the mandatory signal that allows the MN to conclude it is connected to the internal network and safely stop using IPsec.
This document allocates a new skippable short-format Mobile IPv4 extension with Type=149 (Trusted Networks Configured extension). New Sub-Type values under Type 149 may be allocated via Expert Review and Specification Required per RFC 5226.
Because MIPv4 shared secrets are often configured manually and may be weak, an attacker who breaks the i-HA shared secret can fool the MN into dropping IPsec encryption entirely, which is fatal to security. Additionally, when NAT traversal is enabled both MIPv4 and IPsec are susceptible to 'transient pseudo-NAT' traffic-redirection attacks; MIPv4 re-registrations are typically more frequent and require modifying only a single packet, making MIPv4 a softer target for redirection than IKE.
The confidentiality of user data equals the minimum of IPsec security and the security of the internal network detection mechanism. If the MN incorrectly determines it is inside and sends plaintext over an untrusted network, IPsec security is fully bypassed. The detection relies on HMAC-MD5-authenticated MIPv4 registration, firewall blocking of i-HA from the outside, and the i-HA's trusted-source-address check with TNC extension; all three must fail simultaneously for user data to be exposed.
When probing for the internal network, the MN sends a plaintext RRQ to the i-HA from an untrusted network (outside the IPsec tunnel), revealing the i-HA's address, the MN's NAI and home address, and the MIPv4 Authenticator value to the untrusted network; this information exposure may be a concern in some deployments.
Upon a point-of-attachment change the MN issues simultaneous RRQs to both i-HA and x-HA. States: (1) Probing — retransmit to both; (2) Tentatively Outside — x-HA reply received, continue probing i-HA for a detection period; (3) Inside — i-HA reply with TNC extension received, de-register from x-HA, start T_MONITOR re-registration; (4) Outside — detection period expired without i-HA reply, proceed with IKE/VPN setup. Failure of re-registration while inside triggers return to Probing state and halts plaintext traffic.
The TNC extension uses the RFC 3344 short extension format: Type (1 octet) = 149, Length (1 octet) = 2, Sub-Type (1 octet) = 0, Reserved (1 octet) set to zero on send and ignored on receipt. Total extension size is 4 octets.