Regarding HMAC-SHA256

[Thermi]

There are differing implementations of HMAC-SHA256.

Some with a truncation to 96 bit (that was a draft proposed in 2002 that some vendors implemented and they never bothered to implement HMAC-SHA256 correctly), some with a truncation to 128 bit, which is correct.

Both versions use the same IANA identifier in IKE though.

If a CHILD_SA is negotiated between two peers that use differing implementations, traffic will not be able to be transmitted either way, because the check of the ICV in the ESP packet will fail.

It was observed that this was at least the case with the native VPN client of Android 6. This might also pertain other cases. However, I have not experienced any problem with other IPsec clients yet. So this might be an isolated case.

[dguido]

That is not good. Is the suggestion to move to SHA2-512 HMAC? There are not many choices for integrity algorithms and we'll need to test that all our clients still work: https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites#Integrity-Algorithms

[Thermi]

Yes, for example SHA2-512. Or AES-GCM with SHA2-512 as the PRF.

ike=aes192gcm16-prfsha512-ecp521!
esp?aes192gcm16-ecp521!