IKEv2 Child SA: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
So far this is just a scribbling of ideas. How to name the IKEv2 states. | |||
???? Do we need "STATE_" prefix to every state enum? | ???? Do we need "STATE_" prefix to every state enum? | ||
Line 10: | Line 12: | ||
STATE_PARENT_R1 -> IKE_V2_R1 | STATE_PARENT_R1 -> IKE_V2_R1 | ||
STATE_PARENT_R2 -> IKE_V2_R2 | 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 | |||
</pre> | </pre> | ||
Line 27: | Line 33: | ||
<pre> | <pre> | ||
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_R1 | V2_CHILD_R0 responding as part of parenet | ||
V2_CHILD_R2 | V2_CHILD_R1 initiated as a create child sa | ||
V2_CHILD_I2 established child | |||
V2_CHILD_R2 established child | |||
</pre> | </pre> | ||
Child states if we create as part of CREATE_CHILD_SA exchange. | Child states if we create as part of CREATE_CHILD_SA exchange. |
Revision as of 16:33, 18 June 2014
So far this is just a scribbling of ideas. How to name the IKEv2 states.
???? Do we need "STATE_" prefix to every state enum?
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 IKE_V2_K1 initiate a Rekey (not Reauthentication). Essentially we duplicated a parent and now initiatiing a rekey IKE_V2_K
An 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. It does seems the code support multiple child SA using st_hashchain_next.