Network Segmentation

- Posted in Aruba Network by

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

Dynamic port configuration in Aruba OS-CX switches

- Posted in Aruba Network by

Aruba's OS-CX switches have the ability to profile devices connected to ports and dynamically assign roles and policies (ACLs) to those ports. The ACLs can include the usual stuff--filtering on source, destination and protocol. But, they can also include configuration parameters like VLAN assignment.

Here's a simple example that can be useful when deploying access points with bridged VLANs. In this example, the switch makes a profile of the connected device using LLDP (you can use CDP, too), parses the response and assigns a role to the port. The role has policies that assign VLANs.

To see how this would work, let’s say that we have an access point on port 1/1/10. Examining the LLDP query on the port, we get the following:

enter image description here

In our test for the presence of an AP, we will search the description for "IAP". To make the example a little more interesting, we will also skip any AP-305s we might find. The following are rules that will match our LLDP port access test. These are arranged like a sieve; the first pattern that matches wins.

 port-access lldp-group AP-lldp-group
      seq 10 ignore sys-desc 305
      seq 20 match sys-desc IAP

Next, we define the role and the policies that we want to associate with access points that match the above port-access tests. The block below says that the role is called "lldp-AP," and that the policies "create a trunk and allow VLANs 12,22,40 and 100, and make 100 be the native VLAN."

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native 100                                                                                                                                                                  
     vlan trunk allowed 12,22,40,100               

This last section is the glue that pulls the port-access tests and the role assignment together. It says "if the device on port x matches AP-lldp-group tests then assign the role of lldp-AP."

 port-access device-profile AP-lldp-devprofile                                                                                                                                              
     associate role lldp-AP
     associate lldp-group AP-lldp-group

Dynamic profiling can be applied to other kinds of devices too, including printers, projectors and phones. When used in conjunction with Aruba Central or NetEdit, elements of the policies and port-access tests can be described using variables, such as this:

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native %_native_VLAN%                                                                                                                                                                  
     vlan trunk allowed 

When used in conjunction with ClearPass and controllers, the ports can implement enhanced profiling, role assignment and dynamic segmentation whereby VLANs that don’t even exist on the switch can be tunneled from other parts of the organization.

AI in your Network

- Posted in Latest Technology by

AI in your network

There's a scene in "Mars Attacks" where Pierce Brosnan, playing the scientist, dissects one of the dead Martians. He pulls some red jelly from the brain and says "Curious." It captures one of the problems with what we're calling AI today because like the components of an AI, though the jelly can do amazing things, you really can't look at it and say why.

The term Artificial Intelligence has changed its meaning many times over the last 50 years. It currently refers to systems that can do feature correlation and extraction from training data sets--often very large ones. For example, training a system to recognize a face (like your phone does) is an exercise in presenting exemplar data to the system along with reinforcing feedback when a face is dsiplayed. This is called supervised training. After seeing enough faces and getting the green light for each one, the system can learn a correlation and provide the green light on its own when a new face is presented.

enter image description here

The systems and theory for this kind of AI have been around since the 1960s--even the 1950s. A well-known example is called a multi-layer perceptron, or neural network. The original objective was to imitate the way neurons interconnect and to reinforce pathways in the presence of specific stimuli. The neural network would be made of two or often three layers--an input layer, a hidden layer and an output layer. Inputs to a given layer would add or subtract from one another in accordance with weights (multipliers). The weights would be "learned" during the training process. They were the jelly in the Martian's brain.

The neural network is an analog model of how neurons might work, and some analog implementations have been created. On a digital computer, however, it is represented by matrix arithmetic. Matrix arithmetic can often be parallelized so that multiple operations occur at the same time. This makes it fast—very fast--given suitable hardware.

In the last ten years, supercomputers have been teased up, not from liquid-cooled Crays or hypercubes, but from very small-featured computing devices like field-programmable gate arrays or graphics cards. In fact, Nvidia--the company that makes the some of the best graphics hardware--is also the world's leader in supercomputers. That's because Nvidia graphics cards are hyper-parallel, and they can be programmed to do AI just as well as to perform pixel-based ray tracing. Nvidia is currently building what will be the world's largest supercomputer in Britain.

In the network business, you see "AI" being applied to network analytics, intrusion detection and diagnostics. The systems are the product of supervised and unsupervised training that look to correlate events and to recognize unique patterns—such as a network intruder. Part of the reason why vendors are pushing the cloud so vigorously is in addition to being the customer, you are part of the product; your network experiences contribute the training sets for "AI" analytics. They need you to participate in the cloud, too.

Given copious compute power, the quest to make AIs more capable is correlated with making them deeper--adding more layers, more sophisticated back-propagation and weight adjustment. "Deep learning" makes the AI more powerful, but it also makes it subject to pitfalls that are endemic to higher order curve-fitting. That is, when the input is similar to training data, the results can be excellent. In the face of unfamiliar input, deep AI can be wildly unpredictable. "Curious," as Pierce Brosnan would say. And it’s coming to your network.

-Kevin Dowd