In this short chapter we concentrate on the MVPN physical building blocks rather than on underlying technologies and systems architectures. We consider two major categories of MVPN products required to implement a workable system, MVPN clients and MVPN gateways, which can often be supported by or collocated with wireless data platforms and other devices. This chapter completes our discussion of MVPN and transitions to the last chapter of the book on future trends and scenarios in wireless data services.
A detailed review of the architecture of MVPN platforms and clients could easily span not one but a series of books, so our focus in this chapter is simply to analyze how different types of VPN components are used and their suitability to the task, rather than the details of their internal architecture.
As opposed to gateways, which serve the needs of the whole or part of the network they represent, VPN clients are designed to satisfy the networking requirements of a single host. VPN clients might be therefore implemented on any type of computing device, from mobile phones to laptops to specialized equipment such as, barcode or credit card readers and smart appliances. VPN clients designed for a mobile environment must also satisfy requirements specific to mobile devices, such as optimized utilization of often-limited computing resources and power consumption and user interface adaptable for small screen sizes. These requirements are especially important when VPN clients are installed or incorporated into PDAs, smart phones, and other compact form factor devices.
The discussion about VPN clients in general is conducted in the context of voluntary MVPNs based on end-to-end tunnels or tunnel chains, since network-based VPN generaly does note require client functionality.
MVPN clients enable mobile devices to establish and support VPN communications channels. They have multiple functionalities, including tunneling, authentication and authorization, and security options. MVPN clients can be implemented in both software, which must work in conjunction with mobile device operating systems, and hardware, which must be either physically connected to a mobile device through an external or internal interface (such as a PCMCIA) or be permanently built into the device itself during its manufacturing.
Voluntary Mobile VPN connections are most often initiated by the user, which often requires relatively few access control, authentication, and tunneling options. For this reason, the functionalities of a VPN client— especially in mobile environments—often constitute a subset of functionalities of the VPN gateway, discussed in the following section. It is customary for MVPN clients to support only one or two types of tunneling technologies, such as IPSec or PPTP and L2TPclients.
Often, wireline VPN clients are named according to the tunneling technology they support (e.g., IPSec client). That trend may be changing to a less technical convention in an effort by equipment manufacturers to make technology as transparent to the end user (many of whom are not technologysavy) as possible.
Client support for authentication is usually dictated by the VPN gateway and the rest of the infrastructure implemented in the private network the device is set up to access. Contemporary corporate networking environments, for example, tend to rely on RADIUS authentication combined with secure token cards (the so-called three-factors authentication methods versus two-factor authentication, based only on user name and password). A VPN client used in mobile environments may be mobility-agnostic where the underlying mobile network handles mobility transparently, or mobility-aware, as in the case of Mobile IP-based clients.
Within the Mobile IP clients, there may be a class of them supporting automatic fail-over to collocated care-of-address if a Foreign Agent was not found, and also automatic network interface selection (based on signal strength).
This type of VPN client implementation is by far the most widespread for both wireline and wireless VPN. Generally, software-based clients are cheaper to implement, easier to distribute and support, and can be removed or upgraded as needed. All of these advantages are especially appealing to mobile environments, but they come at a price. The software-based clients are usually less efficient and thus more processing-power hungry, which leads to potentially faster battery drain for low-powered mobile devices. For example, software-based 3DES encryption is known to be significantly less efficient than hardware-based implementations, reducing the performance and increasing user data latency. Software-based hashing functions such as MD-5 or SHA-1 are also capable of affecting performance and latency. These effects, combined with an unreliable air link, can have serious consequences on the user data aggregate bit rates.
Software-based clients are usually designed for specific operating systems. They can either be integrated into an operating system or implemented as a "shim" between the link layer and network layer of the OS protocol stack, also known as "bump-in-stack" implementation (see Figure 8.1). Some commercially available operating systems, such as Windows XP and Pocket PC 2002, have VPN clients built in. The OS-integrated VPN clients further simplify distribution and partially offload the burden of installation, distribution, and remote user support from IT administrators.
Software-based VPN clients can be implemented on both the OSI link layer and the network layer. A widely used example of a link layer VPN client is a PPTP/L2TP client supplied with the Windows 2000 operating system. However, by far the most widespread VPN clients are IPSec clients.
VPN implementation in operating systems carries significant advantages, such as higher efficiency than shim implementation. On the other hand, the VPN clients implemented as a part of the OS are limited to features provided by the vendor and may lack capabilities required by different IT departments. In this case, you would need to resort to commercially available alternatives or in-house client software development.
Hardware-based MVPN clients are not commonly found today in the marketplace, although they may be expected to be implemented, in part spurred by the demand for more sophisticated mobile devices. Hardware-based clients can be implemented as add-on devices, such as PCMCIA cards, smart cards, or proprietary hardware connected to the mobile device through one of the available standard interfaces. They also can come on a chip or a chip set and be built into a mobile device itself during manufacturing. The latter option has a good potential to become the solution of choice for high-end mobile phones because of its frugal power use, potentially low-volume pricing, and other attractive qualities. Hardware-based MVPN solutions must be made firmware-upgradeable to keep up with changing standards and technology evolution. Note that an HW client normally would implement only a subset of the VPN client functionality (such as the most computationally intensive) and leave to SW application controlling the user interface.
There are a few design issues unique to MVPN clients that we must consider. Most stem from the specific requirements of compact mobile devices and the nature of wireless communications.
Engineers designing MVPN clients or adapting the existing solutions to various mobile devices, such as PDAs and smart phones, do not have the luxury of unlimited AC power and powerful microprocessors available for VPN client applications residing on stationary personal computers or UNIX workstations. One of the ways to address these constraints is to limit the options and functionalities supported by a mobile client. For example, tunneling support can be limited to IPSec tunnel mode ESP, and encryption options can be limited to 3DES and RC5. Also, the clients can be optimized for use with particular operating systems, such as Pocket PC or Palm.
MVPN clients must be able to cope with an unreliable physical layer or wireless environment over which communication is taking place. When the wireless connection is unreliable (dropped circuit calls while traveling in a car is a good example), the end-to-end tunnels established between the client and the private network can often break and need to be reinstated. To address this problem, the VPN client must support options or procedures for fast VPN connection re-establishment, such as automatic login.
Service providers, enterprises, institutions, and other privately networked entities deploying MVPN solutions must be mindful of the potential difficulties associated with the MVPN clients distribution, remote provisioning, and support. Mobile users tend to travel with their devices in different areas and might be hard to reach or limited in the ways they can communicate with centralized network support groups. Also, it is not feasible to dispatch technicians to constantly changing user remote locations for repairs in case remote support fails.
Distribution and installation of MVPN client software might present similar and even greater challenges to IT departments not only because of the constant mobility of the users but also the general immaturity of the mobile device universe. A remedy to address these problems might include a range of measures such as preventive on-site mobile device maintenance, outsourcing of mobile user's support to a third party, and broader involvement of equipment manufacturers in day-to-day support activities.
The security and authentication requirements for MVPN clients might often need to be more stringent than those of regular fixed VPN clients—and for a good reason. Stationary VPN clients are hosted on computers in closed quarters such as a house or remote office and are usually well protected from perpetrators. MVPN clients, on the other hand, are usually supported in mobile devices, which tend to be carried on a person. Such devices are often stolen, lost, and left unattended for extended periods of time. This makes them easy prey not only for property thieves but also for anybody wishing to get access to resources in a certain private network accessible by the device. Such issues of additional security can be addressed via a set of measures involving periodic user pooling, stricter account administration rules and mandatory use of SecureID cards, and other three-factor authentication methods.