Thoughts On IPSEC versus SSL VPNs: Evaluation Criteria and Architecture
Joel Snyder/Opus One

It is clear that VPNs mean (or they should mean) more than “Layer 3 IP-based IPsec.”  As networks extend within and between corporations, different technologies can be brought into play which solve the problem of securely extending network boundaries.  The best way to think of this is as a 2-dimensional space.  Across one axis is the “locality” of the problem: one department (“very local”), one division, one region, one company, two sister companies, a joint venture, a consortium, or, at the far end of the spectrum, hundreds or thousands of trading partners (“very distant”).  Across the other axis is the “specificity” of the problem: are we talking individual users (“very specific”), encrypting end-to-end?  Or is this a series of SOHO gateways?  Or enormous sites connected (“very broad”) together?  

My point in describing this 2-space is to identify specific areas where IPsec VPNs are generally unsatisfactory and where SSL VPNs are especially appropriate.  By identifying the problem we are trying to solve, we can then identify the key components of SSL VPNs.  The issue is that many non-IPsec VPN vendors are just not really sure what market they are trying to approach and what problem they want to solve.  While it is always possible to jam a technology where it does not fit, the greatest leverage and benefit comes when matching problem to solution.

In the 2-space I described, IPsec fails miserably at one end of the graph: very distant, and very specific.  For example, consider a bank which wishes to make private account information available to its customer base over the Internet.  Or, consider a sales order tool where the salesman has little or no control over what access to the network he will have from call to call.  IPsec would be untenable in these situations.  IPsec does poorly here for a variety of reasons: the burden of policy management.  The difficulty of interoperability.  Clumsiness of clients.   All these, and more, suggest that alternate VPN technologies might solve these problems better.  

Actually, IPsec fails in multiple places in this 2-space, which is why the MPLS people keep popping up, as well as the L2TP folks.  But for the sake of keeping the argument focused, let’s only look at the places where SSL excels and IPsec doesn’t.   If you want the whole picture on these technologies, draw out that graph yourself and the map will be fairly obvious. 

How, then, do we define the base requirements for a VPN technology, such as SSL-based VPNs, to compete with IPsec?  We must identify the crucial features which are needed for SSL to meet the minimum level set by IPsec.  Then, we must identify the areas where SSL must go beyond IPsec to solve the problem of distant locations, but user-by-user (specific) connections.

Before we go into requirements for SSL VPNs, it’s probably worth spending a little time defining “what is an SSL VPN?”  I don’t’ think that there’s going to be a huge controversy over products which fit into this category, but I think that there are some strong characteristics about SSL VPNs which make them different from Ipsec VPNs.  

A working definition of an SSL VPN is: “An SSL VPN uses SSL and proxies to provide authorized and secure access for end-users to HTTP, client/server, and file sharing resource.” This implies that an SSL VPN has several defining characteristics.  Without these six characteristics, a product might offer useful functionality to some set of enterprises, but is not going to be relevant to this document.  

1)	Proxy access and protocol conversion: All SSL VPN products end up doing some kind of protocol conversion, if not on every data stream, at least on many data streams.  For example, the widest application for SSL VPNs is going to be end users connection to the SSL VPN security gateway with HTTPS protocol, and the security gateway proxying access to resources it protects, such as http servers, SMB/FTP/NFS file servers, and even POP/IMAP mail servers.  Thus, the SSL gateway both proxies access (the server sees a TCP/UDP connection to the security gateway, not to the end user) and provides protocol conversion (such as between FTP and HTTPS).  The most trivial type of SSL VPN, an HTTPS to http (or even to HTTPS) conversion does fit into this definition, it probably represents the border case in defining SSL VPN technology.  
2)	Client-less access: At the very least, SSL VPNs must include client-less access (specifically, browser-based access), hopefully requiring neither Java nor Javascript for proper execution.  Some vendors will want to extend their products to offer additional capabilities, such as port forwarding, either through an in-browser client (such as a Java application) or a separately downloadable client tool, but the core competence of the product must include client-less access. 
3)	Remote-access orientation: Although one could conceive of a site-to-site VPN over SSL protocol, this is not a natural use for this technology.  SSL VPNs are designed for remote-access environments, end-user connecting to a corporate LAN and its resources.  This implies more than “no site-to-site;” it also suggests that SSL VPNs need to be designed with simplicity and ease-of-use as primary architectural concerns.  This ranges across the entire end-user experience, from the log-on screen and resource portal to broad-based browser and platform compatibility. 
4)	Extranet support: SSL VPN products will likely be used in environments where the end-user has only a casual connection to the resources being protected, such as the oft-quoted “extranet environment.”  This implies specific requirements on the proxies, including data stream modification (such as removal of internal DNS names and IP addresses). 
5)	Highly granular access control: SSL VPNs should have a very granular and specific access control, especially when compared to most IPsec designs.  The full range of AAA (authentication, authorization, accounting) management controls should be available to the network manager.   SSL VPNs should offer very precise control over who has access to which resources, when.  
6)	SSL Transport: As vendors change SSL VPNs to include client applications (much as IPsec VPNs use a client application), it would be possible to use other protocolsl than SSL for data transport.  I do not regard this as a step in the right direction, since both the security characteristics and management control of the SSL protocol is well-known to security and network managers, and throwing other protocols into the mix begins to change the entire product category.

The following list of items represents the basic requirements for an SSL-based VPN product which will solve the problems which IPsec cannot.  These form the evaluation criteria when selecting SSL-based VPN products.

1)	Authentication Options 

One of the absolutely critical features for any VPN product is the ability to authenticate users with a wide variety of technologies.  Enterprises have never agreed on authentication technologies and the market is filled with commonly used alternatives.  Any SSL-based product should support user authentication using:

a)	Simple username/password from local database

b)	Simple username/password from a RADIUS server (TACACS+ is nice too)
c)	Simple username/password from a Windows domain (could be done via RADIUS, but there are issues with the elegance of this solution when it comes to group attributes and authorization)
d)	SecurID, either directly to an ACE server or via RADIUS, but absolutely with support of “new PIN” and “next value” mode, in any case.
e)	Other one-time password technologies such as challenge/response and S/Key
f)	Digital certificates

Because SSL-based VPN products are also web products, they will need to integrate into other enterprise web applications.  We’ll look at this more specifically later, but this implies that the ability to accept single-sign-on or other authentication information from trusted sources, such as web access control portals, is also desirable.  

2)	Fine-grained Access Control & Firewall

Central to the idea of any VPN is control over access.  VPNs are not just about encrypting data between two sites; that’s a side-effect of the real goal, which is controlling access: giving access to specific resources to properly authenticated users, while restricting access to everyone else.  SSL VPNs have even higher requirements for access control than IPsec VPNs, because they will often be used in Extranet environments where trading partners are not fully trusted.  However, the need for fine-grained control is not restricted to extranets; it includes access controls for employees which extend beyond “this employee has access to that resource,” but “this employee has access from a particular desktop or laptop, when certain integrity controls are met.”  It’s not a question of trusting the employee, but also trusting the environment the employee is in at the moment they want access.  Thus, SSL-based products should have access control in several areas, including:

a)	Source IP and Destination IP; Destination DNS
b)	Destination port 
c)	Time-of-day; day of week; limits on date
d)	User name
e)	User group attributes  (e.g., OU information from a DN on a certificate or Windows Groups from the Windows SAM)
f)	User identifiers held (e.g., “User can dialup” bit in Windows SAM or Service-Type=Administrative via RADIUS)
g)	Application layer information (e.g., http GET versus PUT; URL data)
h)	Status of client integrity check
i)	Authentication method
j)	Client platform (i.e., Java-enabled; cookie-enabled)
k)	Strength of encryption, MAC, key creation (D-H or not)

Access control at higher levels, such as http URL filtering, is one area where the SSL product begins to cross product space and become a more general SSL proxy or front-end to web servers.  This is a perfectly fine product niche, with a number of excellent alternatives (Netegrity, Tivoli, Novell, etc.), but it’s important to be careful in product design and to understand where the real focus of an SSL VPN device is.  There are lots of ways to get distracted going down this path.

Access control must be accompanied by a stronger security model than traditional packet filters.  The nature of an SSL VPN will probably inherently include firewall-like controls (stateful packet filtering; application-layer proxying), but the designer must be sure to include protocol enforcement and validation in all aspects of the system.

Although I believe that group and user information will need to come out of the authentication service (making it partially an authorization service), it is possible that some network managers will want to retrieve actual access control information from the authentication database (such as LDAP or RADIU) as well.  This is probably a fringe case, but is certainly one that should be considered in the architecture.  

3)	Centralized Management

Enterprises rarely have one of anything; they keep backups and redundant systems and do load sharing and hot spares and service multiple data centers in multiple locations.  While element management (controlling each device as a separate security domain) is marginally acceptable in smaller installations, enterprises will insist on centralized management to keep costs and control within acceptable boundaries.  

Note that nowhere in this list of requirements is high-availability.  We assume that other high-availability technologies are better able to handle the load of SSL VPNs, largely because of differing enterprise requirements (multi-site, multi-LAN, multi-provider) and because systemic high-availability generally requires additional tools, such as dynamic routing and multiple providers/data centers, which are out of the scope of the SSL product itself.  However, centralized management is one of the key enablers which allows for easy integration of SSL VPNs into high-availability configurations.  (On the other hand, having built-in high availability features is a benefit, even if it is not a requirement)

The required parameters of centralized management are difficult to state, but it is easy to list a series of “nice-to-haves:”

a)	No requirement for a central management server; management service built into one or more devices
b)	No requirement for a specific management client; use web browser to manage the system
c)	Ability for multiple users to manage simultaneously
d)	Delegated management (e.g., allow some users to manage subsets of the entire network, such as who has access to a particular department’s web servers)
e)	Partitioned management (e.g., allow some users to manage only certain functions, such as generate reports or view device status)
f)	Real-time management information (e.g., “who is logged on now?” or “what is the system load?”) along with real-time control (e.g., “log that person off now”)

Most enterprises will have one or more network management consoles, ranging from full-fledged Tivoli or HP OpenView implementations across to WhatsUp management tools.  It is unlikely that full management will be available from any of these external sources, but some provision for status information export via SNMP counters and SNMP traps from each device must be possible.  This is non-centralized management: it should come from each device individually.  Note that sending these traps and data may create a requirement for an IPsec tunnel-mode tunnel!

4)	Auditing, logging, and accounting

A well-thought-out strategy for auditing, logging, and accounting is important for long-term usefulness of any security product.  This is one area where the diversity of implementation among existing products is particularly astonishing.  At a minimum, an SSL VPN product should have the following:

a)	Auditing : every successful or unsuccessful user login and access needs to be audited via some logging mechanism; every management action needs to be audited; every system startup and shutdown needs to be audited.
b)	Accounting: summary statistics on user sessions need to be aggregated and held via either logging or RADIUS accounting.  This would include values such as time connected, data transferred in/out, and other relevant counters .
c)	Logging: the recording of audit and accounting information needs to be managed in a versatile manner.  Audit and log information need to be stored locally within some ring buffer, with flexible control if the buffer fills (e.g., overwrite, system halt, email or FTP outbound).  Local buffers need to be retrievable from remote systems via common mechanisms, such as TFTP or FTP.  SYSLOG and/or SNMP need to be available as options for real-time logging and health-check information. 

Because one of the goals of SSL VPN products is authentication of end users, some sort of breakin detection and evasion is important.  If the SSL VPN sits on a non-dedicated hardware platform (such as Windows or Unix), additional logging and breakin/intrusion subsystems may need to be added.  This could be as simple as Tripwire or as complex as a full-fledged host intrusion detection system.  However, if you think you need a full HIDS, you probably have done something wrong in designing the architecture of your product.

In general, IPSEC VPNs which have a minimum of persistent storage (FLASH rather than hard drives) have done better in the marketplace because they create greater trust among network managers, both at the operating system hardening level and at the product reliability level. It is not a requirement that the SSL VPN device have no moving parts (even fans!), but it is certainly highly desirable.

Reporting will normally be handled via existing tools, such as HTTP usage logs (WWW/URL reporting and analysis using tools such as WebTrends) and RADIUS accounting (usage reporting and traditional accounting).  An SSL VPN product should be able to generate relevant logs in both formats to facilitate integration into existing production reporting systems.   That is, session information should be sent to RADIUS-style accounting databases, while individual URL information should go to HTTP usage logging in the normal industry-standard formats.  

Internal reporting tools which generate reports, summaries, and trends are nice as well, but it is critical to be able to export data.  These tend to make better demo-ware than useful tools.  Real-time (as events occur) and batch-mode data export (on demand or periodically) are both going to be interesting to enterprise network managers.  Products which support all three (RT, batch-timed, batch-on-demand) would meet the needs of more enterprises.

5)	Wide-range of client systems, both operating system and browser

One of the goals of an SSL VPN is to go where IPsec VPNs cannot.  As a general rule, IPsec clients are particularly snippy about operating systems and even version information.  SSL VPNs cannot be, because they must extend to a wide variety of environments.  Any SSL VPN must accommodate the following:

a)	Common enterprise and hobbyist browsers 
b)	Platforms ranging from laptops and desktop systems to PDAs, cell phones, and unusual browser platforms (e.g., WebTV, kiosks, embedded systems)
c)	Lack of Javascript capability
d)	Lack of Java applet capability
e)	Smaller screen sizes
f)	Non-English environments
g)	Handicapped users without access to pointing devices
h)	Low bandwidth users and locations
i)	No problem working through NAT and NAPT environments

In many cases, the underlying application will not be so forgiving, but it should be the application which is the gating function, not the SSL VPN gateway in front of it. 

Obviously, some non-http applications will require additional client capabilities (such as Java for a terminal emulator or port forwarder), but the needs of particular applications should not be used as excuses to constrain the entire product.  For example, it is not reasonable to say that “we will need Javascript for Feature X, ergo we will assume that Javascript is a given,” even if Feature X is central to many uses of the product.

6)	Support for protocols beyond http

SSL-based VPNs will operate most naturally against http and https servers, since the client used is a web browser.  However, the ability to push other protocols through an SSL connection and to gateway other applications will differentiate these products from one another.  There is probably no minimum requirement, but a list of desirable attributes would include:

a)	Gateway of internal http or HTTPS resources
b)	Gateway of internal FTP, SMB, and NFS servers, appearing as http resources
c)	Gateway of mail servers, using their natural protocols if possible, but also possibly through port forwarding or even application layer gateway.  Protocols here would include SMTP, IMAP, and POP, as well as the Exchange and Notes
d)	Gateway of legacy applications, specifically TELNET to VT100 and 3270 data streams
e)	Gateway of arbitrary data streams through port forwarding

At some point, a client-side application would be required (particularly where any kind of port forwarding is called for), but this should be minimized and only used where absolutely required.    In any environment where a client-side application is used, it should be as platform independent as possible.  In cases such as the TELNET application, the ability to write a platform-independent terminal emulator which doesn’t suck should be balanced against the difficulty of adding port forwarding to the system.

7)	Client Integrity Checking

Because SSL VPNs will be used in environments such as kiosks and public access areas, some ability to check the integrity of the client is important.  This can be used as an authorization attribute (e.g., you can read data if you don’t have virus scanning turned on, but you cannot write data).  While the range of integrity checking is very wide, some of the simple functions would include:

a)	Is a personal firewall running? 
b)	What policy version is installed in the firewall?  What is the software version?
c)	Is a virus scanner running? 
d)	What policy version is installed in the virus scanner?  What is the software version?
e)	Is in-memory virus scanning enabled?
f)	When was the last time a full disk scan was executed?
g)	Has a particular integrity application (presumably corporate-supplied) been installed?
h)	What are the results of running this custom integrity application?
i)	What version and policy (of the integrity application) are installed?

The SSL product should also be able to talk to centralized firewall policy servers so that questions such as “what is the current policy version” are taken in real-time from the policy server rather than requiring the network manager to constantly update the SSL product.

Some vendors have suggested that HTTPS access eliminates the need for a personal firewall on end-user systems.  Obviously, this is wrong.  Whatever rationale was used for requiring personal firewalls before implementation of an SSL VPN is just as valid after an SSL VPN is in place, so there is no change in security posture assessment requirements brought about by installation of an SSL-based VPN.  

A second aspect of integrity checking is ensuring that sensitive data are not left on the client system.  This means that the SSL VPN must provide some tool which lets the end user clear out cookies, cache data, saved password, URL completion, and any other information which might be re-used by the next person to touch the client.  Or, this should be done automatically by the SSL VPN device.  Similarly, some mechanism to restrict the ability to write to the local hard drive from the browser might well be included (where technically possible) to keep files from being downloaded and left on disk.  Digital rights management technology might be used to help in this area.

8)	High performance and Highly transparent

In the category of “God and Mother” attributes, performance and transparency are given more lip service than attention.  Nevertheless, the question of system performance will always dog SSL-based VPNs because of the high rate of security session creation, user authentication, and authorization lookups.  SSL systems will be even more pressed than traditional IPsec systems, because of the high stress which an application-layer proxy and SSL itself puts on the system.  

It is difficult to put a requirement on performance, except to say that any SSL VPN device needs to have some audited performance statistics that will help the network manager predict correct device behavior in a variety of environments.  

Another desirable, yet unmeasurable, metric is transparency.  While end users will be aware of an authentication step, they won’t necessarily need to know what is happening when they are connected through the SSL VPN tool.  This implies that careful thinking should go into configurations which allow the user to be both inside and outside the SSL VPN device without changing settings on their local system, and to handling the server-side authentication of SSL sessions.  

Other issues of transparency include the proper application-layer proxying of http traffic, such as internally embedded URLs (and other content) with IP addresses, DNS information, ActiveX, Java byte code, Javascript, and other data which may have different semantics and access control rules depending on whether the user is inside or outside the SSL VPN device.   In this context, the word “proper” has two meanings: one is that the proxying enables proper operation of applications so that nothing is broken, and the other is that the proxying is secure and does not expose internal information (such as IP addresses, DNS information, and even possibly URLs) to external users.  Obviously, this could be fairly difficult to configure and control. 

9)	Control of Security Parameters

Generally, SSL application users have not been overly concerned with the actual security parameters of their connection.  While this may be reasonable for the very short-lived connections and fairly sloppy security requirements of a web form, it doesn’t suffice for corporate access.  Any SSL-based product should have granular control of the SSL parameters used, including:

a)	Ability to require a certain level of encryption (key length and algorithm)
b)	Ability to require presence of a message authentication algorithm
c)	Ability to require Diffie-Hellman (or other two-party) key generation for session keys
d)	Ability to limit lifetime of a connection in time and octets

10)	Very Large Enterprise (and Service Provider) Features

Until this point, basic SSL VPN requirements have been couched in the vocabulary of enterprises.  However, larger enterprises and, to some extent, service providers, can make even greater demands on these products.  Partitioned and delegated management may need to be an order of magnitude more complex to support the requirements of a service provider.  For example, a normal enterprise may be willing to allow delegated managers to see where they are in a hierarchy, but not see other branches; a service provider or huge enterprise with extranet applications may want to have delegated management users completely partitioned from all other subgroups.  (From the point of view of these products, large enterprises and service providers have nearly identical requirements and can be almost considered in the same breath.)

Large enterprises may also have need for an application programming interface (API) which can be used to more tightly link non-web applications to the feature and function set of the SSL VPN security gateway.  A “toolkit” for application developers will become more and more important as the size of enterprise implementing the product grows.

Other enterprise and service provider features an SSL VPN product might include are:

a)	command-language ability to modify configuration outside of the GUI
b)	quality of service controls and guarantees on different resources or users or management domains
c)	integration with OSS tools for configuration and control
d)	ability to co-exist with other security applications on the same platform, such as a firewall
e)	integrated IPsec VPN functionality for management, logging, accounting, and reporting purposes
f)	tamper-proof/tamper-evident hardware with software alerting; control of direction of management (i.e., ability to disable console port, video display, management from inside, management from outside)
g)	disaster recovery procedures for backup of configuration and quick restoration (such as on externally accessible FLASH); other operations procedures more clearly laid out for backup, restore, deployment
h)	hardware security of keying material
i)	support for multiple languages in management and end-user interface

11)	User Workplace/Portal Functionality

As noted above, SSL VPN products begin to overlap with more traditional web portal and access control products.  It is important for an SSL VPN product to have clear lines which represent what it does and does not do in this area.  Application managers need to understand what function the SSL VPN product provides, and where the architecture ends.

Because an SSL VPN will likely be closely allied with a web browser on the client side, having control of different “start screens” or “user workplace” information for different kinds of users is important.  These could be assigned based on user profile information and heavily customized static screens, or they could be built on-the-fly based on resources which are accessible to the user.  In any case, some functionality to control what the user sees after they have been authenticated is valuable.  At the same time, the ability to customize this at least at the user group level (and perhaps in a more sophisticated manner) will be expected by most network managers.  

Integration with existing portal products which support single sign-on is also going to be expected, although the enormous number and breadth of these products is staggering.  The integration has to go both ways, as well.  Single sign-on (SSO) information entered into the SSL VPN product should be able to be passed securely to the web portal/access control tool transparently to the user.  SSO data from the web portal also should be usable by an SSL VPN device, so that the user does not have to re-authenticate.  I understand that this is harder to do than it sounds, and many portal vendors may not have the API or interest in cooperation.  However, a sound SSL VPN device should have sufficient architectural stability that this integration is possible.

A full-fledged and highly-functional SSL VPN will include a full spectrum of application and portal integration, ranging from the simplest “single URL” access to enterprise resources, through a “mini-portal” presented by the SSL VPN security gateway, up to complete integration with an existing corporate portal so that end users see the same view of the world whether they’re on-net or coming in via a remote access VPN.  

Obviously, evaluating support in this area will be very difficult. 

12)	Speed and Simplicity to Full-Scale Production

SSL VPNs are going to have their “sweet spot” for enterprises in replacing what has been either dysfunctional or insufficiently flexible IPsec products.  This means that enterprise network managers will have little patience for products which are difficult to install or integrate with their existing networks.  SSL product vendors need to ensure that they provide:

1)	High-quality documentation, both in the “quick start” and “reference” areas
2)	Appliance-style installation, requiring little more than a power-on and designation of appropriate IP addresses
3)	Transparent implementation, not requiring network reconfiguration or topology changes
4)	Flexible and easy-to-configure integration with external directories/servers (RADIUS and LDAP, primarily) for authentication and authorization information
5)	Support for end-user desktops in a wide variety of environments

Some of these requirements overlap those above, but it’s the orientation here that is clear: making deployment easy for the network manager.  SSL VPNs will be held to a higher standard than IPsec VPNs.