The Trouble With Middleboxes – Part 2

In the first part of this series, we looked at how the CPU/RAM resource limitations of security middleboxes severely restrict their ability to scale and migrate from perimeter defense to datacenter-based architectures.  When aggregating large numbers of networked assets and/or the traffic from large numbers of endpoints into the cloud, even the most basic stateful functions of these middleboxes become constrained by their resource limits, and performance becomes more drastically reduced when these middleboxes are tacked with packet inspection and forwarding.

In this part we now need to look at the challenges imposed onto networks in deploying security middleboxes onto networks.  The greatest of these challenges is that of traffic symmetry, which is the ability to forward traffic in such a way that the middlebox can examine all packets in a given session, both in the originate and reply direction.  Without symmetric traffic flows, a middleboxes functionality can degrade, such as in the case of an IPS engine that fails to detect an attack, or the middlebox can even fail, as in the case of a FW that drops a reply packet since it isn’t aware of a session originated though a FW on another path.

Within the traditional deployments of enterprise perimeters, as well as the predominant use of IPv4, the problem of maintaining traffic symmetry through middleboxes was mostly resolved through the use of network address translation (NAT).  Security middleboxes on the given path from a perimeter are tasked with translation the private RFC-1918 IPv4 addresses used internally within a network into publically routable IPv4 addresses.  While the deployment of NAT was intended to deal with the limitations in the number of public addresses in the IPv4 address space, security middleboxes benefit from NAT in that reply traffic returns to the translating device.  The advantage of using NAT is lost on IPv6 networks, where NAT is not required to transition between private and public address spaces, as endpoints are given publicly routable IPv6 addresses.

Network architectures are also becoming more multi-path in nature.  The deployment of middleboxes onto redundant paths from network perimeters can be tolerated to a degree, as long as endpoints give a preference to one path over another, or as long as the middlebox itself is the convergence point of the multiple paths.  But if equal-cost multi-path routing environments (ECMP) or other route engineering allowing for traffic distribution amongst multiple active paths are introduced, this will result in asymmetric traffic relative to observing middleboxes.

The problem of asymmetric traffic compounds itself as server/application assets are migrated from enterprise networks to the cloud.  Datacenter architectures are highly multi-path in nature, including multiple peer points and the internal leaf-spine architecture that places all points of the datacenter within one forwarding hop of each other.  It is no wonder that virtualized middleboxes offerings focus on their placement as close to the protected asset as possible, in a manner called micro-segmentation, as there appears to be no reasonable traffic aggregation point where one can effectively deploy a middlebox.

Adding even more complexity to the challenge of deploying security solutions into the cloud is the growing use of segment routing.  Undergoing standardization within the IETF, segment routing provides a flexible means of performing stateless source-based routing on MPLS networks.  Segment routing support already exists within MPLS deployments from major routing vendors.  However, making use of segment routing to deal help aggregate middlebox traffic would be add more challenges than it resolves, particularly as most middleboxes do not offer native support for MPLS.

Similarly, traffic forwarding through the use of programmable forwarding rules offered by software-defined networking (SDN) can allow for deployment of aggregated and scalable security solutions, as an alternative to the limitations of micro-segmentation or deployment of large middleboxes.  The challenge here is in SDN switches supporting large numbers of programmable forwarding rules, and the operational challenges of converting policies and threat information into programmable flows.

In any case, the future of deploying network security solutions lies in dealing with the network integration issues to overcome the issues associated with asymmetric flows.  Micro-segmentation, segment-routing, and SDN are examples of potential solutions, but the one thing these examples have in common is that they do not result in deploying larger middleboxes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s