Re: IKE-SA Deletion

[Charlie_Kaufman@notesdev.ibm.com]

> Thank you for the response.
> Deletion of the old IKE SA would work fine as you explained.
> So, I assume that all the child SAs from the old IKE SA are
> transfered to the new IKE SA when the negotiation is complete.
>
After a new IKE SA is negotiated but before the old one is
deleted, I would expect notifications, deletions, and creations
of child SAs could occur on either the old or the new. I would
not expect anyone to do this on purpose, but as with rollover of
an ESP SA, accepting messages on either channel but sending only
on the new one provides robustness in the case where network
delays cause out of order delivery.

>
> I would like to ask another question:
>
> After the new IKE SA inherits all the child SAs from the old SA,
> how are the message IDs assigned to those child SAs handled?
> Should the original message IDs continue to be used or
> new message IDs from the new IKE SA should be reassigned to
> those child SAs?
>
The message IDs are sequence numbers associated with the IKE SA, and
the number is reset to zero when a new IKE SA is negotiated.
References to child SAs in IKE messages are always by child SA SPI.
These would not change when the IKE SA is replaced.


> If the original message IDs of the old child SAs are retained,
> the conflict of message ID between two (one of the old child SAs and
> a newly created IKE message) could occur (may have the same message ID).
> It may not happen in a real world, but it could happen in theory.
> This may affect interoperability in the future.

The child SAs also have message IDs/sequence numbers whose processing is
specified in
ESP and AH. Those would not be affected by the IKE SA rekeying. A new IKE
SA with new keys
will repeat the message IDs of the old IKE SA, but there is no ambiguity
because those numbers
are only unique within an SA.


          --Charlie Kaufman

This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.