Subject: [Ipsec] REKEY_SA Notify clarification wanted

From: Fukumoto Atsushi <[email-masked]>
Date: Thu, 28 Jul 2005 17:20:45 +0900

draft-ietf-ipsec-ikev2-17.txt says:
in section 1.3:
   If this
   CREATE_CHILD_SA exchange is rekeying an existing SA other than the
   IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
   being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an
   existing SA, the N payload MUST be omitted.

and in section 3.10.1:
        REKEY_SA                                 16393

            This notification MUST be included in a CREATE_CHILD_SA
            exchange if the purpose of the exchange is to replace an
            existing ESP or AH SA. The SPI field identifies the SA being
            rekeyed. There is no data.

These are the only mentions of REKEY_SA, and I found it hard to figure
out what to do when rekeying IKE SA.  The above descriptions strongly
suggests (to me) that the REKEY_SA is not used in IKE SA rekeying.
But apparently the intention is contrary, since the
draft-eronen-ipsec-ikev2-clarification-04 appendix A.5 has this (I
assume N(REKEY) means N(REKEY_SA)):

A.5  CREATE_CHILD_SA exchange for rekeying the IKE_SA

   request             --> N(REKEY),
                           SA, Ni, [KEi]

   response            <-- SA, Nr, [KEr]

Meanwhile, section 5.2 of clarification draft 04 says:
   IKEv2 does not have any special support for reauthentication.
   Reauthentication is done by creating a new IKE_SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
   payloads), creating new CHILD_SAs within the new IKE_SA (without
   REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
   deletes the old CHILD_SAs as well).

which seem to imply by not mentioning "without REKEY_SA" that I need
REKEY_SA, although I wish it be more explicit.

Also in section 7.7 of clarification draft 04:
   Since the main purpose of the Protocol ID field is to specify the
   type of the SPI, our interpretation is that the Protocol ID field
   should be non-zero only when the SPI field is non-empty.
   There are currently only two notifications where this is the case:
   INVALID_SELECTORS and REKEY_SA.

This makes me wonder what the Protocol ID should be for REKEY_SA when
rekeying IKE SA, if I need one.  Is it ProtocolID==IKE_SA (value 1),
in which case the SPI field must be non-empty?  Or ProtocolID==0,
since draft-17 says "For a notification concerning the IKE_SA, the SPI
Size MUST be zero"?

					FUKUMOTO Atsushi
					[email-masked]

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

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 31 Jul 2005 18:58:32 +0300

> suggests (to me) that the REKEY_SA is not used in IKE SA rekeying.

When you are rekeying IKE SA you do not include N(REKEY_SA) at all. It
is only included when you are rekeying ESP or AH SA (as the section
3.10.1 and 1.3 say).

>    response            <-- SA, Nr, [KEr]

I think the clarification draft then has an error. 
-- 
[email-masked]