IKEv2 Child SA: Difference between revisions

From Libreswan
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
DHR:: use exchange names, INIT, AUTH, CREATE_CHILD, part of state.  
DHR:: use exchange names, INIT, AUTH, and CREATE_CHILD, NAME of state state. Auth ones may extend with EAP?
What about informational exchanges.


<pre>
Just the initiator side.
V2_INIT_I = STATE_PARENT_I1
V2_AUTH_I = STATE_PARENT_I2
V2_IKE_I  = STATE_PARENT_I3
V2C_CHILD_I0 = STATE_PARENT_I2
V2C_CHILD_I2 = STATE_PARENT_I3
V2_CHILD_REKEY_I
V2_CHILD_REKEY_I1
V2_CHILD_I1
V2_CHILD_I2
<pre>


So far this is just a scribbling of ideas. How to name the IKEv2 states.
So far this is just a scribbling of ideas. How to name the IKEv2 states.
Line 6: Line 21:
???? Do we need "STATE_" prefix to every state enum?
???? Do we need "STATE_" prefix to every state enum?


Renaming IKEv2 States


<pre>
<pre>
Line 22: Line 36:




An alternative:
alternative:
<pre>
<pre>
STATE_PARENT_I1 -> STATE_IKE_I1
STATE_PARENT_I1 -> STATE_IKE_I1
Line 74: Line 88:
</pre>
</pre>


Multiple Child SA. It does seems the code support multiple child SA using st_hashchain_next.
Multiple Child SA, Pluto code seems to support multiple child SA.

Revision as of 06:55, 26 July 2014

DHR:: use exchange names, INIT, AUTH, and CREATE_CHILD, NAME of state state. Auth ones may extend with EAP? What about informational exchanges.

Just the initiator side.
V2_INIT_I = STATE_PARENT_I1
V2_AUTH_I = STATE_PARENT_I2
V2_IKE_I  = STATE_PARENT_I3
V2C_CHILD_I0 = STATE_PARENT_I2
V2C_CHILD_I2 = STATE_PARENT_I3

V2_CHILD_REKEY_I
V2_CHILD_REKEY_I1
V2_CHILD_I1
V2_CHILD_I2 

<pre>

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

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


<pre>
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.