Continuing on my theme of top 5 Aviatrix Security features, welcome to post #2 on High-Performance Encryption (HPE).
If you missed last weeks post, you’ll find it here:
https://mcna.dev/aviatrix-top-5-security-features-1-firenet/
Before we get into the nitty-gritty, let’s get some level setting.
So, what’s encryption, and why do I care?
Any traffic flowing between 2 endpoints is considered “data in transit” and the decision to encrypt this traffic will be coming from the InfoSec team or the CISO office. Encryption in this context is just the general term used to describe securing a transport medium and thus securing the data traffic that passes through it.
Certain traffic flows, such as HTTPS/TLS, are encrypted at the application layer, and as such this data will be natively encrypted in transit. However, all other data will remain unencrypted unless similar application layer approaches are taken. Most companies desire all data in transit to be encrypted when traversing shared infrastructure.
You need to care about this if any of the below mean something to you:
What is shared infrastructure?
Any transport medium not within the administrative control or within the physical constraints of your premises would be considered shared. For example, any connectivity managed by a service provider (MPLS), or any shared infrastructure managed by a Cloud Service Provider (AWS, Azure, GCP, etc.).
What happens to data as it transits between my Virtual Networks in the Cloud?
Traffic between Virtual Networks (VPCs, VNETs) in the Cloud is forwarded by the underlying CSP Software Defined Network and traverses the CSP network infrastructure. Whether they encrypt this traffic or not is up to them, and you have to trust that they either do or don’t. For some InfoSec teams, this “trust” is not enough, and they will mandate that traffic between Virtual Networks (VPCs, VNETs) must be encrypted as well as traffic flowing into and out of the Cloud.
So, I’ll just encrypt it then. How hard can that be?
IPSec encryption has been around for a long time and is by far the de-facto method for securing data in transit at the network layer. IPSec (leveraging ESP) builds an encrypted overlay (the logical tunnel transporting the traffic) tunnel on top of the “untrusted” underlay (the transport medium over which IPSec runs – an Express Route circuit for example, or the internet). The performance of this overlay will depend on 2 main factors:
- The performance of the IPSec tunnel
- The performance of the underlay
Bandwidth is no longer a restricting factor with 100G and above backbones being deployed in most CSPs today. Even bandwidth to the Cloud is in orders of Gbps with 10G and above normal pipes for most enterprise customers.
How fast can I encrypt, then?
The performance of IPSec is dependent on a number of factors such as MTU sizes, encryption algorithms, etc, but the major decider on performance will be down to how the CPU handles the IPSec flow.
In on-premises times, hardware encryption modules tried to address the high CPU cycles required by routers and firewalls, and for the most part address throughput for the then lower underlay speeds in the 10s and 100s of Mbps.
Now, thanks to virtualization, hardware is shared, and whilst resources such as virtual CPUs (vCPUs) can be abundant, the way in which IPSec utilizes the CPU is very specific. In short, 1x vCPU handles 1xIPSec flow.
Pushing the IPSec tunnel through this vCPU correlates to around 1.25Gbps of throughput and is recognized across the board now as being the limitation to building IPSec tunnels in the Cloud and to the Cloud.
But 1.25Gbps is a lot, no?
Not quite 1.21 Gigawatts, but 1.25 Gbps – Great Scott, indeed.
And, whether it’s a lot or not depends on many factors. If you have to encrypt your Direct Connect circuit using IPSec, and you’re paying for a 10Gbps circuit, then you’re going to be frustrated only pushing 1,25Gbps.
Again, in the Cloud, underlay bandwidth is abundant, so limiting yourself would not be ideal.
How can Aviatrix help?
If using one core is the limiting factor, why not just use more cores?
Well, that’s because every IPSec flow looks the same, no matter how many real traffic flows are getting encrypted. In order to use more cores, we would have to have IPSec flows that looked different, so they would be load balanced onto another core.
Aviatrix achieves this in a very transparent way by orchestrating and managing the build of multiple IPSec tunnels providing the network layer entropy required to load balance across multiple cores.
Each new IPSec tunnel would have different source and destination addresses, thus providing the required entropy.
Doing this manually would be operationally overwhelming and incredibly difficult to troubleshoot.
By enabling HPE mode on Aviatrix gateways, we build all the necessary constructs required and present this back to operations as a common IPSec tunnel.
Remind me again why I need this?
Remember that 10Gbps Express Route circuit you bought? And remember the InfoSec team who told you all traffic going to the Cloud MUST be encrypted? Well, we help you address that in a very elegant way.
Or, remember those applications requiring encrypted connectivity in the Cloud in the 10s of Gbps range? We can address that too.
Do those flows need to move between Clouds? HPE can address this too.
For most of your flows in the Cloud, our standard IPSec encryption and management of redundant tunnels is enough – for everything else, we have HPE!
How do I configure it?
Check out my colleague, Ricardo Trentins post on how to deploy this from a technical perspective:
Hope you enjoyed this. As always, don’t hesitate to connect with me on LinkedIn or let me know if you want to discuss any of these topics further.
Thanks for reading and tune in next time for ThreatIQ and ThreatGuard.
