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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
