[Swan] puzzled by ikev2_delete_out

[D. Hugh Redelmeier]

| From: Matt Rogers <mrogers at redhat.com>

| > From: "D. Hugh Redelmeier" <hugh at mimosa.com>

| > At the end of ikev2_delete_out, after the label "end", there is code to
| > delete states.  It is only used if something has gone wrong with sending a
| > delete to the other side.
| > 
| > There is a while loop that seems to change the state of every state object
| > on the same hash chain as the victim.  What's the reason for that?
| > Is there any meaningful relationship between state objects on a hash
| > chain?

| The hash chain should only have the Parent SA and any of its associated 
| Child SA's - it looks like the STATE_CHILDSA_DEL/STATE_IKE_DEL state 
| change is just for later use in delete_state()

Why?  The hash chain should have any states which hash to the same
bucket.  The hash is of cookies (IKE SA SPIs in IKEv2 terms).  But
it is the nature of a hash that distinct cookies could get hashed to
the same bucket.

I think that any deletion ought to check that the cookies match!
Actually, just as good: check the st_cloned_from value.

| But with this, I think I spot a bug in delete_state(). If we set a 
| parent SA to STATE_IKESA_DEL and delete_state() processes it,
| 
|         if (IS_IPSEC_SA_ESTABLISHED(st->st_state) ||
|             IS_CHILD_SA_ESTABLISHED(st))
|                 delete_ipsec_sa(st, FALSE);
| 
| STATE_IKESA_DEL is not included in either of these macros, only 
| STATE_CHILDSA_DEL. I'm not sure how likely we would be to reach this 
| condition, though.

Could you explain the problem you see?  I'm not familiar with the v2
code.

I don't think that the parent would have an ipsec_sa to delete.