Thanks all the helpful response. It is very clear now. On Mon, May 4, 2015 at 10:21 PM, Paul Wouters <[email protected]> wrote:
> On Mon, 4 May 2015, Lihua Wan wrote: > > Hi all,In RFC5723 section 5, it mentions >> >> +--------------------------------+----------------------------------+ >> | State Item | After Resumption | >> +--------------------------------+----------------------------------+ >> >> ... >> >> | Which peer is the "original | Determined by the initiator of | >> | initiator"? | IKE_SESSION_RESUME. | >> >> If client is initiator of IKE_SESSION_RESUME, I understand client is the >> original initiator AFTER resumption. So the initiator flag in the IKE >> header should be set by client after resumption. >> My question is what about the resume request packet during resume >> exchange? Should client set the initiator flag in IKE header when it sends >> out resume request? >> >> The case is like blow: >> 1. Gateway initiated IKE rekey completed. >> 2. Connection is suspened. >> 3. Client sends a resume request to gateway in the RESUME exchange. >> >> In step 3, should the IKE header sent by Client set the initiator flag? I >> know if client sets the initiator flag, then gateway should response with >> the initiator flag cleared. >> But according to RFC7296 initiator flag explanation, Gateway is the >> initiator of last IKE SA rekey. I am not sure which side should be set the >> initiator flag during resume exchange. >> > > > Remember that the Original Initiator flag is used to see whether you > use are the first (initiator) SPI or the second (responder) SPI in the > ISAKMP header. > > So with that in mind read: > > This document specifies a new IKEv2 exchange type called > IKE_SESSION_RESUME whose value is 38. This exchange is equivalent > to > the IKE_SA_INIT exchange > > So when you initiate IKE_SESSION_RESUME, you have no responder SPI. There > is only your initiator SPI, and you must set the Original Initiator flag. > > The responder receiving your resume exchange, sees the Original Initiator > flag. It also sees the lack of the Message Response flag, so it knows > it is a responder for this exchange. It looks up an IKE SA where it is > the responder SPI and the other end is the initiator SPI. (and since > the responder SPI is zero it knows this will be a new exchange/state > and it will generate a responder SPI to use in the answer) > > Paul >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
