Subject: [IPsec] #65: Original initiator and rekeying

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:22 +0200

Tero: The actual text in the rfc4306 <http://tools.ietf.org/html/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
<http://tools.ietf.org/html/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:

Room: This is a small editorial issue.  Only new IKE SA has roles reversed
and message ID set to zero, rekeying does not affect roles and message ID
for existing IKE SA.  A diagram would make this clear.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:55:26 +0200

> for existing IKE SA.  A diagram would make this clear.

My original email had diagram about this, that can be included to the
draft:
----------------------------------------------------------------------
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