Mobile Internet basics: IkeV3 and MOBIKE -

Mobile Internet basics: IkeV3 and MOBIKE

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

The IKE_AUTH exchange is used to authenticate messages between the two peers, exchange identity information, exchange certificates, and establish the SA.

When the initiator sends an encrypted message to the responder the IKE_AUTH exchange includes:

SPI: The SPI is a random number used to reference the specific SA.

IDi: The IDi provides the initiator’s identity information.

Certificates: The certificate provides validation of identity. This validation is provided by a third-party, trusted validation server.

IDr: If the responder has multiple identities all hosted by the same IP address, the initiator can send the IDr value to indicate which identity it is attempting to communicate with.

SAi2: The SAi2 value contains SA offers from the initiator to the responder.

TSi: The TSi value contains the traffic selector of the initiator.

TSr: The TSr value contains the traffic selector of the responder.

In this message, the initial payload attributes—namely, the SPI, IDi, Certificates, and IDr—are used to establish identity, while the remaining attributes (SAi2, TSi, and TSr) are used to establish the SA.

When the responder receives this request, it validates the information by verifying signatures, comparing computed MAC values, and validating the names used in the ID payload. The responder then issues a response message with the following information:

SPI: The SPI is a random number used to reference the specific SA.

IDr : The IDr provides the responder’s identity information.

Certificates: The certificate provides validation of identity. This validation is provided by a third-party, trusted validation server.

SAr2: The SAr2 value contains an accepted SA offer.

Clickon image to enlarge.

Figure 5-46. IPSec setup and call flow

TSi: The TSi value contains the traffic selector of the initiator.

TSr: The TSr value contains the traffic selector of the responder.

Upon conclusion of the IKE_AUTH phase, the two nodes communicate over a secure tunnel. This secure IP tunnel provides data confidentiality for the duration of communications. Figure 5-46 above illustrates the IPsec setup and data call flow.

IPsec/IKEv2 Mobility Limitations
The IKE authentication and security association information used to build the IPsec tunnel is bound to the IP addresses of the IPsec endpoints.

The IPsec tunnel is established based on the IP address in the header of the IKEv2 message requesting the IPsec SA. While the tunnel determines both source and destination endpoints, IPsec transport still relies on the hierarchical structure of the Internet for routing, and relies on the IP address to determine both the node identity and the node location.

When a mobile node changes point of attachment and receives a new IP address, IPsec cannot continue normally, and rekeying of the IKE SA must occur.

In some instances, rekeying is effective. However, in the majority of instances, rekeying the process is either too lengthy to ensure session continuity or requires manual intervention (such as a password).

Clickon image to enlarge.

Figure 5-47 IKEv2 HDR Format

IKEv2 Message Formats

The IKEv2 protocol uses UDP for transport. The IKEv2 packet is structured as follows:

IKEv2 header (HDR) : The IKEv2 header includes the initiator’s and responder’s SPI value, version (IKE version 2), exchange type, and a message ID (for resending lost messages). Figure 5-47 above illustrates the IKEv2 HDR format.

Figure 5-48. Generic payload header.
IKEv2 payload: One or more payloads can be included in an IKEv2 packet. Each payload is identified by the next payload field in the preceeding payload. Figure 5-48 above illustrates a generic payload header.

MOBIKE Protocol
The MOBIKE protocol solves the mobility problem inherent in IKEv2 by decoupling the SA from the interface IP address. This allows the end node to move between two IP points of attachment, such as an office Ethernet and Wi-Fi network, and still continue the existing VPN session without rekeying. The MOBIKE protocol provides the following capability extensions to IKEv23:

1. Informs the other peer about all available addresses, known as the peer address set (multihoming)
2. Determines the preferred address from the peer address set and notifies the peer to use the preferred address
3. Ensures path connectivity and detects outages
4. Notifies the other peer of address changes (mobility)
5. Notifies the other peer of changes in the available address set (multihoming)
6. Provides NAT traversal functions

To ensure that mobility is transparent to upper layers, MOBIKE only changes the outside tunnel address of the IKE SA. Figure 5-49 below illustrates a mobile node moving between two points of attachment while maintaining a VPN session.

MOBIKE allows either end of the secure tunnel to have multiple IP addresses, creating M*N possible IP address to IP address combinations. The IKE initiator is responsible for determining which address pair is used for communication. In the case of mobile, especially, the initiator is in a better position to understand interface capabilities and limitations.

Clickon image to enlarge.

Figure 5-49 Maintaining VPN Session with MOBIKE

MOBIKE Call Flows
The MOBIKE call flow is similar to standard IKEv2 call flows. The IKE_INIT exchange is identical to the IKEv2 call flow; however, the IKE_AUTH exchange allows both nodes to notify the other peer that MOBIKE is supported. Either node can also include additional IP addresses with which it is associated.

When the IPsec tunnel is established, the IPsec SA is based on the IP address in the IKE_SA instead of the IP header in the IKEv2 message requesting the IPsec SA. This is a key change versus the IKEv2 protocol, and it provides the separation between the SA identity and the node’s location (IP address).

During data communication, MOBIKE messages notify the peer of a change in IP address. MOBIKE uses the INFORMATIONAL message to communicate the new IP address.

Both the INFORMATIONAL message and all subsequent messages are sent using the new IP address. These subsequent messages are marked with an “update pending” flag until the INFORMATIONAL request is acknowledged. Figure 5-50 below illustrates this MOBIKE call flow.

Clickon image to enlarge.

Figure 5-50 MOBIKE Call Flow

Connectivity Discovery
To ensure connectivity, the MOBIKE protocol relies on the IKEv2 Dead Peer Detection (DPD) mechanism. IKEv2 DPD relies on retransmit timers and windows to determine whether the IKE SA peer is no longer responding to requests.

This allows the peers to determine whether the path has stopped working. MOBIKE also uses the DPD to ensure that the peer is synchronized on which address to communicate with.

While the IKEv2 DPD provides information on the existing SA between peer addresses, it does not provide insight into other available peer addresses. MOBIKE peers can use IKEv2 INFORMATIONAL message exchanges to determine whether another path works. These exchanges can be done after a failure is detected or during normal conditions.

Network Address Translation (NAT) Traversal
NAT traversal is a core function of MOBIKE. MOBIKE uses the NAT traversal functions of IKEv2; however, there are still limitations of the MOBIKE protocol when NAT devices are in the data path.

NAT detection payloads are used in MOBIKE exchanges to determine whether the address in the IP header was modified along the path.

Clickon image to enlarge.

Figure 5-51 MOBIKE NAT Scenario 1

This allows both peers to learn whether there is a NAT device between the initiator and responder, and which side of the NAT device each peer is on. Figures 5-51 above and 5-52 below i llustrate the two sides of a NAT device and the two scenarios that are possible.

Figure 5-51 illustrates a scenario where the mobile node, or the initiator, is located on the inside interface of the NAT device, and the MOBIKE gateway, or the responder, is located on the outside interface of the NAT device.

When a peer changes IP point of attachment, it sends an INFORMATIONAL message to the other peer, notifying it of the address change. With most NAT devices requiring that traffic is always initiated from the inside interface, these messages will get dropped by the NAT device and never reach the initiator. For this reason, MOBIKE does not support the responder changing IP point of attachment in this scenario.

Clickon image to enlarge.

Figure 5-52 MOBIKE NAT Scenario 2

Figure 5-52 above illustrates an alternative scenario where the MOBIKE gateway, or the responder, is located on the inside interface of the NAT device, and the mobile node, or the initiator, is located on the outside interface of the NAT device.

Because scenarios where the mobile node, or initiator, are changing IP point of attachment are more common than cases where the MOBIKE gateway is moving, this scenario is unsupported from a MOBIKE perspective. MOBIKE peers, however, will still attempt to send INFORMATIONAL message to notify of address changes, and depending on the implementation of the NAT device, these messages can reach the SA peer.

Authentication and Accounting
MOBIKE authentication and accounting is based on the Extensible Authentication Protocol (EAP) support inherent in IKEv2. EAP, defined in RFC 5247, provides a universal authentication framework.

Rather than providing a specific authentication method, the EAP framework was designed to support both current and future authentication methods. The three main components of the EAP framework are as follows:

EAP Peer: The EAP Peer is any device that is attempting to access the network. The EAP Peer has a supplicant that allows EAP to run over a specific transport layer protocol. This transport layer protocol can be IPsec, PPP, 802.1X, or various other protocols. In MOBIKE, the initiator, or mobile node, is the EAP peer.

EAP Authenticator: The EAP Authenticator is the access gateway that requires authentication prior to granting access. In MOBIKE, the EAP Authenticator is the responder, or MOBIKE gateway.

Authentication Server: The Authentication Server invokes a particular EAP method for authentication, validates EAP credentials, and grants access to the network. In MOBIKE, the Authentication Server is the AAA server.

Clickon image to enlarge.

Figure 5-53 EAP Message Communication

Logically, EAP authentication and connectivity are between the EAP Peer and Authentication Server. The EAP Authenticator has no specific EAP function other than to proxy EAP messages between these two points.

In fact, the authentication-specific information transported in the EAP messages is encrypted, so the EAP Authenticator has a very limited role in EAP authentication. Figure 5-53 above depicts the end-to-end relationship among the EAP Peer, EAP Authenticator, and Authentication Server.

During MOBIKE setup, the EAP exchange occurs as part of the IKE_AUTH exchanges, and it must be completed prior to establishing the IKE_SA. The MOBIKE gateway removes extensible authentication information from the EAP header and inserts it directly into a AAA Request (RADIUS or Diameter).

Clickon image to enlarge.

Figure 5-54 EAP-IKEv2 Authentication Sequence

The AAA server processes this information and authenticates the initiator. The MOBIKE gateway then responds to the IKE_AUTH exchange with an EAP success message. Figure 5-54 above illustrates this message sequence. After the initiator is authenticated, the IPsec SA can be established and bearer flows begin.

MOBIKE in Practice
MOBIKE is well documented in the IETF, but it has limited deployments in either an enterprise scenario or service provider scenario. Some mobile Standards Development Orgnizations (SDOs), such as 3rd Generation Partnership Project 2 (3GPP2), have chosen to implement Mobile IP (MIPv4 or MIPv6) in lieu of MOBIKE. These implementation decisions are based on a number of reasons, including the following:

1. MOBIKE is more complex to implement than Mobile IP.

2. Because MOBIKE uses encryption, MOBIKE headers are larger than Mobile IP headers.

3. MOBIKE processing is “costly” in terms of power consumption, battery drain, and CPU utilization. Until recently, many mobile devices did not have the capabilities to encrypt/decrypt IKE.

4. MOBIKE encryption has largely proved unnecessary because mobile networks implement airlink encryption and utilize dedicated backhaul circuits.

The following section discusses specific implementations of MOBIKE relative to mobile standards organizations. This section will examine a MOBIKE example from 3rd Generation Partnership Project (3GPP) standards, in which MOBIKE is used for dual-mode voice services over Wi-Fi.

Security Architecture for Non-3GPP Access to EPS
Long Term Evolution (LTE) standards define 3GPP’s fourth-generation (4G) high-speed packet data network. The LTE network involves the evolution of both the radio infrastructure and the mobile packet core to support scalable delivery of multiple megabits per second of service.

The radio infrastructure evolution is known as the evolved UMTS Terrestrial Radio Access Network (eUTRAN), and the packet core evolution is known as the Evolved Packet Core (EPC). The total system evolution is known as the Evolved Packet System (EPS).

To facilitate access to the network and provide an offload mechanism for the eUTRAN, EPS also supports access to the network through non-3GPP radio networks, such as Wi-Fi networks.

These networks are untrusted and therefore require that the mobile node’s bearer traffic be delivered in a secure fashion. The security architecture for this non-3GPP access to EPS is documented in 3GPP TS 33.402. Figure 5-55 below i llustrates this security architecture.

Clickon image to enlarge.

Figure 5-55. 3GPP Untrusted Access Architecture

The architecture defines an enhanced Packet Data Gateway (ePDG) that resides between the untrusted access network and the EPC. This ePDG provides confidentiality of the mobile node identity and encryption of data flows when the mobile node is sending traffic from within the untrusted network. These functions are provided through IKEv2, with MOBIKE signaling used for mobility purposes.

Authentication of the mobile node is done through the EAP extensions to IKEv2 using Extensible Authentication Protocol–Authentication and Key Agreement (EAP-AKA).

EAP-AKA, defined in RFC 4187, was developed as a secure authentication mechanism through Universal Subscriber Identity Module (USIM) for 3GPP devices connected to an IP network, such as Wi-Fi. EAP-AKA provides the same mutual-authentication capabilities as standard SIM authentication. Figure 5-56 below depicts the EAP-AKA authentication mechanism with the AAA server.

Clickon image to enlarge.

Figure 5-56. EAP-AKA

During mobile node authentication, the International Mobile Subscriber Identity (IMSI) is carried in the IDi payload, and the mobile Access Point Name (APN) is carried in the IDr payload.

The ePDG initiates an AAA request and inserts the EAP message so that the AAA server can provide authentication and authorization services for the mobile node. Figure 5-57 below illustrates the authentication flow.

When the mobile node changes point of attachment between two non-3GPP access networks, INFORMATIONAL exchanges through MOBIKE are used to notify the ePDG of the new address.

Clickon image to enlarge.

Figure 5-57. Mobile Node Authentication in a Non-3GPP Network

Mobile standards organizations have historically solved macro-mobility and inter-access mobility through these Layer 3 mechanisms. All these solutions are common in their approach to disassociate the IP address of the mobile node from the identity of the mobile node, and instead use the IP address only as a locator.

With capabilities to deliver network layer mobility solutions over IPv4 transport networks, IPv6 transport networks, and across domains, these technologies provide solutions for today, tomorrow, and the transition between.

To read Part 1 , go to Transport layer mobility challenges
To read Part 2 , go to Mobile IPv4 registration and AAA
To read Part 3, go to Mobile IPv4 tunners,bindings and diagrams”
To read Part 4 , go to Mobile IPv6 Technology Overview
To read Part 5, go to Mobile IPv6 in Practice

1. RFC 3588, “The Diameter Base Protocol.”
2. Understanding IKEv2: Tutorial and Rationale for Decisions,” draft-ietf-ipsec-ikev2-tutorial-01.txt.
3. RFC 4621, “Design of the MOBIKE Protocol.”

This series of articles is from the book “Building the Mobile Internet”, by Mark Grayson, KevinShatzkamer and Klass Wierenga.Copyright 2011, used by permission of PearsonEducation, Inc.. Written permission from Pearson Education, Inc. is required forall other uses.

Mark Grayson is a distinguished consulting engineer atCisco Systems with responsibility for leading Cisco’smobile architecture strategy. With 20 years experience in the wireless industry,he holds first class honors in electronics and communications engineering fromthe University of Birmingham (England) as well as a PhD, in radio engineering.

Kevin Shatzkamer is a distinguished system architect atCisco Systems with responsibility for long term strategy and architecturalevolution of mobile wireless networks. He holds a Bachelor of engineering degreefrom the University of Floriga and a MBA from Indiana University.

Klaas Wierenga is a senior consulting engineer in theoffice of the CTO at Cisco. His 15 plus years of experience include planning,analysis and design of systems in the fields of mobility, security and identify.He holds a Master’s degree in consumer science from the University of Groningen,The Netherlands.

This article provided courtesy of Copyright © 2012UBM–All rights reserved.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.