Project

General

Profile

Issue #2357

How to initiate IPsec SA Transport Mode without IKE?

Added by Lars Andersson over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.3.2
Resolution:

Description

Hi,

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.

Thanks!

Also available in: Atom PDF