Subject: [Hipsec] max retry counters

From: [email-masked] (Henderson, Thomas R)
Date: Thu Apr 8 10:12:04 2004

Here is what IKEv2 has to say on this issue:

   Numbers of retries and lengths of timeouts are not covered in this
   specification because they do not affect interoperability. It is
   suggested that messages be retransmitted at least a dozen times over
   a period of at least several minutes before giving up on an SA, but
   different environments may require different rules.

Tom

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]=20
> Sent: Thursday, April 08, 2004 3:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Hipsec] max retry counters
>=20
>=20
> Wesley Eddy wrote:
> > The current HIP draft refers to three constants (I1_RETRIES_MAX,
> > I2_RETRIES_MAX, and UPDATE_RETRIES_MAX), but I don't see them
> > defined anywhere in the draft, nor do I see any guidance on what
> > their values should be set to in an implementation in the draft.
> > Their purpose is clear, but whether their values should be 3 or
> > 1000 doesn't seem to be discussed.  What have implementers gone
> > by?  I think there should be some guideline at least.
>=20
> Folks, should we have some kind of rough guideline for the counter=20
> values in the base draft (some limits or other text that gives some=20
> hints what values implementors could select)? Any opinions?
>=20
> /petri
>=20
> --=20
> Petri Jokela                        Tel:    +358 9 299 2413
> Research scientist                  Fax:    +358 9 299 3535
> NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
> Oy L M Ericsson Ab                  email: [email-masked]
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>=20

---

From: [email-masked] (Pekka Nikander)
Date: Thu Apr 8 10:30:01 2004

>>> defined anywhere in the draft, nor do I see any guidance ...
>>
>> Folks, should we have some kind of rough guideline for the counter
>> values in the base draft ...
>

I would agree that the same applies to the base specification.
Opportunistic HIP would probably have fairly aggressive timeouts
and just a couple of retries (or maybe just one or zero), while
in an environment where communication fails if one fails to
create an HIP association it would probably make sense to continue
even after reporting a problem to the upper layers.

--Pekka