Encryption provides powerful security advantages when used appropriately. It is also one of the most computationally expensive protection measures available in our security toolkit. In this section, we will discuss cryptography from a performance standpoint, including the differences in ability and performance between public key and symmetric key cryptographic systems.
If you would like to learn more about cryptographic services, see Appendix B, "Crypto 101." It provides a basic introduction to the subject and its terminology.
We will also discuss performance characteristics of network cryptographic protocols at the network layer, such as IPSec, and transport layer, such as SSL.
As discussed in Chapter 7, "Virtual Private Networks," cryptography is often used to provide four important security services: confidentiality, integrity, authentication, and nonrepudiation.
Each of these services uses particular cryptographic techniques, and each has varying impacts on the performance of your systems. Confidentiality and integrity services affect performance for as long as they are in use. Because of this, they are normally provided using symmetric key cryptography. Efficient symmetric key algorithms exist that allow high-performance systems to be built using relatively low-end equipment. Public key cryptography can also be used in theory to provide confidentiality and integrity services, but this is not common because public key cryptography requires significantly more work and time to encrypt and decrypt data than symmetric key cryptography.
Public key cryptography makes up for its performance problems by offering the ability to authenticate users and uniquely identify the creator of a message. Because authentication and nonrepudiation are typically only performed once per session, the additional work needed for the public key algorithm does not unduly affect the performance of the entire session. Protocol developers frequently combine the best aspects of both types of cryptography when designing their protocols. It is common for public key techniques to be used to authenticate users and then exchange session details, including a shared secret. This shared secret is then used to generate a key used to encrypt the rest of the conversation using symmetric key cryptography. In this way, the strengths of both techniques are maximized while their weaknesses are minimized.
Understanding Encryption at the Network and Transport Layers
Cryptographic services can be added to almost any layer of the network stack. The decision of which layer to implement your cryptographic services on is dependent on the specific security goal you are trying to accomplish. In the following sections, we will discuss cryptography at the network and the transport layers.
Network Layer Cryptography
Network layer cryptography allows private conversations to occur across untrusted networks. They can be organized as network-to-network, network-to-host, or host-to-host links. The major cryptographic service offered is confidentiality. Performance impacts are driven primarily by the increased CPU utilization of the sending and receiving devices. This impact grows with traffic volume; high-bandwidth circuits use more CPU cycles than low-bandwidth circuits.
Assuming sufficient network bandwidth, performance of a VPN is mainly determined by the choice of algorithm and the hardware platform. A variety of popular algorithms are in common use, including Digital Encryption Standard (DES), Triple DES (3DES), Advanced Encryption Standard (AES), and Twofish. However, the choices available to you will be limited by those supported by your VPN device. In general, algorithms that use larger keys are more secure, but they also perform significantly worse. Table 17.2 shows some common algorithms and the key sizes they support.
Even though algorithms with key sizes of 56 bits or lower, such as DES, have been decrypted using brute-force methods, you should not immediately discard their use. If immediate discovery of the contents of your messages is your primary concern, a 56-bit key algorithm might be more than enough to provide the necessary security while allowing you to use much higher performing encryption algorithms.
The speed of the hardware platform is the other major determinant of VPN performance. Encryption is a CPU-intensive operation. Because of this, platforms with faster processors perform better. Some hardware vendors also support hardware cryptographic accelerators. These are coprocessors that are optimized to perform cryptographic operations.
Be wary of manufacturer performance claims. Performance claims are often highly optimistic. If possible, test the performance of a device in your environment prior to committing to it.
When implementing a VPN in your environment, it is tempting to use preexisting equipment to implement the VPN service. Most firewalls and routers offer this ability either as a standard feature or as a low-cost option. The major performance impact of network layer encryption is CPU utilization on the encrypting and decrypting devices. You should be careful when adding a VPN to an existing router or firewall. If the CPU utilization is already high, then adding the VPN might cripple the device's ability to perform its other duties.
If CPU utilization is too high but a hardware upgrade is not possible, consider reducing the amount of network traffic being encrypted. Most VPN devices allow you to set filters that specify a subset of the network traffic to encrypt. Using this feature can dramatically reduce CPU load.
Transport Layer Security (TLS)
Transport Layer Security (TLS) is an important protocol for providing confidentiality, integrity, and authentication services, and it is in widespread use across the Internet. It was originally named Secure Sockets Layer (SSL) and was created by Netscape. SSL version 3 was the foundation used by the Internet Engineering Task Force to create TLS.
TLS is most commonly used for sensitive web connections, and it can also be used to protect other application protocols such as SMTP. Because of TLS's popularity, it is important to discuss some of its performance characteristics. TLS is composed of two different protocols: the record protocol and the handshake protocol. The record protocol carries the traffic of the TLS connection and can support several encryption protocols, including RC4, DES, 3DES, and Fortezza. The actual encryption used is chosen during the negotiations that occur at the start of a TLS session. These negotiations are handled by the handshake protocol, which authenticates the server to the client, optionally authenticates the client to the server and then negotiates session details, including the exchange of a master secret that will be used to generate the symmetric keys used by the record protocol.
The SSL performance cost is a combination of the one-time session setup costs performed by the handshake protocol, followed by the continuous cost of the record protocol as it encrypts the session traffic using the chosen encryption protocol. Of the two, the record protocol would seem to be the more dominate because its performance impact lasts for the entire session, whereas the handshake protocol's impact is limited to once per session. This turns out not to be true. There are two main reasons for this. First, web sessions tend to be short, with an average data transfer of approximately 4,000 bytes. This limits the amount of time over which the handshake costs can be amortized. Second, the SSL handshake, at least from the point of view of the server, turns out to be an expensive operation.
During the SSL handshake, both the client and the server are asked to perform public key cryptographic operations. However, the server performs the majority of the work. During the handshake, the client receives the server's certificate, which it uses to extract the server's public key. It uses this key to encrypt a secret, which the server eventually uses to generate the shared secret on which the record protocol relies. Before the server can make use of this secret, it must decrypt it. This decryption operation requires roughly two to three times more work than the encryption operation. During a typical SSL web transaction, the server might have to perform 100 times more work to negotiate the session than it would use to encrypt the data to be transferred.
The designers of SSL were aware of this problem. To help alleviate this, they included the ability to cache session details so that subsequent SSL sessions could resume the previous session without performing any of the public key operations. During the initial communication between client and server, the client can present a session ID that it received during the previous handshake. If the session details are still in the cache, the session can be resumed. Performance improvements as cache hits increase are impressive. Netscape reports the ability to handle 2.5 times more operations per second when session reuse is at 100%.1
If SSL performance is low, try increasing the size of the session cache and the length of the session timeout. This increases the chances of cache hits.
If performance is still too low, try limiting the sections of the website that require SSL protection. Most e-commerce sites do not switch to SSL protection until a financial transaction is about to occur. This limits the amount of SSL sessions the site must accommodate.
Using Hardware Accelerators to Improve Performance
Another method you can use to boost performance is to offload the CPU workload to a coprocessor that is specifically designed to perform cryptographic operations. This provides two performance benefits. First, it significantly reduces the load on the main CPU. Because the main CPU does not have to perform the cryptographic operation, its time can be spent performing its normal activities. Second, because hardware accelerators are designed specifically to perform the mathematical operations that cryptography requires, they can perform cryptographic operations more efficiently than general-purpose computers.
Hardware accelerators are available for a wide variety of platforms, including Cisco PIX firewalls, HP-UX servers, Sun Solaris servers, Windows servers, and Linux servers, and a variety of protocols, including SSL and IPSec. When considering the purchase of one of these devices, keep the following details in mind:
Whether you should consider a hardware accelerator depends on your performance goals and the availability of a product that supports your environment and your budget. The price of hardware accelerators can be high. If your current hardware can support the workload, hardware acceleration is wasted money.
Case Studies to Illustrate the Performance Impact of Encryption
These two case studies illustrate some of the cryptographic performance concepts we have covered so far. The first case study examines link encryption performance between two networks. The second case study looks at the performance of web servers when encrypting HTTP sessions.
Case Study 3: Link Encrypting Between Two Routers
A large organization (ALO) has purchased a 768Kbps frame-relay connection between its main headquarters and one of its business partner's field offices (BFO). A Cisco router, as shown in Figure 17.4, terminates each side of the connection. The ALO side has a Cisco 3640 router, and the BFO side has a Cisco 2611 router. Because ALO is not in control of the security policy of the BFO network, it has placed a firewall between its network and its Cisco 3640 router. Rules have been established on the firewall to prevent unauthorized network traffic from entering the ALO network. In addition, due to the sensitivity of the information that needs to be sent between the two networks, an IPSec encrypted tunnel has been set up between the two edge routers. Cisco's documentation shows that the 2611 router would not be able to provide sufficient performance when using the 3DES algorithm. DES performance, however, looks acceptable. Because of this, a business decision has been made to use the less secure but faster 56-bit DES algorithm. Performance between the two networks is acceptable, but it is slower than expected given the relatively large bandwidth connection that was purchased. The ALO management has asked you to look into the problem.
Figure 17.4. Case study 3 examines the link encryption performance issues.
In this case, the problem is more than likely the performance hit from the encrypted tunnel. Running a tool such as ttcp between the two sites can verify the actual available bandwidth.
Never run ttcp during normal production hours. To measure the bandwidth, ttcp has to consume it all. Not only would running ttcp during business hours cause its results to be wrong, but it would also bring the network to its knees while ttcp was running.
In this case, ttcp reports performance in the 260Kbps range. This is far below the bandwidth of the WAN link, so we need to look further into our configuration to determine the problem. An examination of the CPU utilization of both routers taken during the ttcp test will reveal the problem. The Cisco 3640 will more than likely be reporting CPU utilization rates at or below 50%. This will not be the case of the Cisco 2611. This router has a much slower CPU and will likely be reporting utilization rates above 85%. At this level, packet-forwarding performance is affected, increasing latency and potentially causing packets to be dropped. With encryption, the weakest link sets the overall performancein this case, the Cisco 2611.
Now that we have identified the likely cause of the problem, what can we do about it? Because performance is acceptable, the easiest answer might simply be to ignore it. This is somewhat unsatisfactory, though, because ALO is paying for WAN bandwidth of which it is not able to take advantage. Reducing the bandwidth of the circuitif it substantially reduced the pricemight be a compensation for this. However, we need to be careful not to reduce the bandwidth too low or it will become the bottleneck. Another solution might be to reduce the key size of the encryption protocol. Forty-bit DES might reduce the load sufficiently to allow full performance to be achieved, although this would come at the expense of a substantial weakening of the confidentiality of the connection. An alternative solution might be to look at another tunneling protocol. Cisco routers support a proprietary tunneling protocol called Cisco Encryption Technology (CET). CET performs better than IPSec, so when your VPN consists entirely of Cisco products, CET might be a viable option. Your last option is to upgrade the hardware. If you have the budget, you could solve the problem by upgrading the Cisco 2611 router or adding a crypto accelerator card to it.
Case Study 4: SSL Web Server
A company maintains a server that has a website it uses to provide private company information to its large traveling sales force. After a recent embarrassing defacement of the company's public website, it became much more security conscious and has configured an SSL version of the website on the server. Client certificates have been installed on all the sales force laptops, and the website has been configured to require client-side SSL authentication. Almost as soon as the SSL website went online, the complaints started to come in. The sales force stated that the website was almost unreachable, and when it did respond, it took forever for a page to download. You have been asked to help eliminate the performance problems while still maintaining the security of the site.
By reusing the existing server, it is likely that the company did not consider the additional load that the SSL protocol would add to the server. CPU performance is more than likely the cause of the problem, and CPU utilization measurements bear this out. To reduce the load, you might look at SSL session reuse. If the session timeout values or session cache sizes are too low, the server performs unnecessary full SSL handshakes. Increasing these values might reduce the magnitude of the problem. If performance is still too slow, a hardware upgrade might be appropriate. Assuming that the budget is available, a faster computer or an SSL accelerator could be used to decrease the performance hit that SSL is causing. If this is not possible, the only remaining option is to limit the required number of SSL sessions. If some data on the site were less sensitive than other data, then removing it from the SSL side of the web server would reduce the work that the server needs to perform.