According to the original README from the Marvell repository, AES-GCM and AES-CBC are tested and should be supported by the linux-cp plugin and VPP. However, our testing shows that only AES-CBC actually works.
There is a chance that during migration to 25.06, something was lost or we are missing something.
An example of the configuration that is expected to be correct:
set interfaces ethernet eth1 address '192.168.99.1/24' set interfaces ethernet eth2 address '192.168.102.1/24' set interfaces vti vti1 set protocols static route 192.168.202.0/24 interface vti1 set system option kernel memory hugepage-size 2M hugepage-count '1024' set vpn ipsec authentication psk psk1 id 'A' set vpn ipsec authentication psk psk1 id 'B' set vpn ipsec authentication psk psk1 secret 'AB' set vpn ipsec esp-group esp1 mode 'tunnel' set vpn ipsec esp-group esp1 pfs 'disable' ### set vpn ipsec esp-group esp1 proposal 10 encryption 'aes256gcm128' ### set vpn ipsec esp-group esp1 proposal 10 hash 'sha256' set vpn ipsec ike-group ike1 close-action 'none' set vpn ipsec ike-group ike1 dead-peer-detection action 'clear' set vpn ipsec ike-group ike1 proposal 10 encryption 'camellia256ccm96' set vpn ipsec ike-group ike1 proposal 10 hash 'sha256' set vpn ipsec interface 'eth1' set vpn ipsec site-to-site peer B authentication local-id 'A' set vpn ipsec site-to-site peer B authentication mode 'pre-shared-secret' set vpn ipsec site-to-site peer B authentication remote-id 'B' set vpn ipsec site-to-site peer B connection-type 'none' set vpn ipsec site-to-site peer B default-esp-group 'esp1' set vpn ipsec site-to-site peer B ike-group 'ike1' set vpn ipsec site-to-site peer B local-address '192.168.99.1' set vpn ipsec site-to-site peer B remote-address '192.168.99.3' set vpn ipsec site-to-site peer B vti bind 'vti1' set vpn ipsec site-to-site peer B vti traffic-selector remote prefix '192.168.202.0/24' set vpp settings buffers buffers-per-numa '1024' set vpp settings buffers data-size '1700' set vpp settings buffers page-size '2M' set vpp settings interface eth1 driver 'dpdk' set vpp settings interface eth2 driver 'dpdk' set vpp settings ipsec netlink rx-buffer-size '32000' set vpp settings lcp ignore-kernel-routes set vpp settings memory default-hugepage-size '2M' set vpp settings memory main-heap-page-size '2M' set vpp settings memory main-heap-size '1G' set vpp settings statseg page-size '2M' set vpp settings statseg size '128M' set vpp settings unix poll-sleep-usec '500'
This config leads to the error when VPP tries to install SA from the kernel:
Sep 02 14:36:30 vyos vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 14:36:30 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 14:36:30 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 14:36:30 vyos vpp[1777]: linux-cp/ipsec: crypto param extraction failed
The same config with aes256 (CBC variant) works fine.
Examples of other algorithms:
aes256ccm128: Sep 02 15:03:11 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 15:03:11 vyos vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 15:03:11 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: crypto param extraction failed Sep 02 15:03:11 vyos vpp[1777]: linux-cp/ipsec: crypto param extraction failed
aes256ctr: Sep 02 15:03:50 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: Invalid/Unsupported crypto algo: rfc3686(ctr(aes)) keylen: 288 Sep 02 15:03:50 vyos vpp[1777]: linux-cp/ipsec: Invalid/Unsupported crypto algo: rfc3686(ctr(aes)) keylen: 288 Sep 02 15:03:50 vyos vpp[1777]: vpp[1777]: linux-cp/ipsec: Invalid/Unsupported crypto algo: rfc3686(ctr(aes)) keylen: 288 Sep 02 15:03:50 vyos vpp[1777]: linux-cp/ipsec: Invalid/Unsupported crypto algo: rfc3686(ctr(aes)) keylen: 288
And so on. All other algorithms except AES-CBC lead to crypto param extraction failed or Invalid/Unsupported crypto algo.
It was tested with:
- Null encryption
- AES-CTR
- AES-CCM with ICV
- AES-GCM with ICV
- Null encryption with AES-GMAC
- 3DES-EDE-CBC
- Blowfish-CBC
- Camellia-CBC
- Camellia-COUNTER
- Camellia-CCM with ICV
- Serpent-CBC
- Twofish-CBC
- CAST-CBC
- ChaCha20/Poly1305 with ICV
The similar sroty is with unsupported integrity algorithms, with a difference that if an algorithm is unsupported, there are no messages at all in logs.
Supported algorithms are:
- MD5 HMAC
- SHA1 HMAC
- SHA2_256_128 HMAC
- SHA2_384_192 HMAC
- SHA2_512_256 HMAC
Not Supported:
- MD5_128 HMAC
- SHA1_160 HMAC
- SHA2_256_96 HMAC
- AES XCBC
- AES CMAC
- AES-GMAC
What we need to do
- Check why AES-GCM does not work, and fix this if possible.
- Check how hard it would be to add support for more algorithms: crypto engines can cover a lot (check show crypto handlers output in vppctl).