The IP Security Protocol, Part 1

Real-world communications over the Internet are becoming more and more widespread. In particular, commercial transactions, which deserve a high level of security, often take place over our beloved--though insecure --packet network. Furthermore, VPNs (virtual private networks, i.e., private networks deployed over a public packet infrastructure) are definitely emerging as the solution of choice for the interconnection of distant offices belonging to the same company.

Unfortunately, IP packets carry our precious data in a clear form that is easily intercepted by malicious users. Doing this on a common Linux-based PC is actually quite easy, provided that one has access to the network segment over which the desired packets are traveling.

Several different solutions exist that allow us to cope with this problem, each operating at a different level of abstraction. In this article, we will discuss the differences between and purposes of application-level security, socket-level security and network-level security.

An application that needs to transmit protected data over an insecure network may adopt internal mechanisms in order to achieve data integrity and privacy. The application developer must take care of all the intricacies of authentication, encryption and key exchange. Eventually, he or she will come out with an allegedly secure mechanism allowing the application to achieve what was requested. Other developers, working on different applications, will have to do it all over again, coming out with different solutions. The probability of a security flaw hidden inside one of those applications greatly rises as their number increases. Also, most programmers are not security experts, and even if they are, they usually are not skilled mathematicians with a deep knowledge of encryption algorithms as well. Chances are high that, sooner or later, one of them will make a mistake that spoils the whole security infrastructure.

It is amazing to discover how a single bit that turns out to be not quite random enough can dismantle a thoroughly designed security system. The case of GSM (Global System for Mobile Communications, the cellular phone standard adopted in Europe) card cloning is an example of how such subtle details can become baleful. The bottom line is developers should always rely on widespread, possibly open-source solutions for their encryption needs.

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are common solutions to protect users' data from the prying eyes of malicious eavesdroppers. They basically provide applications with enhanced sockets that automatically encrypt any data flowing through them. SSL is used, for example, by web browsers when they are using the HTTPS protocol. The advantage of TLS and SSL over generic application-level security mechanisms is the application no longer has the burden of encrypting user data. Using a special socket and API, the communication is secured.

The problem with SSL is an application wishing to exploit its functionality must be written explicitly in order to do so (see Resources). Existing applications, which constitute the majority of data producers on the Internet, cannot take advantage of the encryption facilities provided by SSL without being rewritten. Think of the common applications we use everyday: mail clients, web browsers on sites without HTTPS, IRC channels, peer-to-peer file sharing systems and so on. Also, most network services (such as mail relays, DNS servers, routing protocols) currently run over plain sockets, exchanging vital information as clear text and only seldomly adopting application-level counter-measures (mostly integrity checks, such as MD5 sums).

Going one step down the OSI stack, IP Security (IPSec) guarantees the data privacy and integrity of IP packets, regardless of how the application used the sockets. This means any application, as long as it uses IP to send data, will benefit from the underlying secure IP network. Nothing has to be rewritten or modified; it even is possible that users won't be aware their data is being processed through encrypting devices.

This solution is the most transparent one for end users and the one most likely to be adopted in the future in the widest range of situations. The main drawback of IPSsec lies in its intrinsic infrastructural complexity, which demands several components to work properly. IPSec deployment must be planned and carried out by network administrators, and it is less likely to be adopted directly by end users.