[Swan-dev] Q: mobike on kernel without mobike: load or not load the connection

[Paul Wouters]

On Wed, 12 Jun 2019, Antony Antony wrote:

>> - if local connection has mobike=yes but kernel support disabled -> fail
>>   to load the connection. IPsec tunnel fails
>> - if local connection has mobike=yes but IKE negotiation resulted in
>>   peer not supporting mobike -> succeeds connection but without mobike
>>
>> The question is whether in the first case, we shouldn't really just
>> setup the connection but without mobike, perhaps log a big warning?
>
> When an end knows the kernel do not suppor mobike and respond or initiate
> with MOBIKE support, it is lying in the negotiation. It clearly know a
> feature can't be supported.

If mobike is not supported by our kernel, it should not send the MOBIKE
notify. But it should still load the connection that has mobike=yes

> 1. To me that is gross violation in ike negotiation. The concept should be if
> you send a notify honer it when time comes.
> 2. IKE is a hard to debug, especially from the other side, protocol by
> design. Early, clear, failure is a good idea.
> In this case sending a mobike supported notify and doing weird things when
> the other end actually request it, it is bad idea for IKE.

That is not what I was suggesting.

> 3. I don't understand someone want to keep unsupported options in
> connection. Are they copy pasting connection between supported and
> unsupported?

Most users copy options from documentation or web pages. But I would
even argue that if we know we are an IKEv2 client going to do CP, that
is we are a "remote access client", it should default to mobike=yes.

> I know this breaks our left/right argument if one side support and the other
> do not.

That too. But also people might get a kernel update that accidentally
doesn't have the support. I see no reason why the whole connection
should fail completely, instead of only mobike not getting deployed.

>> What do people prefer? Close 221 without changes and keep current
>> situation, or change code to allow loading the connection and bringing
>> it up without mobike ?
>
> first one. Do not lie in IKE negotiations.

We don't lie (or if we do, we should fix that as a bug). The situation
we seem to be disagreeing on is:

- We don't support XFRM_MIGRATE
- The conn has mobike=yes

Should we:

A) Load the conn, don't send N(MOBIKE) because we don't support it, and
    establish a conn without mobike

or:

B) Fail to load the conn

Paul