IKEv2 Child SA

Renaming IKEv2 States

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

New child states if 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_I1 (If we are initiating as part of parent SA Negotiation. On initiator we duplicate when we get R1 back) V2_CHILD_I2 V2_CHILD_R1 V2_CHILD_R2

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_XXI1 V2_CHILD_XXI2 V2_CHILD_XXR1 V2_CHILD_XXR2

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. It does seems the code support multiple child SA using st_hashchain_next.