IPsec (Internet protocol security) is a suite of protocols that provide network-layer security to a VPN (virtual private network). A VPN is a virtual network that provides a secure communication path between two peers in a public network. The peers can be two hosts, a remote host and a network gateway, or the gateways of two networks, such as the gateway of your corporate network and a ZEN (Zscaler Enforcement Node) in the service.
IPsec provides the following types of protection:
As shown in the following figure, IPsec provides a number of options for applying each type of protection. The peers in the IPsec VPN use a negotiation process called IKE (Internet Key Exchange) to define the security mechanisms they will use to protect their communications. IKE has two phases. In the first phase, the peers define the security parameters they will use to communicate in the second phase. This collection of security parameters is called a security association (SA). In the second phase, the peers define the SA that they will use to protect the actual data exchange.
Following are the types of protection that IPsec provides and their corresponding algorithms.
Learn about the following:
In this type of cryptography, the peers use the same key to encrypt and decrypt packets. When peer A sends a packet to peer B, it first encrypts the data by dividing it into blocks, and then uses the key and data blocks to perform multiple rounds of cryptographic operations. When peer B receives the packet, it uses the same key and performs the same operations in reverse order to decrypt the data.
AES now supersedes DES and 3DES because it has a larger block size and key length. AES uses a 128-bit block size and keys with 128, 192 and 256 bits. DES uses a block size of 64 bits and a key length of 56 bits. Though 3DES has a larger key size, which is 168 bits, it still has the same block size.
IPsec provides authentication and integrity protection through an HMAC (hash message authentication code) algorithm, such as MD5 (Message Digest Algorithm-5) or SHA (Secure Hash Algorithm). This type of algorithm generates a hash (also referred to as a message digest) from the message and a key known to both peers. When peer A sends a message to peer B, it generates the hash and adds it to the packet it sends to peer B. When peer B receives the packet, it uses the shared key to generate the hash and verifies the authenticity and integrity of the packet when the two hashes match.
SHA-1 and SHA-2 are generally considered more secure than MD5 because they generate a larger hash. MD5 generates a 128-bit hash, SHA-1 generates a 160-bit hash, and SHA-2 is a set of four algorithms whose names refer to the size of the hashes they produce, that is SHA2-224, SHA2-256, SHA2-384, and SHA2-512.
IPsec has two main protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). The IPsec peers determine which protocol they will use to encode the data packets in phase 2 of the IKE negotiations. The selected protocol then uses the algorithms and authentication method defined in the IPsec SA to encode the data packets.
AH provides authentication and integrity protection through a keyed hash algorithm, as described in Verifies Packet Integrity. ESP encrypts IP packets as described in Ensures Confidentiality. The earlier version of ESP did not provide authentication and integrity protection, so most IPsec implementations used AH and ESP. But since the current version of ESP can also use a keyed hash algorithm to verify the authenticity and integrity of packets, most IPsec implementations use ESP, but not necessarily AH.
ESP can operate in either of two modes: transport mode or tunnel mode. See image.
As shown in the diagram, ESP adds a header, a trailer, and if authentication is used, an authentication section at the end. The ESP header contains an SPI (Security Parameter Index) value, which is a unique identifier, and a sequence number. The ESP trailer contains fields such as additional bytes for padding and the padding length.
In transport mode, ESP encrypts the data payload and ESP trailer. It uses the original IP header with the original source and destination IP addresses. In implementations that involve communications from or to a gateway, the source and/or destination IP addresses need to be changed to the gateway IP addresses. Since transport mode does not alter the IP header, this mode is used specifically for host-to-host communications.
In tunnel mode, ESP encapsulates the entire packet, including the original IP header. It adds a new IP header that lists the IPsec peers as the source and destination of the packet. ESP tunnel mode is used in VPNs that include at least one gateway, because the gateway address can be specified as the source and/or destination in the new IP header.
During the IKE negotiations, the peers agree on the Diffie-Hellman group number that they use to generate the shared key. Diffie-Hellman is a method for peers to generate a shared key in a secure manner, without having to exchange shared secrets in the first place. Diffie-Hellman specifies group numbers that correspond to a key length and an encryption generator type. For more information on Diffie-Hellman, refer to RFC 2631, Diffie-Hellman Key Agreement Method.
Aggressive Mode is useful when the IP address of the remote device is not known beforehand.
NOTE: For Phase 1, Zscaler supports AES-128, DES or 3DES for the encryption algorithm, and SHA-1 or MD5 for the authentication algorithm. The Zscaler recommended algorithms are AES-128 with SHA-1.
NAT-T provides a method for passing IPsec traffic between two peers when one peer is behind a NAT device. When NAT-T is enabled, the peers detect if there is a NAT device between them and verify that they both support NAT-T during the IKE phase one negotiations.
After both peers determine that they support NAT-T and it is required, they encapsulate the IPsec packets. See image. The new IP header retains the data from the original IPsec packet, except that the protocol changes to UDP. In the UDP header, the source port is set to 500 and the destination port is that of the IPsec peer. Therefore the NAT device processes the encapsulated packet as a UDP packet. The IPsec peer then removes the UDP header and processes the packets as an IPsec packet. For additional information on NAT-T, refer to RFC 3947, Negotiation of NAT-Traversal in the IKE.
Dead peer detection is a method that is used to detect if an IKE peer is offline. When this method is used, the peers do not periodically exchange keep alive messages. Instead, a peer requests proof that the other peer is online only when it needs to send traffic. Dead peer detection decreases the number of messages needed to determine if a peer is alive. Each peer defines its own dead peer detection interval, which is implementation specific. For more information, refer to RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
Because Main mode uses the IP address as part of the exchange for identification, it cannot be used in a configuration where the IP address of the peer may change.
The Phase 2 negotiations are similar to those in Phase 1, wherein the peers negotiate security parameters that includes the encryption and keyed hashed algorithms, and authentication method. Additionally, in this phase, the peers negotiate the IPsec protocol to be applied to the IP packets. They determine whether to use AH, ESP and AH, or ESP. As stated earlier, most VPNs today use ESP.
After the IPsec SA is established, the peers then exchange the IP packets using the security parameters defined in the IPsec SA.
NOTE: For Phase 2, Zscaler supports Null Encryption or AES for the encryption algorithm and MD5 for the authentication algorithm. If you'd like to use AES, you must purchase a separate subscription. Zscaler doesn't recommend using 3DES for Phase 2 encryption. The Zscaler recommended algorithms are Null Encryption with MD5.