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:

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

Advertisement