On Sat, 2 Jul 2016, Paul Wouters wrote:
Clearly we should be consistent independent of IKE version.
It all depends on what the meaning of auto=add with an ipsec auto --up
really means. Is this the same as "auto=start" meaning "always try to
keep this up"? If so, if the other end sends a delete, shouldn't we
immediately establish a new IKE SA, instead of waiting one minute?
And if the auto=add side sends an ipsec auto --down, does that mean it
will accept a request to immediately go up? That would also be weird.
So, I'm open for input :)
Which I still am, because I think we should not wait 60s before we start
trying again when we are configured to be "always up".
Note:
strongswan always deletes both IKE and IPsec SA's (with auto=add and
auto=start), meaning the endpoint configured with auto=start can be "shut
down" by the other endpoint. I do not think that is the correct behaviour.
This new keyword in strongswan seems related:
closeaction = none | clear | hold | restart
defines the action to take if the remote peer unexpectedly
closes a CHILD_SA (see dpdaction for meaning of values). A
closeaction should not be used if the peer uses reauthentication
or uniquids checking, as these events might trigger the defined
action when not desired.
It seems even more of a pandora's box.
I would say if auto=start or auto=add + ipsec auto --up, and
rekey=yes, it should attempt to bring up a new tunnel upon receiving
delete/notify. Ideally, it should postpone the delete or install a %hold
shunt. I prefer postpone the delete - it is basically a shunt already.
Then we could leave the current 60s dying behaviour in place?
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
