David Wierbowski writes: > I disagree with this "simplification." Tero's logic is that this does make > sense in some cases (e.g. his case), so let's disallow it. As Scott Moonen > pointed out, there are cases where it is perfectly valid to expect either > endpoint to send the next packet and cases where it makes sense that either > endpoint can initiate the creation of an IKE SA.
As I explained that if both ends can initiate the creation of the IKE SA, then QCD is not needed as both end can simply recreate the IKE SA immediately (with INITIAL_CONTACT notify) when they are up and running (or when they receive first unknown ESP packet from the configured peer). This is simple and already specified by the IKEv2, so no new code is needed. > I see no reason to restrict who can be a token maker and a token > taker. IMHO, Adding this restriction just reduces the potential > effectiveness of the solution. I do not agree on that, as I cannot really see any cases where it might be more efficient than simply recreating the IKE SA (or do IKE SA resume) immediately when peer is up again. QCD will simply add one extra round trip (or half a round trip in case of other end sending unknown ESP first) to recovery process compared to starting directly with IKE SA creation or recovery. I.e. if both ends are able to recreate the IKE SA this is not needed, it is just wasting resources and slowing down the recovery. QCD is useful in situation where the peer cannot initiate, but must tell the other end to remove old IKE SA and start creating new one (or start doing IKE SA recovery). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
