Yoav Nir writes: > I agree that the draft in its current form glosses over the fact > that the missing IKE exchanges did something, like setting up a > child SA, or tearing one down. I don't believe there is any way you > can set up a cluster so that this never ever happens. You can make > it rare, but not completely eliminate it.
It does require bit more implementation effor to make them so that they never happen (but that causes bit more traffic on the sync channel as the active node needs to know whether standby received its sync message before it can send IKEv2 message back). On the other hand there is no reason to completely eliminate that, making it rare is enough (i.e. assume that majority of the sync channel traffic is going through and there is no need to get ack from other end before continuing IKEv2 exchange). > When this does happen, we have two things we might prescribe. We can > detect this and delete the IKE SA along with all associated child > SAs, or we can try to recover. > draft-kagarigi-ipsecme-ikev2-windowsync takes the latter way. draft-kagarigi-ipsecme-ikev2-windowsync does not try to recover, it just skips over the problem. It could provide a way to detect this, i.e. it peers could quickly check the message ids and check whether they missed some IKEv2 messages and if so they could do something (for example delete that IKEv2 SA directly just to clean up state quickly). > To get recovery actually working we need some more "stuff". I think we need quite a lot of more stuff, if we really want to recover fully for those lost messages. > We need to accept this case of mis-matched states between peers, and I would rather not accept the mis-matched state. I would rather clean up those messed up IKE SAs and recreate them to get the state matching than trying to make protocol trying to recover from messed up state. > work towards making them better matched, by allowing an > implementation to inform its peer that the SA that is using is > unknown - an obvious thing is to send an INVALID_SPI notify in an > INFORMATIONAL exchange, That is one option, but I think the draft needs to add text explaining how to handle cases where: 1) Peer did IPsec SA delete, which active member answered, but which got undone when standby member took over. 2) Peer did IPsec SA Create Child SA, which active member answerd, but which got undone when standby member took over. 3) Peer did IPsec SA rekey, which active member answered, but which got undone when standby member took over. 4) Peer did IKEv2 SA rekey, which active member answered, but which got undone when standby member took over. Then exactly same cases where the active member started those negotiations and peer responded, but then change got undone when standby member took over (there are cases where there is difference depending who started operation, for example in the rekey case the initiator is supposed to delete the old SA, so if the crashed active member started that the standby member will not continue that operation even when peer expects that to happen). > or maybe add a DELETE_ALL_CHILDREN > notification. That would be about the same than deleting the IKEv2 SA, except deleting IKEv2 SA also takes care of other configuration data like configuration payload information (virtual addresses etc). I would suggest it would be better to just delete the whole IKEv2 SA than to create another protocol extension to delete all IPsec SAs. > The draft will need text that discusses how this actually converges > in a matched IKE SA. > > It should be noted (in the draft!) that this changes some > assumptions about IKEv2 state. Yes. I would except that going through all those cases and explaining what will happen to them and how they are supposed to work takes several pages (in IKEv2bis we have about 3.5 pages of similar text (simultaneous rekeys and exchange collisions sections)). As that is also going to require implementations I would really hope if this IKEv2 SA window sync part is ever defined it will made optional so it can be left out. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
