[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IKE-SA Deletion



The second paragraph in Section 2.8 (in the IKEV2 proposal) specifies:

   To rekey an IKE-SA, establish a new equivalent IKE-SA (see section 4
   and 4.2 below) with the peer to whom the old IKE-SA is shared using a
   Phase 2 negotiation within the existing IKE-SA. An IKE-SA so created
   inherits all of the original IKE-SA's child SAs.  Use the new IKE-SA
   for all control messages needed to maintain the child-SAs created by
   the old IKE-SA, and delete the old IKE-SA.

Also, in Section 7.11 (Delete Payload), the second paragraph specifies:

   Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but
   no SPIs.  Deletion which is concerned with a Child-SA, such as ESP or
   AH, will contain the Protocol-Id of that protocol (e.g.  ESP, AH) and
   the SPI is the receiving entity's SPI(s).



Section 2.8 does not specifically specify which IKE SA is used (e.g., 
new or old) for deletion of the old IKE SA.  Also, it is not clear
for the responder when to transfer (inherits) all the existing child SAs
from the old IKE SA (e.g., once a new IKE SA has been established or
an IKE Delete Payload is received).

If the old IKE SA is used to delete itself, then a Delete Payload for 
the IKE SA needs no SPI as specified in Section 7.11 above.  Then, the
old SA
needs to be valid for a certain amount of time after re-keying.

If a new IKE SA is used to remove the old IKE SA and a Delete Payload
does not specify SPI (the responder cookie), how is the responder
supposed to know which IKE SA to be removed?

Can somebody clarify on this?
Thanks,

Okhee 
NIST