ENCRYPTION ISSUES: MOVING TOWARD HIGHER PERFORMANCE NETWORK SECURITY SUBSYSTEMS.

The Internet is an inherently insecure medium. Sensitive data must be encrypted before being dispatched, meaning that all Virtual Private Network (VPN) traffic must be encrypted before it is transmitted. This is particularly important for e-commerce involving credit card numbers, bank statements, corporate proprietary records, and other sensitive data.

The growing popularity of e-commerce and VPNs is making cryptographic security a critical gateway feature. But at the same time, it is creating a major gateway bottleneck. Internet gateways handle enormous volumes of traffic from many simultaneous sessions. Computational demands of security are greater compared to other gateway tasks. Consequently, as secure sessions become more common, the usual gateway architecture is increasingly less suitable.

Security functions are overly burdensome largely due to the nature of algorithms employed and the fact every byte in a packet must be processed. Most other gateway tasks only operate on packet headers. Cryptography works on the premise that an encrypted message is virtually impossible to decode by an unauthorized user, but is merely difficult to the authorized user. The algorithms used to implement security, encryption, compression, and authentication can be performed in software, which is ideal for systems handling small numbers of connections.

However, when large numbers of users exercise the same security features at the same time, they create a bottleneck that cannot be alleviated with software implementations. In this instance, performance must be achieved through specialized hardware.

Internet Protocol security or IPSec is the security measure for protecting corporate data and access to corporate resources over the Internet, regardless whether those accesses come from the remote user or branch office. These users access the Internet via a local connection to their service provider and data is encrypted via that channel to create the VPN. The implementation of IPSec can be in a firewall, integrated as a feature in a router, or in a separate dedicated VPN gateway.

Remote access and branch office applications take into account a great number of telecommuters and field sales personnel in most cases. Plus, branch offices may have upwards of 50 or more remote locations worldwide. Each may have multiple T1 or T3 lines to the Internet, and they transfer data among themselves, as well as with headquarters. Hence, the requirements on the headquarters gateway are exceptionally high in terms of the demanded bandwidth, which, in turn, creates major traffic bottlenecks.

Internet Protocol Security

A complete IP security solution implements IPSec, Internet Key Exchange (IKE), and IP Payload Compression Protocol (IPPCP). These protocols define the use of public-key encryption, data compression, symmetric key encryption, and authentication to implement a security solution. All these operations are computationally intensive and, depending on the bandwidth needed, may require hardware acceleration.

Public key encryption is used to exchange the symmetric keys when a secure communication link is established. The IKE protocol is used in conjunction with IPSec to perform this task. It validates the identity of users and allows them to exchange new encryption keys for every session without revealing the key in unencrypted form. Symmetric keys are the keys that perform data scrambling on each IP packet.

Symmetric key cryptography is used to encrypt each packet instead of public key cryptography because it is considerably less computationally intensive. Symmetric key encryption makes transmitted data unreadable to all but the intended recipient. Authentication is essentially a testing vehicle to make sure the secured data hasn't been violated. The IPSec protocol defines the use of encryption and authentication at the network layer. Lastly, compression reduces the size of the packet and, thus, mitigates some of the performance impact that IPSec can have on network performance. IPPCP defines the use of compression at the network layer.

IKE Acceleration

IKE represents one bottleneck. An encrypted data session begins with an automatic encryption key exchange. These keys are randomly generated for each session by their associated CPU hosts. When new keys are used for each session, eavesdroppers or snoopers cannot use old keys to decrypt new messages. However, the two systems must agree on keys. Otherwise, they won't be able to decrypt each other's messages.

The Diffie-Heilman (DH) algorithm which is part of the IKE protocol provides a mechanism for setting up a secret, but unauthenticated connection between two parties. The two without fear of eavesdroppers can negotiate a secret session key. DH involves transmission of just enough information so that the two CPU hosts can derive the key to be used. However, an eavesdropper won't be able to do so. Authentication during the key exchange is provided by RSA or DSA public key algorithms, which are also part of the IKE protocol.

IKE does not use the arithmetic operations of an average CPU instruction set. Rather than utilizing 32-bit integers or 64-bit floating point, key exchange heavily depends on extended precision modular arithmetic using 512-, 1024, or even 2048-bit integers. Also, the operations of this modular arithmetic are not limited to four-function arithmetic, but rely on such operations as modular exponentiation.

Since these keys are very large, their operation cannot be processed adequately by a general-purpose processor. Key exchange only occurs during session initiation. The process is so slow that it can bog down the system. This can severely impact systems in which time sensitive data, such as Voice Over IP (VoIP), are transmitted even if that data is not secure.

Special-purpose hardware that is architecturally suited is the best approach for handling the IKE computational load. A single chip public key processor is an example of the type of hardware needed. The modular arithmetic unit embedded in this chip operates on integers of up to 1024 bits wide and reads operands from the data register file, operates on them, and writes the results back to the data register file.

IPSec Performance Issues

Implementing IPSec can result in IP packet fragmentation and additional data transfers within the system. Both of these issues can gridlock what is often an already over burdened resource: the main system bus. In addition, systems requiring more than about Mbit/sec of security performance need IPSec hardware acceleration.

Packet Fragmentation

When IPSec is applied to a data packet at IP Layer 3, a header or trailer or both is added to the packet to let the receiving system know that IP security is used and to call out the associated algorithms. As a result, the packet grows in length. For example, an Ethernet packet is 1,500 bytes, but once encrypted, it becomes bigger.

Once the packet is enlarged, it is difficult to route it through the network. Hence, it must be split into two packets, known as IP fragmentation. The original packet may be 1,490 bytes, however, it increases to 1,544 bytes after new IP and Encapsulating Security Payload (ESP) headers, trailer information, and Message Authentication Code (MAC) value are added as called out in IPSec. This increases the original packet by 54 bytes, and thus, the original packet must now be fragmented into two packets. These additional packets impose an additional processing burden on the system. By compressing the data prior to encryption, the original packet is smaller and the additional headers and trailers added by IPSec are far less likely to induce IP fragmentation. The use of compression, implemented in IPPCP, reduces the performance impact of IPSec.

Data Transfers

if different system resources implement compression and encryption, data is forced to traverse across the system bus multiple times as it moves data to and from packet memory and the processor and on to each individual hardware accelerator. For example, data can come into packet memory. Then, it can go to the compressor, back to packet memory and then to the encryptor chip, back to packet memory, and to the authentication device and then back to packet memory. Data can crisscross the system bus multiple times as a result and this intensive processing of data bogs down system performance. When the system incorporates a single chip completely fitted with compression, encryption, and authentication functionality, data moves across the system bus two times--once to the packet memory and another time back to the integrated compressor, encryption, authentication chip.

Examples of these security processors include Hi/fn's 7711, 7751, and 7811 chips. The 7751 and 7711 each handle up to eight T1/E1 links, while the 7811 handles three times as many. A key design feature these security engines offer is the optional implementation of either a single protocol algorithm, none, or all the compression, encryption, and authentication protocols on a data packet.

These options hand network system designers considerable engineering and design flexibility in various applications. For example, a PPP compression packet going to a remote access concentrator may only require LZS compression and no other algorithm. Hence, a 7711 chip, for instance, can be instructed accordingly to only apply the LZS compression algorithm.

On the other hand, if another link happens to be an IPSec link, it can be instructed to perform LZS, Triple DES, and MD5 on the packet. Chips like these in particular applications areas can support multiple protocols for all the sessions an access concentrator supports. They can support PPP compression and multiple channel of this, as well as multiple channels of IPSec.

In a VPN/IPSec-based design, encryption can pose certain performance degradation issues, unless special care is taken to factor in compression. It is best to compress source data prior to encryption to minimize or eliminate all together IP fragmentation, which can adversely affect system performance. Single pass compression, encryption, and authentication presents the most efficient design route in these instances.

Mark Muegge is the product manager, Hi/fn, Inc. (Los Gatos, CA).

www.hifn.com