Reverse Tunneling for Mobile IP
obsoleted by
- rfc-3024 — Reverse Tunneling for Mobile IP, revised
Extracted elements (30)
Reverse tunnels are needed because routers increasingly enforce ingress filtering (per RFC 2267), rejecting packets whose source addresses are not topologically correct for the originating network. A mobile node's home address does not match the foreign network prefix, causing such packets to be dropped without a reverse tunnel.
Reverse tunnels are specified as symmetric with the corresponding forward tunnel, using the same encapsulation method and IP address endpoints. This simplifies negotiation and avoids requiring a separate capability exchange for the reverse direction.
The design targets mobile nodes that rely on a foreign agent for forward tunnel support rather than those using co-located care-of addresses; the latter can initiate the tunnel to the home agent directly. Supporting FA-dependent mobile nodes in the presence of filtering routers is the primary motivation.
The protocol requires TTL=255 in Registration Requests as a lightweight mechanism to limit reverse-tunnel hijacking to attackers within one hop, without introducing denial-of-service risks from unauthenticated state. The Mobile IP Working Group rejected stronger unauthenticated mechanisms because they introduced DoS exposure.
The 'T' bit is placed in a formerly reserved bit of the Registration Request. Foreign and home agents that do not support reverse tunneling and receive a request with the 'T' bit set will return a registration denial; mobile nodes may retry with the 'T' bit cleared. Agents not understanding the T bit in agent advertisements simply ignore it per the base Mobile IP specification.
A foreign agent that advertises the 'T' bit in its Mobility Agent Advertisement MUST support both the Direct Delivery Style and the Encapsulating Delivery Style.
If a foreign agent receives an unencapsulated packet from a mobile node that explicitly requested the Encapsulating Delivery Style, the foreign agent MUST NOT reverse-tunnel such a packet and MUST forward it using standard IP routing mechanisms.
If the home agent is unable to support the requested form of encapsulation for the reverse tunnel, it MUST return registration reply code 139 (requested encapsulation unavailable). Similarly, a foreign agent unable to support the requested encapsulation MUST return code 72.
In the Direct Delivery Style, the mobile node MUST designate the foreign agent as its default router. The foreign agent MUST detect packets sent by the mobile node and 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 foreign agent MUST consume (not relay to the home agent and not include in replies to the mobile node) the Encapsulating Delivery Style Extension when present in a Registration Request.
The foreign agent MUST verify that the IP TTL field in a received Registration Request is 255; if not, it MUST reject the registration with code 76 (mobile node too distant) and MUST limit the rate of such replies to a maximum of one per second.
The home agent MUST implement, and by default SHOULD enable, a check that validates reverse-tunneled packets by matching the outer header's source address to a mobility binding care-of address and the inner header's source address to the corresponding mobile node address. If no matching binding is found or if the encapsulation method was not negotiated, the home agent MUST silently discard the packet and SHOULD log it as a security exception.
The Mobile-Home Authentication Extension MUST always be present when two entities sharing a mobility security association exchange registration protocol datagrams.
The mobile node MUST place the Encapsulating Delivery Style Extension after the Mobile-Home Authentication Extension and before the Mobile-Foreign Authentication Extension (if present). The extension MUST NOT be included if the 'T' bit is not set in the Registration Request.
The mobile node MUST set the IP TTL field to 255 in Registration Requests sent to the foreign agent. This limits reverse-tunnel hijacking by preventing malicious nodes more than one hop away from posing as valid mobile nodes.
Upon a successful registration granting a reverse tunnel, the foreign agent MUST update its visitor list to record that the mobile node has been granted a reverse tunnel and the expected delivery style, and MUST process incoming traffic accordingly (encapsulate and tunnel to home agent).
While a reverse-tunnel registration is in effect, the home agent MUST process each valid reverse-tunneled packet by decapsulating it, recovering the original packet, and forwarding it to the correspondent host on behalf of the mobile node.
In the Direct Delivery Style, the encapsulating header added by the foreign agent uses source address copied from the Care-of Address field of the Registration Request, destination address copied from the Home Agent field, and Protocol field 4 (IP in IP) by default.
In the Encapsulating Delivery Style, the mobile node's encapsulating header uses the mobile node's home address as source, the foreign agent's address (from the most recent registration reply's IP source) as destination, and Protocol field 4 (IP in IP) by default.
Selective reverse tunneling allows a mobile node using the Encapsulating Delivery Style to send some packets via the reverse tunnel (encapsulated) and others directly (unencapsulated). The foreign agent MUST NOT reverse-tunnel the unencapsulated packets; it MUST reverse-tunnel the encapsulated ones.
Six new Registration Reply codes are defined: foreign agent codes 74 (reverse tunnel unavailable), 75 (reverse tunnel mandatory, T bit not set), and 76 (mobile node too distant, i.e., TTL ≠ 255); home agent codes 137 (reverse tunnel unavailable), 138 (reverse tunnel mandatory, T bit not set), and 139 (requested encapsulation unavailable).
The Direct Delivery Style has the mobile node send unencapsulated packets addressed to the correspondent host directly to the foreign agent (which is set as default router). The foreign agent intercepts them and encapsulates them into a tunnel from its care-of address to the home agent. This style does not support selective reverse tunneling or broadcast/multicast.
The Encapsulating Delivery Style has the mobile node explicitly encapsulate its outgoing packets in an IP-in-IP outer header addressed to the foreign agent. The foreign agent decapsulates and re-encapsulates them in a new tunnel from its care-of address to the home agent. This style supports broadcast, multicast, and selective reverse tunneling.
Blindly decapsulating reverse-tunneled packets at the home agent and injecting them into the network is a potential security weakness. The home agent MUST validate that the outer source address matches a known care-of address and the inner source matches the corresponding mobile node address before forwarding.
Reverse-tunneled packets (IP-in-IP encapsulated with topologically correct outer headers) are expected to pass ingress filters without special treatment, because ingress filtering targets spoofed source addresses, not encapsulated packets. The outer header's source address (care-of address) is topologically valid.
Reverse tunnels exacerbate tunnel hijacking because injected packets are forwarded beyond the local network upon reaching the home agent. Without authentication extensions (Mobile-Foreign, Foreign-Home), a malicious node can pose as a valid mobile node and redirect a reverse tunnel. The TTL=255 requirement limits this to on-link attackers; full protection requires cryptographic authentication extensions.
The Encapsulating Delivery Style Extension is a two-octet extension with Type=130 and Length=0, carrying no additional data. Its mere presence in a Registration Request signals that the mobile node requests the Encapsulating Delivery Style.
The Mobility Agent Advertisement Extension gains a new 'T' bit in the flags octet to indicate that the foreign agent offers reverse tunneling service. All other fields are unchanged from the base Mobile IP specification.
The Registration Request gains a new 'T' bit (formerly reserved) to request a reverse tunnel from the care-of address to the home agent. The IP TTL field of the enclosing IP header MUST be set to 255.