FEATUREDApplication Development & Modernization
PETER WELCHER | Solutions Architect
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 selected Cisco switches’ extended node functionality, policy extended node functionality, and Cisco’s line of industrial switches (“Operational Technology”).
Background Context
After every Cisco Live, 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.
Lately, I’ve been paying increased attention to the Internet of Things (IoT) presentations. I recently wrote a series of IOT blogs, and links to them can be found in the most recent edition: IOT: What is BTLE/BLE?
The Cisco Industrial or OT (Operational Technology) hardened routers and switches have been evolving and have more 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 standard equipment racks but will be mounted in industrial enclosures. Hence, differently shaped, typically into smaller spaces.
Of course, Cisco Live 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 that 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 well be the case.
Do people tell you about new gear, or just plug it in somehow? The challenge there might be getting out in front and keeping the IOT PM from buying cheap network gear to connect their shiny new devices with.
Finding the owner and the requirements is also the first step towards segmentation, which may well be needed to protect the IOT/OT devices from RON (Rest of Network), and vice versa.
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.
It does 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 is 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? Simpler segmentation, secure and robust connectivity via the existing core data network (rather than a standalone network, which might well be duplicative).
The short version is that older industrial switches can integrate as “Extended Nodes” (“EN’s”). To de-conflict “EN” from SDA “Edge Node,” the more recent Cisco documents now refer to the edge nodes as “FE’s” – Fabric Edges. The newer OT switches can be “Policy Extended Nodes” (“PEN’s”), because they can support policy-based segmentation.
Attaching EN’s and PEN’s to your SDA fabric makes up the extended network.
Tying into SDA makes sense because if you think about badge readers, sensors, HVAC management, and sensors, etc., 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. For reference, approximately 10-15 years ago, an IPv6 presenter had demo wireless environmental sensors the size of a stack of 3 quarters. (And note: electronics constantly get smaller!)
Extended Nodes
I understand Extended Nodes (“EN’s”) as classic L2 switches. They don’t “speak” security groups (SG’s). The newly announced Cisco micro-switches appear to be EN’s.
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 (SGT’s). 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 (SG’s using SGT’s) 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 SG’s, but since they’re in different VN’s, 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, VN’s get a little painful in the fusion configuration, so holding down the number of VN’s is also desirable. The best I can say is to use VN’s where segmentation is critical and share a VN where a little Extended Node “leakage” doesn’t matter much.
So, with EN’s, 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 SG’s. 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. In other words: 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 indicates that SGACL blocking can occur (be enforced), the green for open access between same-VN SG’s – 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.
CCC can be used to automate adding new EN’s. 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 new “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).
PEN’s do full fabric SGT enforcement, with policy automated and managed by CCC.
As of 2020, the only IOT devices supporting PEN are the IE3400 and IE3400H models.
Note the FE (fabric edge) switch must also support EN or PEN, which rules out Catalyst 9200 switches.
(2024 note: I googled this topic but am not finding anything new. More research effort or conversation with Cisco might turn up changes.)
PEN’s do support IP multicast. Video surveillance is one example where this might come into use.
Here we see that PEN’s 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 EN’s on the ring will not be able to do local micro-segmentation based on SG. Any PEN’s can.
References
