Demystifying 802.1X - Part 4 - Security Group Tagging

Posted: 2014-07-29. Modified: 2022-09-25. Link.

In an ongoing series of blog entries, I've been talking about 802.1X, starting with the basics and moving on to VLAN override and dACLs as part of an authorization strategy.

This time round I'm going to finish off Authorization and cover Security Group Tagging, a neat way that completely separates security from my network topology.

Authorization options

VLANs
Downloadable/Dynamic ACLs
Security Group Tagging

This article will cover the final option, Security Group Tagging.

Security Group Tagging

Security Group Tagging is a means to provide identity within a network entirely topology-free. Unlike VLANs or using dACLs, SGTs are easier to implement, keep up to date and map to the businesses security policy.

This is achieved by tagging each frame with a security group tag. These tags are assigned at layer 2 and transported within an IEEE 802.1AE frame.

The classic example is that a AAA server provides a tag to the network access device (i.e. switch) which identifies that user. Although the tag itself is numerical, the management system (such as ISE) abstracts this in to a canonical name.

Let's take the same example as before:

Topology showing Regular Users, HR Directors and Guest Users going across a network to HR Servers, Public Internet and Intranet Services

Corporate Policy

	HR Server	Public Services	Intranet Services
Regular User
HR Director
Guest User

Note how there is no network topology information above. These users could be in the same subnets or VLANs - their identity is totally separate from my network infrastructure.

Instead, each user is tagged by the network access device. The services are also tagged either using physical infrastructure or a virtual switch such as the Nexus 1000V.

Tag Mapping

The Identity Services Engine allows you to create a full matrix based on those interaction points. For example:

Matrix showing TrustSec configuration

The business policy above is directly mapped in to this matrix. Any empty cells will use my default policy (in this case fully permitted). This way I can blend existing ACLs and Firewalls with the enhanced security of TrustSec.

Building Rules

The rules in the screenshot above (for example "permit_https" from HR_Director to HR_Server) are topology-independent. For example:

ip access-list role-based permit_https
	permit tcp eq 443
	deny ip

A second rule might allow anything:

ip access-list role-based full_access
	permit ip

These rules are automatically populated on all TrustSec devices and expanded on a per-session basis, allowing both scale and dynamic security.

Manually Defining Rules

Rules can also be manually defined. Assuming the above example where HR_Director is tagged as 2 and HR_Server has the tag of 3 then a rule controlling that interaction would appear as follows:

cts role-based permissions default full_access
cts role-based permissions from 2 to 3 permit_https

Of course it's much easier to manage this centrally via ISE or similar, but it's not a requirement and you can implement TrustSec today on almost any Cisco switch, router, firewall or Wireless LAN controller.

Supporting Mixed Environments

In my next (future) blog entry I'll go through using Security Group Exchange Protocol (SXP) to support mixed environments, where TrustSec and/or 802.1AE is not widely supported.