topic Re: R80.x Performance Tuning Tip - AES-NI in General Topics

R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Fri, 11 Jun 2021 19:03:32 GMT

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

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 07 Nov 2018 17:36:16 GMT

What I noticed was, that R80.20 uses a 1 year old openssl version. I think R&D should look at that.

# cpopenssl version

Re: R80.x Performance Tuning Tip - AES-NI

Vladimir — Wed, 07 Nov 2018 17:57:27 GMT

Heiko,

Great write-up! Thank you.

Do you happen to know if AES-NI is working in VSX?

If it does, is it a global setting for the parent host or is it working on per-VS basis?

Re: R80.x Performance Tuning Tip - AES-NI

Sandro_Gerdel — Wed, 07 Nov 2018 19:21:41 GMT

Hi ,

Am I getting this right?

From your point of view it makes more sense to use AES256 for VPN than 3DES. Is that correct?

Cheers

Sandro

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 07 Nov 2018 19:27:19 GMT

Hi Sandro,

Yes, according to SK and my tests, AES256 with AES-NI should be more effective.

More see here: Relative speeds of algorithms for IPsec and SSL

Regards

Heiko

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 07 Nov 2018 19:33:44 GMT

Hi Vladimir.

I can't say that 100% because the R&D guys should say something. But I think so, because this is actually on the operating system level. Here the linux crypto API is provided or the openssl crypto library.

Regards

Heiko

Re: R80.x Performance Tuning Tip - AES-NI

Danny — Wed, 07 Nov 2018 20:54:48 GMT

Note: Tim wrote on page 44 of his Security Gateway Performance Optimization presentation that large amounts of IPSec VPN traffic using algorithms SHA-384, AES-GCM-128 or AES-GCM-256 can cause an elevated percentage of traffic to be handled by SecureXL in F2F (Slow path).

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 07 Nov 2018 21:37:48 GMT

Hi Danny,

I agree with you and Timothy.

IPSec VPN trafic utlizing the AES-128 or AES-256 algorithms does not require handling in F2F (Slow path). I always use AES-256 for site to site VPN. Here I get the best performance (AES-NI) with a good security level.

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 07 Nov 2018 21:49:35 GMT

When SecureXL is enabled, Encrypt-Decrypt actions usually take place on SecureXL level (on CPU cores running as CoreXL SND). All VPN traffic will be handled on the CPU cores running as CoreXL SND under the following conditions:

Only "Firewall" and "IPSec VPN" software blades are enabled
There are no fragmented packets
SecureXL acceleration is not disabled by any of the security rules (refer to sk32578)
VPN features that are disqualified from SecureXL (see below) are disabled

If all the above conditions are met, all VPN traffic will be handled on CPU cores running as CoreXL SND with minimum traffic being forwarded to the CoreXL FW instances, resulting in multi-core processing of VPN traffic (depending on the number of CPU cores running as CoreXL SND).

The following VPN features are handled by CPU cores running as CoreXL FW instances:

Fragmented VPN packets
Any compression algorithms (go to IPSec VPN Community properties - "Advanced Settings" pane - "Advanced VPN Properties")
Using HMAC-SHA384 for data integrity and authentication (refer to sk104578)
Any transport mode SA (used in L2TP clients and GRE tunnels)
Multicast IPsec (GDOI)
Monitoring Software Blade - if in addition to "System Counters", also "Traffic" counters are enabled in Security Gateway object (in such a case, connections are flagged with "Accounting" flag in the output of "fwaccel conns" command)
Any Software Blades other than "Firewall" are used

Note:

With R80.20 fragmented packets do not necessarily have to run over the F2F path. With fragmented VPN packets under R80.20 I'm not sure which way they go.

More see here: Best Practices - VPN Performance

Re: R80.x Performance Tuning Tip - AES-NI

Alexander_Wilke — Wed, 14 Nov 2018 14:03:10 GMT

Hi,

I am really shocked and worried that you are still talking and comparing Speed with DES and 3DES. No matter what Speed DES and 3DES has it is insecure and should never be used anymore - independent if it is faster or not. My opinion!

Re: R80.x Performance Tuning Tip - AES-NI

Alexander_Wilke — Wed, 14 Nov 2018 14:04:19 GMT

You can check OpenSSH version and you will be surprised ... 😉

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Wed, 14 Nov 2018 18:06:44 GMT

Hi Alexander,

The statement I find great.

Point 1:
I totally agree with you. DES, 3DES, SHA1, RC4,… should not be used anymore. That is also a clear recommendation in all my concepts. Now reality is catching up with us. Many firewall environments still use 3DES because the administrators have work with the change to AES-256. I think about 40% of the firewalls I see are still using 3DES. Secure Client connection is also used 3DES as default for phase 2 (see picture) in R80.20. I think it's a security issue.

Point 2:

Performance and security is a difficult issue in firewall tuning. There is a fine line between more security and high performance. This article is about performance and in this case the more powerful AES-256 encryption is also the safer one. It couldn't be better:-)

Point 3:

Please have a look at what Check Point offers with IPSec VPN in phase 1 and phase 2 in R80.20. Here DES and 3DES are still provided.

From my point of view, DES and 3DES will continue to exist for a long time. Why? Many other manufacturers do not manage to implement high encryption standards. These are often seen in medical sector or in industry sector. It's even worse for industrial systems. Often no encryption is used here.

And I agree with you, away with DES, 3DES, SHA1, RC4.

Regards

Heiko

Re: R80.x Performance Tuning Tip - AES-NI

Dmitry_Krupnik — Fri, 30 Nov 2018 07:15:53 GMT

Hello Heiko, Alexander,

Thank you for your notices, I have talked with RnD owners about these questions.

The OpenSSH and OpenSSL libraries are being patched with every relevant CVE. Open source packages on Check Point are being hardened and modified to answer our strict security standards. We also port many features from newer versions.

In other words, for example, the "OpenSSH 4.3p2" version in the R80.20 isn't equal to the OpenSSH 4.3p2, which we can download from the openssh.com. This is "OpenSSH 4.3p2 Checkpoint Edition".

Re: R80.x Performance Tuning Tip - AES-NI

Alex- — Fri, 11 Jan 2019 14:34:04 GMT

I was explaining to a customer the AES-NI thing and bumped on this interesting thread. It is in my understanding that there is a consensus that AES-GCM is preferable to AES-CBC because of built-in authentication and better general performance. Also, on 64-bit systems a subset of SHA-512 like SHA-384 is supposed to be more CPU efficient than SHA-256.

However Timothy Hall's presentation seems to show that using GCM and SHA-384 is actually worse than CBC and SHA256 on Checkpoint. Is it correct?

Re: R80.x Performance Tuning Tip - AES-NI

Timothy_Hall — Sun, 09 Feb 2020 15:08:45 GMT

"Worse" is a relative term. VPN traffic that uses any form of GCM or SHA-384 cannot be handled by SecureXL in R80.10 and earlier and will be forced F2F which is a much less efficient processing path. This assumes of course that there is not some other "Deep Inspection" blade such as APCL or Threat Prevention needing to inspect the traffic coming out of the VPN and forcing it into a higher path anyway. So in a situation where only the most basic blades are enabled on a gateway (Firewall, IPSec VPN, and IPS w/ profile Default_Protection/Optimized) the vast majority of traffic can typically be handled in the most efficient SXL path at ludicrous speed, even if it is encrypting/decrypting to/from a VPN. However use of GCM or SHA-384 on a VPN tunnel will force all of that tunnel's traffic F2F in R80.10 and earlier regardless of what blades are enabled.

However on most modern firewalls, at least one "Deep Inspection" blade is enabled so most traffic won't be able to be handled in the SXL path anyway, and will end up in the Medium Path (PXL) or F2F. An entire 16-page chapter of the second edition of my book (chapter 8) was dedicated to this topic of VPN optimization.

However this limitation can be turned to your advantage. If you suspect SecureXL acceleration is mishandling a certain VPN, simply enable a GCM-based algorithm or SHA-384 for that VPN which will keep SecureXL from trying to handle it and make it all go F2F in R80.10 or earlier. This technique is much more efficient than disabling SecureXL completely, or alternatively switching off all SecureXL VPN acceleration with sim vpn off.

Edit: I forgot to mention that AES-NI can be successfully leveraged in all processing paths including SXL and F2F.

Update: AES-GCM-128 or AES-GCM-256 (Galois/Counter Mode algorithms) can be fully handled inside SecureXL/Accelerated Path starting in R80.30. SHA-384 is still not implemented in SecureXL as of R80.30, so VPN traffic utilizing SHA-384 still cannot be accelerated by SecureXL.

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

Re: R80.x Performance Tuning Tip - AES-NI

Alex- — Wed, 16 Jan 2019 20:11:25 GMT

Thank you Timothy Hall‌, very interesting. I will review that chapter of your book.

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Sat, 09 Mar 2019 20:04:01 GMT

THX for this info.

Regards

Heiko

Re: R80.x Performance Tuning Tip - AES-NI

HeikoAnkenbrand — Sat, 09 Mar 2019 20:07:46 GMT

I also think that's a better way than disabling SecureXL completely.

I'd rather use:

sim vpn off

Regards

Heiko

Re: R80.x Performance Tuning Tip - AES-NI

Tim_Maurer — Tue, 19 Mar 2019 22:33:11 GMT

nice nice nice

Re: R80.x Performance Tuning Tip - AES-NI

PhoneBoy — Tue, 16 Jul 2019 17:48:01 GMT

Small addition to this thread from R&D:
AES-NI is supported and enabled out-of-the-box for 2.6.18 kernels.
In 3.10 kernels it’s supported and enabled out-of-the-box since R80.30 GA.