Bug 1081804 - RFE: Enable Kernel IPSec support
Summary: RFE: Enable Kernel IPSec support
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: strongswan
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1081805
TreeView+ depends on / blocked
 
Reported: 2014-03-28 03:35 UTC by Christopher Meng
Modified: 2014-08-06 05:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1081805 (view as bug list)
Environment:
Last Closed: 2014-08-05 16:36:13 UTC
Type: Bug


Attachments (Terms of Use)
Patch to enable kernel-libipsec plugin in RPM spec. (2.90 KB, patch)
2014-03-28 03:35 UTC, Christopher Meng
no flags Details | Diff

Description Christopher Meng 2014-03-28 03:35:44 UTC
Created attachment 879721 [details]
Patch to enable kernel-libipsec plugin in RPM spec.

Description of problem:

Since strongSwan 5.1.0, it provides a plugin called kernel-libipsec which provides an IPsec backend that works entirely in userland, using TUN devices and its own IPsec implementation libipsec to emulate the IPSec.

Fedora has compiled kernel interface kernel-netlink, it installs IPsec SAs in the operating system's IPsec stack. libipsec plugin provides an alternative for OS implementation does not support a required algorithm.

Enable this plugin doesn't mean to drop the netlink interface, on the contrary, the kernel backend is still required, therefore kernel-netlink is needed as well, and that's not a problem.

This option is really useful for OpenVZ based virtualization.

Version-Release number of selected component (if applicable):
strongswan-5.1.2-4.fc21

Additional info:

Pass "--enable-kernel-libipsec" option to %configure will enable support of libipsec, I've created a patch of the RPM spec, you can apply it from the attachment.

Please enable this option on EPEL also.

Thanks.

Comment 1 Pavel Šimerda (pavlix) 2014-03-28 08:34:51 UTC
Hi Christopher,

thanks for the report. I was aware of broken IPsec in OpenVZ but I never found time to gather more information. Will the kernel-libipsec be automatically used in OpenVZ guests? Which platforms are supported, by the way?

Cheers,

Pavel

Comment 2 Christopher Meng 2014-03-28 09:21:05 UTC
(In reply to Pavel Šimerda (pavlix) from comment #1)
> Hi Christopher,
> 
> thanks for the report. I was aware of broken IPsec in OpenVZ but I never
> found time to gather more information. Will the kernel-libipsec be
> automatically used in OpenVZ guests? Which platforms are supported, by the
> way?
> 
> Cheers,
> 
> Pavel

You can take a look at the reference:

http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec

I haven't taken exhaustive research, but it works(I can confirm on iOS device of Cisco IKE provided by strongswan).

OpenVZ also said:

https://openvz.org/IPsec

* Kernel 042stab084.8 or later

* The following kernel modules must be loaded before container start:
af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel

* Capability net_admin must be granted to a container

But it used libreswan to test in the last year.

Which platform? What do you mean? Not Linux?

Comment 3 Pavel Šimerda (pavlix) 2014-04-01 11:15:08 UTC
(In reply to Christopher Meng from comment #2)
> (In reply to Pavel Šimerda (pavlix) from comment #1)
> > Hi Christopher,
> > 
> > thanks for the report. I was aware of broken IPsec in OpenVZ but I never
> > found time to gather more information. Will the kernel-libipsec be
> > automatically used in OpenVZ guests? Which platforms are supported, by the
> > way?
> > 
> > Cheers,
> > 
> > Pavel
> 
> You can take a look at the reference:
> 
> http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec

It doesn't seem to specify whether it gets used by default or not. The plugin seems to have a lot of limitations and it would be an unwanted change in behavior if tun was now used instead of the kernel ipsec stack.

> I haven't taken exhaustive research, but it works(I can confirm on iOS
> device of Cisco IKE provided by strongswan).
> 
> OpenVZ also said:
> 
> https://openvz.org/IPsec
> 
> * Kernel 042stab084.8 or later
> 
> * The following kernel modules must be loaded before container start:
> af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel

I thought the whole point of the libipsec plugin was to avoid the need for those kernel modules.

> * Capability net_admin must be granted to a container

Not sure if I had all of those enabled, but I tried ipsec transport mode on OpenVZ a long time ago and both the policy and the keys seemed to be installed in the kernel but the traffic didn't get through.

> But it used libreswan to test in the last year.

And did it work? My impression was that the problem is not in userspace.

> Which platform? What do you mean? Not Linux?

Yep, was just curious.

Comment 4 Pavel Šimerda (pavlix) 2014-05-09 10:23:16 UTC
I would like to get more information here or close the ticket.

Comment 5 Christopher Meng 2014-05-09 10:41:52 UTC
(In reply to Pavel Šimerda (pavlix) from comment #4)
> I would like to get more information here or close the ticket.

I'm afraid I can't provide any more info here. It maybe helpful if we can get some info from upstream...

Comment 6 Tobias Brunner 2014-06-06 13:02:28 UTC
As requested some information from upstream.

> > You can take a look at the reference:
> > 
> > http://wiki.strongswan.org/projects/strongswan/wiki/Kernel-libipsec
> 
> It doesn't seem to specify whether it gets used by default or not. The
> plugin seems to have a lot of limitations and it would be an unwanted change
> in behavior if tun was now used instead of the kernel ipsec stack.

Whether the plugin gets used or not depends on the plugin load order.  Basically the first plugin that provides an IPsec backend gets used.  For Linux choices are kernel-netlink (the default), kernel-pfkey and kernel-libipsec.  Because the kernel-netlink plugin is always required on Linux (because it also provides a network backend) the kernel-libipsec plugin is listed before all other kernel plugins in the default plugin list.  This way its IPsec backend is used and the kernel-netlink plugin only provides the networking backend.  So without further measures, that is, if the kernel-libipsec plugin is simply enabled and packaged, the libipsec IPsec implementation would get used.  Therefore if you consider providing the plugin I would definitely recommend to either disable it by default via its load option (in /etc/strongswan.d/charon/kernel-libipsec.conf), or provide it in a separate and optional package (together with that config file).

> > * The following kernel modules must be loaded before container start:
> > af_key esp4 esp6 xfrm4_mode_tunnel xfrm6_mode_tunnel
> 
> I thought the whole point of the libipsec plugin was to avoid the need for
> those kernel modules.

Exactly, those are not needed when kernel-libipsec is used.

Comment 7 Pavel Šimerda (pavlix) 2014-06-06 13:41:46 UTC
Hi Tobias,

thanks a lot for the valuable information. One more question, if kernel-netlink is required anyway, does the kernel-libipsec actually help in container setups?

Hi Christopher,

with the information from Tobias it looks like we should only ship kernel-libipsec in a subpackage and let container users install it explicitly. Is that acceptable for you? Are you willing to make that change in the Fedora master (rawhide) dist-git branch?

Cheers,

Pavel

Comment 8 Tobias Brunner 2014-06-06 14:13:16 UTC
Hi Pavel,

> One more question, if kernel-netlink is required anyway, does the
> kernel-libipsec actually help in container setups?

With the kernel-libipsec plugin enabled (and loaded before the kernel-netlink plugin) only the networking backend of kernel-netlink is used (to enumerate/install routes/IPs etc.), which doesn't require the XFRM/IPsec kernel modules.  So this should work fine in container setups.

Regards,
Tobias

Comment 9 Pavel Šimerda (pavlix) 2014-06-06 14:25:14 UTC
Thanks, Tobias.

Comment 10 Christopher Meng 2014-06-30 12:27:09 UTC
(In reply to Pavel Šimerda (pavlix) from comment #9)
> Thanks, Tobias.

Can't we package and use configuration file to mark the plugin as disabled by default instead of introducing more subpkgs? I don't think users will notice this change when simply "yum install strongswan". And to me less packages means less operation.

Comment 11 Pavel Šimerda (pavlix) 2014-06-30 14:13:54 UTC
(In reply to Christopher Meng from comment #10)
> (In reply to Pavel Šimerda (pavlix) from comment #9)
> > Thanks, Tobias.
> 
> Can't we package and use configuration file to mark the plugin as disabled
> by default instead of introducing more subpkgs?

It's possible as well but the idea of enabling it by default but not shipping the module by default sounds good to me. You could then install "strongswan" on normal hosts and "strongswan-libipsec" in containers. It's so much easier to integrate with installation tools like kickstart where you just choose the right packages to be included.

Of course you might say that explicit is better than implicit, so I'm ok with any setup that allows you to use strongswan-libipsec as long as it doesn't change the default behavior. Also, if you wanted to modify the default configuration files,
I would be much more happy if that happens upstream rather than specifically for Fedora.

> And to me less packages means less operation.

Subpackages are easy to deal with in Fedora, so I don't think it adds any maintainance burden. And administrators would have to perform some explicit action to use libipsec anyway.

Comment 12 Pavel Šimerda (pavlix) 2014-08-05 16:36:13 UTC
Fixed by creating a subpackage called strongswan-libipsec. I hope this change won't affect behavior of the basic strongswan package in any way.

Comment 13 Christopher Meng 2014-08-06 05:15:44 UTC
OK. 

Thanks, I hope all Fedora and EPEL6+ branch will receive the update.


Note You need to log in before you can comment on or make changes to this bug.