Tero Wrote:
> 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.
I'm not sure this makes RFC4718 incorrect. It just makes it incomplete.
> 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.
I do not like that RFC 4718 used NO_PROPOSAL_CHOSEN as the indicator that
a rekey is being rejected because there are outstanding requests. To me
a new notify would have made sense. Given that RFC 4718 did use
NO_PROPOSAL_CHOSEN it seems to me that when HOST A is rekeying
the IKE_SA it should assume the peer is busy when it receives
NO_PROPOSAL_CHOSEN and should continue to attempt to periodically rekey
the IKE SA again.
I do not agree that when Host B receives NO_ADDITIONAL_SAS that it
should retry the operation using the same IKE SA. As such I do not think
there is a live lock state. What should be done is up to the
implementation. An implementation could assume the other end is in the
process of rekeying or deleting the IKE SA and delay taking any action
or it could take immendiate action. If it takes immediate action it
would need to do so on a new IKE SA.
> 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.
I think it is appropriate to add this to the new draft. If you are
concerned about the lock state then a warning should be added stating
that when you receive NO_ADDITIONAL_SAS that you should not attempt to
retry that operation on the same IKE SA, although that seems
self-evident.
> 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).
I'm not convinced it is broken, I'm just convinced that if you
attempt to retry an operation on the same IKE SA that you received
NO_ADDITIONAL_SAS on that you can get into a lock state. To reduce that
concern we can come up with a new REKEYING_IKE_SA notification, but that's
likely to cause problems with old implementations, so better to stick with
what RFC 4718 proposed.
> 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.
You can never guarantee you are going to get a response back to a
request. I do not see what makes this situation any different.
> As the RFC4718 text can make situatuation much worse by causing live
> lock, I think that solution proposed there isn't usable as is.
I do not agree.
> 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).
Everything in RFC 4718 is allowable in 4306. Both proposals may require
an implementation to change their processing. I do not think these
proposals are incompatible.
> 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.
Agreed
> 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.
I agree that there is nothing that says you cannot wait to delete the
IKE SA. I do not agree that it is the only way to handle the situation.
I think what is in RFC 4718 can work.
>
> 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 understand that RFC 4718 is just one proposal, but it's one that I
expect some vendors tried to implement. I doubt there are many that are
currently delaying the deletion of the IKE SA.
> 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'm not convinced yet that RFC 4718 is broken or at least that it cannot
be made to work.
> 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.
Agreed, but I still think delaying the deletion is at most a MAY.
Dave Wierbowski
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
