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