Reverse Tunneling for Mobile IP, revised
obsoletes
- rfc-2344 — Reverse Tunneling for Mobile IP
Extracted elements (28)
Reverse tunnels are primarily needed because routers enforcing ingress filtering per RFC 2267 require topologically correct source addresses. The mobile node's home address does not match the network prefix of the foreign network, so without a reverse tunnel its packets are dropped by such routers.
Reverse tunnels are symmetric with the forward tunnel (same encapsulation method and IP address endpoints), using IP-in-IP by default. This avoids additional negotiation complexity and allows both tunnels to share the same registered encapsulation options.
The Mobile IP Working Group considered unauthenticated-state mechanisms to further reduce reverse-tunnel hijacking but rejected them because they would introduce denial-of-service vulnerabilities. The consensus was that only weak (non-cryptographic) protection was achievable, making the trade-off unacceptable.
For disparate address space deployments, the foreign agent demultiplexes forward-tunneled packets using a three-tuple: the mobile node's home address (inner destination), the home agent's address (outer source), and the care-of address (outer destination). This disambiguates mobile nodes with conflicting private addresses.
In the Limited Private Address Scenario (LPAS), mobile nodes using private (RFC 1918) addresses MUST set the 'T' bit and use reverse tunneling; foreign agent care-of addresses and home agent addresses used in registrations MUST be publicly routable. Foreign agents supporting reverse tunneling MUST support this private address scenario.
Mobile nodes that do not understand the 'T' bit in Mobility Agent Advertisements simply ignore it, per the base Mobile IP specification, ensuring backward compatibility with existing mobile nodes.
If a foreign agent receives an un-encapsulated packet from a mobile node that explicitly requested Encapsulating Delivery Style, the foreign agent MUST NOT reverse-tunnel such a packet and MUST instead forward it using standard IP routing.
If the home agent is unable to support the requested form of encapsulation for a reverse tunnel, it MUST return code 139 ('requested encapsulation unavailable'). If it cannot support a reverse tunnel with the same configuration as the forward tunnel, it MUST return code 137.
If two entities share a mobility security association, they MUST use the appropriate Authentication Extension when exchanging registration protocol datagrams. An admissible authentication extension (e.g., Mobile-Home Authentication Extension) MUST always be present to authenticate registration messages between a mobile node and its home agent.
In Direct Delivery Style, the mobile node MUST designate the foreign agent as its default router; the foreign agent MUST detect packets from the mobile node and modify its forwarding function to encapsulate them before forwarding.
Mobile nodes wishing to send broadcast or multicast packets via a foreign agent care-of address MUST use the Encapsulating Delivery Style. The Encapsulating Delivery Style Extension MUST NOT be included if the 'T' bit is not set in the Registration Request.
The foreign agent MUST consume the Encapsulating Delivery Style Extension — it must not relay it to the home agent or include it in replies to the mobile node. If it does not support the requested delivery style, it MUST respond with code 79.
The foreign agent MUST verify that the TTL field of the IP header in a Registration Request is set to 255; if not, it MUST reject the registration with code 76 ('mobile node too distant'). The foreign agent MUST limit the rate of these denial replies to a maximum of one per second.
The home agent MUST implement and by default SHOULD enable a check on reverse-tunneled packets: it searches for a mobility binding whose care-of address matches the outer IP source and whose mobile node address matches the inner IP source. Packets failing this check MUST be silently discarded and SHOULD be logged as security exceptions.
The mobile node MUST set the TTL field of the IP header to 255 in Registration Requests sent to the foreign agent. This limits the reverse-tunnel hijacking attack by preventing malicious nodes more than one hop away from posing as valid mobile nodes.
Upon receipt of a valid Registration Reply, the foreign agent MUST update its visitor list to record that the mobile node has been granted a reverse tunnel and the delivery style expected, then MUST process incoming traffic accordingly and tunnel it from the care-of address to the home agent.
Upon successful registration, the home agent MUST update its mobility bindings list to indicate that the mobile node has been granted a reverse tunnel and the type of encapsulation expected.
While a registration is in effect, the home agent MUST process each valid reverse-tunneled packet by decapsulating it, recovering the original packet, and forwarding it on behalf of the mobile node to the correspondent host's destination address.
Selective reverse tunneling allows a mobile node with a co-located care-of address to selectively reverse-tunnel packets or not. A mobile node using a foreign agent care-of address may implement selective tunneling by requesting Encapsulating Delivery Style: un-encapsulated packets are forwarded normally; encapsulated packets are reverse-tunneled.
The Encapsulating Delivery Style Extension (Type 130, Length 0) MAY be included by the mobile node in Registration Requests to request encapsulating delivery. It MUST appear after the Mobile-Home Authentication Extension and before the Mobile-Foreign Authentication Extension.
The 'T' bit is added to the Mobility Agent Advertisement Extension to indicate that the agent offers reverse tunneling service. A foreign agent setting 'T' MUST support Direct Delivery Style and SHOULD support Encapsulating Delivery Style.
The 'T' bit is added to the Registration Request packet. When set, the mobile node asks its home agent to accept a reverse tunnel from the care-of address; if using a foreign agent care-of address, the FA is asked to reverse-tunnel packets.
IANA assigned Type 130 for the Encapsulating Delivery Style Extension, codes 74-76 and 79 for foreign agent rejection of reverse tunnel requests, and codes 137-139 for home agent rejection. Code 79 ('delivery style not supported') was newly assigned for this revised document.
For disparate address space support, the foreign agent uses link-layer information to select the correct reverse tunnel for a mobile node. Because unauthenticated link-layers (e.g., shared Ethernet) allow a malicious mobile node to misuse another's tunnel, the link-layer MUST securely authenticate traffic; unauthenticated technologies are not recommended for disparate address support.
Ingress filtering targeting reverse-tunneled (IP-in-IP encapsulated) packets is not warranted: topologically correct reverse tunnels carry a valid source address in the encapsulating header, which is exactly the property ingress filtering seeks to enforce.
Once a reverse tunnel is established, a malicious node could hijack it to inject packets forwarded beyond the local network. Unauthenticated exchanges allow a malicious node to redirect an existing tunnel to another home agent. The best protection is the Mobile-Foreign and Foreign-Home Authentication Extensions; absent those, the TTL=255 requirement limits attackers to one hop.
In Direct Delivery Style, the foreign agent forwards an IP-in-IP packet with the encapsulating header Source Address copied from the Care-of Address field of the Registration Request, Destination Address copied from the Home Agent field of the most recent successful Registration Reply, and Protocol field 4 (IP in IP).
In Encapsulating Delivery Style, the mobile node sends packets with an outer header src=MN home address, dst=foreign agent address, protocol=4 (IP in IP). The foreign agent then re-encapsulates with outer src=FA care-of address, dst=HA address, protocol=4.