Correto, os algoritmos da Fase 1 têm apenas um impacto na configuração da conexão e na nova, mas não na taxa de transferência do túnel IPsec, que, como você mencionou, é afetada apenas pelos algoritmos da Fase 2.
O desempenho da autenticação durante a Fase 1 não é influenciado por esses algoritmos, porque depende apenas dos tipos de segredos usados (por exemplo, chaves ECDSA / RSA e seus comprimentos).
Os pacotes IKE são geralmente raros e muito pequenos em comparação com Pacotes ESP usados para o tráfego real do túnel (mesmo que algo como Dead Peer Detection seja usado e cause tráfego IKE regular). Portanto, criptografia mais strong é geralmente insignificante. O mesmo vale para os algoritmos de integridade usados para autenticar cada pacote. Os últimos algoritmos também são usados para construir funções pseudo-aleatórias baseadas em HMAC (PRF) para derivar as chaves de criptografia e integridade (também para a Fase 2), mas isso acontece apenas uma vez - e para cada recriação de chamadas.
O que afeta principalmente o desempenho durante a Fase 1 é a troca Diffie Hellman. Como isso também acontece apenas uma vez (e para cada recriação da Fase 1 e da Fase 2, se sigilo perfeito para encaminhamento for usado) pode não ser um problema, mas se os túneis forem estabelecidos com frequência e por muitos usuários, isso pode acontecer. Opções para melhorar o desempenho aqui são para reduzir os tamanhos expoente de acordo com RFC 3526 , use hardware especializado para acelerar DH , ou para alternar para ECDH , que é um pouco mais rápido do que o exponencial modular mais comumente usado (MODP) grupos DH.
Além disso, para evitar sobrecarga devido à criptografia / autenticação, especialmente se seu hardware puder acelerar o AES, por exemplo, através do conjunto de instruções AES-NI , o AES-GCM é uma boa escolha porque criptografa e autentica pacotes ao mesmo tempo (também existem PRFs baseados em AES, por exemplo, AES-XCBC ou AES-CMAC . Claro, esse aspecto é ainda mais importante para a Fase 2.