Proxy SSL and ECC ciphers

In standard SSL decryption setup there does not appear to be a way to have the Big-IP include the client certificate in the hand shake down to the server.

And this is a function (not a limitation) of SSL mutual authentication. The client's certificate is followed in the SSL handshake with a CertificateVerify message that is digitally signed (encrypted) with the client's private key. It is for this reason that you cannot decrypt and re-encrypt traffic between client and server in a mutually authenticated SSL session, because the proxy would not have access to the client's private key to reproduce this message. ProxySSL allows it to work because it is not an active member of the handshake. It silently watches the handshake, gathers the two cleartext random values, and decrypts the third random value with a copy of the server's private key, so that it can create the same master secret and silently decrypt and re-encrypt the bulk encrypted traffic. And since Diffie-Hellman doesn't encrypt anything in the handshake, it cannot be used with ProxySSL.

Currently, a reasonable solution would be to decrypt the traffic and pass an alternative credential to the backend server. This is something that APM (Access Policy Manager) does very well, or you could simply pass the server an HTTP header in re-encrypted traffic.

It's not a function of ProxySSL, but of ANY SSL man-in-the-middle technology. Without getting into the details, ECC is generally deployed with the Diffie-Hellman key agreement protocol, which does not use the server's public and private keys to encrypt anything in the initial handshake. SSL MITM relies on the RSA key exchange, because the server's public key is used to encrypt the third piece of the master secret between the client and server (the other two pieces are relayed in the clear), so anyone with access to the server's private key and a copy of the message can decrypt and access the encryption keys.