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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
