cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Previous day (Jan 2, 2006) | Main | Next day (Jan 3, 2006) »

Tuesday January 03, 2006

Why you can't accelerate LDAP over SSL

As information security comes more and more to the forefront, we're seeing an ever-increasing percentage of our customers configure most or all of their directory-enabled applications to communicate with the server over SSL. It's common knowledge that protocols tunnelled through SSL are generally more expensive than if they're used without SSL, so many of these customers ask about using an SSL accelerator to help reduce this impact. However, all the administrators that I've talked to that have used an accelerator in conjunction with the Directory Server have been unimpressed with the results. For those that I've talked to ahead of time, I've been able to explain why this is the case and let them decide whether they still want to use an accelerator when they have all the details.

Before I explain why this is the case, let me point out a few caveats:

The only SSL accelerator that we officially support with the Directory Server is the Sun CryptoAccelerator 1000 on SPARC-based Solaris systems using the 32-bit version of the server. Even though the NSS library uses the standard PKCS#11 interface and we have tested with other accelerators (including the CryptoAccelerator 4000 and the NCP built into the UltraSPARC T1 processor on Sun Fire T2000 systems) the SCA 1000 is the only one that is officially supported at this time.
There are known issues when attempting to use PKCS#11 devices with the Directory Server on Solaris 10. These issues are being addressed for the upcoming Directory Server 6 release, although there are workarounds for the current version if necessary.
The information contained in this post is not specific to the Sun Directory Server, but applies to any case in which LDAP is used over SSL. Any LDAP directory server that can be used in conjunction with an SSL accelerator would see the same results (unless they've got a broken SSL implementation to start with).
The information contained in this post is not specific to Sun's SSL accelerators, but applies to any SSL accelerator currently available, including specialized network devices like switches and load balancers. For many protocols (especially HTTP) Sun's accelerator boards provide huge performance improvements for SSL-based communication.

To understand why you can't really accelerate LDAP over SSL, you need to understand a little about how SSL works and then a little about how SSL accelerators work. This post is a feeble attempt to provide that information for you to understand why this is the case.

Many encryption algorithms fall into two categories: symmetric or asymmetric. Symmetric encryption algorithms, like 3DES, RC4, and AES, are those that use the same key to decrypt data that was used to encrypt it (so both parties must have the same key). Asymmetric encryption algorithms, like RSA and Diffie-Hellman, use different keys for encryption and decryption (often called public and private keys). Symmetric encryption is generally much faster than asymmetric, but secure key management is usually much easier with asymmetric algorithms. The beauty of SSL is that it combines both forms in order to get the convenience of asymmetric key management with the speed of symmetric encryption. It accomplishes this by generating an essentially random value to use as the key for the symmetric encryption, using asymmetric encryption to securely transfer that key to the other system, and then switching to the faster symmetric encryption mechanism using that randomly-generated key to actually encrypt the communication.

Because the expensive asymmetric encryption is all done up front when the connection is established, the longer that a connection can remain open and using the agreed-upon symmetric key, the smaller the relative cost of the asymmetric key exchange will be. Unfortunately, however, many protocols (like HTTP) use relatively short-lived connections in which the connection is established, the expensive asymmetric key exchange occurs, the request is sent using symmetric encryption, the response is read using symmetric encryption, and the connection is closed. If the connection had remained open and the client had used it for additional requests, then the relative expense of the key agreement up front would seem much smaller by comparison. Although using the same connection for lots of requests is very common in well-behaved LDAP clients, it's much less common with protocols like HTTP and so the expense seems greater.

I should point out that there is a notable exception to this for cases in which a client needs to create multiple SSL-based connections to the same server for separate requests over a relatively short period of time. In these instances, there is an optimization in the form of SSL session sharing that allows the client to perform the expensive asymmetric key exchange when establishing the first connection, but then having subsequent connections indicate that they want to use the same symmetric key as was used for the first. This is good and can really cut down on the expense of the asymmetric encryption, but only for cases of communication between the same client and the same server. It doesn't really provide any help for cases in which lots of different clients are establishing connections to the same server, or where a single client establishes lots of different connections to different servers, but nevertheless it can at least be of use in some cases (e.g., an HTTP client needs to use one connection to retrieve an HTML document and then other connections to retrieve associated files like images, stylesheets, or frames, or a user loads one page and then clicks a link on that page to load another from the same server).

The net effect of this is that the worst SSL-based performance will come from applications that need to handle lots of short-lived connections from a wide range of clients. This is exactly the kind of access pattern that most Web servers endure. On the flip side, the best SSL-based performance will come from applications that use a relatively small number of persistent connections, or failing that, those whose connections come from a relatively small number of clients such that session keys can be re-used. This is exactly the kind of access pattern to which most directory servers are subjected. Since the most common scenario (the one used by Web servers) is also the worst-performing, then this is the one that is targeted by SSL accelerators. Such accelerators have special hardware and built-in logic that allows them to process the expensive calculations associated with asymmetric encryption (particularly for algorithms like RSA). Since this is a very rare access pattern for directory servers, they will generally see little to no benefit from this optimization.

Some SSL accelerators, like the Sun CryptoAccelerator 4000, also make an attempt to speed up certain symmetric encryption mechansisms (also called bulk ciphers), which most commonly includes algorithms like 3DES, and AES. These algorithms are among the most expensive of the symmetric mechanisms, with 3DES taking about 108 clock cycles per byte of encrypted data (source) and 128-bit Rijndael (used by AES) somewhere around 291 clock cycles per byte (source). On the other end of the spectrum is RC4, which only requires about 7 clock cycles per byte. In fact, RC4 is so fast on its own that it's virtually impossible to accelerate through any means outside of the CPU itself because the expense of transferring the data to another board and the associated interrupt handling would negate any potential gains that could be had through specialized hardware. About the only case where one might see improvement would be if the CPU itself had special enhancements for recognizing and optimizing these kinds of operations and none of the major CPUs on the market have this capability (yet).

In many SSL implementations, including the one used by our Directory Server, RC4 is used as the preferred cipher for bulk encryption. This means that short of RC4 acceleration in the CPU itself, you're not going to see this symmetric encryption get any faster than it already is. While it is possible to configure the server to use other ciphers like 3DES and AES that can be accelerated, it doesn't make sense to do so from a performance perspective because even the accelerated forms of these algorithms are slower than unaccelerated RC4.

Another factor that impacts the ability to accelerate symmetric encryption in SSL is the amount of data that needs to be encrypted. The more data there is to encrypt, the bigger benefit that you will see from accelerating it (assuming that the cipher being used can be accelerated). Things like HTML documents and images that are commonly transferred over HTTP are usually at least several kilobytes in size while most LDAP messages top out around a couple hundred bytes, although this will obviously vary with the type of operation (e.g., the size of search result entries depends on the size of the entries and what subset of the attributes are included). So unless your LDAP clients are routinely performing searches that match large numbers of entries and/or those searches are returning entries with lots of data, then there isn't a whole lot of room for improvement by accelerating the symmetric encryption.

So as you can see, it turns out that LDAP is pretty much a poster child for SSL in the way that clients tend to avoid the expensive asymmetric calculations and use small message sizes, and in most cases the performance hit from using SSL in the Directory Server is smaller than you might have expected. Unfortunately, the same qualities that make it a good match for software-based SSL make it the ugly stepchild when it comes to accelerators because the things that they do to help HTTP don't help LDAP. As usual, let me point out that there are exceptions to every rule and I'm sure that there are some customers out there that do have directory access patterns that would lend themselves to acceleration, and in fact I have run several tests with LDAP over SSL using contrived workloads in which I have seen performance improvements resulting from hardware accelerators, but it's just not very common. And of course I should also note that there may be other reasons to use one of these boards than just to speed up SSL (e.g., secure key storage is an attractive feature of the Sun CryptoAccelerator 4000, particularly with its FIPS 140-2 level 3 certification). But if you're in the market for an accelerator in an attempt to speed up LDAP over SSL, then you might want to take the time to investigate this more closely to see if it would really help in your environment. Perhaps a trip to an iForce Customer Benchmarking Center might be in order.

Posted by cn_equals_directory_manager ( Jan 03 2006, 09:30:39 AM CST ) Permalink Comments [5]