[c-nsp] What does SSL VPN Devices offer?

[Tim Franklin]

> #1 - Simply replace an existing IPSec solution.  This is 
> typically driven by
> the issues mentioned by another poster with getting access 
> out of their
> party networks, and the growing occurrence of carriers (and especially
> hotels, etc) to block everything except 53,80, and 443.  If 
> this is the path
> you want, then many of the SSL VPN products (ours included) 
> give you the
> ability to load a network adapter (or something similar) on the remote
> device and you get access very similar to IPSec. In this 
> case, you would
> most definitely want to limit access to trusted devices.

For me at least, this is a *big* driver.  While I'd much rather see ISPs
(and hotels, and cafes, and...) claiming to provide Internet access actually
provide *Internet* access, in the real world we have to work around these
mis-labelled access services.

> #2 - Deploy an access management system which gives you the ability to
> securely permit access into your network by employees, contractors,
> partners, customers, etc, etc. In this case, the 
> functionality of the device
> in the area of access control granularity would be a major 
> feature.  This
> extends to the ability to take a footprint of the remote device.  You
> obviously would want to limit network based connectivity from 
> third parties
> into your network, and totally network level access from 
> untrusted entities,
> such as kiosks.  So you need the ability to scan the remote device and
> authenticate the user so that you grant them the appropriate level of
> access.  For example.

[example snipped]

This isn't inherent to SSL though, is it?  It's merely a feature of next-gen
VPN access devices (and for the footprinting stuff, clients) to provide more
granular access controls than a full-blown route-everything tunnel into the
network, or not.  You *could* do exactly the same things with IPSec, if you
had an IPSec client and central terminator that supported all the necessary
features.

I'll grant that doing the web-application and network access control from
the same place is also useful, but again, there's no particular reason why
you couldn't have the same user database / admin front-end for an IPSec
tunnel terminator and https proxy rolled into one appliance in the same way.

> Many of the solutions on the market provide these types of 
> features (or
> course I feel ours is strongest), but SSL does deserve a 
> proper examination
> by any company or person based upon their needs and requirements.

Agreed.  And one of the questions people might want to be asking vendors is
why these rich access-control possibilities that are in the SSL gateway
devices aren't implemented in their existing IPSec gateway devices.

SSL VPN is certainly *a* solution, and for some cases it's undoubtedly the
*right* solution.  But I think people should be wary, especially of jumping
ship from an existing, working, IPSec solution based on some of the hype,
particularly the "client-less" hype.

Regards,
Tim.

-- 
____________   Tim Franklin                 e: tim at colt.net 
\C/\O/\L/\T/   Product Engineering Manager  w: www.colt.net 
 V  V  V  V    Managed Data Services        t: +44 20 7863 5714 
Data | Voice | Managed Services             f: +44 20 7863 5876