In my daily job, I often get asked why Aviatrix leverage public IP addresses in the public cloud?
For some reason this conjures up ideas of a security risk and for many customers goes beyond what they allow for in their security policy.
I often ask customers if there is a technical reason why they are worried, or if this is simply an issue of principle.
If it is for technical reasons, I can address all those concerns here.
If it is for “principle” reasons, then perhaps some soul-searching would be in order to uncover why non-technical issues are driving your security policy.
As a caveat, I am only addressing the question of security from the perspective of whether an Aviatrix device using a public IP address exposes an organization to additional security risk compared to using private IP addressing.
Security is a vast subject and other security mechanisms such as RBAC, correct administration of logs and alerting are also critical but beyond the scope of this blog post.
Control Plane vs. Data Plane
In computer networks, the control plane and data plane refer to two distinct functional components that work together to facilitate communication between network devices.
Both the Aviatrix Control Plane and Data Plane components are deployed in the customer’s cloud environment. These are not SaaS components.
The data plane, also known as the forwarding plane, is responsible for the actual transmission and forwarding of network traffic. It determines the path that network packets take through the network and ensures that they are delivered to their intended destination. This is accomplished through the use of network switches and routers, which inspect the destination address of each incoming packet and use a forwarding table to determine the next hop along the path to its destination.
Aviatrix Gateways are each responsible for data plane forwarding based on the defined network and security policy.
The control plane, on the other hand, is responsible for managing the network devices themselves and the paths that network traffic takes through the network. It is responsible for tasks such as routing protocol exchange, network topology discovery, and network device configuration.
The Aviatrix Controller is responsible for maintaining a control plane connection to each one of the Aviatrix gateways.
In summary, the data plane handles the actual forwarding of network traffic, while the control plane manages the network devices and the paths that network traffic takes through the network. Both the data plane and control plane are essential for the proper functioning of a computer network.
The Aviatrix Data Plane
The Aviatrix data plane is formed by interconnecting Aviatrix gateways together with secure tunnels, which form the basis for the forwarding architecture. Forwarding intent is installed on each gateway via the Control Plane (explained in the next section), but from that point forward each gateway makes its own local forwarding decision.
The actual data plane connections can be built on private IP addressing where CSP constructs such as VPC peering can be leveraged (within CSP quota constraints) or where private circuits such as Direct Connect or Express Route exist. Or, more commonly, the data plane can be built using publicly addressable CSP IP addresses – offering more scale and flexibility.
Importantly, the Control Plane, or more specifically the Aviatrix controller, is NOT in the data path. The Aviatrix Controller can fail and the forwarding of the data plane will not be impacted
The Aviatrix Control Plane
The Aviatrix control plane on the other hand uses the CSP backbone (and by extension, the CSP public IP addresses) for communication with the gateways.
This communication is fully encrypted using SSL.
The Aviatrix Controller uses this channel to push Network and Security intent, and configuration updates and generally monitor the state of each of the gateway’s health.
There are a number of advantages of using the CSP backbone:
- Ultra High Availability – this is an infrastructure monitored and maintained by the CSPs ensuring optimal availability.
- CSP DDoS Protection – CSP public IPs are also protected inherently by many of the same mechanisms protecting the rest of the CSP’s public-facing resources.
- Extreme Scale – these networks are among the largest and most scalable in the world
- Zero Maintenance – at least from you as the customer. These networks are maintained by the CSPs as part of the consumption model pricing.
- Resilient to Failure – as most of the CSP infrastructure is built for extremely high availability, resiliency mechanisms are built in.
Protecting the Aviatrix Controller and CoPilot
In each of the diagrams above, you will see that the Aviatrix Controller and CoPilot are protected by a third party WAF (Web Application Firewall). This is a best practice and the customer is free to choose the WAF technology of preference.
Aviatrix also manages automatically and dynamically the CSP security groups and firewall rules of both the Aviatrix Controller and CoPilot to only allow very specific and only required inbound IP connectivity.
From this perspective, the Aviatrix Controller and CoPilot are protected from external malicious intent.
Protecting the Aviatrix Gateways
The Aviatrix gateways, from an IP addressing perspective, are fully protected from unknown sources.
Let’s zoom in on a particular gateway as shown above.
Our gateways leverage the CSP Security Groups and Firewall rules to only allow explicit inbound connections:
- SSL from the Controllers specific /32 IP address
- Inbound IPSec connections on UDP 4500 and UDP 500 only from explicit gateway /32 IP addresses
- Inbound connections from the local VPC or VNET for the intents of application and user traffic forwarding
All other inbound connectivity is blocked.
And better than this, the maintenance of these rules is done by the Aviatrix Controller.
Below is an example from AWS, but we maintain this security across any CSP where the Aviatrix gateway is deployed.
The Aviatrix gateways do not allow any additional inbound connectivity.
This renders the attack surface of the Aviatrix gateways to zero from public IP addresses not in the allowed list.
Summary
The Aviatrix control plane is built using public IP addresses, as this is the most highly resilient method and most highly scalable.
Using public IP addresses does not expose the Aviatrix platform to additional security threats compared to private IP addresses for the following reasons:
- The Aviatrix Controller is protected by a WAF as per best practice and additionally has managed CSP security group and firewall rules only allowing inbound connectivity from specific sources, such as the WAF or the /32s of the Aviatrix gateways
- The Aviatrix Gateways lock down all inbound connectivity to only the required and known public IP addresses
Hope this was useful.
