Welcome to this blog covering IPsec and the CX 10000. The topic has a reasonable amount of detail to cover so I'm going to split the initial blog postings into two separate blogs. They should join up to provide a fundamental understanding of what the IPsec capability is on the CX 10000, where to deploy and how to get a service up and running with some sample configurations.
- Part 1 will cover the essential topics of IPsec support and CX 10000 IPsec solution positioning.
- Part 2 will cover the common deployment scenarios in more detail, sample configurations and guidance on why specific configurations are necessary.
As a network engineer, engaging with a new topic can quickly become confusing and frustrating if essential information is left out. To that end, I've included several background topics to the CX 10000 and IPsec technologies to accommodate an audience that is embracing the CX 10000 (and IPsec) for the very 1st time.
The topics in this blog cover IPsec, the CX 10000 general mode of operation, the differences between an 'Ingress policy' and an 'Egress policy' and the role of 'persona' interface ports with different settings.
If many or all these topics are well known to you, do feel free to skip topics and generally jump around in the text if you think 'you're good to go'.
CX 10000 IPsec Overview
The IPsec technology suite has proven to be crucial in maintaining security and privacy of data over IP networks making it a fundamental component of modern network infrastructure, and now it is available on the Aruba CX 10000 platform from AOS-CX release 10.12.1000.
Leveraging the CX 10000 at the Network border edge has several advantages relative to other networking solutions offering IPsec capabilities:-
- Service chaining: Stateful Firewall , NAT and IPsec policies can be leveraged within a single appliance. Each service offering can be applied independently of the other services or 'chained' depending on the solution requirement.
- Throughput: The IPsec encryption throughput will scale up to 540 G per Distributed Services Switch (CX 10000) at a fraction of the cost compared to other solutions available on the market today.
- All services are available with integrated management via the Pensando Policy and Services Manager. This makes it easy to implement as the intricacies of deploying an IPsec policy is driven by the user interface on the Pensando PSM and not via the AOS-CX cli.
The Policy and Services Manager (PSM) supports the delivery of all policy deployment for IPsec, NAT and Firewall policies and the AOS-CX software provides supporting networking CLI configurations that are easy to manage.
CX 10000 - Services Overview
Many of you will already be familiar with the CX 10000 concept of supporting a standard switching fabric and a stateful Firewall capability with services (NAT & IPsec). Networking data traffic can leverage the standard switching fabric without stateful firewall packet inspection or with stateful firewall packet inspection.
To leverage stateful firewall inspection for networking traffic, specific VLANs within the CX 10000 VLAN database are redirected to the integrated Distributed Service Modules ( DSMs) where stateful packet inspection takes place, or if the CX 10000 is positioned at the network Border edge, IPsec and NAT services can also be applied. For ease of use, the operational management and configuration of policies is executed via the PSM and not directly via the AOS-CX CLI.
A redirection example is presented in the diagram below where VLAN 300 & 301, supporting VMs 1 and 2, are redirected to the DSMs..
It's within the DSMs that other services like IPsec or NAT can also be applied.
CX 10000 Ingress and Egress policies
Security policies are applied to VLANs and VRFs and the direction of traffic is all important.
Network security policies are created via the PSM, attached to either networks (VLANs), VRFs, or both and applied to the CX 10000. When a policy is attached to a VRF, it is applied to all networks ( VLANs) in that VRF.
Now for the security policy direction part. The security policy references on the CX 10000 sound counter intuitive to us Networking folks. However, references make perfect sense when aligned to the traffic direction relative to a workload or host, and not from the perspective of the port interface or VLAN. It's the former, not the latter we need to keep in mind relative to policy application.
- 'Ingress' security policies are applied to traffic destined to a host and 'egress' security policies are applied to traffic leaving a host. The same policy can be used for both 'ingress' and 'egress' traffic directions, or different policies can be applied for both 'ingress' and 'egress' traffic flows for more granular control.
- All traffic leaving the workload/host, entering the switch on the host facing ports. These ports are defined as 'access' persona ports and are subject to an 'egress' policy on the switch.
- All traffic destined for the workload/host, entering the switch from the fabric side, via 'uplink' persona ports, are subject to an 'ingress' policy on the switch.
The key points to remember is the direction of traffic leaving or arriving at the host or workload. An 'ingress policy' is applied to traffic flows towards the host and an 'egress policy' is applied to traffic flows leaving a host.
Where and whether a security policy is applied or not is of course down to the administrator and the security policy requirements.
Below is an 'Egress policy' flow example with the direction from 'Host-A' to 'Host B' on the same CX 10000.
And this is an 'Egress policy' flow example with the direction from 'Host-A' to the VXLAN 'fabric'.
And finally, an ingress policy flow example with the direction from the VXLAN fabric to Host-B.
Port 'Personas'
Port personas and their characteristics determine how traffic flows are perceived by the CX 10000. The persona configuration option on a port configures the port for the appropriate 'persona' port role.
Port personas define the characteristics of a port on whether it is expecting traffic from a host, as configured for 'persona access', or expecting traffic to a host, as configured for 'persona uplink'. This in turn dictates the type of security policy and whether it is applied as an 'ingress' or 'egress' policy that is suitable for that specific traffic flow.
By default, all CX 10000 10G/25G ports are defined as workload/host facing ports with the 'access' persona pre-configured and the 100G/400G ports are pre-configured as fabric ports with the 'uplink' persona configuration.
For the most part, you don't have to concern yourself with configuring the port personas but with IPsec and the CX 10000, there are exceptions when implementing IPsec on a 'Border Leaf' deployment. This topic will be covered in more detail in the 2nd blog.
CX 10000 and IPsec support
The AOS-CX release 10.12.1000 supports IPsec on the CX 10000 platform and complements the existing Firewall feature and the NAT feature set. The NAT feature set became available as part of the AOS-CX 10.12.0006 release.
There are two different deployment modes for IPsec. There is Transport mode and Tunnel mode, and it is important not to confuse the application deployment of the two.
- Transport mode is typically used for workstation/client host to gateway and direct host to host communication. Transport mode will encrypt the payload only and leave the existing packet header intact.
- Tunnel mode is where IPsec creates an entirely new packet header, encrypts the original packet header and payload, and treats the original packet header & payload as part of the payload of the new packet. Tunnel mode is typically used to encrypt data between network devices.
The CX 10000 IPsec implementation supports 'Tunnel mode' and not 'Transport mode'.
IPsec uses two protocols to provide traffic security services. The Authentication Header (AH) protocol and Encapsulating Security Payload (ESP) protocol. ("IPSec - NAT, AH, and ESP - NetworkLessons.com")
- AH offers integrity and data origin authentication with optional anti replay features (at the discretion of the receiver).
- ESP offers the same set of services and offers confidentiality. It encrypts the 'internal' IP header as well as the payload and is generally preferred.
- Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as defined by the security policy database. ("RFC 4301: Security Architecture for the Internet Protocol")
An IPsec implementation must support the ESP protocol and may support the AH protocol. The CX 10000 IPsec implementation supports the ESP protocol (and not the AH protocol).
CX 10000 IPsec Protocol framework
The CX 10000 IPsec solution is designed to be positioned at the Data Center Border Edge. This supports Data Center to Data Center, Data Center to Branch or multiple Branch sites and Data Center to Campus topologies.
IPsec has a long history in IP networking and has proved an exceedingly popular method of securing IP transmission based on deployment flexibility and robust security mechanisms.
The IPsec protocol framework supported on the CX 10000 is highlighted in the following diagram:-
As you can see, the essential, critical and commonly used protocols, encryption and hash algorithms are supported, and this is critical for interoperability. Interoperability has been tested between the CX 10000 and Palo Alto, Juniper and Vyatta products. In fact, IPsec interoperability with the CX 10000 should work between vendors that are compliant with the appropriate IPsec standards with supported and aligned implementations.
Firewall Policy and Encryption
IPsec can be deployed on the CX 10000 with or without stateful Firewall Inspection or applying NAT policies. Likewise, IPsec can be deployed with Firewall Inspection and NAT policies or any combination of FW or NAT policy enforcement. The below diagram highlights the sequence of services:
- Traffic 'exiting' the Data Center applies FW inspection first then NAT policy, assuming these policies are desired, prior to applying IPsec policies.
- Traffic 'entering' the Data Center decrypts IPsec traffic flows, and then applies FW inspection and then NAT policies as desired.
- Interfaces facing 'inside' of the Data Center are configured for 'Persona Access' and interfaces connecting the CX 10000 to outside of the Data Center are configured for 'Persona Uplink'.
Key points to note:
- The CX 10000 supports IPsec only at the network Border edge.
- If the CX 10000 is deployed as a 'Border Leaf' at the fabric edge, VXLAN 'decapsulation' is required at the Border Leaf VTEP prior to IPsec encryption over the IPsec tunnel across the WAN.
Solution HA options
There are three modes of implementing IPsec policies on the CX 10000:
- Active-Active – this model is recommended for those network devices that support 'active-active' IPsec tunnel termination.
- Active-Passive – Is a single tunnel deployment using VRRP across a VSX switch pair. Typically, this will suffice for most implementation using CX 10000 VSX switch pairs at each location tunnel end points
- NO HA – Is a deployment with just a single tunnel only and may prove useful where a VRRP deployment is either unsupported, inappropriate, or just not required
Active-Active tunnels are supported between AOS-CX VSX enabled switches and other AOS-CX VSX enabled switches and with Networking hardware that supports active-active tunnel deployments with the appropriate IPsec standards-based protocols.
Active-Passive with the VRRP protocol is supported along with a single IPsec tunnel with no standby IPsec configuration.
IPsec active-active
IPsec active-active has two active IPsec tunnels. If leveraging HPE Aruba VSX switch pairs at either site, an individual IPsec tunnel will peer and terminate to its remote switch tunnel end point from and to each primary or secondary switch. The guidance is for each VSX role to peer directly to its remote VSX role counterpart. As in switch DC-B1 VSX primary to switch RS-B1 VSX primary in the diagram below.
IPsec active-passive
VRRP is also supported and is the only option where one site cannot support an active-active deployment model with its remote site VSX switch pair. There is only one active tunnel in this scenario. The initiating site, the remote site in the example below, will initiate the IPsec IKE tunnel set-up & target the VRRP VIP address at the DC site.
- The DC site tunnel source IP will be the VRRP VIP.
- The remote site tunnel destination IP will be the DC VRRP VIP IP or tunnel interface IP if VRRP is not deployed.
Topology variations
There are variations of topologies that can be implemented. Not all are captured in this blog. For example, site to multi-site.
And a typical 2-tier or 3- tier topology with the CX 10000 at the Border edge leveraging active-active or active-passive topologies. An active-passive topology is shown in the diagram.
That's the end of this blog. Stay tuned for IPsec blog number 2 which will be delivered in a few weeks that will cover the IPsec configuration details of the CX 10000 and the Pensando PSM.
------------------------------
Steve Bartlett
------------------------------