IP Security: Keeping your business private

Without secure communications, much of the commercial potential of the Internet will never be realized because, whether you like it or not, there are people out there who want to know what you are doing. Some may just be curious, while others may want to harm you or your business in some way.

In response to this, we've seen the emergence of all sorts of protocols designed to enhance the security of Internet communications. For example, Secure HTTP is sophisticated and capable of providing fine-grained access control, but it is too complex for network administrators.

Today, the majority of secure Web traffic is protected by Secure Sockets Layer (SSL). SSL can be used with other protocols, such as File Transfer Protocol (FTP). While SSL works well, it applies only to data transmitted at the socket level. And worst of all, SSL requires the client and the server to be SSL-aware.

A more generic solution to secure data exchange is being defined by another protocol, IP Security (IPSec). IPSec is quite ambitious. It defines encryption, authentication and key management to create, in effect, a virtual private network (VPN) session for every connection. In the structure of the Open Systems Interconnection model, IPSec operates at the network layer and doesn't require that applications be IPSec-aware, so all communications are secured.

Grossly simplifying, you could sum up IPSec's operation as two computers exchanging X.509 certificates for authentication and then creating an encrypted tunnel for data transfer.

The difference between regular IP packets and IPSec packets is the addition of an extension header and the encryption of the payload data. There are two parts to the IPSec extension header: the Authentication Header and the Encapsulating Security Payload (ESP) header.

The Authentication Header defines which parameters will be used for authenticating the originator of data, checks integrity and protects the session from protocol replay. Protocol replay is a technique for breaking into systems by recording and replaying an exchange of data.

The ESP header specifies encryption methods and offers limited traffic flow confidentiality. It partially hides the details of how many packets of what size are flowing in which direction. This is important, as traffic flow information can be used to break encryption schemes. It also specifies the encryption and authentication keys and the time frame for which the keys are valid.

These two headers combined are called the Security Association, which describes what are referred to as the "transformations" to be applied to the payload datagram.

A Security Association may be static, containing data that is never changed by the transformation; or dynamic, containing data that is maintained by the transformation and changed whenever a datagram is handled. For example, serial number-based replay prevention and sophisticated encryption systems that change over the course of multiple transactions involve dynamic data.

In either case, to begin a secure session both computers need to determine how they are going to "talk" to each other.

The protocol used to set up the connections is the Internet Key Exchange, yet another Internet Engineering Task Force protocol working its way toward finalization.

If you're getting the idea that this is complicated, you're right. This is why moving IPSec to a standard will take time. And IPSec has processing and management overhead, so it will have to be deployed with care.

IPSec is the best solution on the horizon. It will become the secure communications standard.

See the IETF documents RFC 2401 "Security Architecture for the Internet Protocol" at www.ietf.org/rfc/rfc2401.txt and RFC 2411 "IP Security Document Roadmap" at www.ietf.org/rfc/rfc2411.txt.

Communicate securely to gearhead@gibbs.com.