Subject: [Hipsec] Indicating Reply Requested and renaming NES?

From: [email-masked] (Henderson, Thomas R)
Date: Thu Dec 18 21:15:00 2003

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]
>=20
> What do you guys think of combining the transaction ID (as=20
> used by NES) and=20
> the birthday counter into the same base header field? They=20
> seem to have a=20
> pretty much similar semantic.
>=20

In thinking about this and Pekka's posts some more, this=20
option appeals to me if it is made a parameter or part of
an existing parameter rather than base header.

In my view, birthday's primary role is to prevent replay
attacks of packets that are vulnerable to such.  The
main (only?) one seems to be NES.  Note that I am=20
discounting the R1 at this time because, as I've posted=20
before, I am not sure that this is the right response=20
(or if any response should occur) to unknown SPI.  But=20
RESYNCH might also be a candidate for "avoidance of replay".

A host also wants its NES acked.  So it would seem that=20
there needs to be at least a one-bit sequence number of
some sort to identify it.

If we could guarantee that NES sequence number increased
each time, and that there were well defined modulo=20
sequence number comparisons, then a multi-bit number=20
(let's say 16-bit) would be more useful.  This could be=20
defined as "Sequence number" and could be used for both=20
positive acknowledgment when needed and also=20
avoiding replays.

There could be a global sequence number for the host,
(e.g., birthday).  A minor technicality would be that
long running associations on busy servers might need to
do a NES just because the global sequence number has
drifted far enough along that the modulo sequence number=20
comparison of "greater than/less than" will start to fail=20
for a particular association.  If sequence numbers were
maintained per-association, that could be avoided.=20

The overhead of putting it into the base header could
be avoided since it really only pertains to a couple of
packets.

Counter-thoughts?

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 19 06:10:01 2003

Tom,

> In thinking about this and Pekka's posts some more, this

I'm, on the other hand, inclined to think that we most
probably should have sequence numbers in the base header.
That would make the protocol more future proof, i.e.,
I would foresee less complications with future extensions.

I don't see any real need to reflect the birthday value
in all packets.  Since the birthday value is tied to
incarnation of the HIP association, and each incarnation
has a different DH session key (and therefore different
HMAC values), the only case where we need the birthday as
replay protection is in resynching.

> main (only?) one seems to be NES.

Well, using birthday to protect NES replays would
require that you bump up birthday on each NES.  You
are still using the same HIP keys, and therefore the
HIP keys (i.e. the HMAC) does not provide enough of
replay protection.  I would really like to separate
replay protection on incarnation level, semantic
packet level, and retransmission level.  (See below.)

Remember that Bob's original design used ESP sequence
numbers as replay protection in NES.  We removed it
since it would have been very cumbersome to implement
in many cases.

> But RESYNCH might also be a candidate for
> "avoidance of replay".

Resynch would need birthday protection.  As far as
I understand, resynching was the reason why the
birthday value was added to the protocol in the first
place.

> A host also wants its NES acked.  So it would seem that

Yes.  However, just to make the protocol more future
proof, I would prefer to have generic, per packet
sequence numbers.

Let me try to explain my current understanding in detail:

   The main goal of this exercise is replay protection.
   We seem to have potential replay in at least four
   different cases:

    1. A RESYNCH packet could be replayed.  Birthday
       and including a portion of the ESP packet can
       be used to plug this.

    2. A message from an earlier incarnation of a
       HIP association (between a given pair of HITs)
       could be replayed.  The different DH session
       key, together with HMACs, already plugs this.

    3. A message from the current incarnation of the
       HIP association can be replayed.  There is
       currently no generic mechanism for protecting
       against this.

       In his earlier design, Bob re-used ESP
       replay counters.  This is hard to implement,
       and won't work when you have several parallel
       SAs (as in the case of multi-homing).

       Random transaction IDs would work, but would
       be fairly complex to implement right.

       Explicit sequence numbers, included in each
       packet, looks like the most generic and
       simplest solution, at least to me.

    4. An attacker can replay a message to simulate
       message retransmission.  This is not a security
       problem, since messages may get duplicated in
       the network anyway.

Does that sound right?  If so, then it should be
fairly easy to derive design recommendations from
the above.

--Pekka

---

From: [email-masked] (Julien Laganier)
Date: Fri Dec 19 13:02:01 2003

> I would foresee less complications with future extensions.

Agree.

> replay protection is in resynching.

Agree too, thanks to your insight in your previous mail.

> proof, I would prefer to have generic, per packet

Yet another 'agree too'.

>        and including a portion of the ESP packet can

Yes. 

I was thinking to use the ESP SN to do that [but as you stated before, 
It might be (really) hard to implement this without trashing all 
around in the IP/IPsec stack]

>        key, together with HMACs, already plugs this.

Yes, but then I feel we need to emphasize the need for frequent 
rekeying in the spec.

>        simplest solution, at least to me.

Yes. And binding SNs to the initial sending party birthday counter 
might add some security against SN roll over.

>        problem, since messages may get duplicated in

Yep.

> fairly easy to derive design recommendations from

AFAICS, I agree with your analysis, but let's other people speak [if 
they have time to ;-]

Thanks,

--julien