Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

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.

> --
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec