Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4

From: [email-masked] (Henderson, Thomas R)
Date: Thu Jan 29 11:36:01 2004

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]=20
> Sent: Thursday, January 29, 2004 3:42 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4
>=20
>=20
> Henderson, Thomas R wrote:
>=20
> >>the SA. The
> >>    RESYNC bit in the I1 packet is set to indicate the peer=20
> about the
> >>    possible state loss.
> >=20
> >=20
> > I would prefer to make the above a "MAY" (initiate a new exchange).
> >=20
> > Does it make any difference to the peer whether I1 has RESYNC set or
> > not?  (does it cause any different behavior?).  Maybe rather than
> > RESYNC bit, we should allow for "Unknown SPI" parameter to be
> > included in the I2.
>=20
> I don't know what the host in ESTABLISHED state would gain from the=20
> RESYNC bit.
>=20
> What about the case when hosts A and B do not have any=20
> association. The=20
> host C sends ESP packets to B with A's source IP address. The B would=20
> then initiate a connection to A with an I1 (if host B=20
> considers that ESP=20
> packets may belong to a lost association). The A responds with R1,=20
> thinking that someone is trying to establish a connection.=20
> Thus, we end=20
> up with an SA that neither A nor B needs.

I agree that this should be avoided.  It is easy to envision
how this could occur in certain mobility scenarios.

>=20
> If the I1 contains a RESYNC bit, the A could just drop the=20
> packet. (Or=20
> R1 could include also a RESYNC bit. A responds with R1 without RESYNC=20
> bit, saying "I don't have any association, but feel free to=20
> continue if=20
> you want." and from that B would notice that something is wrong.)
>=20

Yes, you are right, this is probably needed.  But notice that it
requires more work for the responder A (cross-check the incoming
I1 against its list of security associations) than what we have
previously specified for the responder, in order to avoid
a DoS reflection attack on B. =20

Including an "Unknown SPI" field in the I1 and R1 would probably=20
help A evaluate the best course of action.  If the SPI is fake,
generated by C, A can check whether it should ignore or reject=20
the I1 (A may actually have an active SA to B on another SPI).

Maybe we need an explicit reject to notify B in this case, rather
than silently dropping when mischief is detected, to preempt I1
retransmissions?  It seems unfortunate that a rogue packet can=20
trigger a two-packet exchange and some work between A and B,=20
but that is probably an unavoidable consequence of the attempt=20
to respond to an "unknown SPI" packet that itself cannot be=20
authenticated up front.  That is why I would like to not make this
a mandatory response, because we may find that it is abused
in practice.

Tom