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
