IP VPNs: the present, the priorities and the promise: harness virtual nets for real profit
Tom Nolle
Through telecom times, the business applications of virtual services have been challenging to understand and harness. These same challenges apply to today’s most prevalent virtual network offering–IP VPNs.
A VPN Taxonomy
To understand the present and future, you must first grasp relevant history.
VPNs in today’s sense really had their roots in ATM and frame relay. Both these earlier network technologies let users build virtual circuits which were point-to-point paths that sort of behaved like leased lines but were actually sharing carrier trunks and switches. These services are consumed today in quantities of tens of billions of dollars worldwide and are generally profitable to carriers and useful to enterprises.
[ILLUSTRATION OMITTED]
When the Internet exploded onto the scene, it could offer the same sort of network-sharing as frame and ATM through a mechanism called tunneling. Two endpoints on the Internet could use one of many protocols (e.g., L2TP, PPTP, IPsec, SSL) to create a “tunnel” between them. Packets flowing inside this tunnel would not be examined by the network and therefore were “private” paths. If encryption were employed, they were truly private. This was the foundation of the IP VPN.
What made IP VPNs different from earlier VPNs was that the Internet was a generally permissive, open network, and users could establish VPNs over it without the involvement of service providers.
Passive VPNs
This kind of VPN, variously called an overlay or passive VPN, was attractive to users particularly because it was available at zero incremental monthly cost vs. Internet access, and because it could be set up extemporaneously from any point on the globe where the Internet was available. But these passive tunnel VPNs had two significant problems: They didn’t go far enough in eliminating user costs, and they didn’t provide QoS.
Tunnel VPNs are like virtual circuits or wires: They’re point-to-point or Level 2 services. IP networks, now almost universal in enterprises, require Level 3 or routing features.
To add these to passive VPNs, enterprises had to terminate their tunnels in their own routers, creating what one user jokingly described as a “half-virtual private network,” because the Level 3 part still had to be purchased and supported by the network’s user.
A standard for both Level 2 and Level 3 VPNs clearly was needed, and the IETF provided it in RFC 2547. However, 2547 collided with another problem of VPNs, which was pricing.
To create Level 3 VPNs, carrier routers must take on the burden of routing VPN packets using a virtual router function. To do this, carriers must actively support the VPN process with equipment and dollars–for which they expect dollars in return. Level 3 VPNs are active in the sense that the carrier plays an active role and must therefore agree to play that role, which means the zero-cost option of tunneling isn’t available.
Many large enterprises already have private networks and routers, so they can use tunnel VPNs with little incremental cost or difficulty. Even the largest enterprises, though, need some assurance of service performance, and tunnel VPNs can fall short there as well.
VPNs and Service Quality
Paying turns out to be an issue even in Level 2 tunnel VPNs, because another problem is that VPNs inherit whatever service quality problems the Internet has. If applications demand high availability, short delays and minimal packet loss, then there’s a good chance they won’t work dependably over the Internet and passive tunnels.
The problem is that IP is connectionless, which means there is no persistent end-to-end relationship set up in the network against which the network reserves resources and makes guarantees of performance. Packets just show up at routers and on trunks and compete for capacity. On average, good design can make performance steady over a long period, but it is very difficult to make it as dependable as frame relay or ATM, even over intervals of a few seconds.
There are plenty of mechanisms that can provide QoS over IP networks, including recognized standards such as DiffServ and MPLS. All of these work by offering priority to some traffic, and that priority means the user will have to expect to pay more. In theory, these QoS strategies could be combined with RFC 2547 to create VPNs that offer good QoS. In practice, they are used increasingly on converged carrier backbones of common carriers but not on the Internet.
The reason is again economics. Internet peering, unlike common carrier interconnect, doesn’t have things like settlement and admission control. If Carrier A gets $10 thousand a month for an Internet VPN, then passes part or all of its traffic (and responsibility) to other carriers, those carriers expect to get part of the money, and this kind of inter-carrier sharing isn’t a feature of the Internet today. So Level 3 active VPNs with dependable QoS have developed in single-carrier environments much like frame relay and ATM have, with only spotty interconnection between carriers to increase the geographic scope.
VPNs created by tunneling over the Internet are also vulnerable to congestion-based performance problems because VPN traffic can collide with Internet traffic either inside the Internet or on the customer access line. Worse yet, the underlying Internet address to which each VPN tunnel is connected can be subject to a denial-of-service attack, potentially shutting off communications completely.
Fixing VPN QoS problems has taken providers in several directions. MPLS can be used to create QoS within an IP network by creating traffic-managed routes or paths for the VPNs to follow. It is also possible to partition the IP network providing VPN service from the Internet (see chart), so VPN and Internet traffic are “ships in the night,” passing without interference. Both solutions can add considerably to the QoS of VPNs, but also to the cost.
Business Use of VPNs
For the enterprise, the evolution of VPNs is opening new business choices and new issues, primarily in the security and connection areas. For both new VPN users and existing users, the options could create change and confusion.
Security is the big issue for most VPNs today. Passive tunnel VPNs over the Internet must pass through corporate firewalls, and their traffic isn’t secure unless it’s encrypted. Both these factors have moved users toward IPsec and SSL VPNs because they offer encryption, and SSL VPNs are taken most easily through firewalls. But companies are also finding that having the Internet available at all their sites raises the risk that users might connect to an unauthorized VPN, possibly creating a path for theft of company information and/or the introduction of viruses, Trojans, etc.
The active, partitioned VPNs now emerging are as secure as frame relay or ATM in some cases. The exact mechanism the provider uses to implement them, however, may not be advertised, and users may have a problem assessing the level of risk. Does a VPN that has access separate from the Internet need a firewall? If the VPN is separate from the Internet truly and completely, it doesn’t need firewalls or encryption any more than frame relay does. But is your active VPN really separate from the Internet?
Interestingly, carrier convergence on IP may be making your frame relay service into an IP VPN whether you know it or not. As carriers migrate to IP infrastructure they are planning a transition from frame relay and ATM to an IP-based standard such as Martini or pseudowire tunnels. Depending on how these are created by the carrier, they may be as secure and capable of assuring QoS as the original services were, or they may be as risky and QoS-less as the Internet.
What this points out is that VPN awareness is something that enterprises will need to know, and providers will need to communicate. The simple truth is that most enterprise traffic will be carried on VPNs by the end of the decade, whether the user chooses this or the provider converges into it. Only by understanding VPNs and their implications can either provider or consumer be sure the changeover will be successful for all.
Tom Nolle is founder and president of CIMI Corp. (tnolle@cimicorp.com)
COPYRIGHT 2005 Horizon House Publications, Inc.
COPYRIGHT 2005 Gale Group
