[Swan-dev] Behaviour around Delete/Notify: two problems for the price of one.

[Paul Wouters]

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