Data and Control Planes

In some equipment and software, we separate out a data plane from a control plane, and this has some security advantages.

Segmentation in hardware and software

One of our security architecting principles is segmentation. When we separate things out, we have more control: more control of flow between devices, more access control. So we separate out things like our networking, our files and folders and data, and different parts of our infrastructure. When it comes to our hardware and software, there's an element of segmentation with that as well. The way this is expressed is that there is a data plane and a control plane, and there are certain things that happen on the data plane that are separate and segmented out from the control plane. This gives us an element of security from certain tasks from other tasks.

The first thing to understand is this is an architecture model. So how people implement this control and data plane can vary depending on the company, the software, the hardware, however they see fit to implement this model. In fact, some have actually implemented a whole other plane here, and that's the management plane. So there are times when you see a data plane, control plane and a management plane.

Where these data planes and control planes originally showed up is in networking, and specifically routers. Routers would have these two different layers, the data plane and the control plane. But since then we started applying it to software and other equipment, and so you see it in other areas as well.

The basic concept is pretty simple. It just means that at the data plane level, what we have is the worker that's doing the day-to-day job or function. I have a construction worker right here who's working on site, that's moving stuff around, that's nailing things down, whatever they're doing to do the general business, the general operations. Then you have the control plane. That's like the manager of the company, whatever is doing the controlling or giving the instructions. Or maybe this is the foreman at the work site.

The Pony Express analogy

Let's get into an analogy so that way we can apply this to technology. I'm going to use Pony Express. Pony Express is how we delivered mail in the United States about 150 years ago, or a little bit more than 150 years ago. What we had is a network of people that would be set up to deliver mail. What would happen is that there would be somebody, the postman would get the mail, would jump on a horse and gallop to the next area. The next person then would take that letter, and then it would continue on and then be delivered to wherever it was going. So this was the Pony Express.

We have a letter here, and the letter needs to be delivered to a certain address. That address gets put on that letter and then handed to the carrier. Now, the carrier is that data plane. The carrier is what's going to be passing that message off to get to its final destination. And how does that work? The carrier is going to read that message, jump onto a pony or horse and gallop to the next area. Usually it's pretty fast - that's the way the Pony Express worked, they'd run it to the next area. Then the next area would see that letter, it'd be passed off to the next carrier, and then they would pass it off to the next hop, and then to the next hop, and then to the final location, all based off of that address.

This is the data plane right here. The data plane is in charge of routing that information, of sending that information, getting that information to its final destination. And what are the instructions for the data plane? We find that as an address on that message.

Then we have the control plane. For the control plane, let's say something goes down along this path. There needs to be a change. It is no longer efficient to run through this station right here, so we need to run it through another station instead. We need to control where this message is going to be sent through, and so we are going to give updates to all these stations, letting them know that a path is down so it can be sent in another direction.

Where does the security come into play here? On this message, we have information on it, we have data, we also have an address. None of that can change the route which it's going to take to get to its final destination. So the data plane, which would be this address and message, doesn't affect the route and where these carriers choose to carry it. And then we have the control plane. The control plane makes sure that this is going in an efficient manner to get to its final destination. And the control plane doesn't have any say on what's on that letter. We wouldn't want the control plane to reach down inside of that letter and change any information. So we've split these two now into two different planes. We segmented the different operations.

How routers do it

That's exactly what routers do. A router passes this data to get to its final destination - that's the data plane right there. But it needs to communicate and know what the different paths are, and so we use different protocols like OSPF. OSPF is what routers will use to talk back and forth and determine what the routes are to get to those final destinations. So OSPF would run on that control plane, but the data plane would then carry that data back and forth, and the two would not necessarily affect each other, as in the control plane doesn't reach down and start changing the data, and the data plane doesn't reach up and start changing the routes.

Benefits and disadvantages

So what are the benefits of doing this? We've already mentioned security, keeping those separate, because a lot of times there are different people that are doing that, or different levels of security, different levels of impact. It also makes things a lot more scalable, so you can scale things. It gives better performance, because separating this out can improve the performance of that. And then it also makes things more manageable: we can develop things separately, so we can develop the data plane separately from that control plane.

But there are some disadvantages. There is extra overhead in doing this. For instance, maybe now we have two pieces of software that we're running, or two pieces of hardware that are doing the job, so there's some overhead with it. It also creates some complexity to it. We've also got to be concerned about that attack surface: are we doubling our attack surface, or does doing that segmentation improve security?

What implementations look like

Implementation of this concept can look quite a bit different. For instance, maybe we have a single piece of software that's running, but within that software somehow we create some sort of segmentation, and within that segmentation we have the data side of it, what's performing the day-to-day functions, and then the other side of it, which is the control side, which is doing more of the management of that. So we've got two different parts of the software that's segmented out.

Or what we could do is separate it out into actually different programs that are running. So these are different services that are running, and we have the data side of this and then the control side of this.

Or perhaps what we do is we actually have separate hardware along with this as well. So some equipment will have an ASIC or some sort of separate processing unit for the data side of this, and then there needs to be software that's accompanied with that, and then we also have here a control hardware part of this and then the software side of that side. So there's a lot of different configurations of this.

A good example would be a Cisco Catalyst switch. In the Cisco Catalyst switch we have right here what are called ASICs. ASICs are application-specific integrated circuits. So think of it as like a CPU, but it's specially designed to carry out a certain function. In this case, since it's a switch, what it's designed to do is carry out the function of switching, switching between these different ports. We can see that there's one, two, three, four ASICs here that do this switching. And that is the data plane right there. And then we'd have some sort of software that helps run and make sure that that's functioning correctly. And then right here what we see is a CPU. I believe that's the CPU side of this. So now we have a CPU that does the more control or management side of the function of this switch.

Here's a representation of the router. We have that data plane, which is the lower level that's doing the sending of the data along its way, and we have hardware and software that controls that. Then we also have the actual routing tables and the updating of the routing tables, and that's up in the control plane. So that control plane then operates at a different level, and that control plane determines where it's going to be routed next, but it doesn't necessarily do the routing. That's the function of a data plane.

Where else we see this

Where do we see some implementations of this? I've already mentioned networking, like the Cisco switch I showed you, and I said it really stems from routers and how routers are set up. We could see this in software, or databases are often set up with this, or servers can be set up with this. So we see it in a lot of different applications.

As mentioned, it does apply to other areas like databases. If we are going to be reading and writing and making changes within a database, we're going to be adding records, we're going to be removing records - that's the data plane function. So the data plane function would be like our application that's attached to this, making all those changes to not the database structure, but just the data that goes into that database.

But sometimes we do need to change the database structure. When we're changing that, we're changing what's called the schema. So when we're changing the schema, what we're doing is maybe adding a table, removing a table, or maybe we're adding a field to a table or removing a field from the table. When we're making those types of changes, those are the control plane there. So we separate out the data plane, which is what our applications are and which is happening all the time, and then changing the database doesn't happen near as often, or usually at least that's the case. And so that's the control plane, that's manipulating that side of it, and we keep those two separate for security purposes and other purposes.

Another example could be DNS, and essentially DNS is just a database as well. But what is the data plane? That is the users checking to see what the records are inside of this database and then being able to pull that information. But they shouldn't be changing the DNS records themselves. All they're supposed to be doing is getting the records so that way they can navigate to resources. The control plane would be adding or removing those different records and keeping that DNS domain updated.

I've already mentioned that this can apply to hardware and software development. But what it also can apply to is zero trust implementation. When we implement zero trust, there's a data plane and a control plane. Same thing on software-defined networking - it's pretty key to both zero trust and software-defined networking.