wrong tool

Let’s talk a little bit more about Firewalls and Network Databases.

The obvious insight most networking people have is that the purpose of IP is to find a route between A and B. If there is a path, IP will find it.

The problem is that the network is a graph that isn’t owned by anyone. Anyone can create a connection, and any connection can create a path and any path can lead A to B.

The really annoying problem is that because the graph is built on physical cables that are very expensive to put in the ground, a single physical cable can be a path that is open to some packets and closed to others.

In other words, some links from A to B are valid because the person at A is allowed to talk to B, and some are not. And the amount of state you need to inspect to determine if packet A is allowed to go from A to B is considerable.

Really obvious stuff.

If you want to control traffic going that goes through a physical cable then you have to put a device that can look at all of the traffic coming in on the physical cable and make routing decisions. The device has to have a notion of forwarding paths and rules about how the data can flow through the device.

And that’s what a firewall does. First the firewall makes sure the packet is allowed to go through the firewall at all, then the firewall looks at where the packet wants to go next, and sees if the packet is allowed to based on the security policy.

From a particular point of view a firewall is just a router that uses a different kind network database. However, the database properties of the firewall are very different.

What is very confusing, especially to the networking industry, is that because firewalls are really just a router that has a different kind of database, it’s easy to assume that a firewall is a router and that the same kind of system level insights that apply to routers apply to firewalls.

And that’s unfortunate. Because a firewall system design is better informed from the system design of scalable web applications that have centralized databases than routers or switches.

More to come.

 

Following up to yesterday’s post, I wanted to talk about the Network…

Again this is stuff a noob like me finds interesting. I am glossing over massive amounts of detail. And I may be wrong, and if I am I’d like to be corrected.

If you come from a database background, a database has the following useful properties:

1. There is a single IP address you can ask all your questions of
2. Only approved people can add or remove state
3. You can trivially query the current global state of the database.

In an IP network, the database is the network, and the database has the following perverse properties:

1. There is no single IP address you can all ask all of your questions of
2. Anyone can add or remove state
3. You can not query the current global state

The Network Database is the single most unique database on the planet. The properties of that database provide for resiliency, force co-operation between bitter commercial rivals and require some of the most sophisticated protocol engineering on the planet.

And why is this important to Firewalls?

If we consider firewalls, and computationally cheap security then we realize that the single most important function of a firewall is to make sure that Network is a Database only contains records (routes) that are approved.

That was a mouthful.

Consider a route from IP 1.1.1.1 to 2.2.2.2. The network administrator would like to say that no such route must exist in the network database. The problem is that the network administrator can not guarantee that such a route won’t get created either maliciously or intentionally. The inherent properties of the Network Database make this impossible.

What to do?

Well you create a device that has all of the rules that you want to enforce and that device has all of the properties of a real database:

1. There is a single IP address
2. Only approved people can add or remove state
3. You can trivially query the current global state

And then you put that database in the middle of the network and have it verify that no invalid route is inserted by essentially seeing every packet and making sure that every route is valid in the context of the security policy.

In effect, this is the really astonishingly surprising result – a firewall’s first and foremost role in a network is to secure the routing tables. What I mean by securing the routing tables, what I mean is that you are ensuring that no route that you don’t want exists.

That’s why a firewall is inline, that’s why it exists. If you could secure the routing tables without a firewall, then you could – in principle – transform the security industry.

And it turns out that SDN can eliminate the need for a firewall… Maybe. And that is very disruptive. And SDN’s might do this because, well, they move the Network Database out of the Network into a database that has standard database properties…

And I’ll get to that when I talk about SDN.

 

 

Following up from my post about an Idealized Firewall , let’s look at what a Firewall does …

Again this isn’t novel or new…

First a picture:

A firewall provides three kinds of security services.

1. Computationally Cheap Security

The most important service a firewall provides and perhaps the entire raison d’etra is what I call cheap security. Not cheap from a cost, but cheap computationally. The amount of state that has to be kept and tracked is relatively small. This kind of security is what we traditionally call Layer 4 security. A lot of what passes off as security in this space is handled both in a firewall, and using other technologies like vlan’s, ACL’s etc.

This is the layer that transforms packets into flows ..

Everything else a Firewall does stems from this layer, and I’ll get to why in another post.

Remove the need for this kind of security as a stand alone box and you remove the need for firewalls.

2. Connectivity Services

Because a firewall gets deployed at a network choke point, and because it does cheap computational security and is already inspecting traffic flows or must inspect traffic flows, a firewall is a natural place to deploy some connectivity services like NAT or ipsec. You can, and Juniper does, deploy this technology elsewhere like routers.

This technology only gets deployed on a firewall if the box is deployed at the network choke-point.

3. Computationally Expensive Security

As you get better at solving the cheap security problems, the bad guys have to expend more effort to break in. As the efforts to break in costs more in terms of CPU and memory, then the amount of resources required to detect the bad guys increases. Like in a real war, as the weapons of defense improve, the offensive strategies adapt and force the defensive strategies to get more expensive.

Firewalls are able to play in this space because they do the heavy lifting of transforming the packet flood into a flow, and this layer is really just doing deeper and deeper analysis into flows and across flows.

Many innovative startup companies are working on this space because this is where the need is most pressing and most difficult to deal with.

If another layer were to transform the packets into flows, then this layer could live outside of the firewall. And in fact, as some companies have demonstrated it is possible to do this packet-to-flow transformation without being a firewall by hiding behind SPAN ports.

Because of the need for rapid innovation, resource requirements and lack of universality computationally expensive security can exist for a long time outside of the firewall before collapsing to the firewall.

 

When I joined Juniper, my interview was very funny because I knew nothing about networking or security. Well okay, I could draw clouds that had arrows pointing to each other and I knew the basics of sockets, but nothing like anyone who actually knows networking…

That’s what has made the job so much fun. Applying 15 years worth of experience to learning a new problem domain…

A specific challenge, I had was how to think about a firewall, in particular what exactly are the functional elements of a firewall that transcend any specific implementation.

A diagram I came up with that has had surprising predictive power is what I am sharing today.

Basically a firewall has three layers.

Physical Layer

Starting from the top, we have a physical layer that has packets come in as a rain drops. I’ve already talked about rain drops and streams, and this lowest layer is what handles the packets. This is a physical network layer where cables are plugged into a firewall device. Just above the packet flood is a load-balancer that ensures that packets from similar flows end up on the next layer at the correct processing unit.

Cheap Computational Security

Cheap computational security is what I have been calling security that can be done very efficiently,  has to look at a relatively bounded number of packets and can be assisted with hardware. This is typically what we have historically called “L4 Firewall Security”. Things like ALGs etc are implemented in this layer. This layer is able to take the packet flood and turn it into a stream before the security processing begins.

Because cheap computational security is implemented in terms of flows, a series of packets turns into a flow and then we start doing security on it, abstractly we can think of thousands of individual threads each handling a single flow. Obviously this is not how we would implement things, but is a useful mental model.

This mental model is particularly useful because it explains why the prior layer must load-balance the packets. Essentially using packet only information the physical layer must direct packets to the right thread processing the right flow.

Because the physical layer can make a mistake in load-balancing, this layer is able to detect the mistake and forward the packet to the right cheap security element.

Once the cheap computational security is done, then packet is forwarded to more expensive computational security if that is appropriate. That forwarding goes through yet another load-balancer whose purpose is to find either a lightly loaded computational element or send more packets to one that is still processing.

Expensive Computational Security

The final layer in firewalls is expensive computational security. This is stuff we have historically called “L4-L7 security services” such as UTM or SSL forward proxy etc.

This layer expects to receive a stream of packets and typically takes a lot of CPU and Memory resources to perform the operations that need to be done to detect security breaches.

Again this layer can conceptually be thought of a series of distinct computations on independent flows.

Final thoughts

What I described isn’t a firewall per-se, it’s just a useful mental model for how to think about firewalls. And in particular, to understand the hardware trade-offs in designing firewalls.

 

 

One of the funnest parts about having a job in a industry you know nothing about is that you can ask really basic questions. Those questions allow you to build mental models that you can then use to learn about an industry and perhaps if you are extraordinarily lucky and pick the right time and place make an impact on an industry.

What follows are really basic insights, nothing profound here…

When I looked at Firewalls, the networking part of the firewall was very mysterious. Most of the value was in security, but a lot of the hard-back-breaking work was in integration with the network. Especially at scale the network integration was extraordinarily important.

At first I thought it was about protocols. And there is some truth to that but a lot less than we all think. The need to integrate in line with thousands of protocols is absolutely a challenge and a barrier to entry but not the real source of the challenge.

Maybe a different way to express my comment is that the protocol integration challenge is a signal that there is something going on there that is causing complexity, protocol integration is a symptom not the cause.

And my latest way to express the problem is the following:

If you imagine an IP network it’s a flood of packets like raindrops falling from the sky. And at every hop, decisions are made on a per-packet basis.

But security can not be implemented on a per-packet basis. You have to look at a large number of variable packets. The more complex the security system, the more packets that need to be looked at.

The challenge with firewalls is that you need to turn the flood of packets from millions of Alice’s, into little streams of packets that you can then inspect and once done inspecting flip that stream around into packets that the millions of Bob’s are expecting and send them out. Later on you have to be able to get packets from a specific Bob and correlate that packet with packets you received from a specific Alice talking to that specific Bob , turn Bob’s packets into a stream, inspect the packets and send the packets back out to the right Alice.

And – oh by the way – Alice and Bob must never know that you did that because the protocols may not allow that.

I have this image of water drops coming in one end, you enter the firewall and they turn into streams, and then they leave the firewall as raindrops the other side. And this image is remarkably resilient to explaining many things about how firewalls work and why some things in firewalls are easy and somethings are very hard.

And the nice thing about this model is that it explains why protocol processing is so crucial … without the ability to process a protocol it’s impossible to make the rain drop to stream to rain drop transformation correctly and because you are looking at all of the rain drops trying to find a bad guy, protocol completeness is crucial – skip a protocol and that is the door way for the bad guys.