Subject: [Hipsec] Cookies

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

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Friday, March 19, 2004 5:59 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] Cookies
>=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.
> >>
> >
> > 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.
> >
>=20
> Cookie generation itself is pretty cheap, no? Isn't the signature
> generation the computationally expensive part for the responder?

Yes, although there seems to have been consistent goal to make R1
independent of the I1 (I seem to remember some discussion of this
on the old freeswan HIP list, but I don't know where that is archived
anymore.  Maybe someone else can remember or chime in.)

>=20
> 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.
>=20
> Perhaps a concrete proposal would help to clarify
> my (perhaps confused) thinking:

OK, so I think I understand better, you are proposing:
i) move cookie outside of signature
ii) make "I" verifiable and initiator-specific, as alternative to=20
managing R1s

And whether a responder does anything with I value (making it tied
to initiator, or just a random string) is implementation-specific
and up to the responder.

Unless there is some reason not to move it outside signature, it
seems to me that your proposal is more flexible, because it would
allow either approach.

Tom