Mobile Internet basics: IkeV3 and MOBIKE

Mark Grayson, Kevin Shatzkamer and Klaas Wierenga, Cisco

January 16, 2012

Mark Grayson, Kevin Shatzkamer and Klaas Wierenga, CiscoJanuary 16, 2012

In this series of six articles, the authors of “Building the Mobile Internet“ provide a tutorial on extending Internet connectivity into mobile networking by using extensions of protocols such as IPv4 and IPv6 as well as mobile specific protocols such as DSMIP, IKEv2 and MoBIKE. Part 6: IKEv3 and MOBIKE.

The Internet Key Exchange version 2 (IKEv2) Mobility and Multihoming (MOBIKE) protocol was specified in RFC 4555 as a means of providing two main functions:

Mobility: MOBIKE allows a mobile node encrypting traffic through IKEv2 to change point of attachment while maintaining a Virtual Private Network (VPN) session. At a high level, the MOBIKE protocol functions similarly to the Mobile IPv4 protocol.

Multihoming: MOBIKE allows a host that has multiple simultaneous points of attachment to a network to change which interface is forwarding traffic while maintaining a VPN session. Figure 5-45 below illustrates the multihoming scenario.

Click on image to enlarge.

Figure 5-45. Mobike multihoming

MOBIKE provides a secure mobility protocol that allows a remote-access worker to work uninterrupted in the mobile environments such as commuter trains. MOBIKE allows the remote worker to maintain connectivity to the enterprise intranet while changing points of attachment on the Internet, without reestablishing security associations (SAs).

This is an important distinction versus traditional IP Security (IPSec) protocol, which built SAs based on IP address, and therefore suffered from a similar deficiency as standard IP. This is discussed in more detail later in this series.

In recent years, MOBIKE has also been proposed as a mechanism of providing secure connectivity for mobile hosts or routers that are connected to the mobile network over untrusted connections. One example, discussed later in this chapter, is the 3GPP Interworking with Wireless LAN (iWLAN) standards. MOBIKE can also be applied in a service provider environment for enabling femtocells.

Prior to understanding MOBIKE, however, it is important to understand how IKEv2 works and to see the challenges that mobility presents.

IKEv2 Terminology and Processes
Internet Protocol Security (IPsec) provides security services at the IP layer for other TCP/IP protocols and applications to use. IPsec provides a suite of protocols for securing IP communications by authenticating and encrypting each IP packet of a data stream. Several services are offered by IPsec:

1. Encryption of user data for privacy
2. Authentication of the integrity of a message to ensure that it is not changed en route
3. Protection against certain types of security attacks, such as replay attacks
4. The ability for devices to negotiate the security algorithms and keys required to meet their security needs

Initially, endpoints must agree on a set of security protocols to use so that each one sends data in a format the other can understand. They must decide on a specific encryption algorithm to use in encoding data.

They must exchange keys that are used to decrypt data that has been cryptographically encoded. IPsec uses the Internet Key Exchange (IKE) protocol for these functions.

IKE is a protocol for providing mutual authentication and security association establishment for IPsec VPNs. IKE has countless deployments and almost as many RFCs. RFC 2407, 2408, and 2409 all provide base IKE protocol definition, and numerous RFCs exist for supporting Network Address Translation (NAT) traversal, Extensible Authentication Protocol (EAP), remote address acquisition, and so on.

IKEv2, standardized in RFC 4306, centralized all IKE functions into a common RFC and included enhancements to the original IKE protocol for more efficient call setup and lower latency.

IKEv2 provides a mechanism for mutual authentication between two Internet nodes and establishment a Security Association (SA) based on shared secret information and a set of cryptographic algorithms to ensure data confidentiality. Each SA is a logical, simplex connection that provides the secure data connection between devices.

IKEv2 communications are request/response-based message flows known as exchanges. An IKE SA is established with two exchanges (four messages) - the IKE_SA_INIT and IKE_AUTH.


The IKE_SA_INIT exchange is used to negotiate cryptographic algorithms; to exchange pseudorandom numbers, known as nonces, for replay attack prevention; and to establish a symmetric shared key. This process provides the two nodes with enough information to securely transport information required for IKE_AUTH exchange.

The node that sends the initial request message is known as the initiator. The initiator sends the initial request with the following information:

Security Parameter Index (SPI): The SPI is a random number used to reference the specific SA.

SAi1: The SAi1 provides the cryptographic algorithms supported by the initiator.

KEi: The KEi provides a random private value used by the SA peer to generate the shared key for traffic flowing from the initiator to the responder. All messages following the IKE_SA_INIT are encrypted and integrity-protected with this shared key.

Ni: The Ni provides the initiator’s nonce value. This nonce is used as part of replay protection.

The node that responds to the initial request is known as the responder. The responder sends the response with the following information:

Security Parameter Index (SPI): The SPI is a random number used to reference the specific SA.

SAr1: The SAr1 provides the cryptographic algorithm that will be used for all communication. The responder selects this algorithm from the list presented by the initiator.

KEr: The KEr provides a random private value used by the SA peer to generate the shared key for traffic flowing from the responder to the initiator. Because the SA is a simplex connection, this shared key can be different than the one generated for the initiator-to-responder direction.

Nr: The Nr provides the responder’s nonce value. This nonce is used as part of replay protection.

Following this exchange, both the initiator and responder have sufficient information to generate a secret shared key, known as an SKEYSEED. Individual keys are then generated from this shared key to determine a unique encryption key and integrity protection key. These keys are used to ensure that all subsequent communication is confidential

< Previous
Page 1 of 4
Next >

Loading comments...