"It is impossible for ideas to compete in the marketplace if no forum for
  their presentation is provided or available."           Thomas Mann, 1896

Internet Protocol Security
The Security Protocol most commonly associated with a VPN

Contributed by Array Networks, Inc.

Introduction

Virtual Private Networks or VPNs allow corporate enterprises to extend access to their internal networks to external employees and partners over standard Internet public networks. The primary reason VPNs came to be was the immensely expensive lease line solutions. An enterprise had to have a physically closed network connection between its partners and remote employees, either through dial-up RAS (Remote Access Server) solutions into the enterprise network, or lease fractional T1 type connections between remote offices and partners.

What is a VPN really?

VPNs are the enabling technology which allows clients (employees) and partners to use standard public Internet ISPs and high-speed lines to access closed private networks. A common misconception is that VPNs are always IPSec protocol solutions. In fact, there are many encryption and security protocols which offer the functionality of a VPN. SSL is one such protocol.

What is an encryption or security protocol?

Security protocols and encryption are transmission protocols which are used to transmit high value data securely. Encryption, which is at the core of any security protocol, gives you three fundamental advantages over ‘clear-text’ or unencrypted data:

Data privacy - or the ability to hide the data which is being transmitted

Data authenticity and integrity – the mathematical algorithm of encryption give security protocols the ability to ensure data has not been modified or damaged in transit

Non-repudiation - another feature of the math contained in encryption is the ability to prove an act occurred

What is IPSec?

IPSec – or Internet Protocol Security, the security protocol most commonly associated with a VPN – is an encryption protocol which provides for secure encrypted data transmission at the Network Layer across a public network such as the Internet. Two parties who wish to create an IPSec tunnel must first negotiate on a standard way to communicate. Since IPSec supports several modes of operation, both sides must first decide on the security policy and mode to use, which encryption algorithms they wish to communicate with and what type of authenticate method to use.

In IPSec, all protocols which sit upon the network layer are encrypted (once an IPSec tunnel is created) between the two communicating parties. TCP, UDP, SNMP, HTTP, POP, AIM, KaZaa etc, are all encrypted regardless of their built in (or lack of built in) security and encryption.

IPSec issues and complaints

Because IPSec sits at the network layer not only is all your network traffic encrypted, but all users gain access to all company resources as if they were physically resident in the office connected to that LAN. You may or may not want partners or temporary remote employees to be part of your network. Your network may only need to have a small portion of its traffic secure. You may not want to encrypt everything from the remote client to the corporate network.

Issue 1: Client software

IPSec requires special-purpose client software, which in most cases replaces or augments the client systems TCP/IP stack. In many systems this introduces the risk of compatibility issues with other system software as well as the security risk of Trojan Horses being loaded – especially if the client software is downloaded through the Web and not installed by an IT person. Due to the way IPSec was created and the lack of conformance to the standard, nearly all IPSec implementations are proprietary and not compatible with each other.

In some cases IPSec runs on a network hardware appliance. With these types of solutions most often both communicating sides must have the same hardware. In addition, the same compatibility issues with the client software apply to the IPSec enabled hardware.

IPSec clients are bound to a specific laptop or desktop system. This limits the mobility of the users, as they cannot connect to the VPN without an IPSec client first being loaded on the client system they use to access the network. No roaming access from airport lounges here...

Issue 2: IT support

IPSec solutions require immense IT support for both implementation and long term maintenance. Large corporations often have several helpdesk personnel devoted to supporting their employees who work remotely via IPSec.

Issue 3: Platform limitations

IPSec clients typically only run on Windows machines. There are very few implementations of IPSec for any other PC platform (Mac, Linux, Solaris etc.)

What is SSL and how is it different?

SSL – or Secure Sockets Layer – is an application layer protocol used most often to secure web-based communications over the Internet. SSL uses encryption and authentication much like IPSec. Originally SSL protocol encrypted the traffic between two applications that wished to speak to each other but did not encrypt all the traffic from one host to another. However, with the progress in technology SSL VPNs now can be used to encrypt all traffic between a client and a server with SSL VPNs similar to IPSec clients encryption, except that with SSL VPNs there is no requirement for a "fat client". Any client side software that may needed to support Network Layer Encryption is downloaded on the fly using ActiveX technology or Java after the user has been successfully authenticated and authorized. This makes it a "touchless" technology allowing for centralized management and control since the light-weight clients are intelligent and are driven by the centralized access control gateway.

This also extends the client support beyond those applications that are "SSL aware" to applications, such as Web browsers like Internet Explorer and Netscape or email applications such as Outlook and Eudora and allows any IP based application including TCP, UDP, ICMP etc. Thus enabling a wide range of applications from web browsing to video conferencing over this ubiquitous tunneling mechanism.

Why use an SSL proxy?

There are many reasons to use a SSL proxy instead of communicating directly from a client to a SSL enabled resource. The most evident reason is performance.

Reason 1: Increased performance

SSL itself is a very fast protocol; however like any encryption protocol there are special CPU-intense math computations that need to take place before a secure session is established. One example is the RSA algorithm. The RSA algorithm is used within SSL to negotiate keys between a client and a server. As part of this key negotiation, the server must decrypt and verify a digital signature - both computationally intense operations. Most modern Web servers, for example, can only accept about 75 new SSL connections per second, and for each new connection this RSA decrypt and verify operation must be performed. If the system were to take any more than 75 connections per second, the CPU utilization would reach far beyond what is acceptable and the server would stop responding to network requests.

To increase the server’s capacity, SSL proxies may include a SSL accelerator. A SSL accelerator is much like a math co-processor in the 486SX/DX PC days. The SSL accelerator performs the computationally intense operations formerly performed by the server’s CPU and offloads those operations to a purpose built processor. The server, which was only able to perform 75 RSA sessions/second, can now handle well over 800 sessions/second.

You may wonder why would you need an SSL proxy if your server has an SSL accelerator. The questions to ask are: "How many servers do you have which may need this SSL acceleration? Do you have the resources to purchase SSL accelerators for each of those servers?" The advantage of an SSL proxy is that you can utilize the SSL accelerator once for many servers.

With the Array SP (Security Proxy) from Array Networks, for example, you may open 800 SSL connections per second to the clients accessing your resource, while maintaining an SSL connection from the proxy to the back-end server as well. Note the Array SP is able to open a reduced number of SSL connections to the back-end while serving up to 800 sessions/second on the front of the Array SP. The advantage of this is your Web server is never overloaded with SSL connection requests.

Reason 2: Authentication

Another issue with traditional SSL protocol is its lack of built-in authentication methods. SSL includes cryptographic authentication for both the server and the client. However, all of that security is based on one premise: the client’s cryptographic "private-key" was kept secure. If the key has been compromised or left unattended, you may no longer be able to trust the client. It may be necessary to add additional authentication methods on top of SSL to ensure the user or client is who they say they are.

A SSL proxy, however, strongly authenticate clients before they ever connect to the back end resource. SSL proxies enforce much stronger authentication methods than a back-end resource could ever support natively. Many Web servers today do not natively support authentication methods other than SSL.

Why use an SSL proxy over an IPSec VPN?

• No client-side software or hardware requirements
   

• A key advantage to an SSL proxy is that no client software needs to be loaded and distributed through your client base. SSL proxies can use standard Web browsers and email clients which are already enabled to use SSL.
   

• Easy-to-use, easy-to-support Web interface
   

• Web browsers and SSL enabled email clients exist in many form factors today including Windows, Macintosh, Linux/UNIX, PDAs and even cell phones and all can communicate securely via SSL. People are already familiar with how to use these tools so end-user training is greatly reduced.

End-to-End vs. End-to-Edge Security

One of the major disadvantages of IPSec is that it only creates a secure tunnel between a client and an edge VPN Server. When the client requests access to a resource, he is treated as if he was a member of that same network the resource resides on with IPSec. The only secure connection is between the client and the edge of the corporate network; all the data running over the internal network is in the clear, including any passwords and sensitive data that are sent.

With SSL, a secure tunnel is established directly from the client to the resource the client is accessing. With true end-to-end security, no data is sent in the clear, either on the internal network or on the Internet. Everything from the client to the resource is securely authenticated and encrypted.

Which Technology is right for me?

IPSec – Best used for site-to-site connectivity where tunnels are permanently established, such as in the case of connecting branch offices to corporate offices and in scenarios where large volumes of background traffic needs to be sent from automated programs talking to other automatic programs.

SSL – Should be used for all Remote access scenarios.