FPGAs boost protocol flexibility

Network systems houses provide excellent security at the virtual private network and firewall levels, but not at the router, switch, server and storage-area network levels. The reason? The inordinate cost of implementing security via ASIC technology at these network points.

Implementing these subsystems with ASICs poses considerable design cost and challenges, not to mention the difficulties in adapting the subsystems when new and different security protocols evolve. One way to eliminate the cost issues and provide designers the best of all worlds is to take a field-programmable gate array approach so that security can indeed be cost-effectively designed into routers, switches, servers, and storage-area networks (SANs). Also, by deploying FPGA technology in a security blade, changes can easily be made so that periodic outlays for new security subsystems with the newer protocols are not necessary.

The ASIC issue poses one challenge. Another is the network bottleneck created because some network operations-such as security-are still in the megabit/second performance range while network systems operate at the blazingly fast gigabit level.

Today, in some original equipment manufacturer design camps, network security can best be described as a value-added function; in others, security is an afterthought and usually implemented via software for virtual private network, Secure Sockets Layer (SSL) and Transfer Layer Security (TLS) protocols. However, savvy system designers know hardware-based Internet Protocol Security (IPSec) and SSL acceleration is the only way to achieve multigigabit performance.

This hardware-based design approach is currently not available in switches, most routers, SANs or servers. The reason: economics. Present-day system architecture for embedded subsystems such as routers, Internet Protocol (IP) service switches and wireless local-area network switches does not take security into account due to the high cost, design complexity and extended time-to-market associated with ASIC-based network subsystem designs. Consequently, the need for a cost-effective and manageable security solution is paramount as network security becomes an even greater part of the enterprise.

With increasing demand for greater system versatility and performance, designers already face difficult challenges. On top of this, the enterprise continues to call for increasing levels of security. Designers are confronted with the daunting task of trying to stay current with new security standards and adding them to already difficult designs.

One way to place security at the network subsystem level and avoid such problems is to make it much more flexible and programmable at the hardware level. Here, an FPGA-based security blade performs single-pass header and trailer processing on IP and IPSec packets; Lempel Ziv Stac (LZS) and Microsoft Point-To-Point Compression (MPPC); industry-standard encryption, such as tripleDES (Data Encryption Standard), Advanced Encryption Standard (AES), RC-4 and ARC; and authentication, Secure Hash Algorithm-1 (SHA-1) and Message Digest-5 (MD-5 ). In this case, operational throughput always keeps up with a 2.5-Gbit/s line rate on a 1,500-byte packet.

Proprietary algorithms are defined for specific transactions, particularly for government operations. These must be taken into account in a security subsystem. When the system designer has an FPGA in a security system, the central control logic is able to classify nonstandard algorithms and generate exception calls to the host.

The host microprocessor immediately assumes algorithm acceleration. This feature is advantageous to designers since the FPGA-based design can support a broad range of security algorithms.

In our design, putting the controller in the FPGA is the key to making a security blade design flexible for any host system such as a router, switch or server. It configures the blade for a network customer's system and provides a tool to add any new security algorithms on the fly versus making changes to silicon that might take months to perform.

The FPGA-based dedicated controller we designed also provides information that tells the user if the packet header has security data or not, making it easy for system providers to perform statistical data analysis on the network on regular packets versus security-based packets.

The blade consumes little space and power. And it provides enterprise management high performance with technologies such as zero-overhead fault tolerance and wire-speed scalability up to OC-192 without development overhead.

Scaling without overhead

Scalability is not the only benefit, but is also a way to significantly shorten implementation cycles. A security blade provides scalability since it is designed to provide higher system bandwidth. That's done by changing components such as security processors or embedded protocols in the FPGA so that performance objectives in a router, server or switch can be met.

It's important for designers to carefully scrutinize scalability when evaluating network security devices. If those devices use network bandwidth to manage scalability, the overhead will increase relative to the number of system nodes. This kind of system can impose diminishing returns on throughput as the number of nodes increases. Devices that can scale without adding overhead, like the FPGA-based security blade, are more effective regardless of increasing nodes.

A security blade also alleviates concerns about deploying a new function such as security in the fast-paced world of Internet speeds. The FPGA's inherent flexibility helps the designer adapt to a new interface for host systems and/or to using new security algorithms in days rather than months, as is the case with ASIC-based designs.

The interface protocol management residing in the FPGA-based flow controller we built is the key that opens up infrastructure security to make it more cost-effective and manageable. It hands system designers the needed flexibility to upgrade features such as fault tolerance, IPSec protocols and system interface issues. Such FPGA-based security blade designs are ideally suited for SANs. IP storage protocols such as Internet SCSI (ISCSI) and Fibre Channel IP (FCIP) enable block-level storage commands to be transported over TCP/IP, leveraging the enormous IP networking infrastructure and knowledge base.

To match the performance of incumbent fibre channel SAN technology, IP storage solutions must run at gigabit rates without disrupting the interoperability benefits of gigabit Ethernet and TCP/IP networks. Also, since IP networks are ubiquitous, IP storage networks, unlike existing SAN installations, must provide the mechanism needed to ensure secure traffic flows.

Data centers are at the heart of any enterprise, and they demand network security and availability. IP storage standardization efforts have addressed these needs by requiring protocols that support IPSec/3DES encryption and Internet key exchange (IKE) public/private key exchange. The combination of IPSec/IKE with the IP storage protocol standards, while secure between SAN flows, still poses design challenges to SAN equipment and system suppliers.

These include how to design cost-effective, space-efficient security functionality, while integrating hardware components, drivers and application software needed to support IPSec-compliant ISCSI/FCIP products. Another challenge: how to structure high-performance designs capable of running secure IP storage flows at the 1-Gbit/second-plus rates that SAN applications require.

See related chart