<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Apr 2021 at 20:45, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 5 Apr 2021, Andrew Cagney wrote:<br>
<br>
> 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:<br>
<br>
I'll try and play with that.<br>
<br>
>       Also, I wonder if we should keep a recent list of deleted IPsec and<br>
>       IKE SPI's, so when we get a delete response for something we have just<br>
>       deleted, we don't show a weird "not found" error.<br>
> <br>
> <br>
> As in two delete requests crossing in the night?<br>
> <br>
> Could this be from the delete code being a little too aggressive - deleting the incoming channel before the delete response has been received?<br>
<br>
It's simpler.<br>
<br>
1) We realise we want to delete a child sa<br>
2) we send the delete<br>
3) we delete it<br>
4) we get a response, but we cannot find the child sa SPI<br>
<br></blockquote><div><br></div><div>Yea, that's too aggressive with deleting the incoming channel.  I'm pretty sure the initiator should:</div><div><br></div><div>- delete outgoing channel</div><div>- send delete</div><div>on receipt of response</div><div>- delete incoming channel</div><div>- delete child state</div><div><br></div><div>otherwise we get the responder sending packets that have nowhere to go</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A variant:<br>
<br>
1) We realise we want to delete a chilf sa<br>
2) we send a delete<br>
3) we delete it<br>
4) we realise the IKE sa has no more child sa's, so we delete it<br>
5) we receive the encrypted IKE packet for the delete of child sa,<br>
    but can't read it.<br>
<br>
Perhaps this last case is now fixed? with pending the delete, but in<br>
that case the reply message is still unreadable because we deleted the<br>
IKE SA.<br></blockquote><div><br></div><div>It's improved as in it only sends one delete.  It still needs the IKE SA to hang around.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I saw these while working on the expiry code.<br>
<br>
Paul<br>
</blockquote></div></div>