SSL Orchestration: Making outbound SSL inspection faster and more resilient

Last month the super-friendly guys at DevCentral let me use their awesome lightboard studio to record a ten-minute video about outbound SSL orchestration. In the video, I said that an administrator could make the service even faster by sending data to different inspection units in parallel.

 

In reality, though, an administrator may not want to do this, for one very simple reason: One of the primary resources the SSL Orchestrator is trying to protect is the CPU cycles on each of the inspection devices. If the administrator were to send the traffic for multiple inspection to two units simultaneously, it would consume CPU cycles on each for every outbound connection, even if that connection could have been discarded by the first device.

 

One way to architect the outbound service chain would be to promote the inspection device that can toss away the most connections for the least amount of CPU first in the chain. Let’s take a look at a theoretical example.

 

• Suppose a URL-based Web Gateway costs 1 unit of CPU for each connection it examines.
• Suppose a sandbox costs 1,000 units of CPU for each connection it examines.
• By processing these in parallel, the cost to examine each outbound connection is 1,001 units, for every connection.

The more efficient way to architect the solution is to send outbound traffic to the URL Gateway, allowing it first right of refusal. If the Gateway discards the connection first, the sandbox will never see it -- thus saving 1,000 units of CPU.

So even though, in the video, I say that an administrator could make the system faster by processing in parallel, you probably wouldn’t want to do that.

Consider that my mea culpa. And thanks for allowing me to make the clarification.

 

Now, let’s get back to the good stuff. By using custom service chains in a serial fashion, the SSL Orchestrator can still speed up outbound traffic and make it more resilient in three important ways.

 

First, many administrators will want to send only certain types of outbound traffic to subsets of the service chain. For example, server updates from the data center might skip the NGFW and go primarily to the IDS/IPS. And user traffic can skip the IDS/IPS. Obviously, the choices about which traffic goes to which inspection device is specific to each customer, but you get the idea.

 

Second, by intelligently choosing which types of traffic should transit which inspection devices, the CPU cycles of each device can be used more efficiently. With more CPU cycles available, transit times can be improved.

 

Third, the integrity of outbound traffic is improved because the SSL Orchestrator is node-monitoring each of the security inspection components in the chain. If a unit goes down, the Orchestrator will simply not send traffic there while the unit is rebooting, keeping all outbound traffic moving. It is removing the single point of failure for all outbound traffic.

 

Customers have been using F5 for twenty years to bring intelligence to their inbound traffic flows. Now, F5’s SSL Orchestrator is bringing intelligence to the outbound traffic flow. These are great days!