[Swan-dev] Bogus "established IKE SA" messages

[Andrew Cagney]

On Mon, 5 Apr 2021 at 20:45, Paul Wouters <paul at nohats.ca> wrote:

> On Mon, 5 Apr 2021, Andrew Cagney wrote:
>
> > although the comment is slightly out-of-date.  The bit
> SMF2_SUPPRESS_SUCCESS_LOG has been added (more are needed).  You could try
> adding it to this transition:
>
> I'll try and play with that.
>
> >       Also, I wonder if we should keep a recent list of deleted IPsec and
> >       IKE SPI's, so when we get a delete response for something we have
> just
> >       deleted, we don't show a weird "not found" error.
> >
> >
> > As in two delete requests crossing in the night?
> >
> > Could this be from the delete code being a little too aggressive -
> deleting the incoming channel before the delete response has been received?
>
> It's simpler.
>
> 1) We realise we want to delete a child sa
> 2) we send the delete
> 3) we delete it
> 4) we get a response, but we cannot find the child sa SPI
>
>
Yea, that's too aggressive with deleting the incoming channel.  I'm pretty
sure the initiator should:

- delete outgoing channel
- send delete
on receipt of response
- delete incoming channel
- delete child state

otherwise we get the responder sending packets that have nowhere to go




> A variant:
>
> 1) We realise we want to delete a chilf sa
> 2) we send a delete
> 3) we delete it
> 4) we realise the IKE sa has no more child sa's, so we delete it
> 5) we receive the encrypted IKE packet for the delete of child sa,
>     but can't read it.
>
> Perhaps this last case is now fixed? with pending the delete, but in
> that case the reply message is still unreadable because we deleted the
> IKE SA.
>

It's improved as in it only sends one delete.  It still needs the IKE SA to
hang around.


> I saw these while working on the expiry code.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210405/5ca8e109/attachment.html>