Subject: [Hipsec] Cookies

From: [email-masked] (Jonathan Wood)
Date: Thu Mar 18 20:26:00 2004

Hi.

I'm getting familiar with HIP, and I was wondering
about the design rational behind the way cookies
are currently defined. I am curious why something
like SCTP's cookie method wasn't chosen.

A quick recap on the SCTP method:

SCTP cookies contain a chunk ("State Cookie") filled
in by the responder. This chunk is opaque to the sender,
who must return the chunk unchanged. The responder
can use a secret and a MAC to trivially verify that the
sender is the same host that initiated the exchange
(among other things).

It seems like this sort of mechanism could easily be
applied to HIP R1 / I2 exchanges - the responder
could use it to verify that the sender is that same host
that sent the I1, and that the puzzle I is the same that
was propose in the R1.

This approach would be simpler to implement, I think,
than the current mechanism, and would allow
implementors greater flexibility to do interesting things.

Another issue I see with the current mechanism is that
the puzzle I is precomputed, since it is protected by
the signature presumably. This means that an attacker
can solve the puzzle once and then try to pound the
responder by forcing it to do lots of work verifying signatures
and such. This window of opportunity for attack lasts for
the lifetime of the precomputed cookie.

The root problem here seems to be that I is protected by
the signature, so responders can't hand out a new I in
each R1. So just how important is it that the I is protected
by the signature?

If the I doesn't need to be protected, we could do something
like TCP syn cookies, where we can select a special I by
combining it with a secret and the IP addresses  and HITs -
this would achieve the same result as SCTP-style opaque
chunks and also prevent attackers from replaying solved
puzzles.

Any insights would be appreciated!

Thanks,

Jon