VPN’s (Virtual Private Networks) used to be created with the IPSec protocol (Internet Protocol Security). Newer solutions are based on SSL (Secure Sockets Layer). SSL-based solutions can be used in the same way as IPSec solutions; with SSL, however, there are also solutions that are principally different than IPSec solutions.
In this article the differences between SSL and IPSec, and the advantages of SSL over IPSec, will be discussed. This article deals exclusively with solutions for remote access from laptops or PCs. In gateway-to-gateway connections, which for instance are used for connections to branch offices, using SSL doesn’t make sense, so IPSec continues to be used in such scenarios. Also, devices such as the Apple iPhone or other cell phones with Microsoft Windows mobile as a standard have an embedded IPSec client. The advantages of SSL don’t apply here; therefore it doesn’t make sense in this case to replace IPSec with SSL.
This article is organized into the following sections:
- Where SSL can be used, but IPSec doesn’t work
- System Architectures with IPSec or SSL
- Compression with IPSec or SSL
- Streaming with IPSec or SSL
1. Where SSL can be used, but IPSec doesn’t work
Only Access over TCP Port 80 and 443 is possible
In the Internet environment such as in companies, hotels, or Wi-Fi Hotspots firewalls are used regularly as a form of protection from the public Internet. Since access to the protected areas should be possible, predominantly for the web-browser users, access over the HTTP TCP port 80 and the HTTPS TCP port 443 is allowed. If there is nothing else configured in the firewall, IPSec definitely cannot be used.
Proxies within Company Networks for Access to the Public Internet
Proxies are used in many companies and organizations to regulate access to the public Internet. The protocol Socks 4/5 and HTTP are then utilized. Conventional browsers support access through such proxies. Microsoft ISA Server or Squid (Open-Source) are examples of proxies that are used. It could be required within the proxies that a user or a device must be authenticated before access to the public Internet is allowed. Different options can be used for the authentication: Username/Password, NTLM (NT LAN Manager) or Kerberos. It is possible within such proxies to check the incoming websites (HTTP/HTML) for viruses. With the appropriate constructive characteristics it is also possible to receive arbitrary data through the virus checker. Viruses are not received from the Web-Browser, but from the SSL Clients instead. Such proxies generally cannot be used with IPSec, only with TCP or SSL is access possible.
SSL over the HTTP TCP Port 80
There are installations, commonly found in hotels, where only port 80 is open and not the HTTPS/SSL-port 443. It is, in principle, possible to pass SSL data through port 80 so that access with the web browser (over SSL clients) is possible.
Costs for Hotel Internet Access
It has been reported that in many hotels there are different price models for Internet access. There is complimentary or low cost access over the TCP port 80 / 443 (where SSL can be used), but if one wants to use IPSec, then another, more expensive, price model must be chosen.
Low Cost Network Components
When a user is at home and wants to set up a VPN connection on the central network, then as a rule a standard DSL connection should be used. A DSL router is then used and it typically does the NAT (Network Address Translation). It has been reported that such DSL routers often cannot use IPSec, often not even with NAT-Traversal.
2. System Architectures with IPSec or SSL
System Architecture with IPSec
IPSec solutions are usually set up so that a driver is installed on the client. This driver installation creates a so-called virtual adapter in the system. Typically, the IP address used for communication with applications on the central servers comes from the central IT administration. The driver in the system intercepts all (or the relevant) IP packets, encodes them and then sends them over the IPSec tunnel to the server. Packets from the server travel the opposite path. There are also IPSec solutions with compression.
Modern operating systems are designed so that a faulty program doesn’t cause the operating system to crash nor disturb nor damage other programs. This is attained by allowing only the operating system to carry out critical actions such as input/output or memory management. If programs need such actions, they jump over the APIs (Application Programming Interface) in the operating system, the operating system checks whether the action can be carried out faultlessly and then the operating system carries out the critical actions for the application.
Now, however, an operating system can’t always do everything alone; therefore drivers are used to extend the operating system. Drivers, in principle, are allowed to perform all actions, even the critical and dangerous ones. This is necessary because, otherwise, the applications would only be able to do what the standard operating system is designed to do.
Several problems arise from these circumstances. One being, faulty drivers can cause the entire operating system to crash; with Windows one speaks of a “blue screen” event. Often data is lost by a system crash and it causes a big disturbance for the user, because he is not able to work for quite a long time (at least for as long as it takes for the system to reboot).
There are specific interfaces in the operating system for drivers. Operating systems are constantly being further developed, so that these interfaces must always be changed. That mainly means that for every operating system version a specific driver is needed, which doesn’t work anymore with a newer version of the operating system. With normal applications this problem doesn’t exist because the OS manufacturers see to it while developing new versions that the interfaces to these applications (APIs) are maintained at a consistent level.
Qualified developers are needed for the development of drivers and these are hard to find. In comparison to normal applications, drivers are more difficult and more expensive to develop, debug and to test.
In conclusion, it is to be said that the prevailing number of operating system crashes (“blue screen”) are not just errors from the operating system, but instead from the driver.
Microsoft, in Windows XP, introduced the function Windows Error Reporting (WER). This enables Online Crash Analysis (OCA) to be done. When Windows crashes with a blue screen event, than a small core-dump is generated and, after the user is prompted and agrees, this is sent to Microsoft. Microsoft was at the time quite amazed at the many core dumps they then received, the large amount of which was unexpected. As the received core dumps were analyzed, Microsoft discovered that faulty drivers were responsible for 85% of the errors, the small percentage remaining were actual Windows kernel problems. If there were fewer drivers in the system, then there would be correspondingly less annoyances and problems.
Full Network Access over SSL
With some SSL solutions there is also full network access over SSL, analogous to solutions with IPSec. In standard solutions a driver is installed on the client’s operating system, analogous to IPSec. HOB RD VPN PPP Tunnel, a new technique that is patent registered, has full network access without a driver, without administrator rights and completely without an installation on the client. The PPP Tunnel solution within HOB RD VPN is browser-based.
Because with this solution everything is installed on the central server and nothing on the client, software updates are much easier to implement and constitute considerable cost savings.
Access from the Client’s Web Browser over an SSL VPN to the Central Web Server
One of the first and basic functions of SSL VPNs was to make access only via the client’s web browser. When a user wants access, he authenticates himself first on the SSL gateway and then he is granted access to all web servers in the central network. This access can be restricted if necessary by the configuration of the SSL VPNs; the user can then only access predetermined web servers. The communication between the client (web browser) and the VPN gateway is SSL encoded (HTTPS). For communication between the VPN gateway and the internal web servers, normal HTTP is used or, when needed, SSL can also be used. One speaks then of client-side SSL.
This function sounds relatively simple; however it is expensive because all links in the web pages of the VPN gateway must be converted. This is principally possible for:
However, there are restrictions and some general problems with websites with the following content:
In addition, files can be exchanged in both directions with the central office over the browser. Not all SSL VPNs command these costly procedures for the conversion of web pages or for the exchange of files. With HOB RD VPN this function is called Web Server Gate. The exchange of files is called Web File Access.
On the one hand, only web applications are predominantly developed or used in many companies, on the other hand only the normal web browser is needed on the client. For this reason, this form of access over SSL VPNs is often used. With IPSec VPNs there are no comparable functions.
Redirection from the TCP Data Stream to the localhost
One of the basic functions of SSL-VPNs is the following: on the client a small proxy is started which was previously downloaded as a Java applet or an ActiveX control from the SSL-VPN. Now the user can start on the client the desired applications. These then connect over the localhost to the local proxy and then to the corresponding server. To do this, of course, the application has to be configured differently.
The local proxy encrypts the data with SSL and sends it to the VPN gateway. The VPN gateway unpacks the data and sends it to the desired target or server. At HOB this function is called the Universal Client, elsewhere one speaks of port-forwarding. This function has certain limitations and only works when the client application establishes a TCP connection to the server; the other way around, a TCP connection can be made when the server wants to establish one to the client. UDP also cannot be used.
There are also problems when in the TCP data IP addresses are transmitted, as happens, for example, with FTP or RDP. Also in SIP and RTP IP addresses are transmitted in the data packets, but here the communications go over UDP and redirection over the localhost is, in principal, not possible.
When working with a local proxy, the Session Directory cannot be used with RDP for the Windows Terminal Server, because the RDP data stream is being redirected over the local proxy.
With HOB RD VPN, SSL is done directly in the RDP Java Remote Desktop Client HOBLink JWT and in the WebSecureProxy, so that the Session Directory function is also supported here, as opposed to solutions using local proxies and redirection over a localhost.
In many cases, the function with local proxies and redirection over a localhost is sufficient, yet it does not provide complete network access. However, in many cases complete network access is not at all desired.
3. Compression with IPSec or SSL
In many IPSec solutions compression is incorporated, but after different methods, most of them deflate.
With IPSec the packets are individually compressed, if a dictionary is used, it must be reset with each packet. This happens because IPSec is a connectionless protocol. This means packets can get lost, packets can arrive out of order, or they can arrive at the recipient with the wrong Checksum and then be rejected. Packets are also rejected from routes in the transmission network if the network is overloaded; this is a normal occurrence and is accordingly taken into consideration by all IP stacks.
IPSec does not notice if a packet does not arrive at the recipient, these problems are handled at a higher layer, e.g., in the TCP stack. Due to the fact that with IPSec the dictionary is reset with every packet, the compression is less effective. Packets are mostly small with IPSec, MTU = Maximum Transmission Unit or MRU = Maximum Receive Unit is for example, with PPP RFC 1661 1,500 Bytes. With such small packets good compression is not possible. In the meantime, there are Gigabit Ethernet jumbo packets, up to 16,000 bytes, with these, better compression is possible, but, with WAN such large packets currently cannot be exchanged.
Compression with SSL
SSL is connection-oriented and thus efficient compression can be used. Web browsers have a good command of compression methods such as zLib. The data is given in the HTTP header. The web browser doesn’t send compressed data itself; actually the packets from the web browser to the web server are typically quite small. But the web server (or an SSL gateway with the function Web Server Gate) can compress the response with zLib and thereby the corresponding web pages are loaded faster.
Compression with zLib is built into HOB RD VPN Web Server Gate. Web pages can be compressed even if the original web server sends the data uncompressed.
With SSL the shared cipher suite is negotiated through a suitable method, which means deciding which encoding algorithms are used.
The company Netscape originally invented SSL and had intended that while negotiating the cipher suite, a compression algorithm could also be negotiated. For this reason, HOB built this functionality into the corresponding SSL suite so that compression could also be used. This works, however, only when HOB SSL Suite is used on the client as well as on the VPN gateway. There are no other known companies, aside from HOB, that do compression on the SSL level.
If with HOB RD VPN the PPP Tunnel with compression is deployed, Windows Explorer data, for example, is exchanged, and an effective compression takes place. In practice it was observed that the data stream was compressed sometimes down to 20%. The data exchange then goes much faster, just as with a virtually five times faster line.
4. Streaming with IPSec or SSL
Applications like video or audio use streaming, i.e., a continuous data stream is sent. A special case of streaming is real time, such as VoIP (Voice over IP). In order to understand the suitability of IPSec or SSL for streaming, we must first look at the basics.
If data can be transmitted, then physical effects can cause this data to be falsified. That is the reason that checksums are built into the data packets. The transmitter generates the checksum and the recipient checks whether the checksums are still correct; if not, the data packet is rejected. The recipient does not have any other possibility, as the return address in the data packet could have also been falsified and therefore the recipient cannot inform the sender.
Overruns in Routers
The Internet protocol, IP, is connectionless. Let’s assume that we have a router with 2 data lines connected, one fast line 1 and one slow line 2. If the router begins now with the packets in the quick succession from line 1 that should be redirected to line 2; the router cannot redirect the packets so fast over the slower line 2. A solution to this problem is that the router caches these packets and then sends them delayed. But the memory of the router is limited and therefore the router rejects data packets when it has received more than it can redirect.
The UDP Protocol
The UDP protocol (User Datagram Protocol) is very simple. A transmitter sends packets, if the packets arrive at the receiver then it is good, if not, nothing further happens. Nothing is built in the UDP protocol for the transmitter to notice that the sent data packet did not arrive.
The TCP Protocol
The TCP protocol (Transmission Control Protocol) is connection-oriented and complex. With TCP it is guaranteed that all data packets that an application sends intact, complete, and in the correct order will arrive at the recipient.
Simply described, it functions like this: When the IP stack of a computer sends a TCP packet, the recipient must send an acknowledgement within a certain amount of time (a fraction of a second). If the sending IP Stack doesn’t receive an acknowledgement, because the sent packet is lost, the recipient doesn’t exist anymore, or the acknowledgement was lost, then he sends the packet again. If after a certain number of repetitions still no acknowledgement is received, then the IP stack reports this error to the application.
Suitability of UDP or TCP for Streaming
For streaming, specifically for real time, normally UDP, not TCP, is used. If now and then a packet is lost by streaming, it is not a big problem. If however, like with TCP through the repetitions of packets, streaming doesn’t continuously function, then there will be a certain problem.
Suitability of IPSec or SSL for Streaming
IPSec is connectionless like UDP; packets from the IPSec layer are not repeated, and therefore well-suited for streaming. SSL is based on TCP. It is constructively built so that all packets must arrive intact, complete and in the correct order at the recipient, otherwise the cryptography of SSL doesn’t work.
SSL is less suitable for streaming. A way out of this problem is to build an encoded UDP connection parallel to SSL and then dispatch the streaming data in this way when it is possible. This is exactly built in the HOB VoIP solution, HOBPhone.
Streaming over IPSec works well. Streaming over SSL usually works just as well, because transmission errors are seldom seen these days.
Klaus Brandstätter, CEO, HOB Inc.
DEVELOPING DRIVERS WITH THE WINDOWS DRIVER FOUNDATION
Penny Orwick, Guy Smith
You must be registered in order to write comments. To register as a new user click here.
If you're already registered, please leave a comment here