Policy Enforcement In SDA Fabric Translates Business Intent into Security

Intent-Based networking enables security policy

As we described it in Software Defined Access overview, one of the biggest challenges in today’s networks is associating security with IP Addresses or VLAN IDs. This legacy approach is a massive bottleneck for both creating and maintaining any business security policy. It also creates a security loophole where any device can potentially spoof IP address on the network and inherit its security level.

DNA Center and SDA provide full separation of network addressing from the policy enforcement. It provides a framework where business intent defines the policy and automation tools deploy it on the network fabric. One more aspect of the policy is related to application and QOS requirements which we will briefly explain later on.

You can define your security policy in two levels

Depending on your organisation requirements those are your options:

Macro Segmentation – separate network topology into multiple logical chunks by creating Virtual Networks (VN). Traffic flow between two VNs is denied by default. Typical example for macro segmentation is using one VN for corporate traffic and another VN for guest wireless. The other scenario could be splitting building management system that mainly comprises of robots, sensors and machines from the personel. Traditionally many companies built separate networks to achieve this kind of segmentation. One other important use case is building multiple VNs that share resources on another VN but can’t talk to each other. The way VNs are isolated from each other in the fabric is by instantiating Virtual Routing Forwarding instances (VRFs).
Micro Segmentation – allows more granular filtering and policy enforcement inside VN. Classic requirement may be to restrict certain user access to a resource on the corporate network. The other example could be providing different levels of access to contractors and employees. The fabric achieves micro segmentation by using Scalable Group Tags (SGTs) in the data plane.

Both VNs and SGTs are part of VXLAN header in each packet traversing the fabric. The relationship between endpoints, SGT and VNs are part of your organisation access policy design. Your IT departament will no longer have to map IP addresses to any user groups. You won’t have to define complicated ACLs around the network edge that are different for wireless and wired users. Finally you won’t have to correlate your logs with endpoint IP addressing. All endpoints that connect to your network will be classified and given the level of access that is dictated by your security policy. DNA Assurance will provide you with rich set of analytics showing what happens on your network in human readable format.

Data plane policy enforcement in SD-Access

When we keep talking about enforcing network policy without defining any ACLs many readers may get really confused. While the packet flows through the network from Host A to Host B there must be a way to associate the policy with its headers. The difference in SDA is that instead of looking at endpoint IP address, the fabric allows or blocks the traffic based on additional fields. Those tags are Virtual Network Identifier (24 bits) and Group Policy Identifier (16 bits) and both are present in VXLAN header. We have already explained the concept of tunneling, underlay and overlay in SD-Access. VXLAN is simply an extra header that goes between original IP packet and outer tunnel headers. It allows encoding all policy requirements for both micro and micro segmentation.

The huge advantage of defining your policy with those extra tags is disassociating it from the network IP addressing. The packet receives a tag based on source endpoint at ingress edge node. In order to enforce the policy you need to have both source and destination tags available. At ingress there is no knowledge about the destination. The reason for it is to conserve memory and distribute the control plane. Imagine every edge device learning about every endpoint on the network! This is why the packet has to flow through the fabric all the way to the destination where the policy can be enforced. This approach may seem sub optimal but is far more efficient than hard-coding security based on IP addressing.

Bringing it all together we still need to address the process of implementing correct tags in the data plane. This will provide full end-to-end picture showing incredible benefits of next generation network security.

Defining your organisation policy requires Identity Services Engine and DNA Center

What we need to understand now is how the packet in SDA fabric inherits correct tags. At this moment in time it requires various control plane mechanisms as below:

Wired or wireless endpoint connects to the edge node
Edge node acts as a proxy and authenticates this endpoint against Identity Service Engine (ISE)
There are two methods that the switch can use: dot1x or MAC Authentication Bypass if the endpoint doesn’t support dot1x
Whichever method is used the end result is passing endpoint identity to ISE with RADIUS exchange
ISE can use various databases including Active Directory to authenticate the endpoint
Once the endpoint’s authentication is complete, ISE provides authorization of it and pushes relevant tags to the edge node
While all this happens, DNA Center reads information from ISE using pxgrid and writes information to ISE with REST API calls. This allows synchronizing all endpoint groups between both systems.
DNA Center is used to define network policies for the fabric that are also called contracts
Finally DNA Center programs the fabric which brings it all together – edge nodes can impose tags and enforce policy based on source and destination tags

As you can see in the list above, next generation network works based on tight integration between DNA Center and ISE. Those two critical control plane components will be integrated in the future but for now you need to have good understanding how all pieces of the puzzle work with SD-Access fabric

DNA Center drives your application policy

Apart from access control the policy of your organization defines certain quality of service requirements for your applications. DNA Center allows you to either automatically detect or manually define applications that are important for your business. Once you have all your applications defined you can group them in Application Sets. Next you can define applications policies that can be:

business relevant – those applications should be classified and marked according to RFC 4594 rules because they directly support business objectives
default – those applications may or may not support business objective, should be marked with DF and given best effort service
business irrelevant – those applications don’t provide any business benefits and should be marked wih CS1 and provisioned with service that is less than best effort

For the WAN you can also define bandwidth profiles to reserve certain amount of bandwidth.