Subject: HIP resynch (was RE: [Hipsec] Indicating Reply Requested and renaming NES?)

From: [email-masked] (Henderson, Thomas R)
Date: Tue Dec 30 11:06:01 2003

>=20
> But maybe I am missing something?
>=20
> --Pekka

I feel this way regarding this discussion.  Maybe we
are all operating under different assumed requirements.

As I've said, I'm not even sure of the requirement that
a host respond to an unknown SPI with a HIP message.
This seems to me to be a "MAY," if at all, with caveats
that hosts should take care in some way to avoid mixing
HIP SAs with IKE or otherwise negotiated SAs (how?). =20
So I think that the first step should be to decide=20
whether the receipt of an unknown SPI=20
(MUST|SHOULD|MAY|SHOULD NOT|MUST NOT) trigger a=20
HIP resynchronization attempt.=20

Anyway, it seems to me that any host that is sending
some kind of resynch message is playing the role of an
initiator, not a responder.  So why not use a HIP exchange=20
(I1-R2), which is already designed to be more DoS-resilient
for responders?  As I mentioned, there could be a resynch=20
bit in the control field, which has the semantics in the=20
I1 of meaning "I think I might have lost my state, so=20
if we succeed in this handshake, please delete any=20
pre-existing HIP SA pertaining to me."  The resynch
bit also might trigger a harder cookie puzzle if=20
desired, to thwart possible attacks.

> > Can you elaborate an attack on Resynch if it follows
> > the below procedures, *not* using birthday?
> >
> > Resynch I1 ->
> > <- R1
> > Resynch I2 ->
> > <- R2
> >    (responder regenerates R1s)
>=20
> You have to explain your thoughts in more detail before
> I can say anything about it.

My thinking is that if one changes the R1s frequently enough,
there is immunity to replay attacks, and birthday is
not needed.  Replay of I1s is not a big deal.  Replay of I2s
is more of a concern, but that is only possible if there is
a match on the cookie puzzle.

Tom

---

From: [email-masked] (Andrew McGregor)
Date: Wed Dec 31 17:01:02 2003

--On Tuesday, 30 December 2003 8:42 a.m. -0800 "Henderson, Thomas R" 
<[email-masked]> wrote:

> HIP SAs with IKE or otherwise negotiated SAs (how?).
> So I think that the first step should be to decide
> whether the receipt of an unknown SPI
> (MUST|SHOULD|MAY|SHOULD NOT|MUST NOT) trigger a
> HIP resynchronization attempt.

I'd like to see MAY, with SHOULD by default.  I've been doing a lot of 
embedded work, and we can lose state very easily (we have paranoid hardware 
watchdogs and no mass storage; all quickly changing state is in RAM).

> initiator, not a responder.  So why not use a HIP exchange
> for responders?  As I mentioned, there could be a resynch
> bit in the control field, which has the semantics in the
> I1 of meaning "I think I might have lost my state, so
> if we succeed in this handshake, please delete any
> bit also might trigger a harder cookie puzzle if

That makes a lot of sense.  I've been lurking in this discussion, and it 
seems to have been generating some really complex ideas for what seems to 
me to be little benefit, whereas this is a nice, clean and simple solution.

> a match on the cookie puzzle.

Makes sense to me.

---------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet-technologies.com/