IPSEC vs SSL

By David Phillips

June 4, 2009

            The Internet Protocol Security (IPSec) and Secure Socket Layer (SSL) protocols are used to implement Virtual Private Networks (VPN) that allow remote clients to communicate securely with remote networks via “tunnels” across an non-secure medium such as the internet.  While both protocols provide secure communication over the internet, they differ in scope and granularity which needs to be taken into consideration when network administrators deploy a VPN solution.

            IPSec is implemented at the Network level (layer 3) of the Open Systems Interconnection Basic Reference Model (OSI) model and is typically implemented natively as part of an operating system’s network interface subsystem.  SSL is implemented at the Application level (layer 7) of the OSI model (above of the network layer) and is typically implemented as an encapsulated software module within a web browser or secure shell application.

            Intuitively from observing positions of the protocols within the OSI layers, it is clear that SSL encompasses only a subset of the scope that is provided by IPSec due SSL’s services only being available at the Application level, whereas IPSec’s lower position in the stack allows it to provide services to the Transport, Session, Presentation, and Application layers, thus achieving a much broader scope.

            While IPSec’s broader range may make it seem as the more attractive of the two choices, it requires each participating system (including network routers, firewalls, etc) to support the IPSec implementation (contain client software).  Furthermore, IPSec needs to be pre-configured on each system ahead of time by skilled network administration personnel.  In essence, an IPSec solution requires that a lot of manual work be performed up front before the participating systems can begin communication securely.  On the other hand, since SSL is implemented within nearly all modern web browsers, practically any machine can instantly communicate securely with an SSL service via the web browser without the user having to perform complex pre-configuration tasks.

            SSL’s reduced scope also makes it good for access control by restricting user’s access to a much finer level of granularity.  For example, when communicating with a remote host over IPSec, the client can open sockets and send messages to any application running on the remote host such as telnet, ftp, http, etc.  SSL, on the other hand, is encapsulated within a web browser or Secure Shell client, which restricts the client’s access to only the single type of application that it was designed for.  For example, the client would have to use the Secure Shell application to communicate with the remote host over a telnet-like session.  If the client then wants to communicate with a web server via SSL, they would have to do so with the web browser whereas under IPSec, there is nothing preventing the client from directly interrogating any service running on the remote server.

            SSL’s reduced scope also makes it bad for general purpose traffic because it requires that a special application be present to perform each type of communication.  For general purpose VPN’s where a client will want to perform many different types of communications with the remote host, requiring the client to run a bunch of specialized applications is not feasible and thus the IPSec is much more flexible in that regard.  For example, if the client only has a Web Browser installed and no Secure Shell application then the client can only communicate securely with web browsers and will not be able to communicate securely with telnet servers.  If the client is communicating via IPSec then it does need the Web Browser or Secure Shell client in order to communicate securely because the security protocol is being performed at the lower layer which all applications may take advantage of.

            IPSec also increases the size of the original packets by adding extra IP headers and encryption padding whereas SSL has less overhead:

IPSec can reduce overhead from multiple users because the same IPSec tunnel can be used by more than one user.  However, under SSL, each user on the same machine would have to establish a new session using different encryption keys, etc than other users.

One significant disadvantage with IPSec is the compatibility issues that it encounters with routers that are using Network Address Translation (NAT) because of its authentication algorithm which makes fields in the IPHeader immutable which (when changed by a NAT router) causes the receiving host to drop the packet due to an authentication failure.  This is typically solved by using IPSec’s tunnel mode.  SSL does not have any compatibility issues with NAT routers because it does not mute any of the fields in the IP header.

Another disadvantage of SSL is that it does not support the UDP protocol and it does not support compression compared to IPSec.

It appears that IPSec is better suited toward solutions where a broad range of services need to communicate securely whereas SSL is better suited to smaller solutions where specialized applications need to communicate securely.

http://netsecurity.about.com/cs/generalsecurity/a/aa111703_2.htm

http://en.wikipedia.org/wiki/OSI_model

http://eprint.iacr.org/2004/314.pdf