On Fri, 29 Jul 2016, Tuomo Soini wrote:
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".
To work correctly we'd need to know if we had auto=start/route or
"ipsec auto --start". We don't really know that.
What you really mean is we need to know what initial auto=XXX state,
plus any modified ipsec auto --XXX instructions we have received for
this connection from the administrator.
But I think we should
really use our initiator/responder role to decide our behaviour. If we
are initiator and responder ends sends us delete SA we should start
immediate renegotiation. If we are responder and initiator end sends
delete SA we should just delete state.
The problem with a role is that in a way it is irrelevant. Lets say the
two of us configure a tunnel and we both issue "ipsec auto --up" at the
same time. We both want the tunnel up and it does not matter who is the
"responder" for this IKE exchange.
Which is why I say what matters is the original state of auto=XXX plus
any modifications done by ussing ipsec auto --XXX commands. Based on
that state, which can be "add", "ondemand" or "start", we should decide
what to do when we receive a Delete request.
I'm still not sure of auto=start with ipsec auto --down though. Formally
start = add + initiate but it could also mean "ondemand + initiate". So
when you go from auto=start to issue --down, do we go to auto=add or
auto=ondemand?
do we need an ipsec auto --reset conn to mean "go to the original auto=
value of the config file" ? The only practical difference would be that
an auto=start with --down would go to auto=add while a auto=start with
--reset would go to up.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
