In a previous blog post, I covered some of the benefits of micro-segmentation and how Intent-Based Networking can help address the associated network implementation challenges.
In this blog post, I’ll cover some approaches to help reduce operational intricacies and how to manage the network changes.
Composing intent and enforcement
To reduce operational complexity micro-segmentation policy must be portable across your private cloud and public clouds A, B and C. By portable I mean it looks the same. I don’t mean it “can be ported” as “can be ported” is a landmine of operational complexity. So if this is a nirvana we are seeking, why is not out there yet? Because in a pre-Intent-Based Networking world APIs and abstractions are much more tied to implementation than they should be or have to be. You start with implementation and then try to put some abstraction on top of it. It should be the other way around. By “implementation” here I specifically mean how is the segmentation “enforced” and what/where are the enforcement points. So let’s review what is out there.
In a majority of cases, the mechanism is in the form of an Access Control List (ACL) with the difference being where it is applied. An ACL is for micro-segmentation what a forwarding table is for reachability. It may be applied on firewalls acting as choke points. In some designs it is applied to “top of the rack” switches or ToRs. In other cases, it is applied in the server/hypervisor. ACLs are precious resources and any reference design has to take into account the limitations of how many ACLs can be supported on any enforcement point.
Most modern practices do allow micro-segmentation policies to be expressed in terms of endpoints and application workloads. Though this is typically constrained to a single domain (private or public cloud) it, nonetheless, is a higher level of abstraction than ACLs. There are a few challenges with translating these micro-segmentation intent policies into ACLs.
The first impedance mismatch is that intent policies are relational while ACLs are hierarchical. At the intent level you specify relationships between pair of endpoints. Keep in mind that endpoints can be of different granularity — they may be an IP endpoint or virtual network or security zone or Internet. When you render them as ACLs on a specific enforcement point, the ordering of rules (hierarchy) matters when a conflict occurs. ACL as a hierarchical system is very good at telling you exactly what is going to happen, but it is difficult to know if it is doing what you want it to do. Your intent is A can talk to B on port 80, which is easy to reason, but when you look at the actual ACL implementation there is a long list of rules which make it difficult to determine if there are conflicts that may not meet your intent.
As an example, conflict exists when the same packet matches two different policies that have different actions in the case of a match (say allow vs. deny). The first challenge is how to compose the policies that exist between different endpoints. You need to alert a user when a conflict exists and resolve the conflict based on a global policy or ask the user for input. To be able to do this effectively, your system must be able to reason about the existence of the conflict. Yes, you guessed it, a single source of truth that stores your intent will be able to reason about that existence.
If a micro-segmentation API that your provider/solution exposes to you looks hierarchical (it asks you for rule ordering, for example) you should worry, as it means it is driven by implementation and may not be portable. If your micro-segmentation API documentation warns you that there may be conflicts if you apply rules at both the virtual network level as well as at the individual endpoint level, it means it is not doing that conflict reasoning for you. A genuine Intent-Based Networking system will inherently perform this conflict reasoning for you as validation is a key concept in these systems.
You may hear arguments that doing whitelist ACLs as close as possible to endpoints (read server/hypervisor) is all you need. But there are quite a few situations when that is not true. Your IoT endpoints may not have ACL capability, yet they are plugged into our network. Where do you enforce rules for them? The abstraction of endpoints in your policy must have policies as an integral part of their specification. But that does not mandate that the implementation of endpoints must implement policy enforcement mechanisms.
This decoupling is crucial. You will want to place IoT endpoints in groups (say sensors of the same type) and have the policy follow them wherever they appear. Intent captures this easily and your Intent-Based Networking system handles conflicts and enforcement points. APIs slapped on top of enforcement mechanisms are not necessarily higher-level abstraction. If you are anticipating an infrastructure with a mix of IoT devices and compute nodes, you will need a system that decouples security enforcement from micro-segmentation policy. Not to mention that reachability has to be there as well.
Dealing with change
Say you discovered your house and workloads and have established some baseline. The next thing is how do you deal with the change? One approach is to keep doing discovery. If you chose this approach you will constantly be at 80-90% accuracy. A more robust solution is to have an explicit definition of new workloads which is supplied as part of the intent going forward. This way you can actually start approaching 100% accuracy as legacy workflows will become hardened over time and the new workloads will be defined using a “zero trust” model. Your discovery capability becomes a powerful validation tool and less of an intent re-construction tool.
Possible changes include endpoints, their locations, policies applied to them, enforcement points, reachability policies, and things failing. You need an event driven system to adapt to any of these changes. You need to be able to subscribe to changes of interest at the intent and operational level and reason programmatically about them to adapt to a new state. This real time aspect is core to Intent-Based Networking Level 2 systems as defined in Intent-Based Networking Taxonomy.
Let’s illustrate why dealing with change is the most difficult aspect of any implementation. When you start from scratch, you can write a workflow that goes from a blank sheet to a fully functional system with millions of objects fairly easy. It is not the complexity of the end result that matters but the emptiness of the starting point. No preconditions to be checked. You cannot break anything or violate some existing policy and the end result is predictable. Day 0 and Day 1 are sunny. Then you find that you need to change something small. It is not the size of the change that matters but the potential impact of it. You need to check preconditions (and there are millions of objects to potentially reason about) and make sure you don’t disrupt an existing customer or application.
Micro-segmentation helps with limiting the blast radius and is a proven technique, but to reason about this smaller blast radius, you need a system that allows you to ask all the right questions about all the segments and their relationships. Only that capability will make your Day 2 sunny as well.
With Intent-Based Networking, Day 2 operations are implemented using the same model and mechanisms as Day 0 and Day 1 operations. The only difference is the nature of the change and the pre-conditions and post-conditions, but the mechanism is the same. In fact, if you have different systems to deal with Day 0, Day1, and Day 2 operations you are in trouble.
Conclusion
To put it simply, micro-segmentation provides great benefits, but is difficult to implement in a scalable, portable fashion without a single source of truth that ties together policy and enforcement, reachability and security, as well as Day 0, 1 and 2 operations. By defining policies at the endpoint level using intent you embed these policies in the infrastructure and move away from point products and tools that deal with enforcement silos. This is essential as these enforcement points are becoming increasingly distributed. Border Gateway Protocol (BGP) is the control plane for reachability. Event driven, single source of truth is the control plane for micro-segmentation.
