Subject: [Hipsec] Issue 12: Birthday check badly defined

From: [email-masked] (Henderson, Thomas R)
Date: Tue May 4 12:44:01 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Tuesday, May 04, 2004 10:14 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] Issue 12: Birthday check badly defined
>=20
>=20
> Nits below.
>=20
> >    the HIP signaling process.  This counter indicates the current
> >    generation of valid cookie puzzles.  It MUST be incremented at
>=20
> I think the text here really should be "generation(s)" and not
> "generation", to keep it open to the implementations how many
> earlier generations to accept.

It may be more clear to say:  "This counter indicates the current
generation of cookie puzzles.  Implementations MUST accept puzzles
from the current generation and MAY accept puzzles from earlier
generations."

(I don't think that replacing "generation" with "generation(s)"
says this as clearly-- at least, I did not interpret it as you
later elaborated.)

>=20
> >    arrive, and it SHOULD respond to an R1 among the set with the
> >    largest R1 generation counter (where largest is defined by modulo
> >    sequence number comparisons).  If an initiator is processing
>=20
> I find the expression in paranthesis confusing.  In fact, I don't
> understand what you mean, exactly.
>=20

I mean that 0 is greater than 7 when using 3 bits.  Is this understood
implicitly by the term "largest"?  If we allow counter to be initialized
to anything, I think that we need in the spec to handle the case in =
which
it rolls over, or else state that it cannot.

> >    Upon conclusion of an active HIP association with another host,
> >    the R1 generation counter associated with the peer host SHOULD be
> >    flushed.  A local policy MAY override the default flushing of
> >    R1 counters on a per-HIT basis.
>=20
> Perhaps add:  The reason for this RECOMMENDATION is that there MAY
> be hosts where the R1 generation counter (occasionally) decreases,
> e.g., due to system reboots.
>=20

OK, good idea.

> >    The R1_COUNTER parameter is optional but RECOMMENDED.  It MAY be=20
> > included
>=20
> I'd rather say "It SHOULD be included"
>=20

OK

- Tom

---

From: [email-masked] (Pekka Nikander)
Date: Tue May 4 13:05:01 2004

> from the current generation and MAY accept puzzles from earlier

Much better, thanks.

> to anything, I think that we need in the spec to handle the case in 
> which

I think it is best to state that the counter MUST NOT roll over.
If it does, the corresponding HI must be abandoned and replaced
with a new one.  In fact, I didn't even consider the case when
it would roll over, therefore I didn't understand what you were
referring to.

--Pekka