[Swan-dev] Merging IKEv2 STATE_PARENT_I3 & STATE_PARENT_R2 into STATE_V2_ESTABLISHED

Andrew Cagney andrew.cagney at gmail.com
Tue Mar 3 21:24:21 EET 2015


Currently at the end of an IKEv2 negotiation, the original initiator
ends up in STATE_PARENT_I3 and the original responder ends up in
STATE_PARENT_R2.

Both of those states need to accept an identical set of packets and
behave identically.  The thing that controls behaviour is the MSG_R
bit and the payload type, not the IKE_I bit.

Are there edge cases?  Yes:

- the original initiator detects an auth failure
that is, if the original initiator, in STATE_V2_INIT_I, and finds that
the AUTH reply isn't sufficient, then it will send an informational
message with AUTHENTICATION_FAILED.
The merged STATE_V2_ESTABLISHED on the responder need to deal with this.

- the original responder back-to-backs AUTH reply and CREATE_CHILD_SA
packets (it is legal).  This is currently dropped on the floor.
If the states are merged and IKE_I/MSG_R are cleaned up this should
just start working:

-- original originator in state STATE_V2_INIT_I will keep sending AUTH
requests, ignoring the CREATE_CHILD_SAs, until it gets the AUTH reply.
The original responder, regardless of its state, will use
send_ike_msg(st, "ikev2-responder-retransmit") to re-respond to that
last AUTH requests; and keep re-transmitting that CREATE_CHILD_SA.

-- then, in STATE_V2_ESTABLISHED the original initiator will process
the CREATE_CHILD_SA request

Andrew


More information about the Swan-dev mailing list