NFV disaggregates firewall appliance to increase scalability
A traditional firewall appliance can incorporate many services, but NFV can virtualize firewalls to offer individual services that scale for application requirements.
Network functions virtualization, or NFV, is a continuing hot topic in the network engineering world, but it can be difficult to understand for network engineers and IT managers. What sorts of functions might be virtualized in the network, and how can this be done? Let's examine a potential argument for NFV use: the disaggregation of the traditional firewall appliance.
In the network engineering world, the firewall tends to be a catch-all device. If you need security, or even if you just need to pass a security audit, you install a firewall, configure it and call the job done. In the case of security compliance, there are even stories of installing a firewall appliance and then either cabling it so traffic simply doesn't flow through the device or configuring it so all traffic passes through, regardless of what type it is. Humorous as this might be, it illustrates one of the basic problems with firewalls being treated as a sort of magic bullet for security problems.
To move from a firewall appliance to a virtualized function, it's important to begin with the services a firewall offers. While the service options are many, we'll stick to three for illustration.
The first service is stateful filtering. Many application flows are stateful in nature, which means the client begins a session by sending a specific series of signals to a server in order to open a connection. These connections are asymmetrical, with the client or server sending specific kinds of requests down one path and the other party responding by sending specific kinds of information down a different path. In stateful filtering, the firewall keeps track of these requests and replies, blocking any response that isn't requested.
The second firewall service is deep packet inspection (DPI). Here, the firewall examines the contents of each packet in order to block specific problems or kinds of traffic. For example, the firewall may look for specific applications, like voice over IP, being transmitted to a host that doesn't accept this kind of traffic for some reason. Using DPI, the firewall might also examine packets for virus signatures or unusual traffic patterns indicating some form of attack is underway.
Finally, firewalls are often given the job of translating public and private addresses using network address translation (NAT), or translating address and port pairs with port address translation. In some cases, this job can include translation between IPv4 and IPv6 addresses. While many protocol and application developers dislike the concept of address translation, it's still an important part of network infrastructure. It allows communication between networks addressed from overlapping private address spaces and provides a sometimes-helpful security tool, if used correctly.
Using a single firewall appliance for each service
The problem with using a single physical firewall appliance can be seen in the following illustration.
A sample network using a single, physical firewall for all services
Assume host A needs to access a set of five different services across this network. Traditionally, a firewall (B) would be placed in the network just before -- or sometimes just after -- the router. In this position in the network, the firewall receives and forwards all the traffic destined for each of the services running on the server (D). Now, assume the following policies are in place:
All packets coming into the network pass through a DPI process to ensure the network is protected from potential viruses and other generic attacks.
Services 1 and 2 are addressed out of a private address space, so any flows to and from these two services must pass through an address translator.
Services 3, 4 and 5 are stateful services, each with an application-specific state that needs to be tracked in order to protect the server and the user from man-in-the-middle and other attacks.
The single firewall appliance depicted above must be configured with the correct policies to make all of these different requirements happen. To accomplish this, DPI, address translation and stateful filtering will all need to be configured on the firewall. Policies that exempt certain flows from address translation will need to be configured, probably on a per-IP-destination basis. The firewall will need to support each of the different application-specific stateful inspection routines.
Implement multiple firewalls on virtual topologies
To make matters more complex, the firewall will need to support all of this at scale and be upgradable without any of the services failing. It's possible to address some of this by installing multiple firewalls, one per service, perhaps as virtual machines in the network, or by building out virtual topologies and placing one firewall on each. The figure below illustrates an option using virtual topologies.
A sample network using one firewall per service, on virtual topologies
In this network, a set of virtual topologies has been configured between C and the virtual machine or container on which each service runs. A firewall has been configured on each virtual topology. The advantage here is service-specific policies can be configured only on the firewalls that need them. For instance, only the two firewalls on the virtual topologies connecting C with S1 and S2 will need to be configured with address translation. Each firewall can also be upgraded without affecting all of the services, and each firewall can scale with the service as needed.
What if those services were disaggregated from the firewall appliance and built as a separate service?
This configuration has two major disadvantages, however. First, each firewall must still support the full set of services. Whether these are physical or virtual appliances, the network operator will want to be able to use the same device in every location for operational simplicity. This means every network firewall must be the same kind of device and support the same kinds of services.
A second disadvantage is any service commonly shared among all the services will need to be configured on every firewall in the network, and the configuration must be synchronized among all these devices. This is easy enough to automate, but is unnecessarily complex.
Disaggregate the firewall appliance into separate services
Let's look at how this problem can be solved in a way that makes more sense. One path forward is to not only virtualize the firewall, but to break it apart into its component services. In our example, remember that the firewall is composed of three services: DPI, address translation and stateful filtering.
What if those services were disaggregated from the firewall appliance and built as a separate service? Individual firewall services could then be inserted into the network where they are needed and be configured appropriately. Each firewall service would offer all the options for that particular service, but wouldn't support anything beyond that single service, thereby simplifying configuration. The figure below illustrates this kind of virtualization.
A sample network using virtualized firewall components where needed
In this network, each virtual topology now has a set of services based on each application's requirements. All of the virtual networks have a DPI service, each with identical configurations. Having one DPI service per virtual network allows that service to scale as needed, based on traffic levels and the number of services being offered. Services 1 and 2 have two different NAT instances, both of which could have either the same configuration or a per-service customized configuration. Finally, S3, S4 and S5 all have separate stateful inspection services.
Breaking the firewall appliance into multiple services, then virtualizing each service so multiple copies can be created and placed into virtual topologies allows the services to scale with the application requirements -- and be specialized enough to apply the necessary services where they're required.
