Parece que tienes algunos conceptos erróneos sobre IPsec. Usar la protección de integridad para ESP no tiene nada que ver con AH. Entonces, esa no es una clave AH que está especificando con auth sha1 "" , sino una clave de autenticación / protección de integridad y un algoritmo para ESP (con "" solo obtiene una clave de cero).
Por lo general, no se recomienda usar el cifrado ESP sin protección de integridad (por ejemplo, directamente en la introducción de RFC 4303 que especifica ESP) y el kernel le impide hacerlo en modo FIPS. Si marca crypto / testmgr.c en las fuentes del kernel (4.14.15 enlazadas aquí) verá que no existe una definición para authenc(digest_null,cbc(des3_ede)) , que es lo que usa su SA, con fips_allowed = 1 (en realidad , no existe una definición authenc con digest_null en absoluto).
La combinación de ESP con AH es posible y requiere la definición de las SA de ESP y AH por separado y luego las políticas IPsec que las combinan. Por lo tanto, en Linux en modo FIPS, aparentemente solo se admite si ESP aún se usa con protección de integridad. Al establecer el truncamiento de ICV para ESP en 0, probablemente podría evitar la sobrecarga adicional en la red, pero la sobrecarga de cómputo de tener dos servicios de protección de integridad se mantendría (el uso de un algoritmo de modo combinado como AES-GCM para ESP podría mejorarlo un poco) ).
De todos modos, la combinación de ESP y AH no es tan común y no se recomienda, en lugar de usar ESP con un algoritmo de modo combinado como AES-GCM o ChaCha20 / Poly1305 (todavía no está certificado por FIPS) es la recomendación general debido a su eficiencia, consulte < a href="https://tools.ietf.org/html/rfc8221#section-4"> RFC 8221 .