[Swan-dev] parent and child's responsibilities

[Paul Wouters]

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.

Paul