Better handle missing MOBIKE kernel support

[hwdsl2]

With Libreswan 3.27, when mobike=yes is specified in an IKEv2 conn section in /etc/ipsec.conf, and the Linux kernel does not support it, an error message is shown:

MOBIKE kernel support missing for netkey interface: CONFIG_XFRM_MIGRATE && CONFIG_NET_KEY_MIGRATE

And the conn section in /etc/ipsec.conf is not loaded at all. Would it be better to load the connection section anyway but just disable MOBIKE? Also, can you please clarify which Linux kernel versions (3.x, 4.x, etc.) have MOBIKE support, and how to check if it is supported on a particular system?

Thank you!

[letoams]

MOBIKE us been supported a long time in many kernels but notably Debian / Ubuntu disables it. I agree we should just load the connection I will look into that Sent from mobile device

…

On Nov 2, 2018, at 12:16, Lin Song ***@***.***> wrote: With Libreswan 3.27, when mobike=yes is specified in an IKEv2 conn section in /etc/ipsec.conf, and the Linux kernel does not support it, an error message is shown: MOBIKE kernel support missing for netkey interface: CONFIG_XFRM_MIGRATE && CONFIG_NET_KEY_MIGRATE And the conn section /etc/ipsec.conf is not loaded at all. Would it be better to load the connection anyway but just disable MOBIKE? Also can you please clarify which Linux kernel versions (3.x, 4.x, etc.) have MOBIKE support, and how to check if it is supported on a particular system? Thank you! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[letoams]

Developers disagree on what is best in this case. silently disable mobike and have the connection work without mobike support, or fail to load the connection. I agree with you (since the remote endpoint can also decide to not do mobike and then your connection with mobike=yes also works without mobike)

I'll try to convince the other devs :)

[hwdsl2]

Thanks @letoams!

[antonyantony]

@hwdsl2 as it is now yes|no, it is better not to load the connection when kernel support is not detected.

Another possibility I can imagine is add a third option auto. And leave the yes|no as it is.

Auto would load connection, detect kernel support and decide to send|respond to mobike payload, depending on initiating or responding.
As I see it , this is a bigger change, and patches welcome.
It would also need to clearly print, per connection three cases. mobike : configured, detected, and negotiated. Also part of the detection would be warning, when kernel is missing support.
mobike=auto would be a nice to have feature. Not sure when!

Currently if you just change to load the connection pluto will send and respond to MOBIKE notification that would be bad.

Another possibility is request Debian and Ubuntu kernel team to enable CONFIG_XFRM_MIGRATE in the default kernel. New xfrm features are N in kernel. Application developers/users have request to enble it This is a recurring issue coming up next is CONFIG_XFRM_INTERFACE.

[letoams]

auto is not a valid default for mobike= as it would enable mobike for static von connections which is a security risk. Therefor the yes|no|auto cannot work (as I explained on the swan-dev mailing list) unless you default it to "no". But then the user would have to understand that mobike=yes and mobike=auto means kind of the same thing but auto will work if your local kernel is missing support it will treat it as "no".

I find that super complicated for the enduser and not a reasonable solution.

[HughR]

| From: "Paul Wouters (libreswan)" <notifications@github.com> | To: libreswan/libreswan <libreswan@noreply.github.com> | Cc: Subscribed <subscribed@noreply.github.com> | Reply-To: libreswan/libreswan | <reply@reply.github.com> I have no idea where my reply should be sent. My MUA decided to send it to all of the above. | auto is not a valid default for mobike= as it would enable mobike for | static von connections which is a security risk. Makes sense. | Therefor the | yes|no|auto cannot work (as I explained on the swan-dev mailing list) | unless you default it to "no". I would phrase this in a more positive way: the default has to be no. This has no impact on whether yes|no|auto are reasonable explicit choices. | But then the user would have to | understand that mobike=yes and mobike=auto means kind of the same thing | but auto will work if your local kernel is missing support it will treat | it as "no". Yeah. Welcome to the real world. Those are the choices in the real world. It could be argued that even finer-grained choices would be useful. That's not this discussion. | I find that super complicated for the enduser and not a reasonable solution. Well, the current implementation of yes|no is just fine. The error message should be made clear that the the failure must be fixed by the distro or building a custom kernel. That'll be easier for the user to accomplish than understanding what "auto" means. [/sarcasm] Seriously, if the user wants mobike, and we cannot give it to him, let's not mislead him. ================ If we offer yes|no|auto: Will "auto" ever actually be the right choice for the user to make? Will "yes" ever actually be the right choice? (We know "no" will sometimes be the right choice.) If "auto" is never the right choice then our current implementation is fine. This needs to be spelled out in the documentation. If "yes" is never the right choice, then our current implementation, with the error made non-fatal, would be fine. This needs to be spelled out in the documentation.

[letoams]

On Thu, 13 Jun 2019, HughR wrote: | Therefor the | yes|no|auto cannot work (as I explained on the swan-dev mailing list) | unless you default it to "no". I would phrase this in a more positive way: the default has to be no.

The default for all connections yes, the default for a remote access VPN client connection should be "use mobike when both ends support it, otherwise continue without mobike".

| I find that super complicated for the enduser and not a reasonable solution. Well, the current implementation of yes|no is just fine.

I disagree. For all the reasons stated multiple times.

The error message should be made clear that the the failure must be fixed by the distro or building a custom kernel.

"The VPN connection failed" is what NetworkManager might tell you. It might not even have an advanced option to set mobike= differently right now. Or it might not set it now at all, but it won't be able to set it either, because depending on the kernel, the entire connection will fail. So for NM it is better safe than sorry, so no mobike=yes by default. Success! We have won?

Seriously, if the user wants mobike, and we cannot give it to him, let's not mislead him.

So instead, give no users mobike because we cannot default it to yes?

================ If we offer yes|no|auto: Will "auto" ever actually be the right choice for the user to make?

Depends on what you mean with auto, but likely not if it does not mean "try mobike only if a remote access vpn client, continue if not available"

Will "yes" ever actually be the right choice?

Depends on what you mean with yes. If the remote peer fails to negotiate mobike, should the connection not fail according to your black and white interpretation of "the user wanted mobike" ? If you are a server with mobike=yes, should you fail clients that did not propose mobike if your own kernel supports it? Should it fail to load the conn if your kernel does not support it (thus also breaking all clients that never supported mobike to begin with?)

If "auto" is never the right choice then our current implementation is fine. This needs to be spelled out in the documentation.

I think auto can never be the right choice if its behaviour is not further dictated by being a remote access client/server or not.

If "yes" is never the right choice, then our current implementation, with the error made non-fatal, would be fine. This needs to be spelled out in the documentation.

Again, the whole discussion here is what does "yes" mean currently and what should "yes" mean. Where some people believe the current implementation is correct.