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

From: [email-masked] (Henderson, Thomas R)
Date: Tue May 4 21:03:02 2004

OK, here is what we have converged to:

4.1.3 HIP replay protection
    =20
   The HIP protocol includes the following mechanisms to protect against
   malicious replays.  Responders are protected against replays of I1
   packets by virtue of the stateless response to I1s with presigned
   R1 messages.  Initiators are protected against R1 replays by a
   monotonically increasing "R1 generation counter" included in the R1.
   Responders are protected against replays or false I2s by the cookie
   mechanism (Section 4.1.1 above), and optional use of opaque data. =20
   Hosts are protected against replays to R2s and UPDATEs by use
   of a less expensive HMAC verification preceding HIP signature
   verification.

   The R1 generation counter is a monotonically increasing 64-bit
   counter that may be initialized to any value.  The scope of the
   counter MAY be system-wide but SHOULD be per host identity,
   if there is more than one local host identity.  The value of this
   counter SHOULD be kept across system reboots and invocations of
   the HIP signaling process.  This counter indicates the current=20
   generation of cookie puzzles.  Implementations MUST accept puzzles
   from the current generation and MAY accept puzzles from earlier
   generations.  A system's local counter MUST be incremented at=20
   least as often as every time old R1s cease to be valid, and=20
   SHOULD never be decremented, lest the host expose its peers to the=20
   replay of previously generated, higher numbered R1s.  Also, the
   R1 generation counter MUST NOT roll over; if the counter is about
   to become exhausted, the corresponding HI must be abandoned and=20
   replaced with a new one.

   A host may receive more than one R1, either due to sending multiple=20
   I1s (Section 8.4.1) or due to a replay of an old R1.  When sending=20
   multiple I1s, an initiator SHOULD wait for a small amount of time
   after the first R1 reception to allow possibly multiple R1s to=20
   arrive, and it SHOULD respond to an R1 among the set with the=20
   largest R1 generation counter.  If an initiator is processing
   an R1 or has already sent an I2 (still waiting for R2) and it=20
   receives another R1 with a larger R1 generation counter, it MAY
   elect to restart R1 processing with the fresher R1, as if it were
   the first R1 to arrive.

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

6.2.4 R1_COUNTER

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved, 4 bytes                                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | R1 generation counter, 8 bytes                                |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type           2
      Length         12
      R1 generation counter   The current generation of valid puzzles

   The R1_COUNTER parameter contains an 64-bit unsigned integer in =
network
   byte order, indicating the current generation of valid puzzles.  The
   sender is supposed to increment this counter periodically.  It
   is RECOMMENDED that the counter value is incremented at least as
   often as old PUZZLE values are deprecated so that SOLUTIONs to them
   are no longer accepted.

   The R1_COUNTER parameter is optional.  It SHOULD be included
   in the R1 (in which case it is covered by the signature), and if =
present
   in the R1, it MAY be echoed (including the Reserved field) by the=20
   Initiator in the I2. =20

---

From: [email-masked] (Pekka Nikander)
Date: Wed May 5 01:11:01 2004

> OK, here is what we have converged to:

Looks good.

Others, are you happy with Tom's suggested text?

--Pekka

---

From: [email-masked] (Miika Komu)
Date: Wed May 5 08:42:01 2004

> Others, are you happy with Tom's suggested text?

It seemed to be ok.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Petri Jokela)
Date: Tue May 11 08:03:00 2004

> Others, are you happy with Tom's suggested text?

Good text. I will import it into next preliminary version of the draft,
and release the pre-version (unless there comes some arguments against
the proposed text).

/petri