When defining IPSec VPN tunnels, how much of a performance impact can I expect from choosing "stronger" Phase 1 settings (such as AES256/SHA1/DH5 over DES/MD5/DH1)?
For example, I'm told that AES-256 is 40% slower than AES-128 (which is reasonable, I guess), but am I right in thinking that overall "noticable" tunnel throughput is only really going to be affected if that is specified in Phase 2?
I'm thinking that specifying/prioritising stronger Phase 1 settings will just mean that the endpoints will take marginally longer to authenticate on startup (and at the lifetime intervals), rather than decreasing the throughput of the tunnel, and so I should probably prioritise IKE proposals (which are shared by all tunnels in a Cisco ASA device) by algorithm strength, rather than performance.
Am I on the right track?
(Having discussed it with some of the guys at Security.SE, I reckon I have a preference based on the security of the stronger algorithms; for now, I'm more interested in the performance aspect)
Correct, the Phase 1 algorithms have only an impact on connection setup and rekeying but not on the IPsec tunnel throughput, which, as you mention, is only affected by the Phase 2 algorithms.
The performance of the authentication during Phase 1 is not influenced by these algorithms, though, because it only depends on the kinds of secrets that are used (e.g. ECDSA/RSA keys and their lengths).
IKE packets are usually rare and quite small compared to ESP packets used for the actual tunnel traffic (even if something like Dead Peer Detection is used that causes regular IKE traffic). Therefore, stronger encryption is generally negligible. The same is true for the integrity algorithms used to authenticate each packet. The latter algorithms also used to construct HMAC-based pseudo-random functions (PRF) to derive the encryption and integrity keys (also for Phase 2), but that happens only once - and for each rekeying.
What mainly affects the performance during Phase 1 is the Diffie Hellman exchange. As it also happens only once (and for each rekeying of Phase 1 and of Phase 2, if perfect forward secrecy is used) it might not be an issue, but if tunnels are established often and by lots of users it could. Options to improve performance here are to reduce the exponent sizes according to RFC 3526, use specialized hardware to accelerate DH, or to switch to ECDH, which is quite a bit faster than the more commonly used modular exponential (MODP) DH groups.
Also, to avoid overhead due to encryption/authentication, especially if your hardware can accelerate AES e.g. via the AES-NI instruction set, the AES-GCM algorithm is a good choice because it encrypts and authenticates packets at the same time (there also exist AES-based PRFs e.g. AES-XCBC or AES-CMAC). Of course, this aspect is even more important for Phase 2.