Neither Mobile IP nor L2TP by themselves provide scalable mechanisms for access control or accounting. Basic Mobile IP does specify extensions that can be used to authenticate the MN to the FA or the FA to the HA, but these extensions are not mandatory and they assume the existence of preconfigured shared secrets between these entities. That creates a problem because the worldwide public CDMA2000 cellular network will include many subnetworks or domains owned by a variety of private enterprises, CDMA carriers, wireline ISPs, and ASPs. Visited wireless carrier's networks that support PDSNs will expect payment for wireless data services from the mobile user or the user's home domain. To obtain assurances of payment, the CDMA2000 core architecture must support scalable AAA networks consisting of interconnected AAA servers that offer an array of services, as opposed to a group of disconnected noncommunicating AAA servers.
In Chapter 4, we described the basic concepts of AAA in the CDMA2000 environment, which are largely based on the use of RADIUS and other protocols such as PAP and CHAP. In this section we analyze in more detail the CDMA2000-style AAA architecture and its impact on MVPN services. To provide a robust AAA functionality for private network access, the concept of a distributed visited-home AAA infrastructure had to be taken one step further. To better satisfy requirements for different methods of private network access and facilitates peering without the need to preestablish agreements, it evolved into the form of visited-broker-home AAA architecture, shown in Figure 7.9. This architecture was developed with a goal somewhat similar to GRX in GPRS networking, discussed in Chapter 6, to facilitate a network architecture that can be shared by many private peering entities, including ISPs, ASPs, corporate networks, and wireless carriers. Note that the need of GRX in GPRS is for BGP peering, rather than AAA servers peering.
The MS accessing a private network through the access network provided by a third-party entity must be authenticated by both networks. As a result, the MS is identified to the access network by its ID, such as an International Mobile Station Identifier (IMSI), and to a private network via an NAI. As shown in Figure 7.9, such authentication requires AAA functionality at both visited and home networks. In CDMA2000, this functionality is achieved through a visited network RADIUS AAA client (usually hosted by the PDSN) and server, and home network RADIUS AAA client (usually hosted by an HA for Mobile IP and an LNS for Simple IP VPN) and server.
In addition to authenticating and authorizing MS in generic CDMA2000 communications, when private network access is requested, authentication requests are forwarded from a visited AAA server associated with the PDSN to a home AAA server associated with the HA, and authorization responses are forwarded in the other direction. The accounting information must then be stored by the visited AAA server and optionally sent to the home AAA using a reliable AAA protocol and then forwarded to a billing system. For VPN service, the accounting information may include parameters such as NAI, QoS, Session ID for Simple IP service, and destination address. The AAA home-visited communication is based on a reliable transport mechanism, can be optionally protected by IPSec, and is capable of distributing a pre-shared secret for IKE.
This model is fundamentally similar for both Simple IP and Mobile IP VPN types and might include optional components such as a RADIUS proxy server and AAA brokers (described in the section that follows). For both CDMA2000 VPN types, basic communication between RADIUS clients and servers is governed by [RFC2865] and [RFC2866], details of which are beyond the scope of this book. This communication can also be optionally secured by IPSec to provide a security association between the MS, the PDSN, and the HA (or LNS in the Simple IP case) and support dynamic key distribution using IKE.
The home/visited AAA infrastructure just described was designed to serve home and visited network with the relationship preestablished via a set of SLAs. In cases when such relationships have not been established but the visiting MS requests data service, the AAA brokerage must be used. Since this statement, while being accurate, provides little in the way of explanation, we need to take a closer look at both the problem and solution. Home and visited AAA servers may have a direct bilateral relationship. The cellular architecture, however, will involve thousands of domains with many private networks owned by enterprises that seek wireless data service for their mobile workforce. If the number of domains were small, the serving and home networks could have preexisting relationships (perhaps secured via IP security associations). However, this would not be a scalable solution; it would require too many pair-wise relationships to be pre-established.
AAA brokers host directories that allow AAA requests to be forwarded based on the NAI to home networks or to other brokers knowing the whereabouts of the home network. Brokers may also take on a financial role in the settlement of accounts between domains and may process accounting records for the network access requests they authorize. Because the visited network will not provide service unless it is able to obtain authorization from the mobile user's home network, or from a broker that accepts financial responsibility, the AAA infrastructure must be reliable. This implies that servers must retransmit requests and switch over to backup servers when a failure of the primary unit is detected.
As defined in [TSB115], AAA networks must support three modes of broker operation:
Nontransparent (nonproxy) mode, where the brokers essentially terminate requests to and from visited and home AAA servers and initiate new requests on their behalf. In this mode the broker is allowed to change the content and attributes of the messages. This mode is most likely to be used when the broker is permitted to financially act on behalf of visited networks.
Transparent mode, where the broker is not authorized to make any changes to the AAA messages and is only allowed to redirect them to appropriate points of destination.
Redirection mode, where broker AAA server refers the service provider to another AAA server.
Another important task of an AAA broker is to facilitate roaming services. Roaming services permit mobile users outside their carrier's area of coverage to use other carriers' networks to access the public Internet or private networks.
In the case of Mobile IP VPN, when an MS is accessing an HA in the private network, the wireless access provider (that is, the PDSN owner) must not be involved in the security association between the MS and its home network. That was another requirement that the CDMA2000 AAA architecture needed to comply with. With the TIA Security Level attribute in the Access-Accept message, the home AAA server is able to authorize the PDSN on a per-user basis to optionally use IPSec on the registration messages and the tunneled data.
If the home AAA server has indicated that an IP security association must be used between the PDSN and HA, the PDSN will provide IPSec services as indicated in the [IS835] based on a 3GPP2-defined security level attribute (see Appendix B). If no security association is in place, the PDSN attempts to establish the security association using the HA X.509 certificate. If no HA X.509 certificate exists, but the root certificate exists, the PDSN attempts to establish the security association using X.509 certificates it received in Phase 1 IKE. If the certificates do not exist, the PDSN attempts to use the dynamically distributed shared secret for IKE received in the Access-Accept message. If no shared secret was sent, the PDSN attempts to use a statically configured IKE pre-shared secret, if one exists. If the PDSN does not receive the 3GPP2 security level attribute from the home RADIUS server, and an IPSec security association to the HA already exists, the PDSN continues to use the same security association. If no security association exists, then the PDSN follows locally configured security policy.
For Simple IP VPN access mode, the AAA architecture does not include the HA. Its functionality is instead supported by the LNS, as described earlier in this chapter. The AAA server must locate the LNS providing access to the user's home network. Proxy AAA servers in related service providers' networks must therefore be set up and provisioned in order to locate the LNS. After the LNS is located, an L2TP tunnel is established between the LNS and the PDSN from which the MS requests services. The MS IP address is assigned by the LNS after the tunnel establishment. Since the MS does not participate in making routing decisions between the tunnel end-points, both registered or unregistered IP addresses can be assigned to the mobile node. The visited AAA server records the accounting record and forwards the Accounting Request message to the home AAA server if roaming is involved.
Let's consider the sequence of AAA events taking place during Simple IP private network access initiation. When a Simple IP MS initiates the connection to the PDSN, the PDSN forms an Access Request message and sends it to the home AAA server for authentication. The request is positively authenticated and an Access Accept containing tunneling type "L2TP" is sent back to a visited AAA. The PDSN initiates the L2TP tunnel if it has not been established prior to this event, and it sends an Accounting Request message for billing purposes to record the starting time of the service. When the service is no longer required, the L2TP user session and tunnel are terminated. Finally, the PDSN sends another Accounting Request message to record the time when service stopped.