Subject: [Hipsec] Cookies

From: [email-masked] (Henderson, Thomas R)
Date: Fri Mar 19 18:56:01 2004

Jon,
responses inline below.

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Thursday, March 18, 2004 6:11 PM
> To: [email-masked]
> Subject: [Hipsec] Cookies
>=20
>=20
>=20
> Hi.
>=20
> 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.
>=20
> A quick recap on the SCTP method:
>=20
> 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).
>=20
> 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.
>=20
> This approach would be simpler to implement, I think,
> than the current mechanism, and would allow
> implementors greater flexibility to do interesting things.

The puzzles allow the responder to control a certain amount
of DoS resilience.  I believe that the design was motivated by
work described in:
http://research.microsoft.com/users/tuomaura/Publications/aura-nikander-l=
eiwo-protocols00.pdf
>=20
> 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.
>=20

The responder should limit the number of times (once?) that it
responds to the same cookie solution (solutions are supposed
to be generated randomly).  The responder can set the cookie
difficulty (perhaps based on recent history of failed signatures)
to guard against an attacker trivially churning out lots of=20
solutions.

> 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?
>=20
> 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.
>=20

Well, it could be done that way, at the cost of having to do
the cookie generation upon sending the R1, and losing the ability
to force (control) initiator to pay computational cycles to get its
packets processed.

Tom

---

From: [email-masked] (Jonathan Wood)
Date: Fri Mar 19 20:13:01 2004

Hi Thomas,

> responses inline below.

<...>

> http://research.microsoft.com/users/tuomaura/Publications/aura- 
> nikander-leiwo-protocols00.pdf

Sorry if I wasn't altogether clear - I have no doubts about
the value of puzzles for enhancing DOS resilience. My questions
focus on how the responder can verify that an I2 is indeed
a valid response to the responder's R1.

> to guard against an attacker trivially churning out lots of
> solutions.
>

Cookie generation itself is pretty cheap, no? Isn't the signature
generation the computationally expensive part for the responder?

I am concerned about the complexity required to implement a
really robust, industrial strength system to manage R1s. I think
that keeping histories of failed signatures, failed puzzle solutions,
and replayed puzzle solutions will be tricky to get right.

Perhaps a concrete proposal would help to clarify
my (perhaps confused) thinking:

Add a variable or fixed- length field to the cookie TLV (let's call it
the Responder Chunk). The responder can put whatever it wants
in it, and the initiator must return it without modification.

The signature does not cover I, K, or the Responder Chunk, allowing
the hard part of R1 generation to be precomputed.

One way the responder could use the Responder Chunk is as
follows:
Create a secret, and change it every minute or so. Remember the
last secret as well.
For each I1, generate I (or maybe pull it from a block of pre-computed
Is), and place it in the R1 cookie. Generate K based on some measure
of the responder's current load.
Combine the secret, initiator's IP address, HITs, I and K, and the  
secret
using some method that is computationally trivial, and place the result
in the Responder Chunk.
On receipt of an I2, combine the parameters as described above, and
check the result against the value in the Responder Chunk. If it doesn't
match, try using the old secret, and if that doesn't match, drop the I2.
If it does match, continue by verifying the puzzle, and so on.

As far as I can see, this would eliminate the need precompute multiple
R1s and manage them as described in 4.1.1 and Appendix D.

Regards,
Jon