12/03/2009 03:09:32 PM
For years, organizations have sought to secure private communication over the Internet using Virtual Private Networks based on IP Security (IPsec VPNs). The process has proven more time- and resource-consuming than expected, but at this point, many organizations, large and small, have succeeded in connecting together their office and campus networks, and even their business partner’s networks, using secure IPsec tunnels over the Internet.
An IPsec site-to-site solution addresses only part of the secure communication imperative, largely because an increasingly large part of every organization’s workforce has become mobile. To complement site-to-site VPNs, most companies need some form of secure client access. And this is where IPsec VPN deployment has hit the proverbial wall. Every IPsec remote access deployment must overcome a number of major issues. The first is IP addressing, which is encumbered by the commonplace use of network address translation: IPsec and NAT simply won’t work in every situation. The second problem many companies face is how to support an installed authentication infrastructure – for example, token-based or any challenge-response authentication – that is not supported in the IPsec standards: numerous interim solutions exist, but none are supported broadly across the IPsec vendor base.
IPsec remote access requires 3rd party client software. The administrative challenges organizations with large populations of users face when they become responsible for managing IPsec client software and configuration for their own users are considerable. They become impractical when organizations try to extend secure access to business partners, supply-chain and customer desktops.
As the name suggests, IPsec creates an IP- or network- level tunnel (connection). This means that every remotely connected user is directly connected to what an organization considers an internal or protected LAN. Every resource on this protected LAN is now potentially available to the user, and also vulnerable to misuse and attack from the user’s computer. Often, organizations that are successful in deploying IPsec remote access find themselves encumbered with overly complicated security policies that must be configured to restrict user access.
After years of struggling with these issues, many organizations have come to reconsider their requirements for remote and extranet access. Many organizations want to provide users with access to specific applications and they do not want the addressing issues and the exposure of a full network connection to accomplish this objective. They want a clientless VPN, one that doesn’t require additional (IPsec) software to manage on client computers. And they want flexibility in their selection of stronger authentication methods.
Secure Sockets Layer (SSL) is an apparent win-win for secure access (remote and extranet). Users are familiar with the browser interface. SSL is built into every web browser, and thus requires no additional client installation and minimal configuration. SSL operates above IP, so NAT and other IP addressing matters are transparent to the user. SSL-based encrypted tunnels provide sufficiently strong encryption for the purposes most organizations have. Moreover, most organizations have already accumulated years of experience running SSL on their E-commerce and extranet sites, with a variety of authentication methods.
A veritable armada of security appliance vendors – Array Networks, Aspelle, Aventail (now Sonicwall) CheckPoint, Neoteris (now Juniper Networks), Netscaler (now Netrix), Netilla, NetSilica, Nortel, Rainbow Technologies, SafeWeb (now Symantec), URoam (now Netscreen), and Whale Communications (now Microsoft) – hopes to play the trump card in the high-stakes market for secure remote access: return on investment. SSL VPNs are simpler to deploy, and demonstrably less expensive to implement and operate.
Originally written for Networld+Interop 2003 Las Vegas Preview