IKEv2 Mobility and Multi-homing Protocol
Feature Description
- Overview
- Supported Platforms
How IKEv2 Mobility and Multi-homing Protocol Works
Configuring IKEv2 Mobility and Multi-homing Protocol
- Enabling IKEv2 Mobility and Multi-homing Protocol
Monitoring and Troubleshooting IKEv2 Mobility and Multi-homing Protocol
- IKEv2 Mobility and Multi-homing Protocol Show Command(s) and/or Outputs
- IKEv2 Mobility and Multi-homing Protocol Bulk Statistics

IKEv2 Mobility and Multi-homing Protocol

This chapter provides information on the IKEv2 Mobility and Multi-homing Protocol feature.

The following topics are discussed:

Feature Description

Overview

IPSec can support IKEv2 Mobility and Multi-homing protocol (MOBIKE) as defined in RFC 4555. IKEv2 Mobility and Multi-homing Protocol (MOBIKE) allows the IP addresses associated with IKEv2 and tunnel mode IPSec Security Associations (SA) to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multi-homed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. This enables peer hosts to change its point of network attachment and use different interfaces without removing the existing IPSec tunnel.

The MOBIKE feature is suited when the address of at least one peer is stable, and can be discovered using mechanisms such as DNS. While both parties can be mobile, one party must be rooted at any given time. Additionally, the Gateway is neither multi-homed nor possess mobility capabilities.

Supported Platforms

Currently, IPSec supports the MOBIKE feature on Cisco ASR 5500 and Ultra Services platforms.

How IKEv2 Mobility and Multi-homing Protocol Works

Signaling

MOBIKE is initiated when the feature is enabled, and the Gateway receives an IKE_AUTH containing the SA payload with MOBIKE_SUPPORTED from the peer. The Gateway responds with an IKE_AUTH containing the SA payload with MOBIKE_SUPPORTED.

The feature can be enabled using the ikesa mobike command under the Crypto Template Configuration Mode. For more information on the ikesa mobike command, refer Enabling IKEv2 Mobility and Multi-homing Protocol.

Return Routability Check

A return routability check ensures that the other party can receive packets at the claimed address. When the Gateway receives an UPDATE_SA_ADDRESS, IKE SA/IPSec SA is updated and return routability check is triggered. This function can be enabled using the ikesa mobike cookie-challenge command under the Crypto Template Configuration Mode. By default, the Gateway does not perform the return routability check. When enabled, the Gateway sends a cookie challenge to the peer. The session is deleted when a response is not received, or when an invalid response is received. It is assumed that when a valid response is received for any informational exchange, the peer can receive packets at the claimed address.

For more information on the ikesa mobike cookie-challenge command, refer Enabling IKEv2 Mobility and Multi-homing Protocol.

To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request can include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request copies the notification as-is to the response. When processing the response, the original sender verifies that the value is the same as sent. If the values do not match, the IKE_SA is closed.

Limitations and Restrictions

This section identifies limitations and restrictions for the MOBIKE feature:

Mobility is supported for peers only. The Gateway has a fixed interface/IP and does not move across the network.
IPSec supports MOBIKE for Subscriber mode only.
When a change of address occurs, the peers must always notify the change to the Gateway.
As the Gateway has a single IP address, an ADDITION_*_ADDRESS message will not be sent to the peers.
The Gateway does not store the ADDITION_*_ADDRESS information. Any payload with the information from the peer is ignored.
Retransmission/Dead Peer Detection (DPD) timeout must be configured with a larger value when the MOBIKE feature is enabled.

Standards Compliance

This feature complies with the following standard(s):

RFC 4555 - IKEv2 Mobility and Multi-homing Protocol (MOBIKE)

Configuring IKEv2 Mobility and Multi-homing Protocol

Enabling IKEv2 Mobility and Multi-homing Protocol

Use the following configuration under the Crypto Template Configuration Mode to enable the MOBIKE feature:

config 
    context context_name 
        crypto template template_name ikev2-dynamic 
            ikev2-ikesa mobike [ cookie-challenge ] 
            end

Use the default ikev2-ikesa mobike command to restore the configuration to its default setting. By default, mobike is disabled.
If previously configured, use the no ikev2-kesa mobike command to remove the configuration.
Use the cookie-challenge keyword to enable the return routability check. The Gateway performs a return routability check when MOBIKE is enabled along with this keyword. This configuration is disabled by default.

Monitoring and Troubleshooting IKEv2 Mobility and Multi-homing Protocol