Mobile Internet basics: Mobile IPv4 Registration and AAA - Embedded.com

Mobile Internet basics: Mobile IPv4 Registration and AAA

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 2: Mobile IPv4 registration and AAA.

As discussed in Part 1, after Agent Discovery has been completed, the mobile node has successfully determined whether it is connected to its home network or a foreign network.

While mobile nodes might use regular IP when in the home network, and Mobile IPv4 when in a foreign network, mobile standards organizations, such as 3GPP2, treat all networks as foreign networks and therefore require Mobile IPv4 to be used at all times. RFC 3344 defines three registration events for the mobile node: Registration , Deregistration , and Reregistration .

Mobile IPv4 Registration
A mobile node initiates a Registration Request (RRQ) when either the outcome of its Agent Discovery process concludes that it is connected to a foreign network or a link layer mechanism results in network layer establishment.

This RRQ allows the mobile node to request service from a foreign agent (optional), inform the home agent of its current CoA (registration), renew a registration that is about to expire (reregistration), or deregister.

RRQ messages originate from a mobile node and are destined for a mobility agent. The mobility agent might be a foreign agent or a home agent, depending on both the mobile node’s preference for CCoA and the foreign agent’s preference for registration.

Table 5-1 below includes the different scenarios that determine whether the mobile node registers through a foreign agent relay or directly with a home agent.

Table 5-1 Policy Enforcement Interaction Descriptions

When registering directly with the home agent, RRQs and RRPs are exchanged directly between the mobile node and home agent. When registering with the foreign agent, all RRQs originated by the mobile node are sent to the foreign agent, which acts as a relay to the home agent.

The home agent replies with a Registration Reply (RRP) message. The foreign agent also acts as a relay for the RRP toward the mobile node. Figure 5-10  below illustrates the foreign agent’s role in the Mobile IPv4 registration process.


Click on image to enlarge.

Figure 5-10 Mobile IPv4 Registration Process

The registration process also has several other optional capabilities:

Option #1: Allowing the mobile node to discover its home address
Option #2: Maintaining multiple registrations simultaneously for tunneling multiple copies of the same IP packet to each registered CoA
Option #3: Deregistering specific CoAs
Option #4: Discovering the home agent address dynamically

Dynamic Home Agent Assignment
Some link layer establishment protocols require that the end node include a topologically significant IP address at establishment/registration. As noted earlier in this chapter, PPP IPCP, for example, requires that the registering node be assigned a unique IP address prior to identifying a foreign agent CoA.

This ultimately creates a scalability issue for mobile nodes, because the intent of the foreign agent CoA is to allow multiple mobile nodes to share a single CoA.

RFC 2290 , “Mobile IPv4 Configuration Option for PPP IPCP ,” is one of many standards defined to extend link layer mechanisms for support of Mobile IPv4 endpoints. The inclusion of these options using the IPCP IP Address Configuration Option allows the mobile node to determine what IP address to use as the CoA when registering with the home agent.

RFC 2794, “Mobile IP Network Access Identifier (NAI) Extension for IPv4,” extended the flexibility of RFC 2290 by allowing a mobile node to be identified by an NAI.

In addition to allowing mobile nodes to be authenticated through standard AAA methods (discussed later in this series), this RFC also extended the Mobile IPv4 RRQ process.

This extension allows the NAI to be used to determine the mobile node’s home address. A mobility agent includes this message in the RRP. The extension also enables the RRQ to include a “zero” (0.0.0.0) or “all” (255.255.255.255) address for the home agent. This value allows the mobility agent—either directly or through AAA interaction—to dynamically allocate the mobile node’s home agent address. This process is known as dynamic home agent assignment.

Figure 5-11. RRQ message format

RRQ and RRP Messages
RRQ and RRP messages in Mobile IPv4 use the User Datagram Protocol (UDP) as the transmission protocol. UDP relies on a simple transmission model that does not involve session establishment, guarantee reliability, or ensure data integrity. UDP, therefore, provides an unreliable transport mechanism for the Mobile IPv4 registration process.

The Mobile IPv4 protocol itself provides reliability with the inclusion of retransmission capabilities, validity checksums, and session identification. Figure 5-11 above illustrates the format of an RRQ message.

Figure 5-12 RRP Message Format

A mobility agent uses the RRP message in response to a RRQ. The RRP is sourced from the mobility agent and destined to the mobile node. The RRP message notifies the mobile node whether the registration request was accepted and for what length of time. Figure 5-12 above illustrates the format of an RRP message.

Authentication Extensions
For security purposes, Mobile IPv4 messages rely on shared authentication values, known as message authentication codes, for authenticating messages sent from the mobile node to a mobility agent, and between mobility agents.

These authentication values, derived through Hash-based Message Authentication Code (HMAC) with Message Digest algorithm 5 (HMAC-MD5), are used to protect the UDP payload, including all extensions.

HMAC-MD5 uses an iterative cryptographic hash function along with the key defined in the security context to create the message authentication code.

Security contexts are established between nodes in the Mobile IP network. Each security context contains a shared key or public/private key pair, an authentication algorithm, and a style of replay protection.

All security contexts between two nodes are collectively known as a Mobility Security Association. Each security context within the Mobility Security Association is indexed using a Security Parameter Index (SPI) value. When receiving a message that requires authentication, the mobility node uses the SPI value to determine which security context is to be used, and therefore which key is applicable, for the derivation and verification of the authentication value.

Mobile IPv4 includes the authenticator in RRPs and RRQs as extensions. There are three types of authentication extensions:

MN-HA authenticator: The MN-HA authenticator is used to authorize and validate messages between the mobile node and home agent. This authentication extension is mandatory in all RRQs and all RRPs generated by the home agent. The mobile node and the home agent are required to maintain a security association.

MN-FA authenticator: The MN-FA authenticator is used to authorize and validate messages between the mobile node and foreign agent. This authentication extension is optional in all RRQs and RRPs, because the mobile node and foreign agent are not required to maintain a security association.

FA-HA authenticator: The FA-HA authenticator is used to authorize and validate messages between the foreign agent and home agent. This authentication extension is optional in all RRQs and RRPs, because the foreign agent and home agent are not required to maintain a security association.

Mobile IPv4 AAA Interactions
AAA services have historically been used on the Internet to provide a mechanism by which a network can verify and validate a node attempting to access network services, as well as a means to account for the consumption of those services.

AAA relies on credentials communicated by the connecting node to the network access gateway, which can be authenticated prior to allowing access to the network. These credentials can include some form of identification (subscriber or node), other unique data, or digital signature.

AAA servers are typically used to interact with the network access gateway by providing credential verification services. The RADIUS protocol, defined in RFC 2865 , and the Diameter Base protocol, defined in RFC 3588 , are the two most prevalent methods of providing these authentication services.

With the growth of Mobile IPv4 as a mechanism to provide network services, RFC 2977 , “Mobile IP Authentication, Authorization, and Accounting, ” was developed to provide AAA functions to mobile nodes requesting Mobile IPv4 services.

(Note: RFC 2977, “Mobile IP Authentication, Authorization, and Accounting,” is applicable to both Mobile IPv4 and Mobile IPv6 protocols. )

In the Mobile IPv4 AAA architecture, the mobility gateways are the network access gateways contacting either a foreign or home AAA server to validate the credentials provided by the mobile node. The AAA server core functions include the following:

Enabling authentication for Mobile IP registration
Authorizing the mobile node
Initiating accounting

The AAA server can also be responsible for obtaining an IP address for the mobile node. Figure 5-13 below illustrates the generic Mobile IPv4 AAA architecture.


Click on image to enlarge.


Figure 5-13. Mobile IPv4 AAA architecture

As discussed earlier, RFC 2794 provides a mechanism by which a mobility agent can interact with the AAA server and validate a mobile node using the unique NAI value. This allows a mobile node to be authenticated to the network, authorized for connection, and assigned an IP address through AAA interaction.

Mobile IPv4 Challenge/Response Extension
RFC 4721 , “Mobile IPv4 Challenge/Response Extensions ,” provides an additional optimization for AAA interaction by creating the Mobile-AAA Authentication extension for both Mobile IPv4 RRQ messages.

The AAA Authentication extension includes information relevant for the mobility node to create a request to the AAA server for authentication. These extensions also allow the foreign agent to use a challenge/response mechanism in the Agent Advertisement message to verify the mobile node.

Challenge/response authentication methods are common in remote-access networks. These methods allow one node in the authentication process to present a challenge to the other node. The other node must provide the expected response to the challenger to be authenticated. The challenge/response mechanism can take on two forms:

One-way authentication: With this form of authentication, one node is authenticating itself to the other. In effect, the network element (server, network access gateway, and so on) ensures that the client is a trusted entity.

Mutual authentication: With this form of authentication, each node is required to authenticate itself to the other node, in a “handshake” model. In effect, the network element and the client ensure that the other is a trusted entity.

Mutual authentication ensures that the both the client and network element are trusted entities, which protects against rogue network elements responding to client traffic.

Mobile IPv4 relies on one-way authentication in which the mobile node replays the challenge presented by the mobility agent. The mobility agent is responsible for rotating challenges to ensure limited lifetime.

The foreign agent can send a challenge to the mobile node in Agent Advertisement messages. The mobile node includes the response in an MN-FA challenge extension of the RRQ. This challenge is used to ensure that the mobile node is not replaying an earlier RRQ. This provides local assurance that a legitimate mobile node is attempting to connect to the network, instead of a node that has intercepted an earlier RRQ.

Mobile IPv4 AAA Key Distribution
The AAA server can optionally play a critical role in the Mobile IPv4 registration authorization process. The AAA server can maintain a key distribution function for the Mobile IPv4 nodes, including the following:

1) Identification and creation of a security association between the mobile node and home agent so that the mobile node can create the MN-HA authenticator

2) Identification and creation of a security association between the mobile node and foreign agent so that the mobile node can create the MN-FA authenticator

3) Identification and creation of a security association between the foreign agent and home agent so that the home agent can create the FA-HA authenticator

RADIUS Interactions
The RADIUS protocol, defined in RFC 2865, has already been introduced in Chapter 3 and is the most widely deployed AAA technology to date. This protocol has been deployed in dialup, cable, DSL, and wireless networks.

As the most prevalent AAA technology, Mobile IPv4 mobility agents are capable of communicating with AAA servers using the RADIUS protocol through a standardized set of Mobile IPv4 RADIUS attributes. Figure 5-14 below illustrates how a mobility agent provides RADIUS AAA support for Mobile IPv4 RRQs.


Click on image to enlarge.

Figure 5-14 Mobile IPv4 and RADIUS

RFC 5030 provides guidelines for Mobile IPv4 RADIUS attributes. The RADIUS protocol supports Vendor-Specific Attributes (VSA), which permit vendors to use the RADIUS protocol to communicate information between the network access gateway and the RADIUS server that is not addressed through any standard.

While VSAs accelerated Mobile IP RADIUS interaction by allowing vendors to create their own RADIUS attributes, these solutions were not interoperable.

RFC 2865 defines standard attributes communicated between a network access gateway and a RADIUS server, but there is no standardized set of RADIUS attributes for communication between a mobility agent and the RADIUS server within the technology-agnostic Internet Engineering Task Force (IETF).

However, many mobility standards organizations, such as 3GPP2, have adopted their own RADIUS vendor ID (5535). This provides a technology-specific standard for implementing RADIUS communication.

Diameter Applications
The Diameter protocol, defined in RFC 3588, provides another AAA framework, and was designed to be a more robust protocol than RADIUS. Diameter provides the following functions, above and beyond the RADIUS protocol:

Transmission-level security: The RADIUS protocol provides only application layer authentication and validation, while Diameter provides transport security with optional IPsec encryption.

Failover capability: Diameter supports application layer acknowledgments and failover algorithms.

Reliable transport: By relying on TCP or Stream Control Transport Protocol (SCTP) as the transport protocol, as opposed to UDP, Diameter leverages the transport layer reliability mechanisms.

As discussed earlier, UDP does not provide an assured delivery of packets. TCP and SCTP, by contrast, provide sequencing, retransmissions, and flow control algorithms design to guarantee delivery of packets.

Capability negotiation: RADIUS peers do not have knowledge as to the other’s capabilities. This capability allows Diameter peers to determine a mutually acceptable service.

Peer discovery and configuration: RADIUS configuration requires manual assignment of servers and clients. Diameter peers can dynamically discover peers through Domain Name System (DNS).

In addition to these Diameter capabilities, RFC 4004 defines a Mobile IPv4 application that allows a Diameter server to provide AAA functions for Mobile IPv4 services.

During Mobile IPv4 registration, the Diameter server provides the derivation and transport of mobility security associations, namely, the MN-HA, MN-FA, and FA-HA keys. The Diameter server is also an integral component in interrealm mobility, including providing authentication and accounting for a mobile node.

Figure 5-15 Mobile IPv4 and Diameter
Figure 5-15 above illustrates how a mobility agent provides Diameter AAA support for Mobile IP RRQs.

Next in Part 3 : Mobile IPv4 Tunnels, Bindings, and Datagram Forwarding
To read Part 1 , go to “Transport layer problems .”

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 Embedded.com and EmbeddedSystems Design Magazine. Sign up for subscriptionsand newsletters. Copyright © 2011 UBM–All rights reserved.

Leave a Reply

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