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

[Antony Antony]

On Wed, Jun 12, 2019 at 12:12:25PM -0400, Paul Wouters wrote:
> 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. 

you did not explain that in your previous e-mails! Loadding a connection 
with mobike=yes implies you send and respond to the payloads. If not that is 
different complication.

> 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

way complicated, hard do debug when you hit issues. I vote against option A.

> or:
> 
> B) Fail to load the conn

I am for option B.

-antony