[Swan-dev] the new ikev2 default (upstream and downstream issue)

[Paul Wouters]

On Mon, 3 Dec 2018, Tuomo Soini wrote:

>> I'm preparing to move to ikev2 as the default. This comes in the same
>> release where we will no longer allow a connection to be either v1
>> or v2. That is, basically we only have ikev2=yes|no
>
> That is good. ikev1 fallback or ikev2 upgrade were not good ideas.

Note work is being done in the v1-v2-split branch.

>> For the other options, ikev2=propose|permit we need to define what to
>> do. We had come to a tentative conclusion to alias 'propose' to 'yes'
>> and alias 'permit' to 'no'. We figured this would break the least
>> amount of configurations.
>
> This would be most preferred option. This will only break very rare and
> partly broken configurations where ikev2 upgrade of ikev1 fallback is
> required for asymmetric configuration to work. And we can never avoid
> breaking this.

Exactly, which is why we picked it this way :)

>> Red Hat however, prefers that we break cleanly. That is, they prefer
>> that the keywords propose and permit just error out and that the
>> connection fails to load. This makes it a little unfriendler, but
>> the _if_ a failure happens, it is clear as to why and when it happens.
>> (on upgrade, on startup)
>
> I don't think this is good idea to do. At least not with single
> release. We'd need to deprecate keywords first and give warnings about
> obsolete keywords for at least one released version.

I agree, but I also understand their reasoning. Since their argument is
that if anything breaks it should be obvious, and it should happen from
RHELX to RHELX+1 and not anywhere else.

>> This leaves us in an unfortunate situation that upstream would behave
>> different from a major deployment downstream.
>
> That is unfortunate but Red Hat is wrong in this - we can't change
> behaviour that fast.

We could, but we did decide at the last libreswan meeting to do this
slower.

>> So the question is, should we do the same in upstream or not?
>>
>> I have a slight preference for not doing this, but my feelings are not
>> very strong about this. What do others think?
>
> This is tricky. We'd want to go to ikev2=yes|no only finally with
> ikev2=yes being default.
>
> But breaking user experience is bad thing to do.
>
> My suggestion is to do the change in two stages.
>
> Now change our behaviour to default to ikev2=no. And WARN in release
> notes that next version will change behaviour to be ikev2=yes so that
> people at least have possibility to set ikev2=no in their conn %default
> so they won't break all tunnels.

We can do it in two steps, but not sure if that is needed. Since
everyone who will break, will break during 1 step of the process. And it
is easier for us to do both at once. (eg I dont want to fixup 550 test
cases twice to go from ikev2=yes to ikev2=no to no keyword)

> Switching default from ikev1 to ikev2 requires major release. So that
> is libreswan-4.0. I suggest we do that behaviour change at same time we
> drop klips support completely.

That would be even more confusing though. Because then there is
libreswan 3.x in RHEL and 4.x upstream with ikev2 defaults. It would be
nicer if we can talk about 3.x having changed it default ?

Paul