Hi Tero, > Roman Danyliw writes: > > ** Section 3.2.4. > > > > The responder MUST handle this > > situation gracefully and delete the associated state if it does not > > receive the next expected IKE_FOLLOWUP_KE request after some > > reasonable period of time. > > > > Is there a guidance on the timeout value? > > > > IKEv2 traditionally does not mandate exact timeouts. For example, the > same > > situation happens if the initiator completes IKE_SA_INIT and never starts > > IKE_AUTH. The responder should eventually delete the incomplete IKE SA, > but > > RFC 7296 does not specify how long the waiting time is. > > > > FWIW, our implementations waits 5 seconds by default (which is > adjustable > > value). > > > > Do you think we should recommend (but not mandate) to wait for 5-10 > seconds? > > > > [Roman] A recommended value would help if you are comfortable giving > it, or > > explaining why it’s hard to give one. This is a common question that > comes > > from transport review during IETC LC or IESG review. > > Suitable values can be between few seconds up to few minutes. For > example timeout between IKE_SA_INIT and IKE_AUTH might require user > interaction, thus it might be up to minutes if PIN code to unlock user > auth device is required etc. > > Because the timeouts are so different depending on the environment and > usage scenario we do not give them in the IKEv2 document.
With the IKE_FOLLOWUP_KE exchange user interaction is not a problem (it should not take place). However, since we are talking about PQ algorithms and some of them may be quite costly in terms of generating a key pair, the initiator may just be unable to provide data for the next IKE_FOLLOWUP_KE exchange quickly. So, while I think that several minutes is too long in this case, I agree that timeout values could be very different depending on the initiator's resources and on the algorithm employed. For this reason we didn't specify it. We can give a vague recommendation that waiting for 5-20 seconds can be appropriate in most situations, but definitely we don't want making these values normative. Regards, Valery. > -- > kivi...@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
