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

Tuomo Soini tis at foobar.fi
Fri Jul 29 10:02:27 UTC 2016


On Mon, 4 Jul 2016 12:57:26 -0400 (EDT)
Paul Wouters <paul at nohats.ca> wrote:

> 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".

To work correctly we'd need to know if we had auto=start/route or
"ipsec auto --start". We don't really know that. 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.

Does that sound reasonable? And we need to behave exactly same for both
ikev1 and ikev2.

-- 
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <http://foobar.fi/>


More information about the Swan-dev mailing list