Managing SD-Access Segmentation

This blog is about the concepts underlying SD-Access segmentation. It covers the forms of segmentation, where enforcement can occur, and some practical advice.

Previous blogs in this series:

Forms of Segmentation

SD-Access provides a two-tier hierarchy for segmentation.

The “top” tier is virtual networks or VN’s. These are actually VRF’s in terms of implementation: separate routing domains. The SD-Access switches provide no direct way for traffic to move between VN’s. Instead, an external device is used. A “fusion router” connects to the various VN’s (VRF’s in its configuration), either leaking routes or exchanging routes selectively with global routing. A “fusion firewall” does the same thing, generally treating the VRF’s as different zones and applying stateful enforcement.

The second tier is Scalable Groups, sometimes also called security groups, SG’s.

Every VN must have at least one SG in it. There may be more than one SG in the VN.

SG’s as assigned statically as VLANs on ports or dynamically via ISE assignment of SGT (SG tag) and associated VLAN.

By default, SG’s within the same VN can route traffic to each other.

The following diagram illustrates this.

On the left, the dotted line indicates segmentation into two different SG’s in one VN, the black and the orange SG’s. The curved green lines with arrows indicate traffic between the two SG’s, as allowed or denied by SGACL’s applied to the site fabric switches via DNAC.

On the right, the black and red workstations are in two different VN’s. The heavier double line on the switches indicates this stronger segmentation. The red curved line with arrows indicates how traffic would flow between a black and a red workstation. Traffic would be denied unless an SGACL on the firewall permits the flow(s).

As we will see below, DNAC can be used to create SG policies as to what traffic is allowed between any pair of SG’s. Each policy rule can be applied uni- or bi-directionally.

One mild surprise in DNAC is that IP pools are per-VN, meaning all SG’s in a VN will normally be addressed out of the same pool. For those of us used to thinking SG = VLAN = subnet, that seems a bit odd. The key point here is that with SGACL’s and SDA, the whole point is to leverage SG’s and stay out of the IP address business as far as security. So this default addressing scheme in DNAC emphasizes that and saves us from having to specify which IP pool or subnet goes with each VLAN = SG.

Put briefly, VN = subnet with SDA. Because segmentation no longer revolves around addresses!

Practical Advice

SG’s and VN’s are used as a method of grouping devices for segmentation. Segmentation provides places in the network for policy enforcement. In general, it appears best to view them as being global to the network, even if some are not present in all switches or sites.

One common practice is to have certain SG’s that repeat for some or most VN’s. This approach might tie VN’s to business units so that each VN having an Employee and a Contractor SG would make sense.

Some of Cisco’s documentation takes such an approach. What I have heard and believe is that having many VN’s can be a bit painful to work with, in the sense that adding a VN creates work. At the borders, each VN will require a matching VRF that has to be manually configured on a fusion device, plus policy ACL rules if the fusion is in a firewall.

Another perspective is that VN’s are strong boundaries, which should be used where a firewall is advisable to enforce traffic controls between VN’s or between a VN and the datacenter or rest of the network. In particular, if local compliance policy for something like PCI or HIPAA requires a firewall, that’s a good indication that it should probably be a separate VN. If compliance requires an audit of what’s within the boundary, having a separate VN with a firewall as a boundary might be a very good idea.

Despite this, there is a Verizon-Cisco case study on the web to the effect that VLANs may be good enough segmentation. If so, SG’s might be good enough. (“YMMV”).

Another way to think of this is “the matrix” for configuring policies, both in ISE and DNAC. If you have N VN’s, there are, in principle, N x (N-1) policies needed. The matrix is a N x N grid with each box representing a policy pair. The N-1 comes in because the diagonal isn’t needed: there’s no policy from a VN to itself.

Concerning SG’s, if there are M of them (M > N), then M x (M-1) is likely a bigger number. Not great, but it comes with the territory. This does suggest we do not want to get carried away with SG’s either.

The prevailing wisdom is to start small and add VN’s and SG’s where you need to, slowly.

You can re-assign users and devices to a new SG (and possibly thereby to a new VN) via ISE. Deploying new SG’s or VN’s is automated in DNAC, so not that onerous.

Thus, adding segments over time is quite a reasonable thing to do. Doing things this way also means you do not set yourself up for failure when migrating to SDA or first deploying SDA. Do stop adding before managing all you’ve created becomes too complicated. (Job security of the wrong kind?)

As an example, you could have a VOIP SG in each VN, but why? That would mean either firewall rules to get to voice gateways in the datacenters or per-VN interfaces on the voice gateways. Worse, it would mean that calls from a phone in VN1 to someone in VN2 would have to traverse the fusion firewall. So physical VOIP handsets, conference room systems, etc. might belong in an SG within a single large VN, or perhaps a dedicated Voice VN.

On the other hand, softphones on workstations are going to be in the workstation’s SG and VN. So you would still need to permit phones to talk to such softphones through the fusion firewall.

Yes, that’s a bit clumsy. I haven’t seen a good clean way to deal with that.

There seems to be a knee-jerk reaction of putting guests into a separate VN. I’ve seen this at several sites. That could be done, or they could just be in a Company VN with SG rules applied?

The point of bringing this up is that another consideration when planning is, “what happens if I mess up on the SG policy ACL’s?”

If two endpoints are in different VN’s, there will be no traffic between the groups. That’s good for security: what is not explicitly permitted is forbidden. If you mess up, there is no security breach. The endpoints just cannot talk to each other.

If two endpoints are in the same VN and you mess up an SGACL between SG’s, then traffic can flow. So, guest workstations might be able to send traffic to employee workstations. How strongly do you feel about that risk and its consequences?

By way of contrast, suppose you deploy multiple SG’s for employee groups to minimize lateral malware spread. If you get the SGACL’s wrong, their workstations might be able to communicate with each other. That does not have immediate consequences unless malware is already present and probing. Of course, if you don’t notice the lapse for months, then you’ve got exposure.

Networks come with trade-offs (as Russ White is fond of pointing out). Here, the trade-off is added security or risk with policy error versus support effort.

Where Does Enforcement Occur?

Traffic is classified, and tags are applied inbound (“ingress”). Enforcement is on egress, exit from an SDA switch.

The switches themselves do enforcement of SG to SG and other rules on egress. So, traffic from A to B is discarded at the SDA switch B is attached to.

We noted above that VN to VN traffic is enforced on the fusion device. If the fusion devices is a router, and if you set up routing between all the assigned subnets, then VN to VN traffic will be applied until you set up ACL’s. If you’re using a Cisco fusion firewall, then no traffic will flow between VN’s unless you create ACL’s. For simplicity, I am dodging discussing the per-interface security levels and rules in Cisco firewalls – they would work the way they normally do.

What Do I Enforce Where?

We have seen that the fabric switches do SG to SG enforcement, controlling user traffic near the users (and end devices, including IoT devices).

Exiting from a VN to another VN, or perhaps to global routing (WAN, data center, or Internet) typically occurs in a fusion firewall. This can also be viewed as near the users. While the fabric might be used to control a user to data center traffic, it makes more sense to me to do so in the fusion firewalls. An added advantage would be generating flow records for security monitoring purposes.

The fusion firewalls would see all users to the datacenter and cross-VN traffic. They would not see user to user traffic within or between fabric sites (assuming SD-Transit).

We will revisit fusion firewalls in the next blog, where we cover fusion firewalls in more detail.