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

[Antony Antony]

On Tue, Jun 11, 2019 at 06:35:26PM -0400, Paul Wouters wrote:
> 
> See https://github.com/libreswan/libreswan/issues/221
> 
> Currently:
> 
> - 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.

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.
3. I don't understand someone want to keep unsupported options in 
connection. Are they copy pasting connection between supported and 
unsupported?
I know this breaks our left/right argument if one side support and the other 
do not.

> 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. 

when you commit something over the over the wire, better be sure you can do 
it when the time comes.
It is not about the cases where things appear to work for now, but about 
being honest in negotiations. I am not going to defend other examples, or 
history.