This file is part of the documentation for the Linux FreeS/WAN project.
See the documentation index or project home page for more information.

Linux FreeS/WAN Overview

Sections:

Introduction

This document is an attempt to give an overview of: In brief,
IPSEC provides encryption and authentication services at the IP level of the protocol stack.

There are lots of other IPSEC implementations, some free and some commercial. Because the IPSEC protocols are clearly defined by RFCs, these should all work together. Several companies are co-operating in the S/WAN Secure Wide Area Network project to work out additional details. There is also a VPN Consortium fostering cooperation among companies in this area.

Our project is Free S/WAN for Linux. The objective is to help make IPSEC widespread by providing source code which is freely available under the GNU General Public License and is not subject to US or other nations' export restrictions.

Other documents in the distribution

The directory where you found this document should also contain several others including: Comments on and suggestions for these documents are welcome. Please direct them to the mailing list

About the RFCs (Internet Request For Comment documents)

Large parts of this document are basically a simplified summary of RFC 2401 "Security Architecture for the Internet Protocol", or of other RFCs (notably 2402 to 2412 and 2451) where the details for implementing that architecture are laid out. Readers are strongly encouraged to look at those original sources.

Go here for a list of IPSEC RFCs and information on several ways to obtain them.

The Role of IPSEC

Services provided

The basic idea of IPSEC is to provide security functions (
authentication and encryption) at the IP (Internet Protocol) level. It will be required in IP version 6 (better known as IPng, the next generation) and is optional for the current IP, version 4.

Security protocols at other levels

Authentication and encryption functions can, of course, be provided at other levels. Many security protocols work at levels above IP.
and so on. Other techniques work at levels below IP. For example, data on a communications circuit or an entire network can be encrypted by specialised hardware. This is common practice in high-security applications.

Advantages of IPSEC

There are, however, advantages to doing it at the IP level instead of, or as well as, at other levels.

IPSEC is the most general way to provide these services for the Internet.

IPSEC, however, can protect any protocol running above IP and any medium used below IP. More to the point, it can protect a mixture of protocols running over a complex combination of media. This is the normal situation for Internet communication; IPSEC is the only general solution.

IPSEC can also provide some security services "in the background", with no visible impact on users. To use PGP encryption and signatures on mail, for example, the user must at least:

Some organisations may have smartcards or other methods of handling the first two items above and a PKI (Public Key Infrastructure) working with mail software can automate the third, so the burden on users may not be onerous. But any system will place some requirements on users, and no system can hope to be secure if users are sloppy about meeting those requirements. The author has seen username and password stuck on terminals with post-it notes in an allegedly secure environment, for example.

Limitations of IPSEC

IPSEC is not end-to-end

IPSEC cannot provide the same end-to-end security as systems working at higher levels. If you need mail encrypted from the sender's desktop to the recipient's desktop and decryptable only by the recipient, use
PGP or another such system.

At best, IPSEC encrypts it as it leaves the sender's machine and decrypts it on arrival at the recipient's machine. For some applications, this might be considered equivalent to end-to-end encryption, but only after a thorough security audit of both machines. We suggest that if you need end-to-end encryption, you should use software designed for end-to-end service. You may want to consider using IPSEC for other reasons, but it does not meet your requirement here.

In another common setup, IPSEC encrypts packets at a security gateway machine as they leave the sender's site and decrypts them on arrival at the gateway to the recipient's site. This does not even come close to providing an end-to-end service. In particular, anyone with appropriate privileges on either site's LAN can intercept the message in unencrypted form.

IPSEC cannot do everything

IPSEC also cannot provide all the functions of systems working at higher levels of the protocol stack. If you need a document electronically signed by a particular person, then you need his or her digital signature and a public key cryptosystem to verify it with. Note, however, that IPSEC authentication of the underlying communication can make various attacks on higher-level protocols more difficult. In particular, authentication prevents man-in-the-middle attacks.

IPSEC cannot be secure if your system isn't

System security on IPSEC gateway machines is an essential requirement if IPSEC is to function as designed. No system can be trusted if the underlying machine has been subverted. See books on Unix security such as Garfinkel and Spafford or our web references for Linux security or more general computer security.

Of course, there is another side to this. IPSEC can be a powerful tool for improving system and network security. For example, requiring packet authentication makes various spoofing attacks harder and IPSEC tunnels can be extremely useful for secure remote administration of various things.

Some uses of IPSEC

While IPSEC does not provide all functions of a mail encryption package, it can encrypt your mail. In particular, it can ensure that all mail passing between a pair or a group of sites is encrypted. An attacker looking only at external traffic, without access to anything on or behind the IPSEC gateway, cannot read your mail. He or she is stymied by IPSEC just as he or she would be by PGP.

The advantage is that IPSEC can provide the same protection for anything transmitted over IP. In a corporate network example, PGP lets the branch offices exchange secure mail with head office. SSL and SSH allow them to securely view web pages, connect as terminals to machines, and so on. IPSEC can support all those applications, plus database queries, file sharing (NFS or Windows), other protocols encapsulated in IP (Netware, Appletalk, ...), phone-over-IP, video-over-IP, ... anything-over-IP. The only limitation is that IP Multicast is not yet supported, though there are Internet Draft documents for that.

IPSEC creates secure tunnels through untrusted networks. Sites connected by these tunnels form VPNs, Virtual Private Networks.

IPSEC gateways can be installed wherever they are required.

Which of these, or of the many other possible variants, to use is up to you. IPSEC provides mechanisms; you provide the policy.

No end user action is required for IPSEC security to be used; they don't even have to know about it. The site administrators, of course, do have to know about it and to put some effort into making it work. Poor administration can compromise IPSEC as badly as the post-it notes mentioned above. It seems reasonable, though, for organisations to hope their system administrators are generally both more security-conscious than end users and more able to follow computer security procedures. If not, at least there are fewer of them to educate or replace.

IPSEC can be, and often should be, used with along with security protocols at other levels. If two sites communicate with each other via the Internet, then IPSEC is the obvious way to protect that communication. If two others have a direct link between them, either link encryption or IPSEC would make sense. Choose one or use both. Whatever you use at and below the IP level, use other things as required above that level. Whatever you use above the IP level, consider what can be done with IPSEC to make attacks on the higher levels harder. For example, man-in-the-middle attacks on various protocols become difficult if authentication at packet level is in use on the potential victims' communication channel.

Using authentication without encryption

Where appropriate, IPSEC can provide authentication without encryption. One might do this, for example: Authentication has lower overheads than encryption.

Encryption without authentication is dangerous

Originally, the IPSEC encryption protocol
ESP didn't do integrity checking. It only did encryption. Steve Bellovin found many ways to attack ESP used without authentication. See his paper Problem areas for the IP Security Protocols. To make a secure connection, you had to add an AH Authentication Header as well as ESP. Rather than incur the overhead of several layers (and rather than provide an ESP layer that didn't actually protect the traffic), the IPSEC working group built integrity and replay checking directly into ESP.

Today, typical usage is one of:

Other variants are allowed by the standard, but not much used:
ESP encryption without authentication
Bellovin has demonstrated fatal flaws in this. Do not use.
ESP encryption with AH authentication
This has higher overheads than using the authentication in ESP, and no obvious benefit in most cases. The exception might be a network where AH authentication was widely or universally used. If you're going to do AH to conform with network policy, why authenticate again in the ESP layer?
Authenticate twice, with AH and with ESP
Why? Of course, some folk consider "belt and suspenders" the sensible approach to security. If you're among them, use both protocols here.
ESP authentication without encryption
The standard allows this, calling it "null encryption". FreeS/WAN does not normally support it, but it can be enabled with a kernel configuration option. We recommend that you use AH instead if authentication is all you require.

Multiple layers of IPSEC processing are possible

The above describes combinations possible on a single IPSEC connection. In a complex network you may have several layers of IPSEC in play, with any of the above combinations at each layer.

For example, a connection from a desktop machine to a database server might require AH authentication. Working with other host, network and database security measures, AH might be just the thing for access control. You might decide not to use ESP encryption on such packets, since it uses resources and might complicate network debugging. Within the site where the server is, then, only AH would be used on those packets.

Users at another office, however, might have their whole connection (AH headers and all) passing over an IPSEC tunnel connecting their office to the one with the database server. Such a tunnel should use ESP encryption and authentication. You need authentication in this layer because without authentication the encryption is vulnerable and the gateway cannot verify the AH authentication. The AH is between client and database server; the gateways aren't party to it.

In this situation, some packets would get multiple layers of IPSEC applied to them, AH on an end-to-end client-to-server basis and ESP from one office's security gateway to the other.

Using "unnecessary" encryption to frustrate attackers

One might choose to use encryption even where it appears unnecessary in order to make certain attacks more difficult. Consider two offices which pass a small volume of business data between them using IPSEC and also transfer large volumes of Usenet news. At first glance, it would seem silly to encrypt the newsfeed, except possibly for any newsgroups that are internal to the company. Why encrypt data that is all publically available from many sites?

However, if we encrypt a lot of news and send it down the same connection as our business data, we make traffic analysis much harder. A snoop cannot now make inferences based on patterns in the volume, direction, sizes, sender, destination, or timing of our business messages. Those messages are hidden in a mass of news messages encapsulated in the same way.

Of course, if we're going to do this we need to ensure that keys change often enough to remain secure even with high volumes and with the adversary able to get plaintext of much of the data. We also need to look at what information the adversary might gain by snooping on our incoming non-encrypted newsfeeds and comparing things there to the encrypted version.

IPSEC projects

Vendor Groups

VPN Consortium

The
Virtual Private Network Consortium is an association for vendors of VPN products, most of which are based on IPSEC.

S/WAN (Secure Wide Area Networks)

S/WAN is an initiative of RSA Data Security and a number of other companies, mainly vendors of firewalls and other security products. The focus is on testing interoperability and sorting out details so that the players' implementations of IPSEC will work with each other.

Linux FreeS/WAN

Our project leader's reasons for starting this project are described on
his web site. A slightly edited version is included in our document set as this document.

Essentially, we are trying to create IPSEC code not burdened with any obstructions to widespread use:

and especially Note that in order to avoid even the appearance of being subject to those laws, the project cannot accept software contributions -- not even one-line bug fixes -- from US residents or citizens.

The goal is to make Internet "wiretapping" entirely impractical.

IPSEC is designed to support (among other things) VPNs or virtual private networks, which allow multiple sites from an organisation (optionally, and its clients, suppliers, etc.) to communicate securely over an insecure Internet by encrypting all communication between the sites. We want to extend that to a real private network in which anyone who choses to communicate securely can do so, in which strong encryption is universally available.

A long-term goal of this project is to support opportunistic encryption, an infrastructure in which any two sites can secure their communications even if they have no previous arrangements made to do so. This will depend on using Secure DNS services to authenticate the sites so that they can safely create keys via the Diffie-Hellman key agreement protocol. Our current release does not support this, however.

Other projects

There are many other IPSEC implementation and testing projects going on.

IPSEC Services, AH and ESP

IPSEC offers two services,
authentication and encryption. These can be used separately but are often used together.
Authentication
Authentication allows you to be confident that a packet came from a particular machine and that its contents were not altered en route to you. No attempt is made to conceal or protect the contents, only to assure their integrity.

Authentication can be provided separately using an Athentication Header, described just below, or it can be included as part of the ESP (Encapsulated Security Payload) service, described in the following section. That service offers encryption as well as authentication.

Encryption
Encryption allows you to conceal the contents of a message from eavesdroppers.

In IPSEC this is done using a block cipher (normally Triple DES for Linux FreeS/WAN). In the most used setup, keys are automatically negotiated, and periodically re-negotiated, using the IKE (Internet Key Exchange) protocol. In Linux FreeS/WAN this is handled by the Pluto Daemon.

The IPSEC protocol offerring encryption is ESP, Encapsulated Security Payload. It can also include an authentication service.

Note that encryption should always be used in conjunction with some authentication service to prevent man-in-the-middle attacks. Also that encryption does not necessarily prevent traffic analysis.

The Authentication Header (AH)

Authentication service can be provided separately from encryption by adding an authentication header (AH) after the IP header but before the other headers on the packet. This is the subject of this section. Details are in RFC 2402.

Headers on a packet are connected by a linked list where each header contains a "next protocol" field telling the system what header to look for next. IP headers generally have either TCP or UDP in this field. When IPSEC authentication is used, the packet IP header has AH in the field and the authentication header has the next header type -- usually TCP, UDP or encapsulated IP.

IPSEC authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC:

                  BEFORE APPLYING AH
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                  AFTER APPLYING AH
            ---------------------------------
      IPv4  |orig IP hdr  |    |     |      |
            |(any options)| AH | TCP | Data |
            ---------------------------------
            |<------- authenticated ------->|
                 except for mutable fields
Athentication can also be used in tunnel mode, encapsulating the underlying IP packet beneath AH and an additional IP header.
                         |<-- original IP packet --->|
IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
      |(any options)| AH | (any options) |TCP | Data |
      ------------------------------------------------
      |<- authenticated except for mutable fields -->|
      |           in the new IP hdr                  |
This would normally be used in a gateway-to-gateway tunnel. The receiving gateway then strips the outer IP header and the AH header and forwards the inner IP packet.

The mutable fields referred to are things like the time-to-live field in the IP header. These cannot be included in authentication calculations because they change as the packet travels.

Keyed MD5 and Keyed SHA

The actual authentication data in the header is typically 96 bits and depends both on a secret shared between sender and receiver and on every byte of the data being authenticated.

The algorithms involved are the MD5 Message Digest algorithm or SHA, the Secure Hash Algorithm. For details on their use in this application, see RFCs 1828 and 1852 respectively.

For descriptions of the algorithms themselves, see RFC 1321 for MD5 and FIPS (Federal Information Processing Standard) number 186 from NIST, the US National Institute of Standards and Technology for SHA. Applied Cryptography covers both in some detail, MD5 starting on page 436 and SHA on 442.

These algorithms are used to make it nearly impossible for anyone to alter the authenticated data in transit. The sender calculates a digest or hash value from that data and includes the result in the authentication header. The recipient does the same calculation and compares results. For unchanged data, the results will be identical. The hash algorithms are designed to make it extremely difficult to change the data in any way and still get the correct hash.

Since the shared secret key is also used in both calculations, an interceptor cannot simply alter the authenticated data and change the hash value to match. Without the key, he or she (or even the dreaded They) cannot produce a usable hash.

Sequence numbers

The authentication header includes a sequence number field which the sender is required to increment for each packet. The receiver can ignore it or use it to check that packets are indeed arriving in the expected sequence.

This provides partial protection against replay attacks in which an attacker resends intercepted packets in an effort to confuse or subvert the receiver. Complete protection is not possible since it is necessary to handle legitmate packets which are lost, duplicated, or delivered out of order, but use of sequence numbers makes the attack much more difficult.

In Linux FreeS/WAN, the sequence number is ignored for manually keyed connections and checked for automatically keyed ones. The RFCs require that sequence numbers never cycle, that a new key always be negotiated before the sequence number reaches 2^32-1. This protects against birthday attacks. In automatic mode, we do that. In manual mode, there is no way to negotiate a new key, so we don't use sequence numbers.

Encapsulated Security Payload (ESP)

The ESP protocol is defined in RFC 2406. It provides one or both of encryption and authentication. It may be used with or without AH authentication.

Note that some form of authentication should always be used whenever data is encrypted. Without authentication, the encryption is vulnerable to active attacks which may allow an enemy to break the encryption. ESP should always either include its own authentication or be used with AH authentication.

The RFCs require support for only two mandatory encryption algorithms -- DES, and null encryption -- and for two authentication methods -- keyed MD5 and keyed SHA. Implementers may choose to support additional algorithms in either category.

The authentication algorithms are the same ones used in the IPSEC authentication header.

We implement both of the required encryption algorithms but also triple DES or 3DES. We very strongly recommend that only triple DES be used since DES is insecure.

IPSEC modes

Tunnel mode

Security gateways are required to support tunnel mode connections. In this mode the gateways provide tunnels for use by client machines behind the gateways. The client machines need not do any IPSEC processing; all they have to do is route things to gateways.

Transport mode

Host machines (as opposed to security gateways) with IPSEC implementations must also support transport mode. In this mode, the host does its own IPSEC processing and routes some packets via IPSEC.

FreeS/WAN parts

KLIPS: Kernel IPSEC Support

KLIPS is KerneL IPSEC Support, the modifications necessary to support IPSEC within the Linux kernel.

The Pluto daemon

Pluto is a daemon which implements the IKE protocol. It verifies identities, chooses security policies, and negotiates keys for the KLIPS layer.

The ipsec(8) command

The ipsec(8) command is a front end that allows control over IPSEC activity.

Linux FreeS/WAN configuration file

The configuration file for
Linux FreeS/WAN is
	/etc/ipsec.conf
For details of editing it see the ipsec.conf(5) manual page and our Setup and Configuration HTML documents.

Key management

There are several ways IPSEC can manage keys. Not all are implemented in Linux FreeS/WAN.

Currently Implemented Methods

Manual keying

IPSEC allows keys to be manually set. In Linux FreeS/WAN, such keys are stored with the connection definitions in /etc/ipsec.conf.

Manual keying is useful for debugging since it allows you to test the KLIPS kernel IPSEC code without the Pluto daemon doing key negotiation.

In general, however, automatic keying is preferred because it is more secure.

Automatic keying

In automatic keying, the Pluto daemon negotiates keys using the IKE Internet Key Exchange protocol. Connections are automatically re-keyed periodically.

This is considerably more secure than manual keying. In either case an attacker who acquires a key can read every message encrypted with that key, but automatic keys can be changed every few hours or even every few minutes without breaking the connection or requiring intervention by the system administrators. Manual keys can only be changed manually; you need to shut down the connection and have the two admins make changes. Moreover, they have to communicate the new keys securely, perhaps with PGP or SSH. This may be possible in some cases, but as a general solution it is expensive, bothersome and unreliable. Far better to let Pluto handle these chores; no doubt the administrators have enough to do.

Also, automatic keying is inherently more secure against an attacker who manages to subvert your gateway system. If manual keying is in use and an adversary acquires root privilege on your gateway, he reads your keys from /etc/ipsec.conf and then reads all messages encrypted with those keys.

If automatic keying is used, an adversary with the same privileges can read /etc/ipsec.secrets, but this does not contain any keys, only the secrets used to authenticate key exchanges. Having an adversary able to authenticate your key exchanges need not worry you overmuch. Just having the secrets does not give him any keys. You are still secure against passive attacks. This property of automatic keying is called perfect forward secrecy, abbreviated PFS.

Unfortunately, having the secrets does allow an active attack, specifically a man-in-the-middle attack. Losing these secrets to an attacker may not be quite as disastrous as losing the actual keys, but it is still a serious security breach. These secrets should be guarded as carefully as keys.

Methods not yet implemented

Unauthenticated key exchange

It would be possible to exchange keys without authenticating the players. This would support
opportunistic encryption -- allowing any two systems to encrypt their communications without requiring a shared PKI or a previously negotiated secret -- and would be secure against passive attacks. It would, however, be highly vulnerable to active man-in-the-middle attacks. RFC 2408 therefore specifies that all ISAKMP key management interactions must be authenticated.

There is room for debate here. Should we provide immediate security against passive attacks and encourage widespread use of encryption, at the expense of risking the more difficult active attacks? Or should we wait until we can implement a solution that can both be widespread and offer security against active attacks?

So far, we have chosen the second course, complying with the RFCs and waiting for secure DNS (see below) so that we can do opportunistic encryption right.

The Internet default shared secret

An Internet Draft proposes a default key which could allow the authentication protocol to succeed with a unknown partner, while not providing any actual authentication.

This has essentially the same properties as an unauthenticated exchange. It allows opportunistic encryption, protects against passive attacks, and fails against active attacks. It might, however, be considered to fall within "the letter of the law" as far as RFC 2408 is concerned, since it does go through the motions of authentication.

So far, we have chosen not to do this either.

Key exchange using DNS

The IPSEC RFCs allow key exchange based on authentication services provided by Secure DNS. Once Secure DNS service becomes widely available, we expect to make this the primary key management method for Linux FreeS/WAN. It is the best way we know of to support opportunistic encryption, allowing two systems without a common PKI or previous negotiation to secure their communication.

Key exchange using a PKI

The IPSEC RFCs allow key exchange based on authentication services provided by a
PKI or Public Key Infrastructure. With many vendors selling such products and many large organisations building these infrastructures, this will clearly be an important application of IPSEC and one Linux FreeS/WAN will eventually support.

On the other hand, this is not as high a priority for Linux FreeS/WAN as solutions based on secure DNS. We do not expect any PKI to become as universal as DNS. Adding support for PKIs might be a good project for volunteers.

Photuris

Photuris is another key management protocol, an alternative to IKE and ISAKMP, described in RFCs 2522 and 2523 which are labelled "experimental". Adding Photuris support to Linux FreeS/WAN might be a good project for a volunteer. The likely starting point would be the OpenBSD photurisd code.

SKIP

SKIP is yet another key management protocol, developed by Sun. At one point it was fairly widely used, but our current impression is that it is moribund, displaced by IKE. We therefore have no plans to implement it. Adding it might be a good project for a volunteer.
Click below to go to: