Hello Preck-
As a first point, we don't generally document ever possible aspect of performance numbers on products because there are many factors that play into the numbers. This is one of the grey areas where we cannot pin down any hard numbers due to too many outside factors.
Here is the full story on SSL client authentication:
Under a normal SSL handshake, the SSL server exchanges the public key and certificate file to the client, and a cipher is chosen to encrypt the communication between the two entities. Past that communication, there are a few things that could result in extra packets, or a new SSL handshake i.e. SSL version negotiation and/or cipher related issues. Some things can shorten the handshake time like SSL session ID's and using specific SSL protocols (i.e. if the client and server only ever used TLS v1.1 and never had to negotiate from SSL v3.0 to TLS).
Once the handshake is done, the performance only depends on network latency and the amount of time it takes to encrypt/decypt the traffic which is dependent on the SSL version, cipher, and SSL strength (key bits). This is important to your questions because the only thing that effects performance is the initial handshake process.
When you enable client authentication, before the handshake is complete, the server requests the client to send a certificate. The client may send multiple certificates, or just 1. When the server recieves the certificate, it checks that it matches the certificate that it has installed for client authentication. As well, the server may do an extra check against the CRL to see if the certificate has been revoked (this is an external call to the CA via TCP or LDAP generally) The amount of certs, size of the certs, and size of the CRL are not known to the server, hence, it has to work with what it recieves. The larger the files, the longer the handshake takes to complete.
Specific to ACE:
The degredation you are going to see is exactly what I stated in the last paragraph - it will be related to how many certs the ACE has to parse, how long it takes to get the CRL and check it all the way through. Because every client could give the ACE a different amount of certificates and the CRL could be any size/take any amount of time to retrieve and scan, there is no such thing as a common metric we can state about the difference in performance.
We can tell you that the performance degredation is limited to the VIP that you have this enabled on and should not effect any other vips/context/the whole ACE in general. It also only relates to the amount of possible transactions per second, and not to total SSL concurrent connections or throughput. Throughput is not effected because the SSL Nitrox and Cadvium engines are not used to scan the client certificate - the XScale Microengine is, so the throughput of the SSL daughter cards are not effected here.
The bit count within the keypair is non-effecting to the performance when enabling client authentication if you are comparing the same as without client authentication. Certainly, you will see a drop in performance when moving from 1024 to 2048 bit keys due to the extra complexity involved in encrypting/decrypting - but no additional loss with client authentication. On a side note, keep in mind that doubling you key bit strength means your performance will take an exponential drop - not a linear drop. If you are planning on deploying 2048bit keys, make sure you test your environment prior to production release so that you know exactly what kind of performance to expect.
About your question on partitioning resources, because this only effects the vip you have the authentication on, you don't need to worry about sandboxing off a context to handle this.
Regards,
Chris Higgins
