- Zscaler recommends using IKEv2 protocol wherever possible as it is faster, more secure, and more resilient than IKEv1
- Zscaler recommends using AES-GCM encryption rather than NULL encryption
Zscaler has been supporting IPSec as a traffic forwarding mechanism for many years. During this time, we have introduced multiple options to forward traffic to the Zscaler cloud. These have included Z-tunnel 1.0 aka HTTP-based tunnels, and Z-tunnel 2.0 which brought in the support for TLS/ DTLS-based encrypted tunneling mechanisms. These Z-tunnels are established by the Zscaler Client Connector or the Cloud Connector. GRE or IPSec tunnels have been the methods of choice to forward traffic from office locations, and have been employed by thousands of customers. IPSec tunnels are preferred by organizations that need the added security of encryption, integrity, and authentication of the traffic when it is forwarded to the Zscaler cloud.
Internet Key Exchange (IKE) guidance
IPSec peers negotiate the authentication and encryption algorithms using the Internet Key Exchange (IKE) process. The IKEv1 (RFC 2409) introduced in 1998 was succeeded by IKEv2 (RFC 4306) in 2005, which was updated in 2014 and continues to be updated—with the latest being RFC 8983 in 2021. The IKEv2 updates brought with them numerous advantages over v1, some of which are:
- It requires fewer messages to be exchanged between the peers to establish the modalities for IPSec
- It takes up less bandwidth than IKEv1
- It is more resistant to Denial of Service (DoS) attacks
- It natively supports NAT-Traversal (NAT-T)
- Automatic detection of liveness of IPSec tunnel so IKE connection can be reestablished if necessary
- It supports newer encryption algorithms such as AES-GCM
Some customers have endpoint devices that support only the older standard of IKEv1. Zscaler supports IKEv1 although our recommendation has always been to use the IKEv2 because of the aforementioned reasons. Most modern implementations of IPSec support both IKEv1 and IKEv2. Some operating systems, such as Cisco’s IOS and Juniper’s JUNOS, may need a manual configuration to enable the use of IKEv2. We recommend that customers use IKEv2 when available.
Encryption algorithm guidance
Zscaler supports NULL encryption, AES-CBC, and AES-GCM encryption algorithms. Among these, historically, we have always recommended NULL encryption because the traffic forwarded to the Zscaler cloud egresses to the destination using either HTTPS (> 90% of the traffic) or HTTP without being encrypted any further. However, there are thousands of customers who chose to encrypt the traffic being forwarded to the Zscaler service using an encryption algorithm. Support for AES-GCM, which is a relatively newer encryption standard, was added a few years ago. AES-GCM has the following advantages over the older AES-CBC standard:
- It provides authentication, removing the need for an HMAC SHA hashing function
- It is faster than AES-CBC because it allows parallelization and it uses hardware acceleration such as AES-NI
- AES-GCM is a more modern algorithm. For example, TLS1.3 does not support AES-CBC anymore
- It is not susceptible to some of the attacks that the AES-CBC algorithm can be exploited with, such as padding oracle attacks
It is for the aforementioned reasons that Zscaler is now updating its recommendation to use the AES-GCM encryption algorithm.
Zscaler strives to maintain a high level of security in the service offered to its customers. If you are currently using IKEv1 as the key exchange mechanism for IPSec forwarding to Zscaler, you should upgrade to IKEv2 as soon as possible. If you are using AES-CBC as the encryption algorithm and AES-GCM is available for your IPSec device on-premises, you should move to AES-GCM to take advantage of the improved performance and capabilities. If you are using NULL encryption as per our earlier recommendation, note that you will need to purchase an additional subscription to enable the encryption. You can choose to continue using NULL encryption at no additional cost.
Learn more about Zscaler guidance on traffic forwarding here.