IPsec

IPsec is Internet Protocol Security; it is optional for IPv4, but all IPv6 implementations are required to include IPsec. Of course this does not mean all IPv6 systems will actually use it.

The basic idea is to provide security functions, authentication and encryption, at the IP (Internet Protocol) level. This requires a higher-level protocol (IKE) to set things up for the IP-level services (ESP and AH).

Protocols and phases

Three protocols may be used in an IPsec implementation:

• ESP, Encapsulating Security Payload, encrypts and/or authenticates data
• AH, Authentication Header, provides a packet authentication service. No longer widely used,
• IKE, Internet Key Exchange, negotiates connection parameters, including keys, for the other two using a Diffie-Hellman tecnique

The term "IPsec" (also written as IPSEC) is slightly ambiguous. In some contexts, it includes all three of the above but in other contexts it refers only to AH and ESP.

There is more detail below, but a quick summary of how the whole thing works is:

• Phase one IKE (main mode exchange) — sets up a keying channel, called an ISAKMP Security Association (SA), between the two gateways
• Phase two IKE (quick mode exchange) — sets up data channels (IPsec SAs)
• IPsec proper — exchanges data using AH and/or ESP

Both phases of IKE are repeated periodically to automate re-keying.

The role of IPsec

Authentication and encryption functions for network data can, of course, be provided at other levels. Many security protocols work at levels above IP.

   * PGP encrypts and authenticates mail messages
   * SSH authenticates remote logins and then encrypts the session
   * SSL or TLS provides security at the sockets layer, e.g. for secure web browsing

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.

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. Higher-level services protect a single protocol; for example PGP protects mail. Lower level services protect a single medium; for example a pair of encryption boxes on the ends of a line make wiretaps on that line useless unless the attacker is capable of breaking the encryption. IPsec can protect any protocol running above IP and any medium which IP runs over. More to the point, it can protect a mixture of application 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 remember his or her passphrase, keep the passphrase secure, and follow procedures to validate correspondents' keys. These systems can be designed so that the burden on users is not onerous, but any system will place some requirements on users. No such 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.

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.

Limitations of IPsec

IPsec is designed to secure IP links between machines. It does that well, but it is important to remember that there are many things it does not do. Some of the important limitations are:

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.

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.

IPsec is not end-to-end: IPsec cannot provide the same end-to-end security as systems working at higher levels. IPsec encrypts an IP connection between two machines, which is quite a different thing than encrypting messages between users or between applications.

For example, 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. IPsec can encrypt any or all of the links involved -- between the two mail servers, or between either server and its clients. It could even be used to secure a direct IP link from the sender's desktop machine to the recipient's, cutting out any sort of network snoop. What it cannot ensure is end-to-end user-to-user security. If only IPsec is used to secure mail, then anyone with appropriate privileges on any machine where that mail is stored (at either end or on any store-and-forward servers in the path) can read it.

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 provide a useful security service -- only encrypted data is passed over the Internet -- but it 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 also cannot provide all the functions of systems working at higher levels. 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 authenticates machines, not users. IPsec uses strong authentication mechanisms to control which messages go to which machines, but it does not have the concept of user ID, which is vital to many other security mechansims and policies. This means some care must be taken in fitting the various security mechansims on a network together. For example, if you need to control which users access your database server, you need some non-IPsec mechansim for that. IPsec can control which machines connect to the server, and can ensure that data transfer to those machines is done securely, but that is all. Either the client machines must all have strong controls on user access or there must be some form of user authentication to the database, independent of IPsec; in many cases you may need both.

IPsec does not stop denial of service attacks. Denial of service attacks aim at causing a system to crash, overload, or become confused so that legitimate users cannot get whatever services the system is supposed to provide. These are quite different from attacks in which the attacker seeks either to use the service himself or to subvert the service into delivering incorrect results. IPsec shifts the ground for DoS attacks; the attacks possible against systems using IPsec are different than those that might be used against other systems. It does not, however, eliminate the possibility of such attacks.

IPsec does not stop traffic analysis Traffic analysis is the attempt to derive intelligence from messages without regard for their contents. In the case of IPsec, it would mean analysis based on things visible in the unencrypted headers of encrypted packets -- source and destination gateway addresses, packet size, et cetera. Given the resources to acquire such data and some skill in analysing it (both of which any national intelligence agency should have), this can be a very powerful technique.

IPsec is not designed to defend against this. Partial defenses are certainly possible, but it is not clear that any complete defense can be provided.

IPsec is a general mechanism for securing IP

While IPsec does not provide all the functions, or all the security, 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. One organisation might choose to install IPsec only on firewalls between their LANs and the Internet; this would allow them to create a VPN linking several offices and would provide protection against anyone outside their sites. Another might install IPsec on departmental servers so everything on the corporate backbone net was encrypted; this would protect messages on that net from everyone except the sending and receiving department. Another organisation might be less concerned with information secrecy and more with controlling access to certain resources; they might use IPsec packet authentication as part of an access control mechanism, with or without also using the IPsec encryption service. It is even possible (assuming adequate processing power and an IPsec implementation in each node) to make every machine its own IPsec gateway so that everything on a LAN is encrypted; this protects information from everyone outside the sending and receiving machine.

These techniques can be combined in various ways. One might, for example, require authentication everywhere on a network while using encryption only for a few links. In a complex network you may have several layers of IPsec in play, with different security requirements and IPsec policies at each layer. Which of these, or of the many other possible variants, to use is up to you. IPsec provides mechanisms; you provide the policy.

IPsec usage

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.

Normal use: ESP encryption + authentication

Today, typical usage is ESP for encryption and authentication.

Authentication without encryption

IPsec can provide authentication without encryption, via an AH-only connection or ESP using null 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" [1]. 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.

Other combinations

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, you might use both protocols here. You might also use both to satisfy different parts of a security policy. For example, an organisation might require AH authentication everywhere but two users within the organisation might use ESP as well.
• ESP authentication without encryption The standard allows this, calling it "null encryption". Not all implementations support it.
• AH for authentication alone: AH authenticates parts of the IP header, which ESP-null does not do.

There have been suggestions that AH be dropped entirely from the IPsec specifications since ESP and null encryption can handle that situation. It is not clear whether this will occur.

Cryptographic components

IPsec combines a number of cryptographic techniques, all of them well-known and well-analyzed. The overall design approach was conservative; no new or poorly-understood components were included.

This section gives a brief overview of each technique. It is intended only as an introduction. There is more information, and links to related topics, in our glossary. See also our bibliography and cryptography web links. Block ciphers

The encryption in the ESP encapsulation protocol is done with a block cipher.

We do not implement single DES. It is insecure. Our default, and currently only, block cipher is triple DES .

The Rijndael block cipher has won the AES competition to choose a relacement for DES. It will almost certainly be added to FreeS/WAN and to other IPsec implementations. Patches are already available. Hash functions The HMAC construct

IPsec packet authentication is done with the HMAC construct. This is not just a hash of the packet data, but a more complex operation which uses both a hashing algorithm and a key. It therefore does more than a simple hash would. A simple hash would only tell you that the packet data was not changed in transit, or that whoever changed it also regenerated the hash. An HMAC also tells you that the sender knew the HMAC key.

For IPsec HMAC, the output of the hash algorithm is truncated to 96 bits. This saves some space in the packets. More important, it prevents an attacker from seeing all the hash output bits and perhaps creating some sort of attack based on that knowledge. Choice of hash algorithm

The IPsec RFCs require two hash algorithms -- MD5 and SHA-1 -- both of which FreeS/WAN implements.

Various other algorithms -- such as RIPEMD and Tiger -- are listed in the RFCs as optional. None of these are in the FreeS/WAN distribution, or are likely to be added, although user patches exist for several of them.

Additional hash algorithms -- SHA-256, SHA-384 and SHA-512 -- may be required to give hash strength matching the strength of AES. These are likely to be added to FreeS/WAN along with AES. Diffie-Hellman key agreement

The Diffie-Hellman key agreement protocol allows two parties (A and B or Alice and Bob) to agree on a key in such a way that an eavesdropper who intercepts the entire conversation cannot learn the key.

The protocol is based on the discrete logarithm problem and is therefore thought to be secure. Mathematicians have been working on that problem for years and seem no closer to a solution, though there is no proof that an efficient solution is impossible. RSA authentication

The RSA algorithm (named for its inventors -- Rivest, Shamir and Adleman) is a very widely used public key cryptographic technique. It is used in IPsec as one method of authenticating gateways for Diffie-Hellman key negotiation. Structure of IPsec

Three protocols may be used in an IPsec implementation:

ESP, Encapsulating Security Payload

   Encrypts and/or authenticates data

AH, Authentication Header

   Provides a packet authentication service. No longer widely used, AH is not included with FreeS/WAN 2.05 or newer.

IKE, Internet Key Exchange

   Negotiates connection parameters, including keys, for the other two

The term "IPsec" is slightly ambiguous. In some contexts, it includes all three of the above but in other contexts it refers only to AH and ESP. IKE (Internet Key Exchange)

The IKE protocol sets up IPsec (ESP or AH) connections after negotiating appropriate parameters (algorithms to be used, keys, connection lifetimes) for them. This is done by exchanging packets on UDP port 500 between the two gateways.

IKE (RFC 2409) was the outcome of a long, complex process in which quite a number of protocols were proposed and debated. Oversimplifying mildly, IKE combines:

ISAKMP (RFC 2408)

   The Internet Security A ssociation and Key Management Protocol manages negotiation of connections and defines SAs (Security Associations) as a means of describing connection properties.

IPsec DOI for ISAKMP (RFC 2407)

   A Domain Of I nterpretation fills in the details necessary to turn the rather abstract ISAKMP protocol into a more tightly specified protocol, so it becomes applicable in a particular domain.

Oakley key determination protocol (RFC 2412)

   Oakley creates keys using the Diffie-Hellman key agreement protocol.

For all the details, you would need to read the four RFCs just mentioned (over 200 pages) and a number of others. We give a summary below, but it is far from complete. Phases of IKE

IKE negotiations have two phases.

Phase one

   The two gateways negotiate and set up a two-way ISAKMP SA which they can then use to handle phase two negotiations. One such SA between a pair of gateways can handle negotiations for multiple tunnels.

Phase two

   Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH) SAs as required. IPsec SAs are unidirectional (a different key is used in each direction) and are always negotiated in pairs to handle two-way traffic. There may be more than one pair defined between two gateways.

Both of these phases use the UDP protocol and port 500 for their negotiations.

After both IKE phases are complete, you have IPsec SAs to carry your encrypted data. These use the ESP or AH protocols. These protocols do not have ports. Ports apply only to UDP or TCP.

The IKE protocol is designed to be extremely flexible. Among the things that can be negotiated (separately for each SA) are:

   * SA lifetime before rekeying
   * encryption algorithm used. We currently support only triple DES. Single DES is insecure. The RFCs say you MUST do DES, SHOULD do 3DES and MAY do various others. We do not do any of the others.
   * authentication algorithms. We support MD5 and SHA. These are the two the RFCs require.
   * choice of group for Diffie-Hellman key agreement. We currently support Groups 2 and 5 (which are defined modulo primes of various lengths) and do not support Group 1 (defined modulo a shorter prime, and therefore cryptographically weak) or groups 3 and 4 (defined using elliptic curves). The RFCs require only Group 1.

The protocol also allows implementations to add their own encryption algorithms, authentication algorithms or Diffie-Hellman groups. We do not support any such extensions, but there are some patches that do.

There are a number of complications:

   * The gateways must be able to authenticate each other's identities before they can create a secure connection. This host authentication is part of phase one negotiations, and is a required prerequisite for packet authentication used later. Host authentication can be done in a variety of ways. Those supported by FreeS/WAN are discussed in our advanced configuration document.
   * Phase one can be done in two ways.
         o Main Mode is required by the RFCs and supported in FreeS/WAN. It uses a 6-packet exzchange.
         o Aggressive Mode is somewhat faster (only 3 packets) but reveals more to an eavesdropper. This is optional in the RFCs, not currently supported by FreeS/WAN, and not likely to be.
   * A new group exchange may take place after phase one but before phase two, defining an additional group for use in the Diffie-Hellman key agreement part of phase two. FreeS/WAN does not currently support this.
   * Phase two always uses Quick Mode, but there are two variants of that:
         o One variant provides Perfect Forward Secrecy (PFS). An attacker that obtains your long-term host authentication key does not immediately get any of your short-term packet encryption of packet authentication keys. He must conduct another successful attack each time you rekey to get the short-term keys. Having some short-term keys does not help him learn others. In particular, breaking your system today does not let him read messages he archived yestarday, assuming you've changed short-term keys in the meanwhile. We enable PFS as the default.
         o The other variant disables PFS and is therefore slightly faster. We do not recommend this since it is less secure, but FreeS/WAN does support it. You can enable it with a pfs=no statement in ipsec.conf(5).
         o The protocol provides no way to negotiate which variant will be used. If one gateway is set for PFS and the other is not, the negotiation fails. This has proved a fairly common source of interoperation problems.
   * Several types of notification message may be sent by either side during either phase, or later. FreeS/WAN does not currently support these, but they are a likely addition in future releases.
   * There is a commit flag which may optionally be set on some messages. The errata page for the RFCs includes two changes related to this, one to clarify the description of its use and one to block a denial of service attack which uses it. We currently do not implement this feature.

These complications can of course lead to problems, particularly when two different implementations attempt to interoperate. For example, we have seen problems such as:

   * Some implementations (often products crippled by export laws) have the insecure DES algorithm as their only supported encryption method. Other parts of our documentation discuss the reasons we do not implement single DES, and how to cope with crippled products.
   * Windows 2000 IPsec tries to negotiate using Aggressive Mode, which we don't support. Later on, it uses the commit bit, which we also don't support.
   * Various implementations disable PFS by default, and therefore will not talk to FreeS/WAN until you either turn on PFS on their end or turn it off in FreeS/WAN with a pfs=no entry in the connection description.
   * FreeS/WAN's interaction with PGPnet is complicated by their use of notification messages we do not yet support.

Despite this, we do interoperate successfully with many implementations, including both Windows 2000 and PGPnet. Details are in our interoperability document.