IDG Contributor Network: Identity awareness: it’s more than just a packet
It was about 20 years ago when I plugged my first Ethernet cable into a switch. It was for our new chief executive officer. Little did she know that she was about to share her traffic with most others on the first floor. At that time being a network engineer, I had five floors to be looked after.
Having a few virtual LANs (VLANs) per floor was a common design practice in those traditional days. Essentially, a couple of broadcast domains per floor were deemed OK. With the VLAN-based approach, we used to give access to different people on the same subnet. Even though people worked at different levels but if in the same subnet, they were all treated the same.
Port-by-port and VLAN-by-VLAN enforcement
I used to define the access control policies on a port-by-port and VLAN-by-VLAN basis. I would associate a VLAN with an IP subnet to enforce subnet control, regardless of who the users were. When a user connects to a different subnet, what happens to the IP access control lists that are tied to the previous VLANs and subnets? Policies that are tied to earlier subnets eventually get lost when users move from one subnet to another. The priority used to be defined by the subnet and not by the network engineer.
As a matter of fact, segmentation was not the purpose behind the introduction of VLANs. They were primarily created to divide broadcast domains. Segmentation was introduced at a much later stage but today, it comes in many interesting flavors and SD-WAN being one of them.
I set up group policies in Active Directory (AD) to gain control over what my users could do. Everything worked fine, as long as no one wanted to move or work from home. Realistically, there was obviously a big gap between what the network was doing and how the business was operating. At that time, the gap was impossible to be bridged.
Let’s make policy and security enforcement easier
However, when I look at networking today, although we have made tremendous improvement, but still I see we have many security and policy enforcement challenges to be overcome. Indeed, the market has reacted to the demands and is making efforts to make policy instantiation easier. There has been an introduction to reflect intent in the networks, and Cisco is offering an intent-based networking solution.
Intent-based networking is all about informing the network about the end state and allowing the network to figure out the configuration details. Another example of this trend is identity. We need to have better identity awareness so that we can make decisions other than just on application endpoints.
Companies like Cato Network are steering us in the right direction by tying routing and packet flows to AD identity. There routing engine abstracts policy creation from the network and application architecture. This brings identity awareness into the world of networking and enables business-centric routing policies based on user identity. This is the gap that was waiting to be filled during my engineering days.
However, there are still certain flaws that have led us to a path that is full of challenges. Let’s discuss some of the painful episodes which have driven us to this path.
Routing just works
Packets will eventually reach their final destination. It’s really simple in practice. Network devices have interfaces, which connect with other network devices. When a packet comes enters on one interface, the network device needs to find the right interface to send out the packet. How does the network device do this? Well, it examines the destination IP field of the packet.
However, there are a couple of issues with the basics of routing. Firstly, the IP routing is destination based. It is your neighbor’s decision to determine where traffic enters the network; it is not yours.
Secondly, within the context of the open systems interconnection (OSI) model, the routing process is lowered down in the stack and is prevented from making decisions based on the intelligence that exists higher up in the stack. It is sad but it doesn’t take into consideration a lot of contextual that would make organizations run more efficiently. Contrarily, in today’s environment, routing must reflect business context.
Challenges of using traditional constructs
Today, the challenge is that the majority are still using traditional constructs in this new world. Undoubtedly, the technologies invented 20 years ago won’t cut it in today’s networking environments.
One of the main challenges with traditional constructs is that there is no context of the business function. It is merely an IP address or application endpoint that acts as a proxy for who the user is.
Authentically, IP addresses are like someone’s home address and the applications are the people living in the house. They do create a physical identity for the house but do not give you the detail of who is living in the house, which could pose a threat to security. So far, we have used IP address and application endpoints as a proxy for identity. However, until now, we have not had a reliable way for contextual identity to be an element in the policy decision process.
The concept of identity is imperative to properly manage the packet priority, routing, discards, that can now include specific information derived by the username, department, business unit, or other identity-related affiliation. Now the question that surfaces is, what actually is the right path?
The right path
The truth is, we are currently in the process of transition. SD-WAN took a step toward bringing the network closer to the business login with application-aware routing. It allowed us to prioritize traffic by application type. But even with application awareness, we still don’t know about the users behind the application. We may know the homeowner’s house number but not the characteristics such as their height, age, weight, etc. Realistically, the more you know about an entity, the richer the security and policy enforcement will be.
The right way forward for policy enforcement is not dependent on IP or applications as identifiers anymore. We needed to dig deep, which we now have started to. We need the ability to define policy based on the user, not the endpoint device. It is the ability to define the policy based on username, department, business unit or other identity-related affiliation that brings the network closer to the business logic.
For the first time, the policies have now become business-centric in nature and the administrators can ensure that the policies are defined correctly. Now you can tailor design the network and security as per your requirements. With identity awareness, the CEO can now opt for specific network and security policies for example, enhanced VoIP services regardless of device or location.
Summary
In the traditional world, the policy was not built for optimum satisfaction. However, now, identity awareness gives higher priority, bandwidth and better determinism to users. This transports us into a new era, making policy instantiation much easier. The timetable of relevant events is tilting the policy in a new way and that is identity-related affiliation; where routing can actually reflect the business context.
This article is published as part of the IDG Contributor Network. Want to Join?
READ MORE HERE
