Scalable groups tags with SD-Access

Perimeter-based firewalls

When I stepped into the field of networking, everything was static and security was based on perimeter-level firewalling. It was common to have two perimeter-based firewalls; internal and external to the wide area network (WAN). Such layout was good enough in those days.

I remember the time when connected devices were corporate-owned. Everything was hard-wired and I used to define the access control policies on a port-by-port and VLAN-by-VLAN basis. There were numerous manual end-to-end policy configurations, which were not only time consuming but also error-prone.

There was a complete lack of visibility and global policy throughout the network and every morning, I relied on the multi router traffic grapher (MRTG) to manual inspect the traffic spikes indicating variations from baselines. Once something was plugged in, it was “there for life”. Have you ever heard of the 20-year-old PC that no one knows where it is but it still replies to ping? In contrast, we now live in an entirely different world. The perimeter has dissolved, resulting in perimeter-level firewalling alone to be insufficient.

This is the age where the new business requires user mobility, bring your own device (BYOD), intelligent wearables, along with the abundance of enterprise IoT devices lacking sufficient agent security. Such variables introduce the requirement for access level security. Cisco’s SD-Access provides access level security by enabling a policy-based network.

Challenges with traditional constructs

One of the main challenges with traditional access control lists is that there is no context of the business function. It is merely an IP address that acts as a proxy for who the user is. However, this is inefficient in a number of ways. Let’s review the crucial drawbacks one by one.

Firstly mobility: What happens to the IP access control lists that are tied to the virtual LANs (VLANs) and subnets when a user connects to a different subnet? Eventually, they will get a different policy. However, the policies tied to subnets become ineffective when the users move across environments, which is common in the enterprise.

Secondly, management: overtime firewall rules are added and ports are opened to cater for the exceptions. In the end, we are left with a snowflake firewall that is centrally located with thousands of obsolete and unknown rules. The 20-year-old PC responds to the internet control message protocol (ICMP) requests but what else does it respond to?

Realistically, this type of sloppy configuration is a heaven for bad actors. They can move laterally and cause data exfiltration with almost anything these days – social media accounts and even domain name system (DNS). Both of which are commonly not used for file transfer, thus not inspected by traditional firewalling devices.

Also visibility: If you are using a traditional architecture that has thousands of lines of code, how do you demonstrate compliance and ensure the enforced security policy is the appropriate one? An effective security posture starts with the right visibility. If you don’t know what is there from the security perspective, how can you secure it?

Traditional architectures lack agility. The security policy is tightly coupled to the network design. Setting up a new site requires careful planning of VLANs, IP addressing and associated updates to various security rules.

Conversely, changes to security policies are implemented manually across all the network devices. This box-by-box configuration is manageable in a lab setting. However, when you have large enterprise deployments that have thousands of sites, the IT organizations struggle to keep up with the manual approach.

More than often, they end up hiring IT staff whose sole job is to keep the ACLs updated. Nobody wants to live in a world of ACL configurations.

The ideal situation: group-based policy

A good starting point would be to introduce the group-based policy constructs. They extend beyond traditional constructs whereby a policy is assigned to a group. This offers consistent policy, regardless of device type and location.

Previously, if the IP address changed, so would the policies on the firewall and everything else that was configured for policy enforcement. However, with technologies such as scalable group tags (SGT), the policy remains intact, overcoming the previous challenges mentioned in mobility, management and visibility. SGTs carry users’ group membership information.

The policies are business-centric in nature and the administrators can ensure that the policies are defined correctly. The policy is defined centrally in a DNA Center and is tied to user access. Policy moves with the user. It can be defined once and is dynamically associated with the user.

SGTs are based on TrustSec. Initially, this was a Cisco proprietary technology baked into specific application-specific integrated circuits (ASICs) and not multi-vendor.

An ethertype was specifically introduced that used a particular header as a part of the layer 2 Ethernet frame is called Cisco metadata. As you are embedding into the layer 2 header, every switch that does not recognize the metadata header will not process the traffic.

The evolving architecture

The architecture evolved to support interoperability with multiple vendors. An interim phase existed where you didn’t need to carry the header in the data path. The header was programmed with a control plane path using secure exchange protocol (SXP).

The combination of SGT data plane using the Cisco metadata headers and SXP, however, did solve the multi-vendor problem but introduced scaling issues. On every network switch, an IP address is mapped to a group tag. It is taking a binding for every single IP to group address so even though you are using group policies they are still mapped to the IP addresses.

We had VRF-Lite and multiprotocol label switching (MPLS), which do carry segmentation in their headers but then again require complex device-by-device configurations. They are not user-centric, but rather tied to VLANs.

However, now with the introduction of group-based segmentation within a virtual routing and forwarding (VRF), we are able to solve the multi-vendor and scale piece together. SD-Access employs this technology, which can be broken down into three major elements:

• Control-plane based on locator/ID separation protocol (LISP),
• Policy-plane based on SGTs and
• Data-plane based on virtual extensible LAN (VXLAN).

Cisco silicons and application-specific integrated circuit (ASIC) have become more programmable in nature. They can now be embedded in virtual extensible LAN (VXLAN), specifically VXLAN-GPO.

A quick deep dive

VXLAN-GPO allows the carrying of metadata. This metadata could be anything. Cisco uses it for the SGT. There is reserved fields part of the VXLAN-GPO that used to carry SGT information.

However, the proprietary layer 2 headers are now embedded into the VXLAN-GPO. The SGT information is contained in the VXLAN-GPO header. Within the header, there is a group-based policy bit and if the bit is set to one, the SGT is carried, if it’s zero, the SGT is not carried.

The group policies are a 16-bit header in VXLAN. A future capability will enable you to take the header from SD-Access and insert the header into Viptela SD-WAN. This will ultimately enable the end-to-end security and end-to-end segmentation.

SD-Access and SGTs are business-centric in nature. The administrators can manage access control policy pervasively across the network and do so in a manner that is independent of the IP address. 

The policies are managed centrally and are relevant to the business function of the organization. SD-Access and SGTs are more business-driven based on the role of the user in the organization. This enables new features, like rapid threat containment that was almost impossible to do under the traditional security constructs.