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

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

>=20
> I don't see any issues with vastly different counters.  The=20
> smaller one
> is just very old replay.

So long as we do not roll over the counter, there is no ambiguity.
64 bits should pretty much guarantee that.

Here is a proposed revision, based on your comments (thanks).  Note
that I made it non-critical this time around (Type=3D2):

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 valid cookie puzzles.  It 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 implementation expose its=20
   peers to the replay of previously generated, higher numbered R1s. =20

   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 (where largest is defined by modulo
   sequence number comparisons).  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.

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(s) 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 but RECOMMENDED.  It MAY 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: Tue May 4 12:23:01 2004

Nits below.

>    the HIP signaling process.  This counter indicates the current
>    generation of valid cookie puzzles.  It MUST be incremented at

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.

>    arrive, and it SHOULD respond to an R1 among the set with the

I find the expression in paranthesis confusing.  In fact, I don't
understand what you mean, exactly.

>    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

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.

>    The R1_COUNTER parameter is optional but RECOMMENDED.  It MAY be 
> included

I'd rather say "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
>    Initiator in the I2.

--Pekka