Network Segmentation
Last week, while we were exhibiting at the Connecticut Education Network conference, one particular subject came up with visitors to our booth a couple of times: network segmentation-the separation of school networks or VLANs according to their function. The topic was motivated partly by new requirements from insurance companies for increased internal network security.
You can picture a segmented network as one where the firewall is pulled into the core and sits between different internal network segments. In the case of a school district, segmentation could separate administrator VLANs from student VLANS, or separate the BoE from the high school, as examples.
Network segmentation isn't a new idea, but the appearance of a couple of technologies in equipment that school districts are likely to use, plus the performance of firewalls and processors, are making it easier to accomplish.
To explain these improvements, it might be good to start with what's wrong with trying to use last year's firewall and core switch to accomplish the job. Say that we have the following common configuration: a layer-3 core switch that interconnects traffic coming from each school, and possibly multiple VLANs from the schools, which is trunked back to the head-end of the network.
: :
-------- --------
| FW | | FW |
-------- --------
| |
---------- -or- | ----------
| | | | |
| core | | | core |
| | | | |
---------- | ----------
| | | |
| +------+ |
user VLAN user VLAN
| |
A typical configuration is for the core switch to forward internal traffic internally and to forward Internet-bound traffic to the firewall. The two devices could be in series or sit side-by-side. If we wanted to to segment the internal network so that some VLANs were forced through the firewall, how would we do it? The problem is that the core switch has a layer-3 interface on each of the segments, and would usually route the traffic internally.
To force traffic to a firewall requires policy-based routing, including a collection of policy-based routing ACLs that say "if traffic is from VLANx and bound for VLANy, forward to firewall interface on the local VLAN." This overrides the core switch's IP routing. The firewall has a routing table as well, and it probably lists the switch as the correct next hop, so it would be inclined to send an ICMP redirect back to the switch that says "go forward it yourself." In short, we'd have to force the traffic to the firewall and have the firewall forward it back. It's doable, but not graceful.
Another alternative would be to have the firewall act as the core switch. In that case all traffic would have to traverse the firewall, including layer-2 traffic, multicast, everything. This would be ugly, if it were possible; not all firewalls will forward at layer-2. Those that can, can also filter at layer-2. We'll return to that in a moment.
Some of the switches that you might consider for a core switch today, including Aruba Networks' CX line of switches, feature multiple, separate Virtual Routing and Forwarding domains (VRFs). A VRF is a virtual switch instance with its own routing table and ARP cache. Two VRFs running inside one switch cannot see each other and cannot trade traffic unless explicitly forwarded. A core switch with multiple VRFs can seamlessly forward traffic to a firewall without policy-based routing. And, the firewall can forward it back from one VRF to another. This is a graceful way to ingest a firewall into the core--particularly at layer-3 boundaries.
What about performance? Commercial hardware-based firewalls often contain dedicated silicon for fast-path, stateful forwarding of packets. As long as you don't turn on UTM features between internal segments, including intrusion prevention, layer-7 inspection for viruses or content, a firewall in the core should be able to keep up. The UTM features slow a firewall down because the increase the involvement of the CPU. Perhaps these are features that you want between VRFs, in which case a more powerful firewall may be called-for.
So far, we have described a core and firewall combination that can separate internal layer-3 networks or groups of layer-3 networks that share a VRF. Firewall policies can be applied between VRFs--some traffic can pass and some can be denied. What happens when someone from the board of education goes to the middle school and wants to connect back to their desktop? Suddenly, the all-too-familiar swiss cheese of firewall special exceptions gets worse because the firewall is inside the core!
Again, talking about Aruba Networks, there is a capability called Dynamic Segmentation that makes it possible to extend a VLAN from one part of the organization to a switch port in another. The VLAN is encapsulated into a GRE tunnel and then presented as an access VLAN on the switch at the far end. Dynamic Segmentation uses an Aruba wireless controller to forward tunneled traffic to the remote switch in the same way that it dynamically selects and tunnels a VLAN for a wireless user. Combining Dynamic Segmentation with a segmented network makes it possible to secure a network against itself yet still allow for exceptions for administrators and staff.
I mentioned layer-2 filtering with a core firewall, above. Aruba (again) recently acquired a company called Pensando that makes custom silicon for securing flows deep in the core. It is now available in the Aruba CX 10000-series switch (that lists for over $50K...). We're going to have to wait for it to come to an affordable core switch in your district, but it will be possible some time in the future.
-Kevin Dowd