[Swan-dev] parent and child's responsibilities

Paul Wouters paul at nohats.ca
Sat Jun 20 19:31:14 EEST 2015

On Sat, 20 Jun 2015, D. Hugh Redelmeier wrote:

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

What was the effect of the break? Dose this explain our missing packets?

> 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.

This has been a known issue and the core of why we need to fix the state
names. Solving this was postponed a few times. Additional glue has been
put in place to check for st->st_clonedfrom to distinguish the real
parent STATE_PARENT_R2 from the child STATE_PARENT_R2. We know this is
bad, but I do not think it is something we should fix for 3.14.

> 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.

Can we get to a temporary state where we do still send the packets
without overhauling the state machine?

> 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).

I don't think so? I'm not sure what you mean with IV-like objects. I
think any kind of IV for IKE is stored in specific st_ variables or
remains within the nss symkeys.

> 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.

But is this teh cause of the missing packets, or the solution of the
missing packets? I'm completely lost now.


More information about the Swan-dev mailing list