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
