For the past several months I have been inundated with press releases from countless vendors claiming they are in the virtual private network (VPN) business. I've been deluged with articles in the industry press on the importance of VPNs for business success and electronic commerce. I've seen Net rant after Net rant as to why "my VPN is better than your VPN".
And after studying up on VPNs and speaking to a slew of knowledgeable friends in the field, academics and more VPN vendors than I ever knew existed, I have come to the following conclusion: no one has the slightest clue what a VPN really is.
That is, except me.
If you believe the Internet Engineering Task Force and many vendors of related products, a VPN is loosely defined as: "Tunnelling, or establishing encrypted channels over IP networks." I'm sure that means a great deal to the fearless corporate leaders who still have trouble turning on their PCs.
When clients ask me to help them implement VPNs, I ask them: "What are you trying to achieve?" It turns out they have little idea what they really want to do -- which is not surprising given our current concepts of VPNs are about as naive as thinking you can run Windows NT on a 386 with 8MB of RAM.
Remember that the key word in VPN is virtual, meaning the individual packets can take any route to get from point A to point B. The encrypted secure channel is not a fixed pipe, as vendor diagrams would have you believe, but a dynamic, constantly shifting encrypted communications path that may move from your home laptop through Timbuktu to get to your headquarters.
That said, here are some of the things you were never told about VPNs.
VPN architectures are much more powerful than users are being led to believe. Classic VPN network diagrams show "secure" paths from one enterprise's server to a server at another physical location, with the Internet cloud fogging things up in the middle.
Conceptually, this "connectionless connection" replaces dedicated X.25 or leased lines between remote offices and corporate divisions or from data centre to data centre. If this is all you need, fine, but the true VPN technology can do so much more in varying real-world uses.
One popular application is to use a remote client Web browser to communicate with a host server and thereby extract information from a database, conduct commerce or send e-mail in privacy. Using the IP Security concept of tunnelling over IP as the only way to achieve a VPN, we again find a limited architecture. The non-IP intranet, dial-up users and other non-IP connections will not be able to access the VPN.
Most VPNs are of the server-to-server type and protect only an organisation's perimeter from the ravages of the Internet. This provides point-to-point security but not end-to-end security all the way to the intranet desktop.
VPN designers are only beginning to investigate expanding the VPN security model to the interior of the sites' networks, through the intranets to the desktop. This capability will provide protection throughout the organisation and will function using higher levels of the Open Systems Interconnection (OSI) stack than the network or transport layer.
A VPN, as designed today, is a single-level security system. That means everyone with access to VPN resources has the same security classification. I find it odd that VPN designers don't use cryptographic mechanisms to provide data separation based on user identity -- that is, give different users access to different sets of data.
In banking applications, for example, your average customer might not be given as much access to resources and information as elite private banking customers who might receive this perk due to their larger account balances. VPNs should address this user and data separation issue with a single security control rather than forcing you to build additional access control table mechanisms that require multiple levels of administration.
My kind of VPN would let me talk to the host server organisation and to other VPN users privately, whether they be within the boundaries of the host site or sitting at a laptop on a ship. Current VPN architectures are remnants from legacy systems: we can talk to the mother ship but not to one another.
A VPN is supposed to make your clients' businesses more competitive, more secure and easier to use. It is not supposed to be technology for technology's sake. Develop your clients' needs first, model the information flow and process that you would like to see, project what you think you'll need in a couple of years from a secure communications standpoint, and use that as your starting point.
The VPN business is too new to be locked into a short-term solution.