[Swan-dev] parent and child's responsibilities

D. Hugh Redelmeier hugh at mimosa.com
Sat Jun 20 11:22:41 EEST 2015


I'm trying to fix IKEv2's inI2 ourR2 logic (after I broke it).

A child SA is established (if all went well).  So going in, there is one 
parent state object and coming out it is joined by the child state object.

Confusingly, they seem to both be in STATE_PARENT_R2.  That seems wrong.  
Very wrong.

In the current code, the outbound packet gets attached to the parent and 
then there is an attempt to send whatever was attached to the child.  That 
doesn't work very well.

This lack of sending is due to a bug I fixed.  The code used to 
redundantly attach outbound packets to the state twice(!) if SMF2_SEND is 
on in the microcode.  Accidentally, in the case of inI2 out R2, a copy 
would be attached to each of the two states so that when the SMF2_SEND 
logic tried to find it, it was there.

In v1, the st_tpacket logic was used for retransmission.  In IKE V2, inI2 
out R2 is a responder state and will never do any retransmitting.  So it 
kind of doesn't matter if the st_tpacket/st_tfrags values persist.  Unless 
they are used as IV-like objects (I don't think that they are).

In any case, ikev2_parent_inI2outR2_auth_tail creates the child state
but was careless about which state it referenced after that.  I think
that I've resolved the problem by making it always use the child after
the child is created.  This parallels some changes I made recently to
ikev2_parent_inR1outI2_tail but is not nearly as extensive.

Code after other calls to ikev2_parent_inI2outR2_auth_tail ought to be
checked.


More information about the Swan-dev mailing list