<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 21:14, 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>
>       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>
> <br>
> Yea, that's too aggressive with deleting the incoming channel.  I'm pretty sure the initiator should:<br>
> <br>
> - delete outgoing channel<br>
> - send delete<br>
> on receipt of response<br>
> - delete incoming channel<br>
> - delete child state<br>
> <br>
> otherwise we get the responder sending packets that have nowhere to go<br>
<br>
But then an IKE SA needs to be clearly marked as "may only receive<br>
informational delete confirmation". Eg if the responder sends a<br>
CREATE_CHILD_SA or MOBIKE or something, we need to refuse to process it.<br>
<br></blockquote><div><br></div><div>If it is the IKE SA being deleted, yes.  How to correctly implement this part of the IKEv2 RFC makes for an interesting read.</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">
Currently, we have no way of marking an IKE SA state as such.<br><br></blockquote><div><br></div><div>It is technically a gap.  But one where the current strategy of fire-n-forget is kind of sort of close enough</div><div>(one place where it clearly hurts is with re-transmits - no IKE SA means they don't happen)</div><div><br></div></div></div>