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

[h_eznt]

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

[h_eznt]

Added as attachment ipsec.sh, racoon.setkey and racoon.conf.aes :

• /etc/racoon/ipsec.sh : ipsec start script on the i.MX6 - This script must always be called between 2 tests to ensure kernel policies are properly cleaned-up. Policies are defined in /etc/racoon/racoon.setkey
• /etc/racoon/racoon.setkey : ipsec policies on i.MX6 device

Additionaly, all files of the i.MX6 device are available on the sd-card bootable  image referenced above.

• /etc/racoon/racoon.conf.aes : racoon configuration file on the VPN server (ip-address: 192.168.3.1)

[utkarsh_gupta]

Hi,

Can you also share the ipsec.sh and racoon.conf.aes scripts.

Thanks,

Utkarsh

[utkarsh_gupta]

I think you forgot to attach network schema and run logs files.

_________________________________________________

Sorry found it ni original post.

[utkarsh_gupta]

Hi Hubert,

I have come close to replicating this issue. Please forward any configuration files you have and also the log of issues that you faced with accessing aes encryption using caam.

Thanks,

Utkarsh

[h_eznt]

• Added the file  "Network_Schema.pdf" for a schematic description of the test setup.
• Added the archive "run-logs.tgz" containing log files and traces
• The ipsec racoon configuration on the i.mx6 is detailed in the attachment "setup.log.zip"
• The network configuration of the i.mx6 is as follow:

root@imx6qsabresd:~# cat /etc/network/interfaces

# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface

auto lo

iface lo inet loopback

# Wired or wireless interfaces

auto eth0

iface eth0 inet static

        address 10.1.1.1

        netmask 255.255.255.0

        network 10.1.1.0

auto eth1

iface eth1 inet static

        address 192.168.3.77

        netmask 255.255.255.0

        network 192.168.3.0

        gateway 192.168.3.1

• The compressed sd-card image of the MCIMX6Q-SDB BSP Board is available for download under the following URL:

https://extranet.garderos.com/files/?v=share/2B0D4DC9632B442A902AA1A482E34099

This URL is protected with a password: nxp-freescale

[Yuri]

Hello,

  Please try to check CAAM, using section 9 (Security) in "i.MX_Linux_User's_Guide.pdf".

http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=133769948107170617...

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[h_eznt]

Hi Yuri,

Thanks for your post. Unfortunately it does not help:

Chapter 9 of the "i.MX_Linux_User's_Guide.pdf" is related to the use of caam over cryptodev. cryptodev is the user-space interface to the Linux-Kernel cryptographic layers. In Linux, ESP-IPSEC encryption does not happen in user-space but only in kernel-mode. So cryptodev is not involved here.

Hubert

[Yuri]

Hello,

  look slike You should use Scatterlist Crypto API.

https://www.kernel.org/doc/Documentation/crypto/api-intro.txt

Nevertheless, You can test it via cryprodev as mentioned yearlier.

Regards,

Yuri.

[h_eznt]

Hi Yuri,

Thanks for the link. You are right that the Scatter-API is involved here.

The Linux CAAM driver is actually intensively using the Linux scatter-list API.

The Linux CAAM driver is delivered by NXP/Freescale.

The problem is that this Linux CAAM driver that you deliver fails under some conditions.

I am not the programmer of the CAAM driver, I though Freescale/NXP was. If I could fix this driver I would do it, but without deep knowledge of the CAAM hardware and debugging facilities, it is just impossible. That 's why I did report this issue, with the hope that I can get help on this.

I am addressing a very specific issue that happens only under certain conditions. Let me rephrase it briefly.

In Linux with the CAAM driver, when an unencrypted packet gets switched from eth0 (FEC) to eth1 and it matches an outgoing IPSEC policy involving AES encryption, it then gets wrongly encrypted.

So this issue involves IPSEC with AES (i.e. CAAM Hardware/CAAM driver) _AND_ packet switching (i.e. FEC ethernet controller/FEC driver) simultaneously. If you just test IPSEC (with AES encryption) without packet switching over eth0, you will no be able to reproduce the problem.

As for cryptodev, I will underline once more that these test-conditions can _NOT_ be reproduced with any cryptodev stuff because, in Linux, ipsec is always processed in kernel-mode and cryptodev is not involved. The Linux IPSEC implementation forwards the buffers to encrypt directly to the CAAM driver.

I don't know any Linux ipsec implementation based on cryptodev. Therefore, I don't understand what you expect me to do with cryptodev and user-space APIs ?

Regards, 

Hubert