Let’s start this with quoting wikipedia on what network segmentation is according to a encyclopedia.

Network segmentation in computer networking is the act or practice of splitting a computer network into subnetworks, each being a network segment. Advantages of such splitting are primarily for boosting performance and improving security.

How did this start?

Some of the readers might actually be old enough to remember how local area networks started out in the early 90s.

With the success of personal computers and the first network operating systems like early Unixes, Novell Netware and Microsoft Windows that was very late to the party networks quickly grew beyond the scale they once were designed for.

Only one station can send at the same time on a shared ethernet segment, so what happened back in the days when we still had hubs instead of switches was that many stations wanted to send at the same times, collisions were detected and the congestion grew to a point where networks sometimes were unusable. If you remember those times you are really old.

In 1990 the first ever network switch was introduced by a company called Kalpana. Each port was now able to talk to each other port directly without sending the information out to all ports. This was the start of a huge success story and Cisco acquired Kalpana in 1994 and benefits from the invention of the network switch ever since.

The rise of VLANs (802.1Q)

When collissions no longer were an issue through switching and having a separate ethernet segment for two ports communicating with each other, there was still another issue: broadcasts would go out to everyone on the switch (the nature of broadcasts).

This was one of the reasons to invent VLANs, a logical LAN on the same physical switch that reduces the broadcast domain and enables users to have more than one LAN and subnet on the same hardware. A managed switch is able to host many VLANs behaving mostly like physical LANs. Broadcasts are limited to the corresponding VLAN members. This is what we currently refer to as the 802.1Q Standard.

Today, people still use VLANs for the same purpose, but over time a second use case was built upon VLANs, security segmentation. Current switching infrastructure is often hosting hundreds of VLANs on the same infrastructure. Switches are no longer limited to doing layer 2 traffic only, but can route traffic based on layer 3 (IP) information. VLANs are normally built to be a IP subnet and the strategies for setting up VLANs are countless. Some of the strategies are mentioned below:

• by function (e.g. a VLAN for all database servers)
• by application (e.g. a VLAN for your SAP application)
• by company entity (e.g. finance, engineering)
• by risk profile (e.g. high value assets on a separate VLAN)
• by compliance drivers (e.g. your PCI DSS CHD infrastructure or SWIFT payment systems)

Layer 3 and “Multi Layer” switches

Because it is so common sense to put a IP subnet into one VLAN it makes sense for a switch to extend beyone pure Layer 2 and be able to route packets to another VLAN on the same switch or different switches/networks on the switch itself and therefore keeping latency minimal (instead of sending a packet back and forth to another router, and i think even more importantly the need to buy another router with that many interfaces).

Often Layer 3 switching is considered as routing and it really depends on the implementation of the device how the decision is made. Anything with higher performance today performs this in hardware on ASICs, often with the help of a special memory design called CAM. CAM is much faster than traditional RAM in doing lookups. If you are interested in more information it makes sense to read the above wikipedia article and some of the mentioned references.

The use of CAM often is justified when you think about the amount of data modern switches process:

For an idea of why CAM is required, consider that new switch models offer 48 × 25Gbps server-facing ports and 6 × 100Gbps uplinks. That makes a total of 1.8Tbps full-duplex, which means 3.6Tbps (terabits per second) is flowing in any given direction through the switch, which translates to 450GBps (gigabytes per second). Assuming a conservative packet size of 450 bytes (to make numbers easy), you would have one billion packets traversing the switch at peak condition. That is one billion memory lookups per second, which explains the high performance (and high cost) delivered by CAM

The above statement is from Deploying ACI: The complete guide to planning, configuring, and managing Application Centric Infrastructure by Cisco Press in 2018.

The advent of SDN

In the early 2000s there was a movement to decouple the forwarding and control plane of switches and several working groups and companies started working on this. There are several key events that led to a new category in networking called Software defined Networking. The release of OpenFlow somewhere around 2008 and first commercial products using OpenFlow a bit later, and the work of a company called Nicira, which was later acquired by VMWare. Nicira was running software based on OpenFlow, OpenVSwitch and OpenStack.

One of the biggest players in Software Defined Networking right now is VMWare with its NSX SDN software that can be part of VMware deployments.

How did Security Segmentation start?

VLANs were mainly made to segment off broadcast traffic into smaller broadcast domains (after collision domains were no longer a problem since switches got mainstream). This was the primary use case for VLANs, however, a second use-case was identified quickly. Segmenation for security.

People started to use the VLAN as a means to limit lateral movement and access to a group of devices by putting them on the same VLAN. There is a problem with that though, for limiting access to the segment there are several ways to do this:

1. use the L3 capabilities of the switch for routing packets from one VLAN to the other and use Access Control Lists (ACLs) to limit the traffic to only authorized flows. This does not only sound hard, it is hard, mainly because the ACL part makes it very difficult to operate this model in real world scenarios at scale.
2. use a Firewall to limit traffic from VLAN to VLAN. This means you need to use two interfaces to connect to Firewall interfaces and write rules for anything going from one VLAN into the other VLAN. This is not easy either and it becomes very costly, because firewalls are expensive and often made for protecting the perimeter, not east-west traffic in the data center. Administrators then also need to configure at least two devices, a firewall and a switch to make this work at all.

What is the state of segmentation today?

I speak to a lot of companies that face segmenation problems and want to improve their situation. The situation as described by the networking and IT Security people ranges from:

• we have a flat datacenter network where one can move freely once beyond the perimeter defenses
• we have segmented our DMZ and some of the data center networks
• we setup a new datacenter and everything is now segmented
• we tried to improve our segmentation and failed
• we faced a major incident and malware spread without any boundaries
• our network is 100% segmented and we have a strict whitelist policy that only allows authorized connections (NOT!)

There are other states in between the above mentioned examples and because no computing environment is the same there will always be.

What are the main challenges of segmentation?

Visibility

How hard can it be to segment off a application into a segment of its own and write some ACLs to allow traffic in? It turns out this is a very hard problem and the main challenge people have is missing visibility of traffic flows inside their infrastructure.

Dynamic infrastructure

Infrastructure today is far away from what we knew as infrastructure when VLANs first emerged. Workloads come up dynamically in seconds, they are created with code using Terraform, Cloud Formation or Ansible. Not to mention private and public clouds like OpenStack, AWS and Azure.

Hard to keep pace with the business

The last ten years have been providing great progress for software developers. Automated testing, continuous integration and deployment, better workflows for making software. All this leads to much quicker turnaround times for applications.

Networking and Security however did not keep up with that speed and we are only seeing the start of a more automated workflow that is similar to what happens in software engineering.

Keeping your segmentation up to the speed of business and keeping the processes straight is hard and that is what i hear a lot in conversations with network and security folks.

Too many enforcement points

We have been pushing the boundaries of compute infrastructures over the last couple of years. We are no longer running on bare metal, at least not for the majority of workloads. Virtualisation is no longer a hype topic, it is the standard way to deploy servers. We deploy things to IaaS aka private and public cloud and container orchestration platforms like kubernetes.

Everytime we push the boundaries, our old way to segment using a VLAN and a firewall or ACL fails more. We end up enforcing on many more enforcement points than before.

The Future

It is hard to predict a future, but if you look at cloud adoption and how workloads are run today, i think it is safe to say that the traditional VLAN with firewall enforcement may not be what you will be using in the future.

• ← Previous Post
• Next Post →