Subject: [Hipsec] Moving resynch into a separate draft?

From: [email-masked] (Henderson, Thomas R)
Date: Mon Feb 2 09:48:01 2004

I agree also that resync could be moved outside until it is
more mature.

I think that we will have a hard time defining a mechanism
responding to unknown SPIs that doesn't result in some DoS
vulnerability.  However, many of these can be reasonably
limited when processing unknown SPIs by either configuring
policy rules on them (or blocking the response to them
altogether), or if a host takes care to check "uptime" and=20
throws away these packets if the daemon has been running=20
for some time.

> -----Original Message-----
> From: Jan Mikael Melen [mailto:[email-masked]]=20
> Sent: Sunday, February 01, 2004 11:34 PM
> To: Pekka Nikander; [email-masked]
> Subject: Re: [Hipsec] Moving resynch into a separate draft?
>=20
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Hi!
>=20
> On Sunday 01 February 2004 14:07, Pekka Nikander wrote:
> > Given that getting the resynch design seems to be hard,
> > and that it seems that we need some extensions (Unknown SPI)
> > for the resynch packets anyway, I would suggest moving
> > resynch into a separate draft in -10.  (Let it stay for -09,
> > since it is already there, and it might be good to get some
> > implementation experience.)
> >
> > IMHO, that would allow easier discussion in the WG, and
> > would allow the base draft to proceed faster.
> >
> > Opinions?
>=20
> I would also like to see the resynch in separate draft due to=20
> that it seems to=20
> more complex than what one would expect. Here is one example=20
> what kind of=20
> problem scenario I have played around:
>=20
> If host-A receives a ESP packet containing unknown SPI.=20
> Host-A will send a I1=20
> with  resynch bit true. Now if the host-C wants to be nasty=20
> it can send ESP=20
> packets containing random SPIs from random src addresses and=20
> the host-A will=20
> respond with I1 to these packets.=20
>=20
> Now if the host-C wants to spend the CPU cycles of host-A=20
> instead of just=20
> sending ESP packets it can also send afaik R1 packets (those=20
> of course have=20
> to match with the faik ESP packets). Now host-A thinks that=20
> it has received a=20
> ESP from unknown SPI, host-A has sent a I1 and gotten a R1=20
> back as response=20
> to the I1. Host-A starts to process R1 and spends some cycles=20
> on solving the=20
> puzzle and in creation of I2 packet.
>=20
> Now there is a possibility to solve CPU exhausting problem by=20
> limiting the=20
> amount of ongoing HIP negotiations but still the host-C can=20
> make sure that=20
> host-A has the maximium number of HIP negotiations going on=20
> all the time.
>=20
>    BR. Jan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
>=20
> iD8DBQFAHf1jp4iklvjQtTgRArCiAJ9yBM4sivjcz7g6Pg4CjxqS54yeeQCcDm7v
> zoNPWVuUWd1s/Z/hQOckqCE=3D
> =3DWubC
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
>=20

---

From: [email-masked] (Petri Jokela)
Date: Tue Feb 3 00:16:02 2004

> I agree also that resync could be moved outside until it is

Ok, it seems that people do not oppose this proposal. In that case, I 
will remove it from the base draft (after -09 and Seoul) and we can put 
it into a new one.

/petri

> altogether), or if a host takes care to check "uptime" and 
> throws away these packets if the daemon has been running 
> for some time.
> 

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]