IKEv2 Mobility and Multihoming Protocol (MOBIKE)
Extracted elements (32)
For simplicity, MOBIKE assumes that if NATs are present the initiator is the party behind the NAT. The case where the responder's addresses change through a NAT is not fully supported. This choice avoids handling all asymmetric NAT scenarios while still covering the dominant remote-access VPN use case.
The initiator (client in a remote-access VPN) is solely responsible for deciding which address pair is used for IPsec SAs, and the responder only updates SAs upon explicit UPDATE_SA_ADDRESSES from the initiator. This mirrors normal IKEv2 behavior and is appropriate because the mobile node is in the best position to know which of its interfaces should be used.
Tunnel header addresses for a new IPsec SA are taken from the IKE_SA (initialized from the first IKE_AUTH request's IP header), not from the IP header of the CREATE_CHILD_SA message. This is intentional because IKEv2 requires switching from port 500 to 4500 upon NAT detection, and keying off IKE_AUTH simplifies consistency.
MOBIKE does not provide a rendezvous mechanism for simultaneous movement of both parties or initial address discovery. At least one endpoint must have a relatively stable address discoverable via DNS or local configuration.
MOBIKE supports only tunnel-mode IPsec SAs; transport-mode SAs and SCTP-based scenarios are explicitly out of scope. Load balancing (using multiple address pairs simultaneously) is also not supported; only one pair of addresses is active for a given SA at any time.
By default, the return routability check SHOULD be performed, and SHOULD be done before updating the IPsec SAs. In environments where the peer is well-behaved or the address can be verified by other means, the check MAY be omitted.
If a retransmitted address-update request is sent using several different source addresses, a new INFORMATIONAL request MUST be sent (rather than relying on the retransmission).
If an INFORMATIONAL request includes a COOKIE2 notification, the recipient MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value matches; if the values do not match, the IKE_SA MUST be closed.
If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange responder MUST NOT use the contents of the NO_NATS_ALLOWED notification for any other purpose than possibly logging for troubleshooting.
Implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them. This avoids needing to change ports later if a NAT is detected on some other path.
Implementations that wish to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in the message containing the SA payload).
The data associated with the COOKIE2 notification MUST be between 8 and 64 octets in length (inclusive) and MUST be chosen by the exchange initiator in a way that is unpredictable to the exchange responder.
The host not behind a NAT MUST NOT use dynamic IKEv2 address/port updates for IKEv2 packets, but MAY use them for ESP packets. This ensures an INFORMATIONAL exchange not containing UPDATE_SA_ADDRESSES does not cause unintended address changes.
The MOBIKE_SUPPORTED notification data field MUST be left empty (zero-length) when sending, and its contents (if any) MUST be ignored when received. This allows the field to be used by future versions of the protocol.
The responder SHOULD use relatively long timeout intervals when retransmitting IKEv2 requests or deciding whether to initiate Dead Peer Detection; it is suggested that responders continue retransmitting for at least five minutes before giving up.
Unreliable lower-layer information (e.g., spoofable ICMP messages) SHOULD be treated only as a hint that there might be a problem; the initiator SHOULD trigger Dead Peer Detection to determine if the current path is still usable before changing addresses.
When NAT Traversal is not enabled, all messages that can update addresses associated with the IKE_SA and/or IPsec SAs MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of NO_NATS_ALLOWED match the addresses in the IP header; if they do not match, an UNEXPECTED_NAT_DETECTED notification is sent in response.
ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications reveal all interface addresses of a peer, potentially disclosing network topology (e.g., corporate LAN address to a cellular peer), operator affiliation, or fine-grained physical location. Although these payloads are encrypted, any address later used for IKEv2/IPsec traffic becomes visible in the clear.
ADDITIONAL_IP4_ADDRESS (16397) and ADDITIONAL_IP6_ADDRESS (16398): Sent by either peer in IKE_AUTH or INFORMATIONAL exchanges to advertise additional interface addresses. Each occurrence carries one address; multiple notifications may appear. The complete new list replaces the old one.
COOKIE2 (Notify type 16401): Optionally included in any INFORMATIONAL request to perform a return routability check. The responder must copy the value verbatim into its response; the initiator verifies the echo. Data is 8–64 unpredictable octets.
MOBIKE_SUPPORTED (Notify type 16396): Included in IKE_AUTH by both peers to signal MOBIKE support. Protocol ID and SPI Size are zero; notification data is zero-length.
NO_ADDITIONAL_ADDRESSES (Notify type 16399): Indicates the exchange initiator has no addresses beyond the one used in the IP header of the current exchange. No data field.
NO_NATS_ALLOWED (Notify type 16402): Carries the sender's claimed source and destination IP addresses and ports so the responder can detect address modification by NATs or translators. Included in address-updating messages when NAT Traversal is not active.
UNACCEPTABLE_ADDRESSES (error type 40): Sent by the responder when the address pair in an UPDATE_SA_ADDRESSES request is rejected by local policy; no data. UNEXPECTED_NAT_DETECTED (error type 41): Sent when NO_NATS_ALLOWED content does not match the IP header, indicating address modification in transit; no data.
UPDATE_SA_ADDRESSES (Notify type 16400): Sent by the initiator in an INFORMATIONAL request to instruct the responder to update the tunnel header addresses of the IKE_SA and associated IPsec SAs to the addresses in the IP header of the request. No data field.
RFC 4555 allocates values in the IKEv2 Notify Message Types namespace: error types UNACCEPTABLE_ADDRESSES (40) and UNEXPECTED_NAT_DETECTED (41); status types MOBIKE_SUPPORTED (16396), ADDITIONAL_IP4_ADDRESS (16397), ADDITIONAL_IP6_ADDRESS (16398), NO_ADDITIONAL_ADDRESSES (16399), UPDATE_SA_ADDRESSES (16400), COOKIE2 (16401), and NO_NATS_ALLOWED (16402).
MOBIKE address-update payloads are encrypted, integrity-protected, and replay-protected by the IKE_SA; however, outer IP header addresses are not covered by IKEv2 integrity protection, so an on-path attacker acting as a NAT can redirect IPsec SA tunnel headers. The resulting attack is limited mainly to denial of service because payload traffic is still protected by IPsec.
MOBIKE introduces return routability checks (via COOKIE2 in INFORMATIONAL exchanges) to limit 'third-party bombing' attacks in which an adversary redirects a high-volume IPsec flow toward a victim. Only a party that holds the IKE_SA keys and has seen the request can form a valid COOKIE2 response.
Security policies for MOBIKE-enabled peers must account for the fact that a single IPsec SA may be used over paths of varying security properties as addresses change. Traffic-selector authorization in the PAD must be bound to the authenticated IKE identity, not to the current IP address, to prevent unauthorized SA creation when addresses are updated.
ADDITIONAL_IP4_ADDRESS notification data is a 4-octet IPv4 address; ADDITIONAL_IP6_ADDRESS notification data is a 16-octet IPv6 address. Protocol ID and SPI Size fields are zero.
NO_NATS_ALLOWED for IPv4: 12-octet payload containing Source IPv4 address (4 octets), Destination IPv4 address (4 octets), Source port (2 octets), Destination port (2 octets). Protocol ID and SPI Size are zero.
NO_NATS_ALLOWED for IPv6: 36-octet payload containing Source IPv6 address (16 octets), Destination IPv6 address (16 octets), Source port (2 octets), Destination port (2 octets). Protocol ID and SPI Size are zero.