How to interpret sk73980

[Martijn]

Hi Community,

Does anyone knows how to interpret the numbers from sk73980?

sk73980 - Relative speeds of algorithms for IPsec and SSL

For simplicity can I replace the word 'Speed' with 'Throughput'?

And how do we interpret the numbers if we have a combination of different settings.

By changing AES-128 to AES-256, the speed (throughput??) decreases to 95% if we use SHA-1 and DH-Group 2.
By also changing SHA-1 to AES-256 there is also a decrease to 35%.
Does this means an overall decrease to 33.5%? And with DH-Group 14 configured another decrease to 23% making the overall decrease in speed to 7.6% of the baseline if we have a combination of all of the above?

I know there are many factors that have impact on performance etc. But we are trying to figure out if a 6900 appliance can deliver the required throughput for a large number of VPN users. It's VPN only. No other blades are active on the gateway.

Regards,
Martijn

[the_rock]

That was always my understanding.

[Lesley]

Maybe calculate like this will help.

Datasheet says:

VPN AES-128 9.81 (Gbps), let's round it up to 10 Gbps
I assume only VPN clients on this system.

If you reserve 10 Mbit for each user. You can have 1000 users on the system.

But this is only if you have AES-128 and SHA1, this will get you the 100%. 

If you change to AES-256 with SHA1, you will only lose 5%. May more if you combine AES256 with SHA-256. 

I would test with both to compare them if they really affect it. 

Normally different blades will also affect the speed, like IPS etc but not in this case. Most of the time the real performance killer is 3DES, that people really start to notice. I would use the above method to calculate what amount of bandwidth you want to reserve for 1 client, in combination with the datasheet info and as final what encryption methods you will use. 

[Martijn]

Lesley,

So 9.81 Gbps VPN throughput for a 6900 (AES-128, SHA-1 and DG-Group 2) becomes 750 Mbps with AES-256, AES-256 and DH-Group 14.

Off course an estimate and not exact science, but this is how I interpret this SK.

Martijn

[Lesley]

I don't think. The biggest issue would come from SHA-256. The diffie hellmangroup is only for p1, rekey (and p2 if pfs is enabled). So for performance we can skip those. Unless a lot of rekeys happen at the same time a short cpu spike can occur. I would not use group 14 but pick a ECDH Group because they have better performance then 14. 

In the global properties you can change the encryption settings for p1 and p2. Both can be changed independently. The phase 2 setting when the actual data encryption occurs it is most critical to pay attention there for potential performance impact. But as stated by others I also don't expect any issue if you use higher encryption settings. Most of the time people use 3des for p2 and that is a real performance killer. 

For now I would pick highest encryption settings possible in the config and test with this, for both p1 and p2. The risk now if you use a weaker encryption method that the data could be collected and decrypted later in the future. This is an ongoing trend that attackers keep encrypted data to decrypt it later with Quantum Computing.

[Bob_Zimmerman]

Note that quantum computers are worse than classical computers at attacking symmetric cryptography because quantum algorithms for attacking symmetric crypto parallelize exceptionally poorly. Store-and-decrypt attacks depend on capturing and cracking the key negotiation. This is why it's important to move to SNTRU or ML-KEM/Kyber quickly, but why AES is safe.

[ccsjnw]

How many do you call a large number of VPN users?
And what is the current average CPU load load on the gateways?

I have never seen any material impact on performance when changing these parameters. 

[Martijn]

Hi,

Customer is mentioning 2100 concurrent VPN users.

Looking at the specs for the Plus version (64GB memory) 16M concurrent connections and 230.000 conn/sec are supported.
So we are not that concerned when looking at the connections. It's more the impact on troughput for all these users.

Martijn

[Bob_Zimmerman]

The throughput changes are less significant than it would seem, since encrypting/decrypting and applying the HMAC aren't the only things which consume time. Even assuming fully-accelerated traffic with zero inspection, IPSec and TLS involve a lot of copying data around, sanity checks like antispoofing, and so on. If you're doing IPS or other filtering on the traffic, the encryption/decryption and HMAC work rapidly drop below 10% of the time spent on the traffic.

Key agreement is only used when negotiating a new TLS connection, IPSec phase 1 (always) or IPSec phase 2 (only if Perfect Forward Secrecy is enabled). For IPSec in particular, you can generally afford for that to be really, really slow, as it has no impact on traffic throughput, only on the time it takes to (re)negotiate. TLS connections tend to be shorter-lived and more frequent, so you may want something faster there. Also note that the key agreement algorithm is the only part attacked by theoretical quantum computers. That risk is addressed by SNTRU or ML-KEM/Kyber.

Symmetric crypto algorithm affects throughput, and there's no reason to use anything other than AES-256. AES-128 is marginally faster, but thanks to hardware acceleration, the difference is a rounding error in actual data throughput.

HMACs also affect throughput, but they're commonly misunderstood. Hashes used in HMACs don't have the same issues as the same hashes used in, e.g, certificate signatures. An attacker would have to create a collision with a hash they don't control (i.e, no birthday attack) while the symmetric key is still valid (so within the phase 2 timeout). For the default one-hour phase 2 lifetime, that would require unimaginable energy pushed through a computer bigger than Jupiter. HMAC-MD5 is good until well after anybody alive today is dead. There's zero reason to use anything slower than HMAC-SHA1 right now.