[Openswan dev] Design question: ikev2 state change signifying partial success?

[Paul Wouters]

On Tue, 21 Feb 2012, Paul Wouters wrote:

I wrote:

> The tricky thing is that the responder's last packet sets up both the
> parent and the child sa, so we cannot abort sending that 4th packet in
> the exchange, so we have to carry around the bogus child for a while
> and delete_state() it after we sent out the last exchange packet. This
> last bit requires "signaling" that in the call chain of the
> STATE_PARENT_R2 state processor function, and that's where my question
> regarding STF_OK versus a new STF_PARENT_OK came from.
>
> In this case, we have the call chain:
>
> ikev2parent_inI2outR2 ->
>   ikev2_parent_inI2outR2_continue ->
>            ikev2_parent_inI2outR2_tail ->
>                 ikev2_child_sa_respond
>
> These all signal now via their return type of stf_status, and if
> anything in this chain is not STF_OK, we enter "abort" code that
> does not let us complete the parent SA and thus we cannot signal
> child sa errors in an encrypted way.
>
> This is why I am thinking of a new stf_result STF_PARENT_OK, that
> ikev2_child_sa_respond can return, then the previous callers can
> tell the difference between "parent + child SA" and "parent sa only".

This actually cannot work.

For one, there can be more traffic selectors, so multiple childs could
be made, and a subset of those could fail, so STF_PARENT_OK does not
help us beyond signaling "one or more child SAs failed". There is no
real cleanup we can do without redetermining which of those child SAs
actually failed.

Also, throughout the call chain we only have the state
st of the parent sa, not the child sa, so we can only mark the child sa
as "failed, to be deleted" deep in the call chain, so there is limited
value of signaling STF_PARENT_OK.

> So while this creates a new stf_status, this does not create a new
> state, as I think once we delete the incomplete child, the parent states
> are fine, and we don't want the child state to linger? Or do we want
> that, so the child can tell the parent to keep retrying?

Deleting the incomplete child sa's is still a problem, even if we go
through:

 	change_state(st, STATE_CHILDSA_DEL);
 	delete_state(st);

I'm still investigating why, but it seems related to the macros around
parent and child SA's, and assumed states those SA's would be in that
are not true for our incomplete child SAs.

Paul