Category list

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 hosts stay within their LAN, which can be limiting, especially in this mobile age.

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 efficiently managing the security keys. This is accomplished by storing the security associations in an authentication, authorization, and accounting (AAA) server.

Storing Security Associations in AAA

A AAA server is a separate centralized database that can store and maintain security associations. It is especially helpful to incorporate a AAA server into the network architecture for scalability reasons. For example, if a Home Agent is supporting hundreds or thousands of Mobile Nodes, the Mobile Node-Home Agent (Mobile Node-Home Agent) security associations can be stored on the AAA server instead of the Home Agent, freeing memory on the Home Agent. This allows the Home Agent to service more Mobile Nodes as the number of users on the network grows. When using a AAA server, the Home Agent queries the AAA server for the credentials necessary to authenticate a Mobile Node, as shown in Figure 5-3.

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 altered every time a Mobile Node is added or removed. This model of having a fixed configuration on the Home Agent and dynamic user information on a AAA server has already proven effective and scalable.

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:

Remote Authentication Dial-In User Service (RADIUS)
Terminal Access Controller Access Control System Plus (TACACS+)

This is accomplished using the following global IOS configuration commands on the Mobility Agent:


aaa new-model


aaa authorization ipmobile

The next task is to configure the entities to share a trust relationship. This configuration is related to the AAA protocol and not a specific Mobile IP configuration. In any case, once a protocol-specific trust relationship is established through the AAA protocol, the AAA server and Mobility Agents can now exchange sensitive security information. Cisco IOS only supports storing the Mobile Node-Home Agent security association in a AAA server; other types of security associations are rarely used and, as such, must be configured on the command-line interface (CLI).

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 yes or no responses to authentication requests so that passwords do not have to be distributed. However, for Mobile IP purposes, it is not enough for the Home Agent to simply know whether the Mobile Node is authenticated. Rather, the Home Agent must retrieve the Mobile Node-Home Agent secret key because it needs that key to compute the authenticator value to be included in the Registration Reply (RRP). To this end, Cisco IOS typically bypasses authentication on the AAA server to receive the Mobile Node-Home Agent key as a textual authorization attribute. The AAA server then provides the Home Agent with the Mobile Node's Mobile Node-Home Agent security association through a Cisco vendor-specific authorization attribute. At this point, the Home Agent can authenticate the Mobile Node as usual.

NOTE

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 consult the AAA server for the Mobile Node's security association. While this is true, some Cisco IOS features can mitigate this latency. security association caching is a mechanism that allows the security association to be locally stored on the Home Agent when it has been retrieved from the AAA server. Then, the next time the Home Agent must authenticate the Mobile Node, the Home Agent only needs to consult its local cache. You might be thinking, "But if you are retrieving the security associations just to store them on the Home Agent, what is the benefit of caching?" Good question. The idea behind caching is that only the security associations for the Mobile Nodes that are currently active (roaming) are kept in the Home Agent's cache, while the security associations of nonroaming Mobile Nodes are kept on the AAA server. Thus, caching still allows the benefits of using a AAA server, while reducing the latency incurred with having to consult the AAA server. Depending on the configuration, the security association can either be deleted from the cache automatically after a binding terminates or it can be kept permanently on the Home Agent. The security associations can also be manually cleared.

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:

aaa This option specifies that the security association is stored on a AAA server (TACACS+ or RADIUS).
load - sa This option specifies that security associations are cached (or loaded) into RAM after retrieval. If the Mobile Node is an NAI host, the security association is cleared from the cache after the binding is deleted. For non-NAI hosts , the security association is kept permanently in the cache. Caching provides significant benefits in most deployments.
permanent This option specifies that the security association for NAI hosts is kept permanently in the cache after retrieval from the AAA server. Exercise care when using this option, because as the user population changes, the Home Agent memory could fill with unnecessary security associations.

Looking at the security association caching, you might wonder what happens if the security association is changed on the AAA server and corresponding entityfor example, Mobile Nodeafter it has been downloaded to local cache. No worries. One option allows the Home Agent to requery the AAA server if the authentication fails based on the security association in the local cache. The resync-sa feature has some intelligence built in to thwart denial of service (DoS) attacks on the AAA server by allowing only one AAA query per Mobile Node in a specified interval. Use the following command to achieve the requery behavior when authentication fails, with the seconds argument specifying the interval that the Home Agent must wait before requerying the AAA server:


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

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 considered lighter-weight than TACACS+, which uses Transmission Control Protocol (TCP) (and is recommended for use in Mobile IP deployments over TACACS+.) (TACACS+ is described in the next section of this chapter.) However, because the packet is not encrypted, the security association transits the network in the clear. If enhanced security is necessary, IP Security (IPSec) can protect the RADIUS traffic.

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:

radius-server host host Specifies a RADIUS server host.
radius-server key key Sets the authentication and encryption key for all RADIUS communications between the Mobility Agent and RADIUS server.

Example 5-1 shows a sample Mobile IP configuration using RADIUS as the default group to retrieve security associations from the AAA server.

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

NOTE

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+

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:

tacacs-server host host Specifies a TACACS+ host.
tacacs-server key key Sets the authentication encryption key that is used for all TACACS+ communications between the access server and the TACACS+ daemon.

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