Mobile IP-Based VPN

Public HA VPN Option

This Mobile IP VPN option is well described in IETF, 3GPP2, and TIA/EIA standard documentation.^[1] It is expected to be a mainstream scenario supported by the majority of CDMA2000 wireless operators offering MVPN services. In this approach, depicted in Figure 7.5, all of the downstream traffic (to the MS) that originated in a private network is tunneled from the HA that resides there to the PDSN that resides in the carrier's network. The upstream traffic (originated by the MS) is tunneled from the PDSN in the wireless access network to the HA in the customer network. For this purpose, the PDSN may establish an optional reverse tunnel, as defined in [RFC3220]. Both forward and reverse Mobile IP tunnels are based on IP in IP or GRE protocols and can be combined with optional IPSec security.

Figure 7.5: Public HA VPN architecture.

The IP address of the MS is assigned from the address space of the customer network, which might rely on public or private IP addressing schemes, relieving the wireless access provider from the duty of IP address management, similar to a Simple IP VPN case. As defined in [IS835], the address of the HA in the private network is discovered using NAI in Mobile IP RRQ when HA is statically allocated (dynamic HA allocation is considered in the "CDMA2000 IP Address Management" section later in this chapter). The MS in this scenario must register with both the visited and home AAA servers and undergo a AAA procedure involving AAA clients in both the PDSN and the HA.

Public HA VPN Security

Mobile IP tunnels to and from private networks established through public IP networks such as the Internet are generally insecure and require security protection, similar to the situation with the L2TP tunnels in the Simple IP case. Such protection can be provided by the IP Security protocol suite combined with a mechanism for distributing keys, like the Internet Key Exchange (IKE) discussed in Chapter 2. Figure 7.6, depicts a protocol reference model for this VPN option. It is important for the HA to verify the identity of the wireless carrier's PDSN that will have access to unprotected user data for the duration of the session. It is also important for the PDSN to verify the identity of the HA so that user traffic is not misdirected to an unknown insecure location. In the public HA VPN access scenario, the HA is owned and operated by the private network to which the user is gaining access and will manage both security and mobility of the user by forming dynamic security associations with changing serving PDSNs.

Figure 7.6: Public HA VPN protocol stack.

Note

Some of the mechanisms we describe in this section are unique to CDMA2000 and are not a part of the generic 3220 Mobile IP spec. Apendixes A and B list Mobile IP extensions and RADIUS attributes that have been added to the original IETF specification by 3GPP2 and TIA.

Normally, wireless carriers deploy IP security for interdomain communication and for Mobile IP signaling protection. To further minimize the chances of a security violation, the traffic to and from the HA can be encrypted by using one of the techniques outlined in Chapter 2. The PDSN can decide which policy to apply based also on the Security Level RADIUS attribute as defined in [IS835]. During a setup of an IPSec-secured tunnel between the PDSN and HA, IKE is used to verify the identity of the PDSN and HA. The security key association may be:

• A statically configured secret for the Mobile IP HA-FA authentication extension

• A statically configured IKE pre-shared secret

• A dynamic IKE pre-shared secret distributed by home AAA

• PKI with certificates

The static Mobile IP HA-FA authentication extension supersedes the static IKE pre-shared secret, which supersedes the dynamically distributed IKE secret, which supersedes the PKI certificate in order of precedence. Preprovisioning the MN-HA pre-shared key is required in the current version of [IS835], the standard governing most of the requirements of the CDMA2000 core infrastructure. Keying material that is distributed during the AAA registration process should be protected against eavesdropping. If an attacker could learn these keys, he or she could carry out denial-of-service or session stealing attacks against mobile nodes. This protection can be provided on a hop-by-hop basis—for instance, by using IPSec between visited AAA servers in the rest of the AAA infrastructure.

When a static pre-shared secret key association is used, the first phase exchange is authenticated with message authentication codes. Using pre-shared secrets can simplify operation because it avoids the need to process and validate certificates. However, these associations may introduce an additional burden because of the need to establish them in PDSN-HA pairs. For this reason, [IS835] provides a mechanism for dynamic pre-shared keys distribution via the AAA infrastructure during mobile node registration. While the home AAA processes and validates the MN's challenge-response, it can generate a pre-shared secret and distribute it with the AAA response back to the PDSN. The PDSN then can use the secret, along with an identity constructed from the response, to carry out IKE negotiation with the HA. This enables secure establishment of IP security between the PDSN and HA without the need for manual configuration of the keys between all possible pairs.

If reverse tunneling is supported by the Home Agent as indicated by the home AAA server in the [IS835] Reverse Tunnel Specification RADIUS attribute (see Appendix B), IPSec security is authorized for tunneled data, and the mobile requests reverse tunneling, then the PDSN will provide security on the reverse tunnel. Reverse tunnels are set up as a result of the mobile node setting the "T" bit in its registration request. This causes all packets from the mobile node to be encapsulated and delivered to the HA by the PDSN. Such tunnels enable the use of private, nonunique addresses by mobile nodes, and the reverse (as well as forward) tunnels can be optionally protected with IPSec if desired by the home domain.

Private HA VPN

Wireless carriers might not always be open to the idea of sharing their data infrastructure with the rest of the world like in the public HA VPN model. This might be especially disconcerting when some of the key infrastructure elements such as HA owned by a third party will be connected to their core networks through the shared public Internet. Also, carriers might not be willing to give up control of their subscriber management and hesitate to become "just" wireless data access providers.^[2] These concerns were significant to GPRS operators and standard bodies like 3GPP and eventually prompted them to recommend placing all of the GPRS infrastructure elements in the wireless operator's domain (as explained in Chapter 4). Similar to their GPRS and UMTS counterparts, CDMA2000 operators deploying the private HA VPN option will own both PDSN and HA infrastructure elements.

While significant amounts of HA capacity must be provisioned in the wireless carrier's network for non-VPN use to enable them to offer ISP and other services, use of the carrier's HAs for VPN services have not been addressed by the standards and therefore must be analyzed carefully. The CDMA2000 subscriber's data path will always include both the PDSN and the HA, at least in one direction. The downstream data traffic must pass through the HA in the MS home network and the serving PDSN. The upstream traffic (from the MS) must pass through the PDSN only if the MS requests plain Internet access, and through the PDSN/HA pair joined by the reverse Mobile IP tunnel if the MS requests private network access. To satisfy these requirements, wireless carriers must deploy enough HA capacity to support Mobile IP MSs whether or not they require private network access or only requesting plain Internet access.

Having such a vast HA infrastructure already available, wireless carriers wishing to exercise as much control as possible of the subscriber provisioning might then completely disallow the access to the HAs in the private networks, forcing all the traffic to and from private networks through their own HAs and then forwarding it between private networks via the use of other technology, as shown in Figure 7.7. In this scenario, private networks do not need to maintain the HA and terminate Mobile IP tunnels. Instead, the wireless carrier and the private network must rely on a set of tunnels (or other technologies) concatenated at the carrier-owned HA combined with private peering agreements and specific SLAs to be able to provide secure VPN offerings.

Figure 7.7: Private HA VPN architecture and protocol stack.

The rules of deployment for private HA VPN are quite different from those for public HA VPN and bring some significant consequences for operators. Arguably, private HA VPN might simplify IP address assignment for mobile users by allowing one entity, a wireless carrier, to control the procedure. Optionally carriers may even be able to consolidate—at least in theory—the IP address assignment process into one location, a hypothetical HA farm combined with massive IP address repository and super-sized DHCP and AAA servers. Moreover, wireless carriers can retain control over the user's provisioning and both payload and signaling traffic security, which will minimize the risks of their core network security breach. However attractive this reasoning might be for both greenfield and established operators, in our view the disadvantages of this solution equal if not outweigh its advantages. To name a few, operators favoring private HA VPN will have to pick up the burden of user provisioning, fully engage in ISP-style business and hence competition, be responsible for supplying millions of IP addresses to their mobile users, and be prepared to limit their offerings to corporations and forgo other advantages and simplicity of standard-based public HA VPN.

The responsibility for IP address assignments might pose a dilemma for a successful^[3] CDMA2000 operator. The operators must decide whether to provide their subscribers with a public or private "topologically incorrect" IP address or a mixture of both. Both cases would be equally problematic. Public routable IPv4 addresses are a scarce commodity and unlikely to be available in the millions. Private IP addressing might seem to be an easy way out, but that practice would prevent mobile subscribers from accessing private networks using voluntary VPN based on end-to-end tunneling, which requires public routable IP addresses, unless complex and not adequately defined NAT traversal schemes are deployed within the operator's core network. In any case, customers will effectively feel forced into using private HA VPNs, often entailing mandatory customer-operator agreements as the only option available for private intranet access.

Another potential challenge associated with private HA VPN is the necessity to create a tunnel-switched infrastructure around the HA. This situation is not quite addressed in standards and will require a new architectural framework involving wireless carriers and their corporate peers alike. Creation of such a framework will be a nontrivial exercise involving new types of SLA definitions, new billing arrangements, and new requirements to HA platforms—which will need to support tunnel switching and WAN technologies on a carrier-class scale, among other new tasks.

Sample architecture, as depicted in Figure 7.7, can be based on one of the tunneling technologies defined by IETF, such as IPSec deployed in tunnel mode or combined with MPLS. In such a scenario the Mobile IP tunnels to and from geographically distributed PDSNs would be terminated at the private HA in the carrier's network and then concatenated with the corresponding IPSec tunnels created for individual enterprises, assuming the existence of predefined relationships with the wireless carrier. This scenario assumes that not only IP address assignment but also authentication of mobile stations will be completed in the carrier's network. A similar "tunnel switching" scenario in GPRS and UMTS, referred to as the PPP Relay option under the Nontransparent IP access method, is well defined by 3GPP and therefore, can be expected to become one of the popular VPN options, as mentioned in Chapter 6. A likely alternative might be based on use of private lines or ATM or Frame Relay PVCs to transmit user data to and from corporate network. The details of such a solution, however, are beyond the scope of this book.

We complete this section by discussing one of the most controversial aspects of the private HA VPN solution—one that does not concern the technology itself but rather the technical community's perception of it. The standards bodies such as the IETF Mobile IP Working Group (which defines Mobile IP and AAA systems architecture) and TIA [TR45.6] (which defines CDMA2000 packet data core) based their efforts on the assumption of access network transparency and relative subscriber independence from the access providers. Their efforts concentrated on definition of Simple IP or Mobile IP public HA-based private network access methods, both of which preserved a certain degree of enterprise control over mobile user provisioning.

It was assumed that private networks wishing to provide their members with mobile access would be able to achieve this goal through a relatively straightforward standards-based set of agreements with wireless carriers that would not require them to sacrifice their involvement in AAA, IP address assignment, and other remote user management functions. As such, while not directly violating the CDMA2000 private network access standards and overall logic, the private HA VPN approach works against at least the spirit of the standards This controversy is bound to stir emotions and spark debates in both wireless and corporate IS communities with consequences yet to be measured. After all, the original goal of Mobile IP was focused on providing easy secure private network access in the mobile environment, ease of distributed infrastructures implementation, including AAA brokerage, and support for a wide range of options to control remote user provisioning exercised by service providers and private networks alike.