Subject: [Hipsec] Problems with resynching

From: [email-masked] (Pekka Nikander)
Date: Fri Dec 12 03:03:01 2003

I am starting to feel that there are indeed quite a lot
of problems with the resynching idea.  My current opinion
is that either we should drop it (as Tom suggests) or we
really need to spend some serious work on getting it right.

The problems start from the very beginning.  Just sending
an R1 when one receives an unknown SPI is not quite enough.
We have to remember that anyone can trigger a host to send
and R1.  It looks also plausible to assume that anyone can
trigger a host to bump its Birthday count.  (Even if that
would be impossible right now, we should not rely on such
an assumption.)  Hence, an attacker can contact a host,
make it to bump up its Birthday count, and get an R1.  It
can then later send this R1 to another host, making it to
start the resynchronization process.

There is a fairly easy way of plugging this problem.  We
just adopt a new packet, RESYNCH, as Tom suggested, and
include the ESP packet that triggers the resynching into
this packet.  Obviously, the included ESP packet cannot
be covered by the signature.  Now the host that sent
the ESP packet can verify that the RESYNCH is sent in
response to some data that it sent.  It still cannot be
sure whether the RESYNCH was sent by the real peer or
someone on the path, though.

It's a good question whether the RESYNCH should just contain
the triggering ESP packet or whether it should be similar to
R1.  Including the R1 fields would save one round trip time.
But is that worth the effort and complexity?

And then there are those fundamental questions that Tom
asked about the overall sanity of the resynch idea:

> i) it has been stated that IPsec has made a conscious
> decision not to respond to unknown received SPIs by
> rekeying.  Why do we do something different with HIP?
>
> ii) if we decide to respond to unknown SPIs, how do we
> know whether the SPI corresponds to a HIP or an IKE SA
> if both daemons are running?

The next question is that if someone can trick a host into
the resynching state, how should the peer react?  Clearly,
if the peer is still running fine, there is no need for the
resynch, and unnecessary resynch would open a DoS vulnerability.

The easiest way seems to be continuing to send ESP data, and
using fresh ESP data as an indication that resynching is not
needed.  Julien's state machine figure seems to include this,
but the description didn't.

Finally, we have the problem of dropped R2s.  Clearly, just
keeping on sending I2s don't quite work.

Now, what shall we do?

0. Drop the resynch altogether?
1. Keep running this discussion on the mailing list?
2. Form a design team, e.g. for the duration of January,
    with regular telecon meetings, to get this right?
3. Have a volunteer to work out all the transitions in
    the state machine, verify it with a protocol analyser,
    and run it with a crypto protocol analyser to get
    all multiparty attack scenarios considered?

--pekka