IPSec Tunnels

Cisco Secure Policy Manager enables you to use tunnels in two ways:

This chapter contains the following sections:

The IPSec specification allows both AH and ESP to be applied to the data being protected, but with IPSec tunnels based on ESP that is not always necessary. ESP provides an authentication algorithm, called the authenticator, which can be used for data source authentication. The authenticator, however, can be set to null, in which case ESP will not provide data source authentication. In this case, another method of authentication, such as AH, will need to be employed for authentication.

The AH and ESP protocols rely on several keyed encryption and hash algorithms to provide integrity, authentication, and confidentiality. The IPSec specification does not state which algorithm must be used, but it does provide a standard set that must be supported by all implementations of IPSec. This standard allows for the selection of an algorithm based on the needs of the particular implementation of IPSec, as well as the future addition of algorithms as they are developed. The standard set of algorithms used by both AH and ESP for integrity and authentication include HMAC-MD5 and HMAC-SHA. ESP-based tunnels often use the Data Encryption Standard (DES) or Triple Data Encryption Standard (3DES or Triple-DES) algorithms in cipher block chaining mode for encryption.

IPSec provides two methods for determining the keys used by these algorithms: pre-shared key (manual) and Internet Key Exchange (IKE). With a pre-shared key, both tunnel peers must be pre-configured with a shared key and the AH and/or ESP algorithm prior to creating the tunnel. Tunnels created with a shared secret are referred to as manual tunnels. With IKE, both the key and the AH and/or ESP algorithm are negotiated by the tunnel peers prior to creating the tunnel. Tunnels based on the IKE are referred to as IKE tunnels or negotiated tunnels. The benefits of negotiated tunnels include automatic key updates and automatic negotiation of the security algorithms with an IPSec peer. For more information about manual tunnels and IKE tunnels, refer to the following sections:

One benefit of manual tunnels is that they are slightly faster and less resource intensive to set up than IKE tunnels. This is because the tunnel peers already have the tunnel parameters established---the peers do not need to negotiate the key, protocol, and algorithm.

Of course, this does mean that each peer must be properly pre-configured to accept the tunnel from the other. If the parameters of the tunnel are misconfigured on one peer, the tunnels will be unable to communicate. Cisco Secure Policy Manager alleviates this potential problem by using tunnel templates. The tunnel peers are defined in a tunnel group, and the group references a single tunnel template, ensuring that the same tunnel parameters (protocols and algorithms) are used on each peer.

Another problem with manual tunnels is key management. You need to manually select and configure shared keys between all tunnel peers. Every time a new peer is added to the tunnel group, you must manually select and configure keys between that peer and each of the other peers. Consequently, the more manual tunnel peers you add to your network topology, the more complex the task of key administration and tracking becomes. For this reason, manual IPSec tunnels are recommended for smaller networks where key distribution can be kept to a minimum. For larger networks with a large number of tunnels, we recommend that you use IKE tunnels for dynamic negotiations of keys and protocol algorithms.

IKE tunnels use the Diffie-Hellman algorithm to derive a symmetric key for the tunnel peers when creating the tunnel. This key can be given a time-to-live value, after which another key is negotiated, providing perfect forward secrecy to the tunnel. During key negotiation, a hash algorithm is used to verify data integrity and either a certificate or a shared secret is used for data authentication. If a shared secret is used for authentication of the Diffie-Hellman exchange, the shared secret must be pre-configured on the tunnel peers.

One major benefit of using IKE tunnels as opposed to manual tunnels is key management. Because the peers negotiate the key each time a tunnel is created, there is no need to manually maintain and change shared secrets between each tunnel endpoint (unless, of course, you use a shared secret for authentication of the key negotiation). For this reason, on large networks with a large number of tunnel connections, we recommend that you use IKE tunnels with certificate authentication to avoid key management problems.

Another benefit is that each time the tunnel is created, and each time a key's time-to-live value is reached, a new key is generated. Even if one key is derived from the encrypted data, data protected by subsequent keys will remain safe. It also prevents an observer from gaining a large amount of cipher text generated by the same key, which can potentially make the key that encrypted the text easier to decipher.

IKE tunnels are not limited to a single AH and/or ESP protocol. You can create prioritized lists, called proposals, of protocols that are negotiated between the peers when creating the tunnel. For example, you can have a group of three tunnel peers, two of which support 3DES (called PeerA and PeerB) and one of which only supports DES (called PeerC), that you want to connect with an ESP tunnel. On PeerA and PeerB, you can create an initial proposal for 3DES followed by a proposal for DES as the ESP encryption algorithm. On PeerC, you create a single proposal for DES. Whenever PeerA tries to negotiate a tunnel with PeerB, it will use 3DES as the ESP encryption algorithm. When PeerA negotiates a tunnel with PeerC, it will propose using 3DES, to which PeerC will reply with DES. Because DES is an option on PeerA, it will use DES as the ESP encryption algorithm.

This negotiation is prioritized by the administrator setting up the tunnels, not by any inherent property of the algorithms. In the above example, the 3DES and DES proposals could easily have been reversed so that the peers attempt to use DES as the ESP encryption algorithm. In this case, PeerA and PeerB would have used DES.

Cisco Secure Policy Manager facilitates the configuration of IKE tunnel key negotiation and protocol algorithm proposals through the use of tunnel templates. The template enables you to specify the parameters of key negotiation (integrity and authentication algorithms as well as Diffie-Hellman type) and to create prioritized lists of AH and ESP proposals. This template can then be applied to a tunnel group, which defines the tunnel peers, ensuring that all peers in that group are configured with the same IKE configuration.

Of course, negotiation of the key does take time and system resources, so creating an IKE tunnel is more time and resource intensive than creating a manual tunnel. Where speed and resources are a concern, you should consider using manual tunnels.

We begin by defining the key components of IPSec encryption and their role in the encryption process. Next, we describe the different encryption algorithms that IPSec offers. We close our discussion of encryption by describing how IPSec packet encryption works and how to manage the secret master keys used by IPSec.

The simplest mode supported is ECB, also known as block mode. Block mode combines a block of plaintext (64 bits or 8 characters) and a key to yield a block of ciphertext. Every block of plaintext is encrypted independently of preceding blocks. For most communications, this mode is unsuitable because transformation of repetitive plaintext blocks will yield repetitive ciphertext, which is vulnerable to cryptoanalysis that uses a one-for-one substitution (also called a known plaintext attack). However, block mode is the fastest form of encryption that can be supported by DES implementations.

To address the problem of repetitive plaintext, some DES implementations also support one or more chaining modes. In a chaining mode, each block is still encrypted; however, the ciphertext is calculated using a third input, a feedback value based on the previous block of information. As with block mode, the two remaining inputs are the plaintext block and the key. Using chaining modes ensures that the ciphertext appears as a random stream of data, even when the source plaintext contains highly repetitive sequences.

In place of a feedback value for the first block, an initialization vector is used to start the encryption processes. This initialization vector causes bit changes in one block of the plaintext, which propagate into the subsequent ciphertext.

Because chaining modes have distinct starting points where the initialization vector is fed into the calculation, the sender and receiver must synchronize between messages. To do this, the sender and receiver agree on the initialization vector and the key, and a method of signaling the start of a new message.

Errors that occur during transmission (such as changed, dropped, or extra bits in the ciphertext) can introduce synchronization problems. Chaining modes are designed to address these synchronization problems. If the problems are not addressed, the received plaintext stream would be continuously unintelligible.

To address these synchronization problems, all Cisco IPSec solutions use a type of chaining mode for DES-based encryption called CBC. In CBC mode, the ciphertext of each block is the feedback value of the next block. When a bit error occurs in the ciphertext, it does not propagate more than two blocks into the deciphered plaintext. However, CBC does not deal well with lost or extra bits or characters in the ciphertext. Even though this is true, block chaining is still well suited for protocols, such as the IPSec suite, that use packets and datagrams. These higher-layer protocols use a checksum to verify that the ciphertext was received unaltered.

Unlike encryption that takes place in lower-layer protocols (like the data link layer), packet encryption avoids synchronization problems because the chaining process is restarted on each packet. If a receiver misses or ignores some packets, he can still decipher subsequent packets without error because each packet is independent of previous packets from the point of view of the encryption mechanism. A transmission error in one packet will not propagate to subsequent packets.

In packet encryption, the entire message packet is not encrypted, specifically the packet header is not encrypted. Parts of the header must remain unencrypted because the header contains information needed by the recipient to decipher the message. (For example, a recipient communicating with a number of systems may need to see a source address to determine which of several keys to use for decryption.) Moreover, any additional headers appended by lower-layer protocols must remain unencrypted. By not encrypting the protocol headers, the destination address of a datagram remains visible, which allows it to be routed to its proper destination.

For example, you may want HTTP services between a remote office and a main office intranet to be encrypted so that remote office users can access confidential company information from the main office's internal network, yet at the same time permit unencrypted HTTP traffic to the internet.

Before planning your IPSec tunnel implementation, you need to have a solid understanding of the services you want protected by IPSec tunnels, and the sources and destinations of the protected services. This information will serve you later when you begin to write and enforce the security policies that use your IPSec implementation.

IKE Tunnels Benefits

• Simplified Key Management. You do not need to configure and manage the keys used by the tunnel peers to create the tunnel sessions; the keys are negotiated and created when the tunnel is created.

• Protocol Negotiation. IKE tunnels allow the protocol and algorithm to be negotiated at the time the tunnel is created. This means that you can mix devices with various levels of security abilities in your tunnel topology without having to specify exactly how each device will communicate with each other. Instead, you set up a list of preferred protocols and algorithms, and let the devices negotiate the highest supported IPSec settings.

• Key Renegotiation. You can specify the amount of time or the amount of data passed for a key to be valid, after which a new key is negotiated. This provides greater security, because eavesdroppers will only be able to obtain a limited amount of data encrypted or authenticated with a particular key.

IKE Tunnel Drawbacks

• Speed and Resources. IKE tunnels require additional time and processing power to negotiate the key used by the IPSec protocol. This becomes even more of an issue if your key renegotiation settings are set to a low value, causing key negotiation to occur frequently.

• Additional Network Resources/Configuration. If you use certificates to authenticate IKE negotiation, you will need to either install a certificate authority on your network or purchase certificate services from a third-party, and you will need to configure your tunnel endpoints with certificates.

Manual Tunnel Benefits

• Speed. Because manual tunnels are pre-configured with the necessary keys, they do not require the extra processing time and resources for the key negotiation computations.

Manual Tunnel Drawbacks

• Key Management. In large networks, maintaining and changing the manual keys on each tunnel endpoint requires time and effort. For small networks, or large networks with only a few tunnels, this issue is somewhat mitigated by the relatively few number of keys to be managed.

• Security. Unless you change the keys on your tunnel endpoints often, someone attempting an attack against your authenticated/encrypted data will be able to gather a large amount of cipher text, making it statistically easier to derive the keys used to create the cipher text.

• Integrity

• Authentication

• Confidentiality

• Key Derivation

• SHA. SHA produces a 160-bit digest, which is more resistant to brute-force attacks than MD5. It is also more resource intensive than MD5. For implementations that require the highest level of security, use the SHA hash algorithm.

• MD5. MD5 produces a 128-bit digest, which uses less processing time for an overall faster performance than SHA but also is considered to be weaker than SHA.

• Certificate (RSA Encryption). This setting enables two peers to authenticate each other by sharing public keys. The RSA Encryption setting does not provide non-repudiation for IKE negotiation. RSA Encryption may require the use of a certificate authority to authenticate the exchange of public keys if the public keys are not already known by the devices.

• Certificate (RSA Signature). This setting provides non-repudiation for the IKE negotiation, which means that a third party can prove that a communication took place between two peers. RSA Signatures require the use of a certificate authority. Also, RSA Signatures require less processing time than does RSA Encryption.

• Shared Secret. This setting specifies that you want to use a pre-shared key rather than a certificate. Pre-shared keys offer the advantage of being simple to configure in small networks, but in larger networks key management can become time-consuming and difficult.

• DES. DES is faster than triple DES and uses less system resources, but it is also less secure. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.

• Triple DES. We recommend that you use triple DES whenever the software on your tunnel endpoints supports it and where speed or system resources is not an issue. Triple DES, however, is not part of the IPSec standard, so support for triple DES may not be widely implemented. It is also slower than DES and uses more system resources, because it performs three computations on the data being encrypted.

• Group 1. Group 1 uses a 768-bit modulus, which requires less processing time for an overall faster performance.

• Group 2. Group 2 uses a 1024-bit modulus, which requires more processing time than a Diffie-Hellman group 1 computation, but it is more secure.

Use the following information to decide which IPSec protocol to use in your IPSec session implementation:

AH. AH authenticates the entire IP packet, including the IP header on the packet. However, it does not provide confidentiality for the data payload of the packet.

• If all you need is authentication, you should choose AH as the IPSec protocol.

ESP. ESP can provide both authentication and confidentiality services. It uses two separate algorithms to provide these services: a hash algorithm for authentication and a cipher for confidentiality. The difference between AH and ESP authentication is that ESP only authenticates the ESP payload; it does not authenticate the outer IP header. Furthermore, you can use ESP without the authentication services to provide confidentiality services only.

• If you require data confidentiality only in your IPSec tunnel implementation, you should use ESP without authentication. By leaving off the authentication service, you gain some performance speed but lose the authentication service.

• If you need authentication and confidentiality services, use ESP with authentication. It is more resource intensive than ESP without authentication, because it needs to perform another computation for authentication, but you gain the security of authentication. However, if you need stronger authentication (by having the entire IP packet authenticated) and confidentiality, you should use both AH and ESP in your IPSec tunnel implementation.

Both. You can also use both protocols in your IPSec session implementation. When you use both, the ESP protocol is applied to the packet first, and then AH is used to authenticate the entire packet. When using both AH and ESP in your tunnel implementation, you should consider using ESP without authentication services (since authentication is also being provided by the AH protocol) to provide a less resource-intensive implementation.

These protocols define the method used for authentication/encryption, but do not define the algorithm used to achieve that method. Next, you need to decide the algorithms used with each protocol.

• For tunnels using the AH protocol, you must select an authentication algorithm.

• For tunnels using the ESP protocol with authentication, you must select an authentication algorithm and an encryption algorithm.

• For tunnels using the ESP protocol without authentication, you must select an encryption algorithm.

If the tunnels use both AH and ESP protocols, the algorithms must be selected for each protocol.

• HMAC-SHA. This algorithm is considered more secure than HMAC-MD5, but it is also slower. If speed or system resources is a not a concern, you should use HMAC-SHA.

• HMAC-MD5. This algorithm is considered less secure than HMAC-SHA, but it is faster. If speed or system resources is a concern, you should select MD5. If security is a concern, you should select HMAC-MD5.

• DES. DES is faster than triple DES and uses less system resources, but it is also less secure. A tool, called Deep Crack, that can derive a DES key in less than a day has been developed and is available from a variety of sources on the Internet. If you do not need strong data confidentiality, and if system resources or speed is a concern, you should choose DES.

• Triple DES. We recommend that you use triple DES whenever the software on your tunnel endpoints supports it and where speed or system resources is not an issue. Triple DES, however, is not part of the IPSec standard, so support for triple DES may not be widely implemented. It is also slower than DES and uses more of the system resources, because it performs three computations on the data being encrypted.

Note In IKE tunnel configurations, you can specify up to three sets of IPSec protocol proposals to be negotiated when the endpoints are creating the tunnel. If you are not certain whether an endpoint can support triple DES, you can create a proposal that attempts to use triple DES first, and then drops to a proposal using DES if triple DES is not supported.

Note If you are creating both types of tunnels on your network, you should create your Policy Distribution Point-to-Policy Enforcement Point tunnels first, and then your Policy Enforcement Point-to-Policy Enforcement Point tunnels.

Each tunnel usage has unique requirements for set-up and configuration. The following checklists will guide you through the process of configuring tunnels for each usage: