Shota Nagayama writes: > Though I replied that fallback mode might be treated as local policy > and not to be negotiated at the beginning of IKE, now I notice a > difference between fallback mode and other local policies, if my > understanding is correct. In current IKE, after establishing the > first SA, the success of rekeying is guaranteed at the configuration > level;
Not true. Other end can simply reject the rekey by sending NO_ADDITIONAL_SAS notification back to the rekey request. RFC7296 section 1.3 last paragraph: The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notification can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. > any difference of local policies which are not shared do not > prevent rekeying the SA. If fallback mode isn't negotiated, when the > system fallbacks, if no fallback method is enabled in both peers, > rekeying gets blocked until QKD succeeds to generate new key. Yes. Just like it does with normal IKEv2 rekey. On the other hand as both ends will KNOW for sure when the QKD has succeeded, there is no need for fallback policy for QKD use. There could be uses for it in the other out of band key distribution methods, as there the state might not be shared between both ends at the same time. In QKD the node will know it has shared keying material with the other end, and if it will know that it will also know that other end has the same key material also... > If fallback mode is negotiated at the beginning, the system may know > whether rekeying in fallback mode be blocked as such or not. Then, > this can be warned to users/system admins before fallback mode is > needed to be operated. So, now I think that fallback mode should be > negotiated at the beginning and it should not prevent initial > establishment of IKE but should be warned. I do not think there is any need for fallback mode to be negotiated. If the peer A is willing to fall back to diffie-hellman then it will try rekeying with diffie-hellman. If other end rejects this rekey with NO_ADDITIONAL_SAS or some other suitable error notification (depending how the actual out of band key distribution is negotiated), then they know there is differences in the policy, thus he cannot rekey. If his policy says it can continue in that case, it will, if not then it will close down the IKEv2 SA, and no more packets are sent/received as specified by the policy. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
