AnsweredAssumed Answered

Encryption of IPSEC ESP-packets coming from eth0 fails with CAAM when using AES

Question asked by H. Euzenot on May 13, 2016

Hardware impacted:

- imx6qsabresd  BSP Board (MCIMX6Q-SDB)

- imx6 Solo custom board

 

Linux  kernel versions:

- imx_4.1.15_1.0.0_ga,

- imx_3.10.17_1.0.0_ga

- and probably all others

 

Description of the Problem:

Encryption of IPSEC ESP-packets coming from eth0 ("fec" driver)  fails with CAAM when encryption algorithm is AES or AES256 on Linux platforms.

 

The sample test setup is as follow:

 

  • an i.mx6 BSP board (MCIMX6Q-SDB) with 2 network interfaces:
    •    eth0:  attached to the processor, handled in Linux by the fec driver
    •    eth1:  a digitus USB2.0 Ethernet  Adapter (Pegasus/Pegasus II USB Ethernet driver) connected to the OTG port.
  • The board runs the latest linux 4.1.15_1.0.0_ga yocto software with "ipsec-tools" and the necessary ipsec kernel modules .i.e.

CONFIG_XFRM_IPCOMP=m

CONFIG_NET_KEY=y

CONFIG_INET_AH=m

CONFIG_INET_ESP=m

CONFIG_INET_IPCOMP=m

CONFIG_INET_XFRM_TUNNEL=m

CONFIG_INET_TUNNEL=y

CONFIG_INET_XFRM_MODE_TRANSPORT=m

CONFIG_INET_XFRM_MODE_TUNNEL=m

CONFIG_INET_XFRM_MODE_BEET=m

  • The ipsec client on the board  (ipsec-tools) is configured to encrypt traffic in an IPSEC-tunnel from eth0 to a VPN-server behind eth1: the ip traffic comes unencrypted via eth0 and goes out encrypted over eth1. This is a typical "road-warrior" scenario.
  • The esp encryption algorithm chosen is aes (or aes256)
  • In this case CAAM does not encrypt correctly the ESP packets and they are discarded by the VPN-server.
  • It doesn't matter which VPN-server is used, we have been trying with CISCO ASA, various Juniper gateways, PfSense, racoon, strongSwan: problem is always there.
  • We have been replacing ipsec-tools by strongSwan: the problem remains
  • We have been investigating this issue quiet intensively these last 6 months and found out that:
    •   changing the encryption algorithm from aes to 3des solves this issue
    •   deactivating caam also solves this issue
    •   switching cable and ip addresses of eth0 and eth1 also solves this issue
    •   using VLAN tagging on eth0 solves this issue

 

For different (good) reasons non of these workarounds are acceptable for us: we have a customer that needs to perform IPSEC AES encryption from eth0 to eth1. This issue seems to be present on all i.MX6 platforms.

 

Are there any workarounds other than the ones listed above for this issue ?

 

We can provide additional logging/configuration files/images if needed.

Attached is a short description of the IPSEC  test-setup on the i.MX6 test board.

Original Attachment has been moved to: ipsec.sh

Original Attachment has been moved to: racoon.setkey.zip

Original Attachment has been moved to: racoon.conf.aes.zip

Original Attachment has been moved to: run-logs.tgz

Original Attachment has been moved to: setup.log.zip

Attachments

Outcomes