Classifying VPN Technology

Classifying VPN Technology

There are two approaches to the classification of VPN technology:

  • Architecture taxonomy deals with how VPN is architected and deployed.

  • Tunneling taxonomy deals with how underlying tunneling techniques are implemented.

Historically, architecture taxonomy is more often used in sources dealing with wireline data VPNs, while tunneling-based taxonomy is usually applied in sources addressing cellular systems. While this book mostly deals with mobile wireless systems, we will provide an overview of both taxonomies and their applicability to Mobile VPNs. The examples of VPN classifications include compulsory versus voluntary, which is based on tunneling taxonomy, and site-to-site versus remote access, which is based on architecture taxonomy.

Tunneling Taxonomy

All IP VPNs can be implemented using basic tunneling methods:

  • End-to-end, or voluntary

  • Network-based, or compulsory

  • Chained or mediated tunnels, which fall somewhere in the middle

Based on the tunneling method being used, the VPN itself can be classified as voluntary, compulsory, or combined. We will now take a closer look at all three methods.

Voluntary VPN

Voluntary IP VPN provides remote users with the ability to create a tunnel from their terminals, such as mobile phones or PDAs, to certain tunnel termination point, such as a VPN gateway that resides within the private network. Private networks are usually protected by firewalls and require firewall traversal and security mechanisms—for instance, user authentication and data integrity and confidentiality protection—applied to the remote access traffic. Consequently, remote user equipment must support proper protocols to satisfy these requirements. For example, a remote user equipped with a device such as a PDA could establish an IPSec ESP tunnel to a corporate network using PKI-based key distribution (also known as an asymmetric keys approach) or predistributed shared secret key (also known as a symmetric keys approach). All data between such mobile stations and the private network would then be encapsulated in the secure end-to-end IPSec tunnel. The end-to-end tunneling in this example exists only for the duration of the session and is torn down when the remote users do not require private network access, or when the user must be preemptively disconnected based on a set of predefined events, such as session duration or limits in access rights.

This type of VPN service is depicted in Figure 5.3, which uses mobile dial-up access over a GSM network as an example. In this scenario, the remote user establishes a VPN connection to a private network after a wireless carrier grants him or her Internet access. Note that both wireless and wireline-based access to the Internet allow roaming users to establish this type of VPN at will, by "voluntarily" opening a communication channel to the private network when they need it—hence the name of the approach.

Click To expand Figure 5.3: Voluntary VPN over 2G network.

Voluntary VPN carries a number of significant advantages. For private network IT administrators and often for remote users, this is the simplest way to establish a remote access VPN. Remote users simply need access to the Internet or any other public IP network, and a VPN client in their mobile or fixed devices. All that the private network IT department needs to do is to provision a VPN gateway connected to the Internet and capable of terminating a particular type of tunneling, and establish a proper set of policies and security procedures. The service provider offering Internet access service cannot access the end-to-end encrypted private data being transmitted between remote user and private network, and hence it will not have to be entrusted with it. Voluntary VPN also does not require any preestablished relationship between corporations and service providers. Therefore, there are no multiple SLAs and legal agreements about data confidentiality. However, the user and the corporation should be ready to accept a network access service that may be less predictable and often qualitatively inferior to the service provided to parties that instead enter in a SLA, unless the service provider offers predefined levels of service such as a "business class" Internet access option.

Voluntary VPNs require that public, topologically correct IP addresses be assigned to remote users' equipment. This requirement—along with other properties of an end-to-end tunneling—creates a number of potential drawbacks to voluntary VPN service. Because of the limited number of IPv4 addresses available to service providers—especially for mobile operators that would like to offer "always on" connectivity to the Internet to their subscribers—reliance on private addressing schemes to conserve valuable IP address space, combined with various subnetting and address translation techniques such as NAT, is very common. Until recently, this made end-to-end tunneling, where public IP addresses were required, impossible. For example, IPSec AH mode is not compatible with NAT, which would not even allow for the tunnel to be established. Luckily, a few mechanisms allowing for NAT traversal have been recently introduced by the IETF and are being widely implemented by the industry (see Chapter 2). Also, the emergence of an IPv6-based network and the expected gradual conversion to an all-IPv6 Internet should resolve problems with insufficient addresses.

Another disadvantage of voluntary VPN arises from the nature of secure end-to-end tunneling, in which the contents of the tunneled packets are encapsulated and thus not available for inspection by any nodes on the tunneled packet's path except the tunnel endpoints. This makes QoS, classe of service (CoS), and the majority of traffic-shaping mechanisms requiring multifield packet inspection a difficult to impossible task. Monitoring equipment and certain firewalling functions will fail to work properly as well. We discussed some QoS issues that relate to tunneling in Chapter 2.

When Mobile VPNs are implemented in a cellular wireless environment, voluntary tunneling will lead to an extra layer of encapsulation over the last-hop wireless link. This will consume more of already scarce and expensive radio resources. Also, complex encryption and security algorithms may not be suitable for implementation in small wireless devices, which typically have limited processing and battery power. Additionally, widely mutable radio conditions and lossy wireless environment are not friendly to the establishment and preservation of IPSec tunnels. This may translate in a long tunnel setup time, or in extreme cases, to complete failure and perhaps the need to move to a region with better coverage. Note that this is not only affecting cellular systems but also Wireless LAN-based access networks.

For these reasons, while voluntary tunneling provides a clean and secure end-to-end solution for access to private networks, often greater VPN efficiency and unique services can be achieved with a participation of service providers prompting an introduction of another VPN type.

Compulsory VPN

A service provider may offer compulsory VPN service by concatenating or chaining multiple tunnels or provisioning a single tunnel for a part of a data path between two participating endpoints. For example, a compulsory VPN can be based on a tunnel created between a private network and a service provider and not extended to reach all the way to a remote user that is using the network access service. As a result, with compulsory VPN service the remote user does not need to have any involvement into VPN establishment process and is "forced" to use the available preprovisioned service whenever the access to the private network is required, hence the name.

This VPN type assumes that the operator's network infrastructure features the intelligence and functionality necessary to support VPN services based on the tunnels or sets of tunnels provisioned between the private network and service provider's networks rather than all the way to the end-user device. In both cases, the enterprise must preestablish a detailed SLA with the service provider responsible for VPN service and must trust it to handle its valuable data with the necessary care and confidentiality. The service provider often participates in the network's access control, and the corporation must trust the service provider to deny access to nonauthorized users according to the network access policy defined by the corporate network administrator. One possible compulsory VPN scenario implemented in the CDMA2000 infrastructure—based on Mobile IP—is depicted in Figure 5.4. In this figure the user data is encapsulated into Mobile IP tunnel only between the PDSN in carrier's network and the HA owned by corporation.

Click To expand
Figure 5.4: Compulsory VPN in CDMA2000.

The need to keep a part of the private data path unprotected, to trust the service provider, and to establish multiple SLAs and complex data confidentiality agreements are some of the drawbacks of compulsory VPN. In mobile environment, security problems become even more serious, since the user traffic is being sent over potentially insecure radio channels. During packet data roaming, the unprotected traffic to and from the mobile station must also traverse the visited carrier network (which may or may not have established SLA with the corporation served by a home wireless carrier) before being tunneled to original carrier's network. If there are insecure links in this network, especially unencrypted links in the backhaul section, this could present serious security problems. These problems are hard to address unless the provider puts careful service provisioning in place. For instance, gateway-to-gateway IPSec tunnels in critical points of the network could address this problem.

On the positive side, the compulsory approach better utilizes the air interface by avoiding over-the-air encapsulation overhead, which is especially advantageous for cellular wireless systems, and by simplifying the user equipment. When compulsory VPN is used, the end-user equipment does not have to support any VPN clients or tunneling or security capability at times they could be CPU-hungry and battery-life-consuming. Also, the user is not involved in VPN creation and only needs to request the service when accessing the service provider's network.

Compulsory VPN presents a number of other significant advantages to service providers. Offering and marketing compulsory VPN as a feature can potentially enable new business models and carrier service offerings. With the voluntary approach, service providers do not get involved in provisioning and often are not even aware of the existence of encrypted and encapsulated traffic unless they offer special access points to the Internet associated to publicly routable IP addresses or NAT traversal-compliant devices. In contrast, compulsory VPN access offerings can be marketed in different forms by carriers to a variety of private enterprises and ISPs interested in outsourcing their remote access function. This will bring new revenue streams, along with greater differentiation from the competition service offerings.

Another benefit of compulsory VPN for service providers lies in greater control over the user. In a compulsory model, the service provider is usually involved in user authentication and IP address assignment (though the latter might be a mixed blessing in some situations), which allows it to control user provisioning to a greater extent. IP addresses can be assigned to remote users from the customers' networks private address space, thus saving the usage of publicly routable IP addresses from the provider side.

Chained Tunnel VPN

The third type of VPN is not easily classified as either voluntary or compulsory. Chained tunnel VPN consists of a set of concatenated tunnels that extend all the way to the end-user equipment. Chained tunnel VPN can come in many different forms, as shown in Figure 5.5, which depicts a few tunnel chaining options in the GPRS network.

Click To expand
Figure 5.5: Chained tunnel VPN options (GPRS environment).

Similar to the voluntary VPN approach, chained tunnel VPN provides end-to-end user data protection, and the user participates in tunnel initiation. Like compulsory VPN, the service provider is involved in chained tunnel VPN provisioning and construction and can easily apply QoS and traffic shaping at the tunnel concatenation points. This participation does necessitate SLA and data handling agreements, though.

In our opinion, all of these VPN types have their positives and negatives and will coexist in future networks. The service providers can offer them interchangeably, depending on the available technology, suitability to task, and business environment.

Architecture Taxonomy: Site-to-Site and Remote Access VPN

In this section we look at VPN classification from an architecture rather than a tunneling perspective. We also analyze the current wireline IP VPN taxonomy and its applicability to the mobile environment. VPN architectures can be classified into two main types: Site-to-site VPNs, also called LAN-to-LAN or POP-to-POP, and Remote Access VPNs. Site-to-site VPN can include variations usually referred to as Extranet VPN and Intranet VPN, which share the same properties but are designed to solve different sets of problems. Remote Access VPN includes dial-up and direct packet access methods, which are also discussed in a main architecture framework. All of these VPN types can be implemented (at least in theory) over mobile wireless networks; however, the discussions involving MVPNs are concentrated mainly around remote access type, since normally a wireless network connects a single remote host to a network it wants to access.

Site-to-Site VPN

Site-to-site VPN is used to connect geographically distributed corporate sites, each with private network addresses administered in such a way that normally conflicts do not arise. In traditional networking, remote corporate offices can be interconnected by partially full meshed networks based on T1 and E1 leased lines or link layer circuits, such as ATM or Frame Relay PVCs inside the service provider's networking "cloud." Another option is to implement it based on private routed network or based on MPLS label switched paths, for instance, a la [RFC2547]. Private routed networks require routers capable of segregating traffic from different intranets, based on multiple routing tables, leading to scalability problems. The resulting infrastructure is called an intranet.


Because of the recent slew of company mergers, acquisitions, office up-and downsizing and the shrinking pool of available IP addresses, a NAT in the future may be more necessary than ever to exchange traffic between intranet or extranet sites.

Similar results can be achieved by provisioning secure IP VPN tunnels over public Internet or service provider IP networks. Here, IP VPN provides significant cost advantages along with greater simplicity. Communication costs are reduced because the customer pays only for the access to the service provider's network IP network or Internet access. Remote offices are connected via tunnels provisioned over a public shared IP network, such as the Internet or a commercial shared IP network offered by service providers like WorldCom or AT&T. Along with public IP network access, VPN implementation requires CPE, in the form of VPN gateways capable of supporting sufficient numbers of individual tunneling sessions at each site.

Site-to-site VPNs are still possible in mobile environments, but the value of such models from a wireless subscriber perspective is still unclear at best and they are outside the scope of this book. It is nevertheless possible for this VPN type to be deployed in the context of wireless core networks such as GPRS PLMN and GRX, when a wireless service provider wants to deploy alternative connectivity to its roaming partners. In addition, a GPRS access point to a corporate network may be considered as a particular instance of a site in a site-to-site VPN. In fact, a service provider may offer full connectivity to all corporate sites and even route packets directly to the most appropriate customer site via IP tunnels that connect them to an access point.

Extranet VPN

Extranet is a relatively recent concept in data networking. It is usually deployed in the situation when a corporation needs to interact not only with its own remote offices but also with the sites, which belong to its customers, suppliers, and other entities it is engaging in transactions or information exchanges with. These are generally referred to as partner networks. To support such communications, VPN tunnels can be established between private networks that belong to different private entities. VPN functions such as access control, authentication, and security services can be used to deny or grant access to resources required to conduct business. Security threats to the extranet—including unauthorized resource access— are greater than in an intranet, so the VPN and extranet environment should be carefully designed with multitiered access control policies and unique security arrangements between extranet members. For instance, a supplier may have access to the customer's order and perhaps inventory system, while the customer may want to be able to track the supplied material by accessing the suppliers' delivery status tracking system.

IP VPN's ability to provision tunnels and access control preferences dynamically within minutes or even seconds and often without the need to notify the access provider (if the permissions to do so were part of the SLA in the case of compulsory VPN) is especially useful in the extranet environment. Dynamic provisioning is crucial for today's business communication where business needs and situations can change quickly, requiring new networking arrangements to be reestablished literally on the fly. This capability addresses networking technologies disadvantages, including relatively long provisioning intervals and complex provisioning procedures. For example, a Frame Relay PVC provisioning typically requires somewhere between 5 and 20 business days to complete. Figure 5.6 shows a major corporation establishing dynamic relationships with its suppliers and other business partners.

Click To expand
Figure 5.6: Dynamic Extranet VPN.

Note that the use of IP VPNs interconnecting partner networks is worthwhile when a sizable amount of information needs to be exchanged between networks. When the interaction between partners can be performed via Web-based applications, the preferred approach is normally to set up TLS- or SSL-protected Web interfaces to applications and information repositories. It is also common today to base business interactions on customers' or suppliers' portals.

Intranet VPN

A corporation may decide to set up a VPN not only to interconnect sites belonging to the corporation but also to define virtual networks within its own administrative domain. Most of the time this is not required, since security zones may be defined by means of properly provisioned firewalling and resource access control policies at the application level. However, in mission-critical environments, it is possible that organizations—especially large ones—may decide to enforce security measures by segregating particularly important traffic and network zones via IPSec-encrypted tunnels and enforce on these network zones additional authentication and access control policies. Companies need to ensure the confidentiality of such data as employee personal records, as well as information about the upcoming events such as product launches and reorganizations. Intranet VPN's main role in the corporate network is to establish and manage different levels of internal access to specific information. In this capacity, the Intranet VPN is yet again used to create an environment similar to physically segmenting groups of users on distinct LAN subnets joined by bridges and routers.

Remote Access VPN

Remote access networking was originally conceived as a way to provide remote hosts with the access to the information resources and data services located in a private network. Remote access is equally useful for both consumers and remote workers or other business and institutional users. Corporations and other entities had to maintain adequate facilities, usually consisting of farms of remote access servers (RASs) and appropriate security equipment, to maintain the proper level of service availability and reliability to remote users. Dial-up connections were considered private and adequate for all intents and purposes (recall our opinion on popular misconceptions about private networks). Wireless dial-up technology, explained in the previous chapters, worked—and still does—very similarly to wireline and presented similar convenience, as well as a similar set of problems.

Dial-up Remote Access VPN

Dial-up remote access is expensive and requires significant support from corporate IT departments. Often, remote users are far away from corporate headquarters or data centers and require long-distance or 800 calling, which can become especially costly for international callers and telecommuters who tend to stay connected for a long time. Corporations relying on this technology were frequently forced to create (or outsource) multiple regional data centers and maintain local support and maintenance personnel to avoid high long-distance charges. Dial-up access also requires expensive RAS equipment, which is complex and far from being trouble-free.

With the rapid buildup of remote access networks—complete with nationwide and even international rollouts of local dial-up points-of-presence (POPs) by service providers—this situation has changed dramatically. Now all the worries about the dial-up procedures could be offloaded into the capable hands of ISPs and other network access providers for whom dial-up or for that matter any type of Internet access was not a burden but a core competency and who already had extensive regional dial-up facilities available. Remote access outsourcing was born, and then it was reincarnated a few years later as Remote Access IP VPN.

Dial-up remote access VPNs can be based on either compulsory or voluntary tunneling methods. In a typical dial-up access outsourcing (compulsory) scenario, the user dials into a local Internet service provider's POP, establishing a PPP link. After the user is authenticated and a PPP link is established, the service provider establishes in a compulsory manner— that is, transparently to the user—a tunnel to a gateway in the private network, the remote user is wishing to gain access to. The private network performs final user authentication and establishes connection. The resulting architecture is depicted in Figure 5.7. In contrast, traditional direct dial-up access involves a user dialing into a bank of modems, a RAS, or a concentrator located within a corporate data center. The tunneling technology of choice for dial-up access outsourcing VPN is L2TP, which is widely accepted by both wireline service providers and corporations. This technology is described in detail in Chapter 2. To offer this VPN option to remote workers, corporations must establish detailed SLAs (for instance, to configure a list of LNSs, security aspects, and QoS levels), with one or more service providers, which will be responsible for local dial-up termination facilities.

Click To expand
Figure 5.7: Landline remote access outsourcing.

The approach resembling wireline dial-up remote access was adopted for 1-G and 2-G circuit data systems to offer Remote Access VPN services to mobile users. IWFs based on familiar RASs were outfitted with tunneling hardware and software, which allowed wireless carriers to avoid costly and cumbersome IWF dial-out procedures (see Chapter 4). After the operator establishes proper SLA with a corporation, the mobile user's data traffic could be compulsory-tunneled to their private networks using L2TP technology in the way already familiar to corporate IT departments experienced in wireline remote access. The operators who had followed the model now had the option of aggregating the user data traffic onto their backbone network, which would allow them to further optimize their data backhauling costs. A good example of such architecture is CommWorks Quick Net Connect based on Total Control IWF, mentioned in Chapter 4.

Voluntary VPN is essentially access technology independent, and it can therefore be easily supported over any dial-up connection, including wireless. All end users have to do is establish a dial-up connection to the ISP of their choice and then via a VPN client establish a secure network layer tunnel to a particular private network. There are ISPs with a global footprint that offer this kind of capability in wireline data networking. Otherwise, consortia of ISPs—like those that are part of iPass or GRIC—may offer global roaming capability. While widespread in the landline networking, this technology has been of limited applicability in the cellular wireless environment. The reason is in the limited data throughput available to the circuit wireless data users. Voluntary VPN relying on an end-to-end tunneling requires extra encapsulation on a last-hop wireless link, further decreasing already-low throughput and making this option suitable for vertical applications but not for a mass deployment. We expect this trend to change, however, with the wider deployment of higher-speed wireless data systems.

Direct Packet Access VPN

During the past decade, new Internet access technologies such as Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), and cable became available to telecommuters and other remote workers who traditionally relied on dial-up access. Both service providers and corporations had a remote access technology option that allowed more efficient use of both compulsory and voluntary VPN for secure private network access. Wireless packet data systems by design are closer to high-speed wireline services such as DSL and cable modem and offer mobile users the same level of convenience, such as automatic always-on capabilities, granular billing options, and banishing of frequent logon procedures. Most of the discussion in the following chapters is devoted to this type of remote access provided within the wireless packet data systems framework.