Demystifying 802.1X - Part 2 - Authorization and VLANs

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

In my previous blog entry I talked about 802.1X and Authorization. In this entry I'm going to expand on that and talk about some of the options you have available.

Your options

At the most basic level there are three generally used options to implement an authorization profile:

This entry I'm going to discuss VLANs

VLANs

VLANs are the most common (and most basic) method of providing access-layer security. The idea is that I build up different security zones and deliminate them by VLANs. At each 'crossover' point I provide security (firewalls, access lists etc) and keep my network simple to manage.

Let's take this simple example:

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
10.10.200.1		Public Services
10.10.210.1		Intranet Services
10.10.220.1
Regular User
(VLAN 100)		XXX
HR Director
(VLAN 110)		XXX
Guest User
(VLAN 120)		XXX

By mapping a VLAN to each of these users and then having a subnet for each I can then create a simple policy. For example, I can give a regular user an IP in the range of 10.10.100.0 /24, an HR Director an IP in the range 10.10.110.0 /24 and a guest user 10.10.120.0 /24.

When any user connects to the network, I look up in my authorization policies what group the user is (perhaps from Active Directory) and push down a dynamic VLAN assignment. That user is then tied to that IP address and VLAN assignment and I can build my security from there.

For example for VLAN 100 I might apply the following Access Control List:

ip access-list extended REGULAR_USER
	deny   ip 10.10.100.0 0.0.0.255 host 10.10.200.1
	permit ip 10.10.100.0 0.0.0.255 host 10.10.210.1
	permit ip 10.10.100.0 0.0.0.255 host 10.10.220.1

This works well as I can control exactly what's allowed between my inflection points. However, my security is tied to my topology. Any new VLANs, users or services mean that I will need to update all my ACL entries across my network

VLAN Hell

The challenge with VLANs is that they are notoriously difficult to keep in check. Although the above example is feasible, moves, adds and changes quickly make VLANs hard to scale. IP address pools can become exhausted and any topology change directly impacts my security architecture.

I work with organisations that have teams of people updating ACLs, Firewall rules and so on because they're caught in VLAN Hell.

VLANs also need to be spanned everywhere a user could conceivably go. If someone moves to a new office or starts hot desking, I have to rebuild a whole load of infrastructure to support that. Security policy becomes network policy and things become static on both sides for fear of breaking things.

NAT is also a tricky area here - I need to ensure that any changes or address translation respects my original security intentions.

Platform Limitations

The best way to run 802.1X on a switch is to use multi-auth. To rewind a little bit, there are four main ways to configure port security on a Cisco switch:

The trick here is that multi-auth is clearly the best mechanism as it treats each session independently allowing for flexible deployment options. This comes at the cost though on all current IOS releases and hardware platforms of not supporting VLAN override!

The 3850, 3650 will both support this capability in a future release of code (I believe 3.7.0), meaning different users on the same access port can have completely different VLAN assignments.

Summary

VLANs are often seen as an easy way to start network security and are certainly the easiest when the network is simple and well-defined. However, it becomes quickly unmanagable and complex as time progresses and things change.

Is there a better way? In my next blog entry I'll discuss dACLs and how they can make things a lot simpler.