定义IPSec VPN隧道时，select“更强”的阶段1设置（例如DES / MD5 / DH1上的AES256 / SHA1 / DH5）会对性能产生多大的影响？
例如，我被告知AES-256比AES-128慢了40％（我想这是合理的），但是我认为如果这样的话，整个“明显的”隧道吞吐量真的会受到影响在阶段2中指定？
我认为指定/优先考虑更强大的阶段1设置意味着端点在启动时（以及在生命周期间隔）将花费更长的时间进行authentication，而不是减小隧道的吞吐量，所以我应该优先考虑IKE提议（由Cisco ASA设备中的所有通道共享）通过algorithm强度而不是性能。
我在正确的轨道上？
（在与Security.SE的一些人讨论过之后，我认为我有一个基于更强大的algorithm的安全性的偏好;现在，我对性能方面更感兴趣）
正确的，阶段1algorithm只影响连接build立和重新启动，而不影响IPsec隧道吞吐量，正如你所提到的那样，它只受到阶段2algorithm的影响。
然而，阶段1中authentication的性能不受这些algorithm的影响，因为它仅取决于所使用的机密种类（例如ECDSA / RSA密钥及其长度）。
与用于实际隧道stream量的ESP数据包相比， IKE数据包通常很less，并且相当小（即使使用像Dead Peer Detection这样可导致常规IKEstream量的东西）。 因此，更强的encryption一般可以忽略不计。 用于validation每个数据包的完整性algorithm也是如此。 后面的algorithm也用于构造基于HMAC的伪随机函数（PRF）来导出encryption和完整性密钥（也用于阶段2），但是这只发生一次 – 以及每次更新。
主要影响阶段1的performance是Diffie Hellman交换。 因为它也只发生一次（并且对于阶段1和阶段2中的每一次更新，如果使用完美的前向保密 ），这可能不是问题，但是如果隧道经常build立并且由许多用户可能的话。 在这里提高性能的选项是根据RFC 3526降低指数大小，使用专用硬件来加速DH，或者切换到比更常用的模块化指数（MODP）DH组更快的ECDH 。
此外，为了避免由于encryption/authentication引起的开销，特别是如果您的硬件可以通过AES-NI指令集加速AES， AES-GCMalgorithm是一个不错的select，因为它同时encryption和validation数据包基于AES的PRF，例如AES-XCBC或AES-CMAC ）。 当然，这个方面在第二阶段更重要。