Open Source IMS Client

Naturally doing this shall be straight forward for anybody knowledgeable about netlink, maybe even the strongswan plugin kernel-netlink could be somehow used. I am not yet experienced in netlink :)

However I would like to raise an issue that is I think important to be discussed: in case of VoLTE we are OK, since we only need a single tunnel created once connectivity is established with the ims APN. However in case of VoWiFi two tunnels must be created, and the inner address of the first tunnel must be the outer address of the second tunnel. When I asked about this on the strongswan IRC channel I got the response that this might be hard to realise because of how the kernel treats IPsec policies, hence I was recommended to use network namespaces, meaning the first tunnel would live in the default network namespace and the policies for the second tunnel would get installed inside of a dedicated namespace, keeping the policies properly isolated. I tried this approach manually and it worked fine for a quick test-run.
Though I am still unsure if this is indeed necessary, but last time I tried the other way I did have troubles installing two policies, one depending on the other. It might be my lack of Googling on the topic, but I thought it is good to keep this in mind when creating plugins for IPsec handling.

Hi domi,

On Mon, Mar 07, 2022 at 09:30:12PM +0000, domi wrote:

Naturally doing this shall be straight forward for anybody knowledgeable about netlink, maybe even the strongswan plugin kernel-netlink could be somehow used. I am not yet experienced in netlink :)

I've already written the doubango code, see
https://gitea.osmocom.org/ims-volte-vowifi/doubango/src/branch/laforge/wip/plugins/ipsec_linux and it is working. It implements the kernel netlink xfrm calls using libmnl and plugs as ipsec provider into doubango. That part is working already in early tests.

However I would like to raise an issue that is I think important to be discussed: in case of VoLTE we are OK, since we only need a single tunnel created once connectivity is established with the ims APN.

ACK.

However in case of VoWiFi two tunnels must be created, and the inner address of the first tunnel must be the outer address of the second tunnel. When I asked about this on the strongswan IRC channel I got the response that this might be hard to realise because of how the kernel treats IPsec policies, hence I was recommended to use network namespaces, meaning the first tunnel would live in the default network namespace and the policies for the second tunnel would get installed inside of a dedicated namespace, keeping the policies properly isolated. I tried this approach manually and it worked fine for a quick test-run.

Yes, this is what I've described in #5484 and will be tracking there. This particular issue is really only about the 'inner' IPsec with doubango.