R80.x Performance Tuning Tip - AES-NI

[HeikoAnkenbrand]

What is AES-NI

Intel‘s AES New Instructions AES-NI is a encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data in many processor familys.

Comprised of seven new instructions, AES-NI gives your environment faster, more affordable data protection and greater security.

Chapter

More interesting articles:

- R80.x Architecture and Performance Tuning - Link Collection

Appliances and Open Servers with AES-NI

Better throughput can be achieved by selecting a faster encryption algorithm. For a comparison of encryption algorithm speeds, refer to sk73980 - Relative speeds of algorithms for IPsec and SSL.

AES-NI is Intel's dedicated instruction set, which significantly improves the speed of Encrypt-Decrypt actions and allows one to increase AES throughput for:

•       Site-to-Site VPN
•       Remote Access VPN
•       Mobile Access
•       HTTPS Interception

The general speed of the system depends on additional parameters.

Check Point supports AES-NI on many appliances, only when running Gaia OS with 64-bit kernel. On these appliances AES-NI is enabled by default. AES-NI is also supported on Open Servers.

Affected encryption algorithms include:

• AES-CBC (128-bit and 256-bit)
• AES-GCM (128-bit and 256-bit), which shows the most significant improvement - with AES-NI, it is faster than AES-CBC, when both sides support AES-NI. Without AES-NI support, it is slightly slower than AES-CBC + HMAC-SHA1

Check Point supports AES-NI on the most appliances (only when running Gaia OS with 64-bit kernel).
AES-NI is also supported on Open Servers. Make sure that Gaia OS is running in 64-bit mode.

Check if AES-NI is activated

R80.10 - R80.30

Old AES-NI commands with "dmesg" no longer work in R80.40 and R81 (sk170779).

# dmesg | grep "AES-NI"

If it is not available, the following message is displayed:

R80.40 Jumbo HFA 100+ and R81 Jumbo HFA 13+

# fw ctl get int AESNI_is_supporte

0 = not supported
1 = supported

Check AESNI CPU support

It can also be checked if the CPU provides AES-NI. For this the following command should be executed. Here "aes" should now be displayed.

# grep -m1 -o aes /proc/cpuinfo

If AES-NI is not enabled, it must be turned on in the BIOS (if available). Typical way for Open Servers.

AES-NI performance measurement

A little bit of reverse engineering.

Check Point uses OpenSSL as library. Therefore the command "openssl" is provided as "cpopenssl". This gives us the possibility to execute all openssl commands. With this I tested a little bit and came to the conclusion that performance measurements are possible with the following command. So you can test the performance differences with enabled and disabled AES-NI.

Warning notice: If you execute this command you have 100% CPU usage on the firewall for 20 sec.

# cpopenssl speed aes-256-cbc

Enabled AES-NI:

Disabled AES-NI:

After these results I would always recommend to activate AES-NI and AES is preferred to 3DES because it offers many performance advantages through the hardware acceleration.

With the following command you can test and compare all encryption methods. After these results I would always recommend to activate AES-NI and AES is preferred to 3DES because it offers many performance advantages through the hardware acceleration. 

Warning notice: If you execute this command you have 100% CPU usage for a long time!

# cpopenssl speed

This makes it possible to compare encryption algorithms. It shows that e.g. AES 256 is more performant than DES. Therefore AES 256 should rather be used for VPN connections than DES or 3DES. This is also well described in the following SK Relative speeds of algorithms for IPsec and SSL.

References

Relative speeds of algorithms for IPsec and SSL 
Best Practices - VPN Performance 
vSEC Virtual Edition (VE) Gateway support for AES-NI on VMware ESX 
Best Practices - VPN Performance 
MultiCore Support for IPsec VPN in R80.10 and above 

[RamGuy239]

I did test the "cpopenssl speed" command on a 1500 series running R80.20.40 and it seems like both SHA-256 and GCM is getting accelerated:

8192 bytes:

SHA1: 724200.11k
SHA256: 681768.28k
SHA512: 88003.52k

GHASH: 1300073.13k


Running a similar test on a 1400 series running R77.20.87 to compare. I suppose this means the R81.10.00 documentation is misleading? Or is this linked to SecureXL in some way, openssl itself might be able to hardware-accelerate SHA-256 and GCM on Gaia Embedded but it might cause issue with SecureXL so it won't work great in practice regardless?

[RamGuy239]

1500 series

8192 bytes:

SHA1: 724200.11k
SHA256: 681768.28k
SHA512: 88003.52k

GHASH: 1300073.13k
MD5: 250115.41k

1400 series

8192 bytes:

SHA1: 155225.47k
SHA256: 91007.73k
SHA512: 92685.39k

GHASH: 106812.57k
MD5: 235681.27k


In terms of 1400 series running R77.20.87 matters seems worse. Anything other than MD5 or SHA-1 looks to be rather rough for it to handle.

[PhoneBoy]

The SMB appliances use ARM processors, not Intel.
fw accel stat will tell you definitely what can be accelerated in terms of ciphers on an SMB appliance (or any other for that matter).
For example, on my 1590 appliance running R81.10.00, AES-128, AES-256, and AES-XCBC are listed as accelerated.

As for VTIs, I'm not sure, but I suspect you are correct.