Issue #2357

How to initiate IPsec SA Transport Mode without IKE?

Added by Lars Andersson almost 5 years ago. Updated over 1 year ago.

Affected version:



I would like to get some advice for a new IMS VoLTE application in which I have strongSwan incorporated.

First I would like to mention that I already have a working VoWiFi application based on strongSwan. strongSwan is in that case used to add IPsec capability to a proprietary IP-stack which is run entirely in user space. For that TUN interface is used to let the IP-stack send and receive its clear-text data with strongSwan using the kernel-libipsec plugin. A custom network backend plugin for strongSwan which interoperates with the IP-stack has been added. Basically the new network plugin consists of a UNIX domain socket that enables encrypted data to flow between strongSwan and the IP-stack. The IP-stack then adds the UDP tunnel for the encrypted data.

Our client application is using the Davici library to configure and manage IKE and IPsec SA connections.

This is all working well for our VoWifi solution.

Now, for the new VoLTE case things are getting a little more complicated. Again strongSwan is used to add IPSec capability to our user space IP-stack, but now it has to be configured for transport mode and SIP REGISTER procedure is used for authentication and key agreement. What I am trying to implement for the new VoLTE case is in essence described in the 3GPP specification TS 33.203 "Access security for IP-based services". The scheme used for authentication and key agreement in this VoLTE case is IMS AKA. The security parameters like the keys generated by the IMS AKA scheme are entirely transported by SIP. Thus, no IKE signalling is performed at all to set up an IPsec (ESP) SA.

After EAP-AKA authentication, key expansions are applied on master keys to derive integrity key and crypto key for ESP. The following new ESP parameters will be obtained

- Cryptographic key
- Cryptographic algorithm
- Integrity key
- Integrity algorithm
- SPI (for the receiving party)

I envision that these new derived ESP parameters should be possible to be communicated to strongSwan via the Davici API and populate an extended VICI Config. (Davici is the preferable API that will keep license compatibility.) ESP parameters should then somehow be injected into the SAD. The SPD functionality (what to protect) is so far believed to be redundant since the control of the data traffic resides in the IP-stack.

Otherwise this is that I have done so far to adapt our solution for transport mode

- To be able to use kernel-libipsec for transport mode I have made some adjustments to the handling of data chunks. If SA (ipsec_sa_t) is set for transport mode only IP payload part is encrypted and not the whole packet.

- The custom network plugin is used as in the VoWiFi tunnel mode case and does not impose any UDP encapsulation. If packet (packet_t) is marked for transport mode it will be sent out through our IP-stack via IP raw socket instead of UDP.

Now when I am able to use libipsec for transport mode I also want to exclude the IKE signalling part to make it work for the VoLTE case.

My problem now is that my understanding of how the different software modules in strongSwan are organized is still quite limited. Which modules needs to be initiated and which dependencies among the modules needs to be kept?

Could you please give some advice about how I should proceed? Any tips about what to keep in mind or suggestions to a solution would be appreciated.

Also, it would be interesting to know if anyone else has done something similar with strongSwan.



#1 Updated by Piyush Badkul over 1 year ago

Have you progressed for this particular case?

#2 Updated by Noel Kuntze over 1 year ago

  • Status changed from New to Feedback


strongSwan is an IKE keying daemon, so not using IKE for signaling invalidates it completely for the use case.
You probably want to use libstrongswan with, as you already discovered, libipsec or the kernel-* plugins for libcharon. To use them without initializing charon as the daemon or generally using its IKE implementation, you will need to basically reimplement at least part of the initialization part of the daemon and replace the IKE packet processing stuff with your own glue to get the signaling information from that other software component. The majority of the strongSwan core code deals with processing of IKE packets and responding to them correctly - which you don't need - so basically the stuff left over is the kernel integration, libipsec, and libstrongswan.

#3 Updated by Piyush Badkul over 1 year ago

As per your approach, i have a few queries.
1 - Can we pump a load of 500 security associations per second from application to kernel and application will not lag. It is observed that as soon as 80,000 association are reached, kernel hangs? We are directly sending to kernel by opening a PF_KEY socket and writing data over it.

2 - Which is better among libipsec, vici or davici?

Also available in: Atom PDF