David Wierbowski writes: > >I do not think there is any other way than to wait some time to get > >them finished (or at least failed and acked). The other end who > >started those outstanding exchanges MUST know whether they were > >processed or not. If IKE SA is deleted immediately there is no way > >other end can know that as after IKE SA is deleted the other end does > >not send ACKs back. > > RFC 4718 states:
RFC4718 is informational and tried to clarify things which are not clear in RFC4306. Now we are writing standard track document when revising RFC4306 and in that case we can even change things specified in RFC4306, if needed. In this case I do not think we need to change things from RFC4306, but I think the text in RFC4718 is not correct as it does not consider the case completely. > It seems this situation is tricky to handle correctly. Our proposal > is as follows: if a host receives a request to rekey the IKE_SA when > it has CHILD_SAs in "half-open" state (currently being created or > rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host > receives a request to create or rekey a CHILD_SA after it has started > rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. This solution might cause peers to stay in live lock state, causing the whole IKE SA to be unusable. I.e. host A starts IKE SA rekey and host B starts Create Child SA. Host B replies NO_PROPOSAL_CHOSEN to host A's IKE SA rekey, and Host A replies NO_ADDITIONAL_SAS to Host B's Create Child SA request. Both ends process replies, and notices they failed, thus both start again, causing both ends to be trying these operations as fast as they can. This situation will stay as it is unless something kicks hosts out of sync. Or returning NO_ADDITIONAL_SAS might cause other end to delete the whole IKE SA and start from scratch. > If you have outstanding requests to rekey a CHILD SA when you get > a request to rekey the IKE SA you should respond with > NO_PROPOSAL_CHOSEN. This is not in RFC4306, this is just one proposal given in RFC4718 which might be used, but as I noted above, it can cause live lock loop, thus it is not really acceptable. > Given that is seems reasonable that you would not > start the rekey of an IKE SA while you have outstanding requests to rekey > a child SA, but if you did then it would make sense that you'd delay > sending the delete request associated with your own successful rekeying > of the IKE SA until those outstanding requests have been responded to. > > If you follow 4718 the only request you can have outstanding when you > send a non-error response to an IKE SA rekey request is your own request > to rekey the IKE SA. The proposed solution in RFC4718 does not really work, so I do not think we should include that to RFC4306 (yes, I know I should have noticed this when RFC4718 was being processed not now, but better now than never). > >Not really. The RFC4306 do say that you MUST be able to process > >incoming requests while having your own requests out: > > > >2.3. Window Size for Overlapping Requests > >... > > .... An > > IKE endpoint MUST be prepared to accept and process a request while > > it has a request outstanding in order to avoid a deadlock in this > > situation. An IKE endpoint SHOULD be prepared to accept and process > > multiple requests while it has a request outstanding. > > > I see nothing in this text that says you must delay deleting the IKE SA > or accept new requests on an IKE SA that you've rekeyed. That is what > you wish to do and that is a protocol change. The text above implies that regardless what you do you should be able to allow other end to start exchanges and process them. I.e. IKEv2 protocol tries to be specified in such way that both ends can start exchanges at any times and expect them to either fail or succeed and get reply back, but not stay in situation where you do not know, whether other end processed your request or not. If you delete the IKE SA immediately that will happen. > >I.e. when you have REKEY started and even when the rekey itself has > >finished, and delete request sent out (and even replied), you still > >might receive requests from the other end which were started before > >the REKEY was started. > > If RFC 4718 is followed the only outstanding create child request that > can be received is a request to rekey the IKE SA. There is little > value in waiting for this. When the peer receives the request to > delete that IKE SA it will know one of two things happened. As the RFC4718 text can make situatuation much worse by causing live lock, I think that solution proposed there isn't usable as is. > As I said above there are only 2 reasons for getting the delete, so > strike the most likely from my original text. If RFC 4718 is followed > the receiver of the delete request can deterministically conclude that > any outstanding create child requests will fail. In addition, the only > outstanding create child request possible in this case is one to rekey > the IKE SA. Informational RFC 4718 proposes much bigger change to the standard track RFC 4306 than what I want to do and also the solution has problems which needs to fixed first before it can be taken to IKEv2bis. I would propose much smaller change to the RFC4306, which says that wait a while before deleting the IKE SA after successful rekey so that exchanges from other end has time to finish before deleting the IKE SA. Those exchanges happening after the IKE SA was rekeyed should either be failed or if they are processed, they should be processed in such way that they are done on the Child SAs which are already moved to new IKE SA (i.e. creating IPsec SAs or rekeying IPsec SAs should be failed, and deleting IPsec SAs should be processed, so that IPsec SAs is deleted from the IKE SA where it was moved to). > >The RFC4306 says what you need to do when you see simultaneous rekey, > >and it only gives you one option: Check for the nonces. The rekey is > >simultaneous, if either end detects it was simultanoues, it is > >completely possible that other end didn't notice it. > > RFC 4306 does not say that. RFC 4306 never uses the term simultaneous > rekey. What it does say is: > > If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. > > If only one host detects the simultaneous rekey then redundant SAs > are not created. By adding a timer to delay sending the delete you > are going out of the way to try to create redundant SAs. That is not my reading of the text. But I think it is bit pointless to argue about this text as I think we can only agree that it is not clear. There is nothing there in RFC4306 to say that you cannot wait after doing rekey of IKE sa, and as that is only way to properly and cleanly process other ends exchanges to end before deleting the SA, that is what implementation should do. If that cause redundant SAs to be created then then we do have those and we need to check nonces to check which of them should be deleted. The RFC4718 text is NOT in RFC4306, that is one (broken) proposal to try to solve this problem. The text in RFC4718 even says "Our poposal is at follows" which would indicate that it was not really meant to be final protocol for that case. > I suspect that many vendors did what we did with regards to RFC 4718. > We implemented what RFC 4718 suggested. RFC 4718 was the starting > point for the IKEv2bis work. I see no reason to reinvent solutions > contained in RFC 4718. Mostly that is true, but we should not include broken proposals from RFC4718 to IKEv2bis, but instead we should try to find solution that works. > I do not agree that we should encourage people to go out of their way > to detect a simultaneous IKE SA rekey. I'm fine with allowing an > implementation to do that. I think MAY is the correct way to go. Implementation needs to still have the code that detects the simultaneous rekey, and other end might still use this delay, thus you need to be able to cope with the case where this happens. Implementations need to be able to handle both cases regardless whether we use SHOULD or MAY, only thing that is different is whether they allow other end finish exchanges or not. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
