Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages

From: [email-masked]
Date: Tue, 13 Sep 2005 09:25:29 +0300

Mohan Parthasarathy wrote:

> But i wonder what the purpose of N(REKEY_SA) is ? What is the
> responder supposed to do with REKEY_SA notification ? If it just
> ignores it, then it is the same as the CREATE_CHILD_SA ? One can
> potentially use it to insert the new SA in front of the old SA so
> that outbound traffic can use the new SA. But you can't do so for
> the reasons given in the last paragraph of section 2.8.

An earlier version of the IKEv2 clarifications draft (-01) had 
some text wondering the same thing:

2.10  Rekeying CHILD_SAs

   (Preliminary text, still open.)

   Section 2.8 describes that rekeying a CHILD_SA within an existing
   IKE_SA is done by first creating a new equivalent SA, and then
   deleting the old one.  However, this section does not describe
   exactly what payloads are involved, and does not even mention the
   REKEY_SA notify payload.  Another description about rekeying can be
   found in Section 1.3, but this section also omits some of the details
   that are in Section 2.8.

   A typical conversation that rekeys an existing CHILD_SA pair and then
   deletes the old SAs would look like this:

       Initiator                                       Responder
      -----------                                     -----------

      [traffic flowing via CHILD_SA pair with SPIi1/SPIr1]

      HDR, SK {N(REKEY_SA, SPIi1),
               SA(..., SPIi2, ...),
               Ni, [KEi], TSi, TSr}  -->

                                   <--  HDR, SK {SA(..., SPIr2, ...),
                                                 Nr, [KEr], TSi, TSr}

      HDR, SK {D(SPIi1)}  -->

                                              <--  HDR, SK {D(SPIr1)}

      [traffic flowing via new CHILD_SA pair with SPIi2/SPIr2]

   However, it seems that exactly the same (or almost the same) end
   result would have been achieved if the REKEY_SA notify payload was
   not included.  Not including REKEY_SA here is allowed in IKEv2; in
   that case, it is not called rekeying, but creating a parallel SA with
   identical traffic selectors, and coincidentally, deleting one of them
   very soon after that.  Why, then, was the REKEY_SA notify payload
   included in the spec?

   This document's interpretation is that by including REKEY_SA, the
   initiator promises that (1) it will move its outbound traffic to the
   new SA as soon as it receives the CREATE_CHILD_SA response, (2) it
   will not use the old outbound SA after that, and (3) it will delete
   the old SA pair soon afterwards.

   If this interpretation is correct (which is not clear yet), there
   seems to be three main differences between the cases with and without
   REKEY_SA.  First, if REKEY_SA is included, the responder can do
   certain optimizations that would not be possible without it.  Second,
   the exact point when the responder moves the outbound traffic to the
   new SA may be different.  Third, there may be some differences if
   rekeying is started simultaneously by both parties.

   Let's consider the optimization case first.  It seems that when doing
   rekeying, a simple responder implementation could, in fact, replace
   the old SAs "in place".  This can result in some packets being lost,
   so Section 2.8 recommends against this.

       Initiator                                       Responder
      -----------                                     -----------
      HDR, SK {N(REKEY_SA, SPIi1),
               SA(..., SPIi2, ...),
               Ni, [KEi], TSi, TSr}  -->

                                        [responder replaces the old SAs
                                        with new ones,  but remembers
                                        the values SPIi1/SPIr1]

                                   <--  HDR, SK {SA(..., SPIr2, ...),
                                                 Nr, [KEr], TSi, TSr}

      HDR, SK {D(SPIi1)}  -->

                                        [the old SA is already gone,
                                        but the responder still
                                        remembers SPIi1/SPIr1]

                                              <--  HDR, SK {D(SPIr1)}

                                        [now responder can forget
                                        SPIi1 and SPIr1]

   The second difference seems to be when exactly the responder should
   move the traffic to the new SA.  When REKEY_SA is used, Section 2.8
   says that the responder should continue using the old SA until it
   either receives a packet on the new inbound SA, or receives a Delete
   request for the old SA pair.  When REKEY_SA is not used, the traffic
   is obviously moved when the old SA is deleted, but not necessarily
   earlier.

   The third difference may be what exactly happens when both parties
   start rekeying at the same time, and the requests cross in the
   network.  Here REKEY_SA indicates that neither party wants to keep
   parallel CHILD_SAs around.  (TO BE WRITTEN: details of exactly what
   happens in this case.)

   Yet another interpretation is that an IPsec implementation that does
   not work strictly on per-packet basis, but instead associates SAs
   with transport layer sockets, could use this information to update
   the socket instead of searching the SADB/SPD for a suitable SA.  (TO
   BE WRITTEN: details, and whether this makes sense.)

   (References: Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
   Implementation Guidelines", 2005-02-07.)

This text got removed when some of the rekeying text was rewritten,
and might be partly wrong... but some off-line conversations around
that time were quite clear that even if you do rekeying, you still
have to delete the old SAs explicitly, in a separate INFORMATIONAL
exchange containing Delete payloads as usual.

(But yes, it looks like IKEv2 could have been designed so that a
separate Delete payloads would not be needed; but that's too late
to change now.)

Best regards,
Pasi

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