[VPN] SSL VPN

[Kent Dallas]

>Siddhartha Jain wrote:
>
>Lets examine VPN - Virtual Private Network.
>
>Virtual as in you overlay a private network over a
>public network.
>Private coz the traffic should be authentic and/or
>encrypted.
>Network - A network would be linking more than two
>hosts? Moreover, it should provide a host connectivity
>to whoever joins the network.
>
>Now looks at SSL *VPN*.
>
>Is it virtual?? Nope, you just use the public network
>(internet) to create a secure session.
>
>Yes, its private coz it provides for authentication
>and encryption.
>
>Network - Now thats my biggest grouse over calling SSL
>a VPN. Unlike a IPSec or any other network-layer based
>VPN which provides a single host or multiple hosts
>access to a whole network behind a VPN device, does
>the SSL VPN provide the same functionailty?
>
>I think SSL VPN is just a marketing gimmick, nothing
>more. Having said that, I would also like to admit
>that lots of places I sold a regular VPN device
>could've done by deploying plain simple SSL. But the
>current marketing frenzy fed the customers with IPSec
>VPN. (Sigh)
>
>Siddhartha

Personally, I have always been a bit irritated by such pedantic definitions
of VPN.  I do not acknowledge any industry standard definition of VPN, and
grant everyone their opinions (as I hope they will grant mine).  I note that
our gracious host and moderator's definition (on the homepage) is quite
liberal.

First, in terms of "virtual", I would be more willing to accept the
definition as meaning "not physical".  The implication is that it is built
across a shared network (perhaps public), but the  referenced network isn't
"hardwired" on the underlying physical network.

In Siddhartha's evaluation of SSL's fit for "virtual", the criteria of
"session" seems limited to where it is in the stack, versus the fact that it
is setup and torn down as necessary, much like many IPsec applications and
implementations (which appear just as "virtual" to me).

Second, privacy should not be defined as authentication (user, host, data,
or packet) or encryption.  As a simple refutation, a physical network can be
private without either authentication or encryption.  Encryption is simply a
common tool to deliver privacy across a shared network.  Authentication is
another security concept altogether, but can also use cryptography as a tool
to achieve it (but in and of itself, is different than privacy).

Third, a network need not be more than the ability to connect two hosts.

As you may observe, I am willing to allow SSL to fall within my technical
definition of VPN.  However, by no means do I equate IPsec with SSL.  The
significant technical differences have been discussed sufficiently well here
on the list recently.

When I talk about VPN with clients, I avoid any technical definitions.  To
understand why, let me excerpt from a document I wrote a few years back, but
is still relevent:

***EXCERPT***
Many in the industry attempt to define a Virtual Private Network based on
the technology that delivers their particular solution.  But such a method
of developing the definition often fails to address the underlying reason
such a solution may be used – to solve a business problem.  VPNs only exist
to solve such problems, so a proper development of a definition should start
with an understanding of the business problems they address.

The term "Virtual Private Network" and the acronym VPN have been around
since the mid-80s, and was first used by the Sprint Corporation.  However,
Sprint's use refers to their service of providing feature-rich
multi-location circuit switched voice and data services to large corporate
enterprises.  Further, many other public data network technologies could
fall under the description of a VPN.  Services based on protocols such as
X.25, Frame Relay, and Asynchronous Transfer Mode (ATM) all could be
considered VPN services.

For the purposes of this document, the acronym VPN will refer to transport
of digital data across a shared or public network infrastructure, in a
manner that provides characteristics of a private network (security,
performance, and control) but at a lower cost.

[portions omitted related to IP versus Frame Relay and ATM, limiting further
reference of VPN's to those using IP at the network layer]

In the final analysis, corporate enterprises considering VPN solutions only
do so for one reason – to solve a business problem.  Yet any business
problem solved with a VPN could be solved with a truly private network
solution.  The choice to use a VPN ultimately comes down to the VPN solution
yielding the most cost-effective solution to a particular business
problem(s).  Although there may be many business problems that a VPN could
address, the vast majority of customer applications fall into three broad
categories – secure remote access; secure site to site communication
(internal to the enterprise), and secure business to business communication
(external to the enterprise).
***END OF EXCERPT***

I later define "secure remote access" as connecting a trusted user to a
protected application, host, or (IP) network; and secure site-to-site as
connecting a trusted host or (IP) network to another trusted host or (IP)
network. I won't go into my definition of secure business-to-business VPN
here, as it gets even more complicated.

While I agree that the definition of VPN gets narrowed or widened by vendors
for marketing reasons, such artificial limits aren't in the customer's
interests, per se, and only serve to cloud the business issues (as
Siddhartha seems to admit).

Regards,
Kent Dallas