IKEv2 Child SA

Use name of exchange (INIT, AUTH, CREATE_CHILD, INFORMATIONAL) in name of state. Auth ones may extend with EAP?

From the comments in pluto_constants.h (only describes V1):

* The name of the state describes the last message sent, not the
* message currently being input or output (except during retry).
* In effect, the state represents the last completed action.
* All routines are about transitioning to the next state
* (which might actually be the same state).
*
* IKE V1 messages are sometimes called [MAQ][IR]n where
* - M stands for Main Mode (Phase 1);
*   A stands for Aggressive Mode (Phase 1);
*   Q stands for Quick Mode (Phase 2)
* - I stands for Initiator;
*   R stands for Responder
* - n, a digit, stands for the number of the message from this role
*   within this exchange
*
* It would be more convenient if each state accepted a message
* and produced one.  This is not the case for states at the start
* or end of an exchange.  To fix this, we pretend that there are
* MR0 and QR0 messages before the MI1 and QR1 messages.
*
* STATE_MAIN_R0 and STATE_QUICK_R0 are ephemeral states (not
* retained between messages) representing the state that accepts the
* first message of an exchange that has been read but not yet processed
* and accepted.

This should be extended to v2.

We may or may not need "0" states for each side of each exchange: that depends on how the internal logic unfolds. Typically, each exchange needs its own state object (struct state) to record progress through the exchange. Generally those would be born in an I0 or R0 state since no message has been sent at the start.

Tricky point: V2's Auth can successfully end with an IKE SA and an IPSec SA, or it can successfully end with just an IKE SA. It would seem that distinct states would be needed to represent those, but in fact they can be accurately represented: in the former case, there ought to be two state objects, one for the IKE SA (in STATE_V2_AUTH_[IR]) and one for the IPsec SA (in STATE_V2_CHILD_[IR]).

Radical thought: It might be nice if the terminal states of an exchange had a name that suggested what has been accomplished: not just an exchange step number, but an SA established. There need not be a terminal state if there is no accomplishment (i.e. the state object does not survive). That makes all the tests for "is an SA established?" read more clearly. Such a change should be apply to v1 states too. I'm not sure how this extends to or meshes with XAUTH/EAP states.

Just the initiator side.
STATE_V2_INIT_I0 = STATE_PARENT_I0 , STATE_V2_INIT_R0 = STATE_PARENT_R0
STATE_V2_INIT_I  = STATE_PARENT_I1 ,  STATE_V2_INIT_R = STATE_PARENT_R1
STATE_V2_AUTH_I  = STATE_PARENT_I2  , STATE_V2_IKE_R  = STATE_PARENT_R2
STATE_V2_IKE_I   = STATE_PARENT_I3  ,  
  
STATE_V2_CHILD_I0 STATE_V2_CHILD_R
STATE_V2_CHILD_I2 

STATE_V2_CHILD_REKEY_I0
STATE_V2_CHILD_REKEY_I

So far this is just a scribbling of ideas. How to name the IKEv2 states.

Do we need "STATE_" prefix to every state enum?

I'm used to it. Without "STATE_" the name could refer to a message. But some creativity might come up with something clear and shorter. Hugh (talk) 08:30, 28 August 2014 (EEST)

STATE_PARENT_I1 -> IKE_V2_I1
STATE_PARENT_I2 -> IKE_V2_I2
STATE_PARENT_I3 -> IKE_V2_I3

STATE_PARENT_R1 -> IKE_V2_R1
STATE_PARENT_R2 -> IKE_V2_R2 

IKE_V2_K1 initiate a Rekey (not Reauthentication). Essentially we duplicated a parent and now initiatiing a rekey
IKE_V2_K

alternative:

STATE_PARENT_I1 -> STATE_IKE_I1
STATE_PARENT_I2 -> STATE_IKE_I2
STATE_PARENT_I3 -> STATE_IKE_I3

STATE_PARENT_R1 -> STATE_IKE_R1
STATE_PARENT_R2 -> STATE_IKE_R2 

New child states when a Child SA is negotiated as part of ISAKMP_v2_SA_INIT, aka with Parent SA. During this process also parent advances its state. The following state name may not have entry in smc/svm table. Still they are states????

 
V2_CHILD_I0 (If we are initiating as part of parent SA Negotiation. On initiator we duplicate when we get R1 back)
V2_CHILD_I1 if iniiated as part of chreate child SA
V2_CHILD_R0 responding as part of parenet 
V2_CHILD_R1 initiated as a create child sa
V2_CHILD_I2 established child
V2_CHILD_R2 established child

Child states if we create as part of CREATE_CHILD_SA exchange.

-- The Parent SA just stays in I3/R2. 
-- We create/duplicate a state. 
-- Add new keying material etc. 
-- Complete the negotiate. 
-- Inhert the Children from parent
-- expire the parent. Switch to IKE_V2_I3/IKE_V2_R2

V2_CHILD_I1 V2_CHILD_I2 V2_CHILD_R1 V2_CHILD_R2

When Parent is Re keying using the old parent. I guess we duplicate and send new SPI/COOKIES over the old one to negotiate. Newly duplicated parent need a name too

V2_REKEY_I1
V2_REKEY_I2
V2_REKEY_R1
V2_REKEY_R1

Rekey Child SA over the existing parents.

V2_CHILD_REKEY_I1
V2_CHILD_REKEY_I2
V2_CHILD_REKEY_R1
V2_CHILD_REKEY_R2

Multiple Child SA, Pluto code seems to support multiple child SA.

Hugh's current preference:

STATE_V2_INIT_I0 /* ephemiral: sent nothing yet (MAY NOT BE NEEDED) */
STATE_V2_INIT_I /* sent INIT I */
STATE_V2_AUTH_I /* received INIT R; sent AUTH I */

STATE_V2_IKE_I /* terminal: created IKE SA, either from AUTH or CREATE_CHILD_SA */
STATE_V2_IPSEC_I /* terminal: created IPSec SA, either from CREATE_CHILD_SA or AUTH exchange */

Since CREATE_CHILD exchange can create a child or a parent, I want to just call it a CREATE exchange.  But perhaps we will find it convenient to break the cases down into NEW_IPSEC, REKEY_IKE, and REKEY_IPSEC.

STATE_V2_CREATE_I0 /* ephemeral: sent nothing yet (MAY NOT BE NEEDED) */
STATE_V2_CREATE_I /* sent first message of CREATE_CHILD exchange */