Simple IP: A True Mobile VPN?

In Chapter 4, we reviewed the CDMA2000 three-tiered data mobility model (Figure 4.5). We mentioned that one of the mobility levels is provided by Mobile IP, preserving the mobile station's IP address when it changes its serving PDSN. When the Mobile IP service is not available for any reason, the Simple IP service is used. In Simple IP, PPP sessions originated by the mobile stations are terminated at the PDSN in a similar manner as Mobile IP. However, if the Simple IP MS must change the current serving PDSN, the PPP session is terminated and the MS must obtain a new IP address when attaching to a new serving PDSN.

CDMA2000 infrastructure vendors made significant efforts to address this problem on the data link and physical layers. One popular solution (depicted in Figure 7.8 in the "Case Study" section at the end of this chapter) is to fully mesh the network of Packet Control Functions (PCFs) and PDSNs. This solution would ensure that the MS stays anchored at the same PDSN even if the serving PCF is changing. This is possible because the PPP connection is established between the MS and the PDSN, and if the underlying network can keep the connection alive, the PPP session will be preserved. This way, the MS's IP address stays constant and can potentially even survive the MSC boundary crossings. Along with possible significant backhaul costs and IP address assignment restrictions, however, this solution will only work for the duration of the session. In other words, new dynamic IP addresses must be acquired if the session is dropped and then reinstated by the mobile or in the event of spotty coverage. As a result, Simple IP is not expected to be a mainstream access method offered to CDMA2000 VPN customers when they will require support for high mobility patterns as par of their service usage requirements. Because of these limitations, corporate subscribers using mobiles operating in Simple IP mode often can't obtain a "truly mobile" VPN service. In many instances, MSs connected to CDMA2000 networks in Simple IP mode can't maintain either their compulsory or voluntary VPN connections if the serving PDSN change happens. For these "unlucky" users, the Mobile VPN experience can be simulated by specially designed applications or special infrastructure enhancements (discussed in the section that follows), but never truly supported on the network layer. In addition to this hurdle, seamless roaming to the networks based on other technologies such as WLAN will be problematic at best (see Chapter 9 for more discussion). As a result, according to the taxonomy proposed in Chapter 5, the case of Simple IP should be more classified as wireless rather than mobile VPN. In summary, the Simple IP access would be optimal for access to networks requiring limited or no mobility.

Simple IP VPN Architecture

Let's look at the architecture model of Simple IP, depicted in Figure 7.1. As in wireline remote access networks, the PPP session initiated by the MS is terminated by an NAS, whose functionality in this case is supported by the PDSN and then relayed over a tunnel to a remote tunnel termination point maintained behind a firewall in the private network. The tunneling protocol recommended by [IS835] in this case is L2TP, described in Chapter 2. The L2TP Access Concentrator (LAC) functionality supported by the PDSN, encapsulates the mobile station's PPP session and carries it over an arbitrary IP network to a remote L2TP Network Server (LNS), which terminates the PPP link in the private network.

Figure 7.1: Simple IP VPN architecture model.

Simple IP-based wireless VPN with PDSN-originated L2TP can be classified as a typical case of compulsory tunneling. The mobile user's PPP link is effectively relayed through the PDSN over an L2TP tunnel to a remote LNS, which terminates the PPP link and, in combination with the home AAA server, provides primary authentication and address assignment functions, enabling private network owners to retain a significant amount of control over MS authentication and address assignment (and the operator, conversely, can offer the service with no need to take care of these aspects). The PDSN and its associated visited AAA server complete only enough of CHAP negotiations to discover the address of the private LNS. As opposed to Mobile IP, the Simple IP access method does not require a Home Agent but may still rely on broker-based distributed AAA infrastructure to access remote AAA servers associated with the LNS in private networks. Details on CDMA2000 AAA subsystem and IP address assignment options are provided later in the chapter. If VPN service is not requested during the Simple IP negotiation stage, the PDSN becomes an element responsible for IP address assignment and user authentication.

A Simple IP VPN protocol reference model is shown in Figure 7.2. In this figure, L2TP is augmented with optional IPSec protection. Wireless carriers often prefer this option, since as mentioned in Chapter 2, L2TP by itself is not a secure protocol and does not provide data confidentiality and data origin authentication. The L2TP tunneling is flexible, is familiar to IT departments around the world, and is often used to provide such exotic services as remote access outsourcing, IP access wholesaling, and so forth to third-party ISPs and ASP.

Figure 7.2: Simple IP VPN protocol reference model.

Simple IP-based VPN can also be used by the wireless carrier itself to allow selected users, such as maintenance personnel, access to its own private intranet. For example, operator's field technicians would be able to access essential system information or poll certain infrastructure elements status and error-reporting functions. This private intranet subnet would include dedicated LNS, which can be accessed by maintenance staff by entering, for example, their username/NAI combination (<john_technicians@support.ACME.com>) to be tunneled to this LNS and then be provided access to the network service center or any other appropriate network. Because the accounting records for this access contain the NAI (Network Access Identifier) used by the wireless operator's staff, these records can be treated as "nonbillable" by the carrier billing system, or can be billed internally at a separate rate from other data services.

Simple IP VPN Call Scenario

Let's consider the Simple IP VPN connection establishment sequence depicted in Figure 7.3. Note that this scenario assumes that a mobile station is attached to its home network—that is, the network where its original IP address was assigned.

Figure 7.3: Simple IP VPN connection establishment

There are two phases of VPN establishment: the establishment of connection between the MS and its serving PDSN and the establishment of L2TP session encapsulating PPP traffic between the PDSN supporting LAC functionality and an LNS in the private network. Because of the growing tendency in the vendor community to combine PDSN and LAC functionalities in a single platform and for the sake of simplicity, we refer to this combination as a PDSN/LAC in this and other chapters.

At the beginning of the first phase, the radio link is set up between the MS and BSS, and subsequent link layer connection is established between the MS and PCF (see Chapter 4 for details). To authenticate the user, the PDSN sends an authentication request to the local AAA server. The AAA server sends back an authentication response indicating whether the request is accepted or rejected. The message from the AAA server also contains the tunnel type (L2TP in our case) and destination IP address of the LNS within the private network. If the user is positively authenticated, private network access is granted and the PPP link is established.

During the next phase, the PDSN/LAC creates an L2TP tunnel toward the LNS in the private network, if it did not exist prior to this event, with unique session created within the tunnel for individual mobile user traffic. The LNS possibly after additional LCP negotiation and user authentication assigns the IP address to the MS from the pool of IP addresses owned by the private network using RADIUS, DHCP, or another dynamic address assignment mechanism at the NCP establishment phase. Next, the LNS strips off the encapsulation headers and routes the IP packet to the destination host within its private network. In the other direction, IP packets from a host trying to send packets to an MS, arrive at the LNS, which encapsulates them in PPP frames and send them to the PDSN/LAC where the MS is anchored through the L2TP tunnel. The PDSN/LAC strips off the L2TP header and forwards the PPP frames to the MS. As mentioned previously, IPSec can augment this scenario, by securing L2TP tunnels with ESP transport mode. If the MS changes its location and attaches to another PDSN, this whole procedure must be repeated and new IP addresses may be assigned, which may inconvenience many MVPN service subscribers.