Mobile IP Traversal of Network Address Translation (NAT) Devices
Extracted elements (29)
The mechanism reuses the home agent's well-known UDP port 434 for both MIP signalling and tunnelled data traffic. This means that if a MIP registration can reach the HA, tunnelled data will almost certainly also pass through any firewalls or NATs on the path.
The MIP Tunnel Data Message header (Type field) is introduced to disambiguate tunnelled data packets from MIP Registration Requests/Replies when both arrive on the same UDP port 434; without this header, a receiver cannot distinguish data from control messages.
Two-way keepalives (ICMP Echo Request/Reply) are required rather than one-way because: (1) they allow the MN to detect loss of a NAT mapping and trigger re-registration, and (2) acknowledged keepalives reduce overall keepalive traffic since retransmissions only occur on no-response, whereas unacknowledged one-way keepalives must be sent more frequently to survive occasional loss.
Private address aliasing may cause a mobile node to fail to detect movement when two private networks use identical addressing (e.g., both 10.0.0.1/8). Implementations SHOULD monitor link-layer gateway addresses (e.g., via ARP) as a movement-detection heuristic, since IP addresses alone are insufficient across NATs.
When the Encapsulation field in the UDP Tunnel Request Extension is non-zero, a specific encapsulation format is requested; the HA MUST either accept with that format or reject with ERROR_HA_UDP_ENCAP_UNAVAIL (code 142). When zero, the encapsulation defaults to the 'M' and 'G' bits of the Registration Request.
Before decapsulation, the decapsulating node MUST verify that the outer IP addresses and UDP port numbers exactly match the values used for the tunnel, except for 'half bound' tunnels (Section 4.11) where the source UDP port may differ.
Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP tunnelling, even if not all traffic will be reverse tunnelled, to ensure that a HA not prepared for reverse tunnelling will reject the registration before it becomes unusable.
If a mobile node includes a UDP Tunnel Request extension but receives a Registration Reply without a UDP Tunnel Reply extension, the mobile node MUST NOT use UDP tunnelling; the HA is assumed not to understand the extension.
If fragmentation is needed, it MUST be done prior to MIP UDP encapsulation. This differs from IP-in-IP tunnelling and is required because NAPT devices cannot associate non-first fragments (lacking port numbers) to the correct session.
If the HA assents to UDP tunnelling, it MUST use the source address of the registration request as the effective care-of address (the NAT's public address) rather than the care-of address given in the Registration Request body, except when the 'R' flag is set.
Mobile IP Registration Requests and Registration Replies SHALL NOT be tunnelled even when MIP IP-in-UDP tunnelling is in force; they are already UDP datagrams and must travel as ordinary MIP signalling.
The HA MUST NOT attempt to detect or compensate for NAT binding loss by dynamically changing the keepalive interval in Registration Replies; the mobile node is better positioned to determine actual NAT mapping loss.
The keepalive message sent MUST consist of a properly UDP-encapsulated ICMP Echo Request directed to the home agent. The non-HA endpoint MUST send a keepalive if no other packet has been sent to the HA in K seconds (default K=110 seconds).
The receiver of a tunnelled packet MUST check that the Next Header value in the MIP Tunnel Data Message matches the tunnelling mode established for the mobility binding; if a discrepancy is detected, the packet MUST be dropped.
The remote UDP tunnel endpoint MUST use two-way keepalives (ICMP Echo Request/Reply). The mobile node MUST NOT use a keepalive interval less than 10 seconds, even when compensating for NAT mapping loss.
When sending MIP UDP tunnelled data, the mobile node MUST use the same UDP source port as was used for the most recent registration request, to preserve the NAT mapping.
When the mobile node requests MIP UDP tunnelling, the 'D' bit (Decapsulation by the mobile node) MUST be set in the Registration Request; otherwise UDP tunnelling would not be meaningful.
The MIP Tunnel Data Message (Type 4) is a 4-octet header prepended inside the UDP payload to differentiate tunnelled data from MIP signalling messages. It contains a Next Header field (using IP Protocol field values, e.g., 4=IP-in-IP, 47=GRE, 55=Minimal) and a Reserved field.
The Mobility Agent Advertisement Extension is extended with a 'U' (UDP Tunnelling support) flag to indicate that a foreign agent supports MIP UDP Tunnelling as defined in this document. This flag SHOULD be set when the FA is behind a NAT, and MUST NOT be set when the FA is not behind a NAT.
The UDP Tunnel Reply Extension (Type 44, Length 6) is a non-skippable extension returned in Registration Replies to indicate whether the HA accepts MIP UDP tunnelling. It contains a Reply Code (0–63 = assent, 64–255 = decline), an F (Forced) flag, and a Keepalive Interval field specifying the NAT keepalive interval the MN should use.
The UDP Tunnel Request Extension (Type 144, Length 6) is a skippable extension added to Mobile IP Registration Requests to signal that the sender supports MIP UDP tunnelling. It contains F (Force) and R (Registration through FA Required) flags, an Encapsulation field using IP Protocol field numbering, and Reserved fields.
IANA registered four new values for Mobile IP: UDP Tunnel Request Extension type 144 (with sub-type 0); UDP Tunnel Reply Extension type 44 (with sub-type 0); MIP Tunnel Data Message type 4; and error code 142 (ERROR_HA_UDP_ENCAP_UNAVAIL) in the 'Error Codes from the Home Agent' sub-range. New sub-type numbering spaces for both extensions require Expert Review and a specification.
An attacker who can observe a Registration Request/Reply exchange during the 'half bound' state can send a bogus keepalive to redirect the tunnel to an arbitrary UDP port at the same IP address. The HA MUST NOT accept a keepalive from a different source IP than the registration request. Using short re-registration intervals and having the MN send the first keepalive immediately limits exposure.
It is RECOMMENDED to use a conservative (short) mobility binding lifetime when using NAT traversal (suggested maximum 60 seconds) to limit the duration of any redirection attack. IPsec is recommended for protecting user data confidentiality on insecure intermediate networks, but does not prevent the redirection attacks inherent to this mechanism.
The NAT traversal mechanism requires the HA to trust the unauthenticated IP source address from received packets as the effective care-of address, since the NAT rewrites the address protected by the MN-HA authentication extension. This enables traffic-redirection attacks where an on-path attacker modifies registration IP/UDP headers to redirect mobility bindings to an arbitrary address.
When a mobile node registers a co-located address through an FA (the 'R' flag case), the tunnel enters a 'half bound' state after the Registration Reply. The HA waits for the first keepalive from the MN to determine the correct NAT port; only after receiving the keepalive does the HA transition to sending forward-tunnelled traffic.
MIP IP-in-UDP encapsulation adds an outer IP header, UDP header, and MIP Tunnel Data Message header before the original (inner) IP header. The outer IP and UDP endpoints identify the tunnel; the inner IP header is not changed except for TTL decrement when forwarding.
UDP Tunnel Reply Extension: Type=44, Length=6; fields are Sub-Type (1 octet), Reply Code (1 octet), F|Reserved bits (2 octets), Keepalive Interval (2 octets, in seconds).
UDP Tunnel Request Extension is 8 octets (excluding Type and Length): Sub-Type (1 octet), Reserved1 (1 octet), F|R|Reserved2 bits (1 octet), Encapsulation (1 octet), Reserved3 (2 octets). Type=144, Length=6.