SD-Access and the Internet of Things (IOT)

This blog is part of a series covering various SD-Access topics.

Previous blogs in this series:

This blog covers how Cisco has extended SD-Access to provide segmentation and automation for large scale IOT networks. More specifically, this blog will discuss extended node and policy extended node functionality and Cisco’s line of industrial switches (“Operational Technology’).

Background Context

After every CiscoLive, I download slide decks for convenient reference and for offline reading. I skim many decks looking for significant new things and to broaden my perspective and increase awareness of technologies and capabilities I might encounter in the future.

This year, I paid increased attention to the Internet of Things (IoT) presentations. The Cisco industrial or OT (Operational Technology) hardened routers and switches have been evolving and have more NEW! EXCITING! capabilities. If you want more info about the hardware, follow the links embedded in “routers” or “switches” in that last sentence. If you’re wondering about the different and boxy form factor, the devices probably won’t go into racks but will be mounted in industrial enclosures. Hence, differently shaped.

Of course, CiscoLive slides contain marketing messages. One that resonated for me is (my wording) that there are too many groups of things that do networking and security in their proprietary way, etc. Life’s too short for that. And it costs too much.

I’m a huge fan of the concept that there must be ONE network in an organization, with a consistent and comprehensive approach to security.

What’s coming to the corporate and enterprise office networks is an expanded network boundary: building controls, outdoors, factory floors, security monitoring devices, and surveillance, etc. Not only for new construction but for retrofits. Welcome to the “Extended Enterprise”!

The first apparent benefit is that Cisco ISE’s device profiling could be very useful in that setting. Cisco has been populating ISE with profiles for all sorts of IOT devices. Knowing the vendor of a new device popped up on the network is the first step towards finding the owner and having a conversation about requirements, security, etc. Assuming you haven’t already had that conversation, which might be fairly likely. (Do people tell you about new stuff, or just plug it in somehow. The challenge there might be getting out in front and keeping the IOT PM from buying cheapo network gear to connect their shiny new devices with.)

Find the owner and the requirements is also the first step towards segmentation, which may well be needed.

The slideware mentioned Cisco’s Industrial Network Director (IND) for gathering information about OT networks/devices. My first thought was, “why is this a separate tool?”. I suspect it is because IOT / OT devices may have different management requirements and methods. Inventory FTW!

I’m mentioning it as another tool to be aware of, something to learn more about when you or I need it (and not to be discussed further in this blog). Ditto with CyberVision, which I understand as the overall security and technology architecture Cisco is applying to OT.

I love the name of the standard protocol for identifying IOT devices. Its name is mud. Is this clear as mud? Seriously: MUD (Manufacturer Usage Description). See the slides for more about MUD.

SD-Access and IOT

Returning to our SD-Access overall theme: Cisco is cleverly tying the OT switches into SD-Access. Why? Segmentation.

The short version is that older industrial switches can integrate as “Extended Nodes” (“ENs”). To de-conflict “EN” from SDA “Edge Node,” the documents now seem to refer to the edge nodes as “FEs” – fabric edges. Newer OT switches can be “Policy Extended Nodes” (“PENs”).

Attaching ENs and PENs to your SDA fabric makes up the extended network.

And tying into SDA makes sense since if you think about badge readers, sensors, HVAC management, and sensors, etc., where some degree of isolation for security is wise. If some brand of IOT device has poor security, you don’t want that exposed to any malware on a user’s computer looking to do lateral propagation. And vice versa.

If you consider that sensors are getting very small and may be present in large numbers, scalability and automation will be necessary. Something like 10-15 years ago, in an IPv6 context, I recall a talk where the speaker had demo environmental sensors the size of a stack of 3 quarters. They’re probably a lot smaller now.

Extended Nodes

I understand Extended Nodes (“ENs”) as classic L2 switches. They don’t “speak” security groups (SGs). The newly announced Cisco micro-switches appear to be ENs.

You may manually set up ports on an EN via static VLAN configuration. Or perhaps via 802.1x / NAC, perhaps using MAB.

The EN then trunks traffic to the FE (fabric edge) fabric switch, which applies security group tags (SGTs). The fabric can do SGACL enforcement on egress. So, you get some control over what can send traffic out of the fabric to a device attached via EN.

As I understand this, what you don’t quite get is micro-segmentation on the EN. In SDA, each VN (virtual network, VRF) is tied to a VLAN / subnet. The various security groups (SGs using SGTs) are just tags using that shared subnet.

If devices are in different VLANs, they’re on an L2-only switch, so they can’t communicate. Upstream in the fabric, they pick up SGs, but since they’re in different VNs, they’ll need to be routed through a fusion router or firewall, which can do any enforcement desired.

Note: From this, one might draw the conclusion that you should use a different VN and VLAN for every device type in the IOT network. But as I noted in previous blogs, VNs get a little painful in the fusion configuration, so holding down the number of VNs is also desirable. The best I can say is to use VNs where segmentation is critical and share a VN where a little Extended Node “leakage” doesn’t matter much.

So, with ENs, you could have multiple types of devices sharing a VLAN and VN. They’ll be able to talk to each other via local switching even if they logically are in different SGs. They won’t be able to talk to a device in a different SG on another EN if you have an SGT policy forbidding that.

Thus, on an EN, you get VN level macro-segmentation with no local micro-segmentation inside a VN / VLAN but micro-segmentation for any traffic that hits the fabric. Reworded: there is no East-West within-VN SGT enforcement on the EN itself.

Here is a diagram to make sure you are thoroughly confused:

The red line is to indicate that SGACL blocking can occur (be enforced), green for open access between same-VN SGs – no ability to enforce policy locally for same-switch traffic.

The ugly EN with X on top is attempting to remind you that for extended node discussion purposes, we’re renaming the Edge Node (EN) as Fabric Edge (FE).

That might be good enough for your purposes and could well be better than nothing. Leverage the OT switches you already have.

DNAC can be used to automate adding new ENs. See the documentation for the details.

Previously enabled “Extended Node” with its reduced functionality will continue to be supported on the IE3300, IE4000, IE4010, IE5000, 3560-CX, and the Catalyst Digital Building (CDB) switches.

Policy Extended Nodes

PENs are newer “smarter” switches (my wording, not Cisco’s – intended as an easy way to keep this straight).

A PEN talks 802.1x / MAB to ISE and learns the right VLAN and SGT for attached devices. A PEN supports inline SGT tags from the PEN to the edge node (FE).

PENs do full fabric SGT enforcement, with policy automated and managed by DNAC.

Right now, the only devices supporting PEN are the IE3400 and IE3400H models.

PENs do support IP multicast. Video surveillance is one example where this might come into use.

Here we see that PENs allow blocking of SG to different SG same-VN traffic.

OT Topologies

REP ring topologies are common in OT to reduce costs. That means your OT switches may be joined in a ring topology, with one node connecting the others to the SDA fabric.

The following diagram shows how a REP ring would be attached (via a single FE).

Exercise for the reader: If you think about it, any ENs on the ring will not be able to do local micro-segmentation based on SG. Any PEN’s can.

References

Disclosure Statement