Campus Mobility Model
Campus mobility refers to mobility within a single administrative domain, whether it is an entire university campus, a hospital, or a couple of conference rooms in a hotel. The main assumption in this model is that communication is within the campus (intranet), and no roaming exists across global Internet connectivity.
A good example of a campus intranet is a corporate campus. Consider a corporate facility of many units/departments, as shown in Figure 5-1. Assume that every unit/department has its own Local Area Network (LAN) segment (either Ethernet or 802.11, or both) and that the various segments are connected through a gateway router to a high-speed backbone, allowing the different departments to communicate with one another, albeit with proper security credentials. Note that this allows communication as long as the different
Figure 5-1. Typical Corporate Campus
Deploying Mobile IP in this environment allows the network to become "campus mobile" capable, because Mobile IP client hosts can now roam around the campus and still maintain connectivity. This can be accomplished by various configurations, including simply installing Mobility Agent functionality on the gateway routers and installing Mobile IP client software on the portable hosts, for example, laptops, as shown in Figure 5-2.
Figure 5-2. Mobile Corporate Campus with Users Roaming Inside the Network Only
The first step toward simplifying Mobile IP deployments in the campus mobility environment is
Storing Security Associations in AAA
A AAA server is a separate centralized database that can store and maintain security associations. It is
Figure 5-3. Integration of a AAA Server into a Mobile IP Network
Another advantage of using a AAA server is that it allows maintenance and administrative functions to be streamlined, facilitating ease of support. With a AAA server, Home Agent configurations do not need to be
When a AAA server is introduced into the network, it must be configured to share a trust relationship with the Mobility Agents that it supports. The trust relationship between mobility entities and AAA servers is not part of Mobile IP, but rather is configured according to the AAA implementation.
When a AAA server is introduced into the Mobile IP architecture, both entities (the Mobility Agent and AAA server) need to be configured for proper integration. Throughout this section, we introduce the IOS configuration commands that are needed on the Mobility Agent to leverage the AAA architecture.
The first step is to configure the Mobility Agent to retrieve the security association from the AAA server using a specific AAA protocol, such as one of the following:
This is accomplished using the following global IOS configuration commands on the Mobility Agent:
aaa new-model aaa authorization ipmobile
Because the AAA server stores Mobile Node-Home Agent security associations, it needs a way to identify the specific security association needed by the Home Agent. As advanced as Cisco products are, they cannot read mindsat least not yet! Thus, the Mobile IP user must be uniquely identified on the AAA server. To this end, the Mobile Node is identified on the AAA server, either by a statically assigned home IP address or other username (for example, Mobile Node Network Access Identifier [NAI] without the realm portion). The realm portion of the NAI can route the AAA request to the appropriate server. Configuration of this routing is specific to the AAA infrastructure and, as such, is beyond the scope of this book.
In general, AAA servers are designed to provide
responses to authentication
It is important to understand the difference between Mobile IP authentication and AAA authentication. Processing of the Mobile Node-Home Agent Authentication Extension always occurs on the Home Agent and requires the key to be on the Home Agent. Because RADIUS authentication can only return a pass/fail answer to the network access server (NAS), the Mobile Node-Home Agent security association must be stored on the AAA server as an authorization attribute. However, RADIUS requires a positive authentication before it can return authorization attributes to the NAS. In a sense, AAA authentication must be passed before Mobile IP credentials can be retrieved. Most RADIUS servers can be configured so that if no AAA password is configured for the user, the server assumes positive AAA authentication. Alternatively, each Mobile IP authentication request is sent with cisco as the user password. If the RADIUS server does not support default authentication, a password of cisco can be used for each Mobile Node account.
In many cases, a AAA server already exists in the network and is configured with secure passwords for each user. In these scenarios, Mobile Node-authentication, authorization, and accounting (MN-AAA) authentication can perform AAA authentication with a secure password. MN-AAA requires the use of a Foreign Agent (FA) and requires the FA to be configured to forward the MN-AAA extension to the Home Agent rather than strip it off.
The Cisco Zero Configuration Client (ZeCC), described in the section "Cisco ZeCC," later in this chapter, is an ideal option for integrating with an existing authentication infrastructure. With the Cisco ZeCC, Mobile Node-Home Agent keys do not need to be configured for each Mobile Node.
It should now be clear that the AAA server does not authenticate an entity per se, but rather it provides the requesting Mobility Agent with the security association through a AAA protocol, for example, RADIUS or TACACS+.
As one would expect, some latency might be involved in processing a Mobile Node's Registration Request (RRQ) because now the Home Agent must first
The following options are available as part of the ip mobile host global configuration command to allow use of a AAA server and the associated caching of the security association:
Looking at the security association caching, you might
ip mobile home-agent resync-sa seconds
The next question is "What happens if the Mobile Node is no longer authorized to use my network?" In this case, you should remove the security association from the AAA server and the local cache in the router. This can be accomplished in two ways. The first is by using the clear ip mobile secure command on the command line. While effective, the CLI is not ideal for automated provisioning and management systems. For these advanced systems, you can also flush a cached security association using the Simple Network Management Protocol (SNMP) set queries on objects defined in the Cisco Mobile IP Management Information Base (MIB), as discussed in Chapter 8, "Deployment Scalability and Management."
RADIUS is a AAA protocol that provides authentication and accounting services in a client/server model. RADIUS-specific messages and attributes are used for communication between the clientcalled a NASand server. In the context of a Mobile IP deployment, the NAS is the Mobility Agent, for example, Home Agent, and the server is the AAA server.
RADIUS uses User Datagram Protocol (UDP) as the transport mechanism and only encrypts the password portion of packets, with the remainder of the packet sent in the clear text. Thus, RADIUS is
After configuring the use of AAA on the Mobility Agent, the AAA protocolspecific configurations must be added. Use the following configuration commands on the Home Agent to specify which RADIUS server should be used, and the security between the Mobility Agent and RADIUS server:
Example 5-1 shows a sample Mobile IP configuration using RADIUS as the default
Example 5-1. Home Agent Configuration Using a RADIUS AAA Server
aaa new-model aaa authorization ipmobile default group radius radius-server host 192.168.162.173 auth-port 1645 acct-port 1646 radius-server key itsasecret ip mobile host 10.0.0.1 10.0.0.5 virtual-network 10.0.0.0 255.0.0.0 aaa
You must ensure that your RADIUS ports match on both the NAS and the server. Request for Comment (RFC) 2138 defines ports 1812 and 1813 as the default authentication and accounting ports, respectively, replacing the widely used ports 1645 and 1646.
TACACS+ is another AAA protocol that provides authentication and authorization services. Although TACACS+ is considered to be heavier-weight than RADIUS, it provides more flexibility because it separates the functions of AAA. TACACS+ uses TCP as the transport layer protocol and encrypts the entire packet. Use of TACACS+ is not recommended with Mobile IP because many features are only supported with RADIUS. TACACS+ can only receive the Mobile Node-Home Agent security association. Advanced features, such as dynamic addressing, are not supported.
Use the following TACACS+ configuration commands to specify the TACACS+ server and authentication keys:
Example 5-2 uses TACACS+ to retrieve security associations from the AAA server.
Example 5-2. Home Agent Configuration Using a TACACS+ AAA Server
aaa new-model aaa authorization ipmobile tacacs+ tacacs-server host 192.168.3.4 tacacs-server key mykey ip mobile host 10.0.0.1 10.0.0.5 virtual-network 10.0.0.0 255.0.0.0 aaa