WAN Services /

Will the real VPN please stand up?

By Kevin Tolly
Network World, 02/04/02

Acronyms are the bane of our IT existence. They've been produced in such volume that, even within the networked world we've ended up with duplicates with different spell-outs: for example, NCP referring to IBM's Network Control Program and Novell's NetWare Core Protocol. But now network vendors have upped the ante by giving us VPN and VPN. What makes this different is that, in both cases, the acronym stands for virtual private network, but the references can have completely different meanings.

That was the case during our recent Network World/The Tolly Group State of the LAN/MAN tour. During the course of our roundtable discussion, we had vendor speakers proclaiming the benefits of VPNs and meaning different things - and both were correct.

The problem is that VPN is a generic term, but one that has, over the years, acquired a fairly specific meaning - at least by those in the network security arena. Now leading-edge Multi-protocol Label Switching (MPLS) technology is delivering a capability that, though radically different, can legitimately be termed VPN as well.

So when we hear the term VPN bandied about, we need to know the implied modifier - is the reference to an IP Security VPN or an MPLS VPN? Time to understand the difference.

In its most generic sense, VPN implies technology that brings attributes of a private, leased-line network to data flows that are actually running across a public or quasi-public IP packet network. Two of the most important attributes are privacy and predictability.

Early on, security vendors devised a number of encapsulation/encryption approaches in an effort to deliver on the promise of privacy. The Layer 2 Tunneling Protocol and the Point-to-Point Tunneling Protocol were early efforts promoted by the likes of Cisco and Microsoft.

Ultimately, and thankfully, the industry converged on the vendor-independent IPSec standard for secure tunneling. IPSec provides for authentication between endpoints and then coordinates the flow of encrypted traffic between them.

Because any third party seeing your traffic would see only the encrypted jumble, IPSec lets you have the security of a private network while enjoying the flexibility, robustness and economic benefits of using a shared network.

Paradoxically, an IPSec tunnel is not a tunnel at all - not, at least, in the "fixed" sense of having all traffic belonging to a particular session following the same set of router hops across the network. And that is where MPLS comes in.

The data paths on private networks are fixed. This is one of the great benefits of a circuit-based approach and one that, until recently, has been beyond the realm of possibility with packet networks.

Without such predictability, service providers can't easily deliver on service-level agreements, and end-user network architects cannot feel comfortable running important, latency-sensitive applications across public packet networks.

MPLS solves that problem. By tagging traffic as it enters the edge of a WAN, MPLS-enabled switch/routers can make certain that particular flows traverse particular paths across a backbone network. The best part of this is that MPLS tagging can be generated on ingress to the network and stripped at the egress point without having to involve applications at all.

But MPLS does not encrypt your traffic. What, then, if someone wants the predictability of MPLS with the security of an encrypted IPSec flow? Because neither interferes with the other, it is possible and reasonable to run an IPSec VPN on top of an MPLS VPN. What more could you want?