[IPsec] ikev2bis issue #184: Interaction of rekeying of the IKE_SA and windows

[Tero Kivinen <[e-mail]>]

Paul Hoffman writes:
> s2.3: Should there be some discussion of the interaction of rekeying
> of the IKE_SA and windows?

We already have text about that in the section 2.8 and section 2.25
Exchange Collisions.

> Presumably a rekey message should not be actioned until all previous
> messages have been responded to.

Depends about the message. I.e. if peer receives request to create or
rekey Child SAs when it is rekeying IKE SA it should reply with
TEMPORARY_FAILURE. If it receives requiest to delete child SA, it can
go on normally.

Note, that rekeying IKE SA does not mean that the old IKE SA is
deleted immediately, it can still (and usually will stay) there for a
moment, before it is deleted, and will be deleted as separate
exchange. 

> Likewise receiving a Message ID with a sequence number bigger than
> that in the rekey message should be very suspect!

You mean getting first rekey request and then some other request on
the same IKE SA? Yes, that is something that should not happen, but is
not explicitly forbidden. It cannot really create or rekey IPsec SAs,
as it does not know to which IKE SA those IPsec SAs belong to.
Rekeying moves those IPsec SAs from old IKE SA to new IKE SA, and
depending when other end processes the rekey message, this move might
already happened or it might be still in progress.

Deleting IPsec SAs is possible, but not advisable. Other messages like
DPD should be processed as normally, and there is no problem there.

> Should the INVALID_MESSAGE_ID notification be sent
> in this case (and before or after the rekey?)

No. The message ID is not invalid, as it is not outside the window,
thus this error message cannot be sent. The responder can fail those
request with various error messages, like TEMPORARY_FAILURE,
CHILD_SA_NOT_FOUND, or NO_PROPOSAL_CHOSEN depending on the request and
how the other end processes messages.

> There might be some knock on into s2.8 where rekeying is discussed.
> And maybe into s2.25?

This is mostly covered by 2.25, altough I do not think we explictly
say that initiator cannot send any new exchanges after it started IKE
SA rekey. It is just assumed that it does not do that... The 2.25
mostly covers cases where the other end starts exchanges after
one end has started IKE SA rekey, as this is something that the end
starting IKE SA rekey cannot control. 
-- 
[e-mail]