Members of the communication design sector have long talked about implementing security capabilities inside the datapath of IPSec virtual private network (VPN) and storage area networking (SAN) equipment designs. But, despite the hype, security capabilities have traditionally been relegated to a co-processor that connects to a network processor unit (NPU) through a look-aside auxiliary control bus.
However, with line rates increasing and security demands consuming more resources, the look-aside model is starting to fall short in meeting the security demands of today's VPN and SAN designs. Fortunately, new flow-through security processor architectures have been developed that allow designers to finally bring security into the data path and provide wire-speed security processing.
In this article, we'll analyze how the look-aside security approach works and the short falls it provides. We'll then examine how the flow-through approach handles processing tasks and show the benefits it provides to communication system designs.
Before Flow-Through
Traditional security appliances are based on software-based routers with minimal hardware for switching (PHYs, MACs, and memory), and an network processor unit (NPU) to handle the all other functions (e.g. firewalling, NAT, VPN, IDS, VDS, QoS, etc.). When performance drops to unacceptable levels, the designer will often considers a more expensive, higher performing NPU or adding an additional NPU to offload some of the burden. In either case, this adds significantly more cost to the design.
The VPN function requires more NPU bandwidth than other security functions, because most security processing analyzes certain fields in some headers of some packets. However, the VPN function requires the NPU to process every bit of every packet with compute-intensive encryption and authentication operations. Furthermore, IKE requires the NPU to perform compute-intensive public key operations. Unfortunately, software-based VPNs cannot easily perform IKE and IPSec VPN functions simultaneously, that is, while IKE is performed, IPSec processing typically halts for all secure channels. More importantly, software-based VPNs can never operate cost-efficiently at gigabit speeds, so security co-processors are connected to the network processor through a look-aside interface to accelerate critical portions of IPSec processing.
Figure 1 illustrates the simple hardware hook-up to add look-aside security functionality to an NPU. Security co-processors that are connected to the NPU through a separate control port outside the main data-flow path force the NPU to handle many IPSec packet parsing tasks and security functions, as well as the associated stack functions before handing packets to be processed to a security acceleration IC. While a look-aside security processor offloads the compute-intensive symmetric crypto and hashing functions, at gigabit speeds, the remaining protocol processing functions of IPSec can become a serious bottleneck on an NPU, especially at gigabit speeds.
Figure 1: Look-aside security system concept for a security gateway.
Figure 1 also highlights that security gateways do more than simply terminate Layer 3 (and possibly routing), terminate Layer 2 (Ethernet), and perform IKE and IPSec. Security gateways at a minimum also perform the firewall function and network address translation (NAT), in addition to other compute-intensive applications, such as intrusion detection (IDS), virus detection & scanning (VDS), and some level of quality of service (QoS).
After the packet is classified, these additional functions can be added modularly and incrementally by enhancing the policy table, then incorporating additional software. However, at some point, the NPU resources will become exhausted, and throughput performance will begin to degrade.
Figure 2 compares the additional host NPU bandwidth required (for both IKE and IPSec) of traditional look-aside architectures versus systems that implement flow-through technology.
Figure 2: Flow-through vs. look-aside functional comparison.
In the look-aside architecture, inbound packets are parsed and classified, policy, and security associations are looked up, and IPSec headers may need to be removed in the NPU all before the encrypted packet is either decoded in software or forwarded to the look-aside security processor for decryption and authentication. Outbound traffic follows a similar process, only in reverse. That is, outbound packets are parsed and classified, policy and security associations are looked up, and IPSec headers may need to be added in the network processor all before the IP packet is either encoded in software or forwarded to the look-aside security processor for encryption and authentication.
Figure 2 illustrates the amount of additional NPU burden created by adding VPN functionality with hardware offload for only security algorithms. IKE is more than just modular exponentiation, as a single IKE transaction also requires forming nine messages, negotiating policies, and setting up the SA database entry, as well as performing Diffie-Hellman and RSA public key operations. IPSec is more than just AES and SHA-1 algorithms, as IPSec also requires packet parsing and classification, security policy and SA look-up, creating and checking security headers, checking SA lifetimes, and updating flow statistics. Thus, off-loading only some of the compute-intensive portions of IPSec is inadequate, especially at gigabit speeds.
Furthermore, in Figure 2, the look-aside column represents the functionality of traditional security product offerings from algorithm accelerator or packet processing vendors. Algorithm accelerators only perform encryption and authentication algorithms, and some vendors also support IPComp compression. Packet processors additionally convert from IP packets into IPSec packets, and vice versa. Some look-aside crypto devices also offer public key acceleration hardware. Thus, it can be seen that the look-aside devices only offer a fraction of the total IPSec and IKE processing functionality in hardware, and may not solve the problem of performing IKE and IPSec concurrently.
Lastly, the fact that in the look-aside configuration some of the VPN protocol processing tasks are handled by the system processor, means that a significant amount of IPSec and IKE software must be developed, ported, and integrated by the OEM developer. This adds significant software complexity, time to market, engineering risk, and development resource load to incorporate VPN functionality at line speed.
The Flow-Through Advantage
The flow-through security architecture is a fundamentally new approach to hardware implementation of the IPSec security protocol. In the flow-through architecture, the security processor is located in front of the network processor. The flow-through security processor handles all of the IPSec hardware and software functionality without any outside intervention. The NPU can operate as if it didn't know the VPN function was there.
Figure 3 illustrates the flow-through solution, offloading all IPSec and IKE processing. The flow-through IPSec device shown in this figure contains the policy and SA databases and IKE support all on chip. The self-contained flow-through device allows the NPU to perform other security, networking, and QoS functions, without requiring any modifications to rest of the design.
Figure 3: Flow-through security system concept for a security gateway.
In the flow-through architecture, the MAC to PHY hardware connection is broken. Thus, the flow-through device acts as a PHY to the host port and acts as a MAC on the network side. This hardware hook-up greatly decreases the system design effort required of OEM developers, and not only works in VPN implementations, but also in IP Storage equipment, where the flow-through device is located between the TOE and the PHY.
All IPSec processing functions for inbound traffic are completed at line speed before the traffic reaches the network processor. The standard hardware interfaces (GMII, TBI, PL-3, etc.) allow the flow-through security processor to feed network or system processor at line rates. This enables predictable VPN performance independent of NPU bandwidth, because the NPU is not performing any IPSec function, other than exception conditions, and configuration of policy. Latency is reduced because multiple look-aside bus transactions are not required.
Device configuration can occur using a standard Internet browser, or can be integrated into the system configuration software using a low-level interface over Ethernet, for example. The only other system software required is for exception handling.
In addition to technology benefits, the flow-through solution provides development benefits. Flow-through devices can be easily integrated directly into the datapath, as they disturb very little of the system when adding the IPSec functionality. Flow-through devices can further reduce design risk by featuring an ICSA certified IPSec/IKE solution ensuring tested and certified interoperability.
The self-contained VPN solution accelerates time to market by significantly reducing the software effort to implement the IPSec and IKE protocols. That is, there is no IPSec API to integrate into the system software for processing each IPSec packet.
Additionally, the OEM developer is not burdened with maintaining the IKE and IPSec software, as this is a benefit to the OEM by incorporating an encapsulated flow-through IPSec solution. Furthermore, the OEM developer is not burdened with migrating to new IPSec standards that emerge, as the FlowThrough device manufacturer also supports this.
Wrap Up
The flow-through security architecture allows security to be easily added to a system in a way that provides maximum offload with minimum integration work at a low-cost. The flow-through architecture provides a more efficient technology solution over traditional look-aside architectures, while guaranteeing VPN performance, accelerating time to market, lowering implementation risk and in-house IPSec expertise required. The flow-through architecture also frees NPU bandwidth for integrating additional security features, such as firewalling, intrusion detection and prevention, and virus scanning.
About the Author
Robert Friend is a senior staff technologist at Hifn, where he evaluates next generation protocols, technologies, and market segments. Robert is an active member of the Internet Engineering Task Force (IETF), co-author of RFC1967, RFC1974, RFC2395, contributor to RFC2118 and RFC3078, and holds a patent for a switchable bus termination and address selector. He earned a BSEE from UCLA and can be reached at rfriend@hifn.com.
