Subject: [IPsec] Original initiator and rekeying

From: Tero Kivinen <[email-masked]>
Date: Fri, 31 Oct 2008 15:55:03 +0200

I had another question about this from our customer and realized that
the actual text in the rfc4306 or clarifications does not exactly
specify when the message ids are reset and when the roles are changed.
For me it was clear that of course the old IKE SA uses the old roles
and old message IDs as otherwise it could not work at all, and the new
IKE SA created by rekeying IKE SA will use the new message ID starting
from 0, and new roles of the original initiator and responder (i.e.
the Initiator flag in the header). After reading the RFC4306 and
clarifications and latest draft, I think most of the text is there,
but it is scattered so widely it is hard to find:

RFC4718 section 5.1 and ikev2bis-01 section 1.3.2 says the new IKE_SA
has its message countes set to 0, but does not specify what happens to
old IKE_SA message IDs (for me it is clear they stay as they were).

RFC4718 section 5.9 and ikev2bis-01 section 2.2 says that the
"original initiator" always refers to the party who initiated the
exachange that resulted in the current IKE_SA. For me that means only
the new IKE SA has its roles changed, not old one, but some people
have misinterpreted that.

So I propose we add couple of more example sections showing the two
cases, i.e. normal case where the original initiator does IKE SA rekey
and another case where the original responder does the IKE SA rekey
and the roles on the new IKE SA are changed. These sections should
most likely be added between 1.3.2 and 1.3.3:
----------------------------------------------------------------------
x.x.x Example of IKE SA Rekey by Original Initiator

  Here is full example of the IKE SA rekey, including the IKE SPIs,
  message id, and the Initiator and Response bit on the header. SPIA*
  are IKE SA SPIs allocated by Alice, and SPIB* are IKE SA SPIs
  allocated by Bob. HDR(I,R,M,F) format is used to explain fields in
  the header. I, and R are the initiator and responder IKE SA SPIs, M
  is the message id (in this example we assume the next one to be used
  by initiator is 33, and the next one to be used by responder is 44).
  The F is the flags field of the header, having Initiator and/or
  Response if those flags are set in the header.

  In this first example the Alice is the original initiator, and Bob
  is the original responder, and the Alice starts the IKE SA rekey.
  SPIA1 and SPIB1 are the SPIs of the old IKE SA and SPIA2 and SPIB2
  are the SPIs for the new IKE SA.

   Alice                         Bob
   -------------------------------------------------------------------
   HDR(SPIA1,SPIB1,33,Initiator),
   SK {SA(SPIA2), Ni, [KEi]} -->
                                <--  HDR(SPIA1,SPIB1,33,Response),
				     SK {SA(SPIB2), Nr,[KEr]}

  Now the IKE SA is rekeyed, and next the party who started the rekey
  deletes the old IKE SA, i.e. in this case it will be Alice. The
  delete sent as last message to the old IKE SA.

   Alice                         Bob
   -------------------------------------------------------------------
   HDR(SPIA1,SPIB1,34,Initiator),
   SK {D(Protocol ID=1,No SPI} -->
                                <--  HDR(SPIA1,SPIB1,34,Response),
				     SK {}

   The next request sent by the Alice and Bob will have headers as
   following, first the request from Alice and Bob's reply to it:

   Alice                         Bob
   -------------------------------------------------------------------
   HDR(SPIA2,SPIB2,0,Initiator), ... -->
				 <--- HDR(SPIA2,SPIB2,0,Response), ...

   The Bob's first request and Alice's reply to it will be like this:

   Alice                         Bob
   -------------------------------------------------------------------
				 <--- HDR(SPIA2,SPIB2,0,), ...
   HDR(SPIA2,SPIB2,0,Initiator Response), ... -->

x.x.x Example of IKE SA Rekey by Original Responder

   In this second example the Alice is still original initiator, and
   Bob is the original responder, but now Bob starts the IKE SA rekey.

   Alice                         Bob
   -------------------------------------------------------------------
                                <--  HDR(SPIA1,SPIB1,44,),
				     SK {SA(SPIB2), Nr,[KEr]}
   HDR(SPIA1,SPIB1,44,Initiator Response),
   SK {SA(SPIA2), Ni, [KEi]} -->

   After this the Bob deletes the old IKE SA, and send his delete
   request as last exchange for the old IKE SA. Note, that the old IKE
   SA still keeps the original initiator and responder roles, and the
   message ID is still incremented as normally. 

   Alice                         Bob
   -------------------------------------------------------------------
                                <--  HDR(SPIA1,SPIB1,45,),
				     SK {D(Protocol ID=1,No SPI}
   HDR(SPIA1,SPIB1,45,Initiator Response),
   SK {} -->

   The new IKE SA on the other hand will have original initiator roles
   reversed compared to the original IKE SA. The next request sent by
   Alice and Bob's reply to it will have following headers:

   Alice                         Bob
   -------------------------------------------------------------------
   HDR(SPIB2,SPIA2,0,), ... -->
				 <--- HDR(SPIB2,SPIA2,0,Initiator Response), 
				      ...

   Note, that the SPIs in the header are reversed (i.e. the SPI
   allocated by the Bob is first, and the Initiator bit is set on
   those packets sent by Bob, not those sent by Alice as it was in the
   old IKE SA).

   The Bob's first request and Alice's reply to it will be like this:

   Alice                         Bob
   -------------------------------------------------------------------
				 <--- HDR(SPIB2,SPIA2,0,Initiator), ...
   HDR(SPIB2,SPIA2,0,Response), ... -->
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 31 Oct 2008 08:11:09 -0700

I gave this a ticket number; we definitely need to make this clearer.

IKEv2 implementers: please review Tero's text and comment.

--Paul Hoffman, Director
--VPN Consortium