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