Solution Brief #2
Why Would Anyone Choose IPSec over SSL for Secure Remote Access?
Author: Dana Hendrickson, Director, Breakaway Security Group
Even if your organization already relies an IPSec VPN for remote access, you might seriously consider replacing it with an SSL VPN Gateway solution. Why? Because the investment can produce a very positive ROI and reduce the number of support headaches associated with maintaining IPSec client software on a variety and large number of end user devices. And if you are building your first remote access VPN, the choice is obvious: invest in an SSL VPN. These rapidly evolving network security solutions already match IPSec VPNs in terms of their flexibility to access all TCP and UDP applications, and file servers. Plus, SSL VPN security capabilities and ownership costs are clearly superior.
In this Solution Brief the Breakaway Security Group (BSG) takes a close look at the F5 FirePass Controller in order to illustrate how SSL VPN solutions can now provide access options that are even more versatile than IPSec VPNs and more convenient for users. Both attributes translate into greater productivity for mobile workers. The two areas of focus are resource accessibility and user device support.
And the good news does not stop here. Breakaway expects many SSL-based security gateways will soon evolve into more general-purpose, universal access systems that extend secure access capabilities well beyond the realm of remote access to include internal network users, as well. In 2004, many security gateway vendors will enhance and re-position their products to meet the broader customer requirement for ways to implement highly selective and flexible security policies across their entire extended networks. We expect these products to include sophisticated application-level security features, high performance and powerful security management. Ease-of-use for the security admistrator will be critical. This trend will be reviewed in a future Solution Brief.
Outlook
At the start of 2003, the remote access landscape looked a whole lot different. Remote access IPSec VPNs could support all TCP and UDP applications. While only a few SSL VPNs could offer much more than access to web applications and network file servers. IPSec clearly enjoyed the advantage of “universal access”. Since then, things have changed dramatically. By broadening the remote access connectivity options available on their security gateways, SSL VPN vendors have aggressively narrowed the opportunity to deploy new IPSec VPNs for remote access. Instead, IPSec VPNs will continue to provide still important, site-to-site WAN security.
Both Nortel and Cisco have recently announced products that integrate
SSL and IPSec on one system but these solutions will appeal primarily
to those customers who already operate IPSec remote access networks
and wish to add SSL to their existing systems. These are transitional
systems for both vendors who must signal their commitment to more advanced
SSL VPN gateways and buy time as they ready truly competitive SSL VPN
products. In the near term, SSL VPN gateway vendors should fear the
marketing power of these two companies more than the competitiveness
of their product offerings. Yet all should assume both Cisco and Nortel
will eventually offer very competitive SSL VPN solutions. But, let’s
be clear: SSL-based security has already won the battle for enterprise
remote access.
F5 FirePass ControllerePass Controller
In October, F5 Networks announced the latest version of its FirePass Controller (acquired earlier in 2003 from uRoam) with the claim that it “eliminates the need for IPSEC VPNs for secure remote access”. At the start of the year, most SSL VPN vendors were still most comfortable saying that IPSec remained valuable for “power users”. Now one vendor had taken the stand that building a new remote access network that includes IPSEC no longer makes sense.
The table below illustrates the broad set of remote access options now available on the F5 FirePass Controller. A brief explanation of how each option works follows the table.
Remote Access Versatility
| Types
and Examples
|
FirePass
|
Download |
Application
|
FirePass |
|
| Adapters
& |
Client-side
|
Com
Protocol
|
Server |
||
| Connectors |
Code |
WAN |
LAN** |
Proxies |
|
| Webmail | Web Adapter |
None |
HTTPS |
HTTP |
Reverse HTTP Proxy |
| Microsoft® OWA™, IBM® IWA® | ( URL Rewriter) |
||||
| Webified Standards-based mail | Email Adapter |
None |
HTTPS |
Native |
Webifier |
| POP, IMAP,SMTP | |||||
| Intranets and Extranets | Web Adapter |
None |
HTTPS |
HTTP |
Reverse HTTP Proxy |
| Web File Server Access | Web Adapter |
None |
HTTPS |
HTTP |
Reverse HTTP Proxy |
| Web Access to Non-Web Servers | File Server Adapter |
None |
HTTPs |
Native |
Webifier |
| Web File Transfer | File Server Adaptor |
None |
HTTPs |
FTP |
Webifier |
| Remote Access to Desktop | Desktop Adapter |
Yes |
HTTPS |
Native |
Webifier |
| Applications and Files | Unix/Linux Adapter |
||||
| Proprietary F5 Application | |||||
| Native Email | Application Connector |
Yes |
Native-SSL* |
Native |
Application
Proxy |
| Microsoft Outlook, IBM Lotus | |||||
| Client-server | |||||
| Use Static Ports | Application Connector |
Yes |
Native-SSL* |
Native |
Application
Proxy |
| Use Dynamic Ports | VPN Connector |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| Legacy Host Access | Host Adapter |
Yes |
HTTPS |
Native |
Webifier |
| IBM 3270/5250, DEC VT100/300, Telnet, SSH, x-term | |||||
| Terminal Services | Terminal Server |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| Citrix®, Microsoft, VNC | Adapter |
||||
| Full FTP | VPN Connector |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| Collaboration (UDP) | VPN Connector |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| IBM Lotus Sametime™ | |||||
| Microsoft NetMeeting™ | |||||
| Instant Messaging (UDP) | VPN Connector |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| All TCP & UDP Applications | VPN Connector |
Yes |
Native-SSL* |
Native |
Generic Proxy |
| and Network File Servers | |||||
* Native-SSL refers to a native application protocol port-forwarded
across SSL (port 443)
** Communications across the LAN between the FirePass Controller and
internal servers can also be encrypted using either SSL
(web) or IPSEC.
BMG Observations
The following points are noteworthy:
- The F5 FirePass Controller enables remote access to all internal network resources: email servers, intranet and extranet applications, network file servers, client–server applications, terminal services, host/server applications, and even a mobile users own desktop. And importantly, remote access users enjoy the same functionality as when they are directly connected to local networks via a LAN adapter.
-
Most access options are implemented through application or generic proxies (e.g. HTTP, FTP, C-S) resident in the F5 FirePass Controller so users never obtain a network-level connection to an internal resource. This architecure is inherently far more secure than IPSec's.
-
The F5 FirePass Controller offers an “IPSec-like” capability through its VPN Connector. But unlike IPSec, administrators do not install, configure and maintain VPN client software on every remote device. That can amount to large savings in workload and costs. The VPN Connector supports all TCP and UDP applications and network file servers, and is valuable in supporting client-server applications that require dynamic port assignments, UDP applications (e.g. instant messaging, collaboration software), and technical support personnel who need network-level access. This broad “network level” access can be easily restricted to specific users, and resource access can be selectively narrowed through filtering. A user’s view of the internal network is limited to only those resources he/she is authorized to use (This is true for all access options). In addition, the FirePass Controller can be configured to allow access only from devices protected with anti-virus and personal firewalls. (Note: This device-level security is also a best practice for IPSec VPNs.)
-
A browser acts as the sole VPN client for web access and shared file access; all the other access options require executable software (either ActiveX or java) to be downloaded to the client device. So, these options are not really "clientless". But, unlike IPSec clients, the downloaded FirePass Controller software does not need to be configured with network path information, and SSL VPN vendors claim there are much fewer software compatibility issues.
-
Downloaded software can raise a red flag as non-company owned devices might not allow this activity. While this is a potential obstacle, it’s not likely to become a significant problem for most organizations. Remember that web access will satisfy most users as they most commonly want access to email, shared file servers and web applications. Those who wish to work from their own laptops or personal PCs can permit the software downloads that enable more access options. And business partners can allow selected users to download software to specific authorized devices. The inability to access client-server applications, host resources or the entire network from public kiosks or "borrowed" computers will not be troublesome for most organizations. In fact, most will find this a desireable limitation. And remember, most mobile business users are expected to possess portable devices that either they or their employers own.
-
The still widely held view that remote IPSec VPNs are required to support "power users" and network support personnel is simply not true. Select the right SSL VPN Gateway, and one security system will securely handle the access needs of all your remote users.
Access Option Descriptions
Brief descriptions of the individual F5 FirePass access options follow. Other vendors like Aventail, Neoteris and Netilla Networks use similar methods to both establish an SSL tunnel between the client and the SSL Security Gateway and to control access to internal resources. Note that, when required, all ActiveX and java software is automatically downloaded without any user involvement.
Web Adapter
This reverse HTTP proxy is the service point for user authentication and for rewriting URLS (and HTTP pages) for external users. The web adapter software is located entirely on the security gateway.
Email Adapter
This is a standard HTTP application which runs on the FirePass Controller and enables web access to non-web (POP/IMAP/SMTP) email servers and LDAP address books. The email adapter software is located entirely on the security gateway.
File Server Adapters
The file server adapter is used to browse the network neighborhood and access files. Users can browse, upload, download, copy, move and delete files (unless these actions are restricted). This adapter emulates a Windows client and natively accesses the Windows domain and NFS servers (e.g. SMB, Windows for Workgroups, Windows NT and Windows 2000 file servers, and Novell Native File Systems).
Application Connectors
Each Application Connector supports one specific TCP-based client/server application and uses an SSL session to transport the native application traffic. The Application Connector only supports communication from a specific client port to a specific application server port. For each individual application, specific software is downloaded to the client device. This software re-directs the native application protocol stream to port 443. At the Security Gateway the SSL Session is terminated at either a generic or application proxies so security policies services can be rendered. Organizations can easily add support for any application that uses static ports.(Note: Once a user has "signed-on" to the FirePass Controller via a browser-based connection, additional and different user authentication requirements can be imposed for access to individual internal resources. The administrator controls the overall authentication policy).
VPN Connector
The VPN Connector is a generic proxy that supports all TCP applications, including those that require dynamic ports, and all UDP applications. The VPN Connector includes software on the FirePass Controller and software downloaded to the client device. Encryption is provide by SSL and user authentication for access to individual resources is controlled by the individual interrnal application or file server.
Host Adapters
For each environment, specific terminal emulation software is downloaded to the client device. This software displays the appropriate terminal user interface within a browser window. At the FirePass Controller, SSL sessions are terminated and the http terminal protocol stream is converted to the native terminal protocol of the internal host server. Browser access is enabled for VT100, VT320, Telnet, xterm and IBM 3270/5250 applications.
Terminal Server Adapter
If a Terminal Services (TS) client is not already installed, the FirePass Controller automatically downloads it for either Microsoft Terminal Servers, Windows XP Desktop, Citrix Metaframe, or VNC Servers. The native TS protocol (e.g., Citrix ICA) is port-forwarded across an SSL session between the remote device and a FirePass generic proxy.
Desktop & Unix/Linux Adapters
These adapters allow users to securely access their own desktops from
a remote device. The Desktop Adapter is installed on the user desktop;
requires the feature to be enabled on FirePass; and requires either
a Java or ActiveX download to the client PC. The UNIX system adapter
requires no installation on the UNIX system; requires the feature to
be enabled on FirePass; requires either a Java or ActiveX download to
the client PC. The downloaded software performs terminal emulation and
"screen scraping" functions.
Mobile Adapter
This adapter resides entirely in the FirePass Controller. It presents
standards-based email in a format appropriate for micro-browsers and
the display characteristics of particular PDAs and webphones. This software
module supports devices with Palm OS, Pocket PC, WAP and iMode software.
Conclusion
Given the versatility of leading SSL VPN appliances, there is little (no?) reason to deploy new IPSec VPNs for mobile user access. Firewall/IPSec VPN vendors like Cisco and Nortel trail SSL VPN vendors in terms of SSL-based application support so they will continue to tout their hybrid solutions until they can catch-up. In the meantime, SSL VPN vendors will be adding new features and expanding their reach to internal network users. The race for leadership in secure universal access has only just begun!
Some Final Thoughts
Advocates of IPSec VPNs for remote access often raise objections about SSL VPNs that are steadily loosing weight. Here are two of the most commonly expressed concerns:
Trusted Devices. The simplistic argument goes as follows: IPSec clients are installed on trusted (i.e., carefully controlled) company-owned, computers (THAT's GOOD); SSL clients permit access from untrusted computers, like kiosks (THAT's BAD).
BSG View #1 - IPSec and many SSL VPNs allow network-level access to internal networks. This access should be limited to trusted users and trusted devices. This means trusted users and untrusted devices can be used with SSL VPNs but they should be restricted to application-level access, and user activities like file downloading should be further restricted based on an organizations security policy re: these "public/shared" devices. This is not bad; this is simply a reality.
| Access Device |
IPSec VPN |
SSL VPN |
| Trusted |
Network-Level Access |
Network-level Access (Special users) |
Application-level Access (General users) |
||
| Untrusted |
Application-level Access with Limitations |
BSG View #2 - Do not assume
that any device (incuding one with an IPSEc VPN client) is trusted just because
it has anti-virus and personal firewall protection. Any device that allows
network-level access requires strong protection against various types of attacks
that can compromise the device (where important files might be stored) and
the internal network. This is true whether IPSEC or SSL is used. Malware and
software patch detection are just two examples.
BSG View #3 - The
whole point of SSL is to provide mobile users with a number of access point
options while providing organizations with the tools required to control/limit
what they can do based on who they are, the trust-level of the access
device, and the organization's security policies. Yes, if a user that needs
network-level access can live access from a single device, IPSec
VPN remote access works just fine. But BMG expects the number of this type
of user will shrink in the future.
Strong User Authentication. Two-factor user authentication (e.g. certificates, tokens) are an essential and costly add-on for SSL VPNs; IPSec VPNs do not carry this burden.
BSG View #4 - This is a myth. If you want strong user authentication the costs are the same for both approaches. Device-level authentication is another story. Yes, IPsec provides it at no cost. But digital certificates are available for SSL VPNs - if you absolutely need this type of protection. And alternative methods for identifying specific devices will be supplied by SSL VPN vendors in 2004. So this argument is rather weak and will diminish even further.
Your Feedback
If you can think of situations where mobile users (and their organizations) would be better served by an IPSec VPN, submit your ideas. BSG will publish the best ones - along with vendor responses - on the SSL VPN Central web site.
Copyright 2003 Breakaway Security Group All rights reserved. Published December 2003
