[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISAKMP Draft 10
W. Douglas Maughan wrote:
>
> Sumit,
>
> > The General Message Processing section of draft 10 (section 5.1) has the
> > following regarding how an implementation is supposed to set the
> > retransmission timer:
> > NOTE: Implementations MUST NOT use a fixed timer. Instead,
> > transmission timer values should be adjusted dynamically based on
> > measured round trip times. In addition, successive retransmissions
> > of the same packet should be separated by increasingly longer time
> > intervals (e.g., exponential backoff).
> >
> > How and why has this been added to the draft? I don't recollect it being
> > discussed on the mailing list. This is an implementation detail. The draft
> > should only suggest a scheme, not make one a requirement.
>
> This was added to the ISAKMP-10 I-D because of Thomas Narten's IESG
> vote. Basically, it was added so we can get the documents accepted to
> RFC. The wording was exactly as he proposed it. As I see it, the text
> as presented gives a suggested approach, i.e. dynamically adjusted
> using exponential backoff. That is not part of the requirement. The
> requirement is "MUST NOT use a fixed timer".
>
> On another note, I asked Ted to send the list of ISAKMP-10 changes to
> the IPSEC list after the I-D was announced. I'm just returning from
> vacation and I haven't seen it, so attached is a list of all changes
> made to the ISAKMP-10 Internet Draft.
>
> Regards,
>
> Doug Maughan
>
Measuring round trip time has little meaning in ISAKMP. The time to
process every ISAKMP packet can vary allot, for example in main mode
with signatures, it can be very quick to answer the first message, two
answer the third message may require to generate a DH key, which is a
longer operation (but implementation may start to compute it after the
answer to the 2nd message and have it ready). Then when it comes to
answer the 5th message it must do RSA computation, it may need to look
at LDAP servers for CRLs, maybe several levels of CRL, it can be quite a
long operation. Implementation that will try to estimate the expected
return from the measured round trip times in the same negotiation will
be way off.
I suggest to, at least, replace "measured round trip times" with
"expected return time".
Moshe
--
-----------------------------------------------------------------------
Moshe Litvin Check Point Software Technologies Ltd.
moshe@checkpoint.com Tel: +972-3-753-4601 (972-3-753-4555)
Fax: +972-3-575-9256
-----------------------------------------------------------------------
References: